Funkciók visszatérő húrok, jó stílus?

A legtöbb esetben visszhangozom @ratchet_freak (lehet, hogy sizeof buffer felett 128) de furcsa válaszokkal szeretnék ide beugrani. Mi lenne, ha furcsa lennék? Miért ne, azon túl, hogy kollégáink furcsa pillantásokat kapnak, és külön meggyőzőnek kell lennünk? És ezt ajánlom:

// Note allocator parameter. char* mytype_to_string(allocator* alloc, const mytype_t* t) { char* buf = allocate(alloc, however_much_you_need); // fill out buf based on "t" contents return buf; } 

És példa a használatra:

void func(my_type a, my_type b) { allocator alloc = allocator_new(); const char* str1 = mytype_to_string(&alloc, &a); if (!str1) goto oom; const char* str2 = mytype_to_string(&alloc, &b); if (!str2) goto oom // do something with str1 and str2 goto finish; oom: errno = ENOMEM; finish: // Frees all memory allocated through `alloc`. allocator_purge(&alloc); } 

Ha így csinálta, nagyon hatékonyá (hatékonyabbá) teheti az elosztót mint malloc mind a kiosztási / elosztási költségek, mind pedig a memória-hozzáférés javított referencia-helyének szempontjából. Ez lehet egy aréna-elosztó, amely csak egy mutató növelésével jár a kiosztási kérelmek általános eseteiben és a memóriát szekvenciálisan összegyűjti nagy összefüggő blokkokból (az első blokkhoz nem is szükséges halom hely – a veremhez rendelhető). Ez leegyszerűsíti a hibakezelést. Szintén ez lehet a legvitatottabb, de azt gondolom, hogy ez gyakorlatilag teljesen nyilvánvaló abban a tekintetben, hogy világossá teszi a hívó számára, hogy memóriát fog lefoglalni az általad átadott allokátornak, és kifejezett felszabadítást igényel (allocator_purge ebben az esetben) anélkül, hogy ezt a viselkedést minden lehetséges függvényben dokumentálnia kellene, ha ezt a stílust következetesen használja. A lefoglaló paraméter elfogadása remélhetőleg meglehetősen nyilvánvalóvá teszi.

Nem tudom. Itt olyan ellenérveket kapok, mint a lehető legegyszerűbb arénaallokátor megvalósítása (csak az összes kéréshez használja a maximális igazítást), és ezzel foglalkozni túl sok munka. Tompa gondolatom az, hogy mi vagyunk mi, Python programozók? Használhatja a Pythont is, ha igen. Kérjük, használja a Pythont, ha ezek a részletek nem számítanak. Komolyan beszélek. Sok olyan C programozó kollégám volt, akik nagy valószínűséggel nemcsak helyes kódot, de esetleg még hatékonyabban is írnának a Pythonnal, mivel figyelmen kívül hagyják az olyan dolgokat, mint a referencia helye, miközben balra és jobbra létrehozott hibákba botlanak. Nem látom, mi van olyan ijesztő néhány egyszerű arénaallokátorral kapcsolatban, ha C programozók vagyunk, akik olyan dolgokkal foglalkoznak, mint az adat lokalitása és az optimális utasításválasztás, és erre vitathatatlanul sokkal kevesebb a gondolkodás, mint legalábbis az olyan típusú interfészekre, amelyek megkövetelik hívók, hogy kifejezetten felszabadítsanak minden egyes olyan dolgot, amelyet a kezelőfelület visszaadhat. Tömeges elosztást kínál az olyan típusú egyedi elosztásokkal szemben, amelyek hajlamosabbak hibázni. Egy megfelelő C programozó kihívást jelent a malloc számára, ahogy látom, főleg, ha hotspotként jelenik meg a profiljukban. Az én álláspontom szerint több ” oomph ” kell, hogy legyen indoklása, hogy 2020-ban továbbra is C programozó lehessünk, és megtehetjük ” ne zárkózzon el többé olyan dolgoktól, mint a memóriafoglalók.

És ennek nincsenek olyan éles esetei, hogy fix méretű puffert allokálunk, ahol mondjuk 256 bájtot osztunk ki, és az így kapott karakterlánc nagyobb. Még akkor is, ha függvényeink elkerülik a puffer túllépését (például sprintf_s esetén), még több kód van helyreállítva az ilyen hibáktól, amelyek szükségesek, amelyeket elhagyhatunk az allokátor esettel, mivel nem “nincsenek ilyen éles esetek. Az ilyen esetekkel nem kell foglalkoznunk az allokátor esetében, hacsak nem merítjük ki igazán hardverünk fizikai címzési terét (amelyet a fenti kód kezel, de nem kell ezzel foglalkoznunk ” az előre lefoglalt pufferből ” külön a ” memóriából “).