Funktioner som returnerar strängar, bra stil?

I ”echo @ratchet_freak i de flesta fall (kanske med en liten tweak för sizeof buffer över 128) men jag vill hoppa in här med ett konstigt svar. Vad sägs om att vara konstig? Varför inte, förutom problemen med att få konstiga blickar från våra kollegor och behöva vara extra övertygande? Och jag erbjuder detta:

// 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; } 

Och exempel på användning:

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); } 

Om du gjorde det på det här sättet kan du göra din fördelare mycket effektiv (effektivare) än malloc både när det gäller allokering / deallokationskostnader och även förbättrad referensplats för minnesåtkomst. och poolminne på ett sekventiellt sätt från stora angränsande block (med det första blocket som inte ens kräver en hög al plats – det kan tilldelas på stacken). Det förenklar felhantering. Och detta kan vara det mest diskutabla men jag tycker att det är praktiskt taget uppenbart när det gäller hur det gör det tydligt för den som ringer att det kommer att allokera minne till den allokerare du skickar in, vilket kräver uttrycklig frigöring (allocator_purge i detta fall) utan att behöva dokumentera sådant beteende i varje enskild funktion om du använder den här stilen konsekvent. Godkännandet av allokeringsparametern gör det förhoppningsvis ganska uppenbart.

Jag vet inte. Jag får motargument här som att implementera den enklast möjliga arenatilldelaren som är möjlig (använd bara maximal anpassning för alla förfrågningar) och att hantera det är för mycket arbete. Min trubbiga tanke är som, vad är vi, Python-programmerare? Kan lika gärna använda Python om så är fallet. Använd Python om dessa detaljer inte spelar någon roll. Jag är seriös. Jag har haft många C-programmeringskollegor som med stor sannolikhet skulle skriva inte bara mer korrekt kod utan möjligen ännu effektivare med Python eftersom de ignorerar saker som referensplats medan de snubblar över buggar som de skapar åt vänster och höger. Jag gör det inte. t se vad det är som är så läskigt med någon enkel arenatilldelare här om vi är C-programmerare som är intresserade av saker som datalokalitet och optimalt instruktionsval, och detta är utan tvekan mycket mindre att tänka på än åtminstone de typer av gränssnitt som kräver uppringare att uttryckligen frigöra varje enskild sak som gränssnittet kan returnera. Det erbjuder bulkdeallocation över individuell deallocation av ett slag som är mer felbenägen. En riktig C-programmerare utmanar loopy-samtal till malloc som jag ser det, särskilt när det visas som en hotspot i deras profil. Från min synpunkt måste det finnas mer ” oomph ” till en motivering för att fortfarande vara C-programmerare 2020, och vi kan ” t skjuter bort saker som minnesallokatorer längre.

Och detta har inte kantfallet att tilldela en buffert med fast storlek där vi tilldelar, säg 256 byte och den resulterande strängen är större. Även om våra funktioner undviker buffertöverskridanden (som med sprintf_s), finns det mer kod för att korrekt återhämta sig från sådana fel som krävs som vi kan utelämna med allokeringsfallet eftersom det inte ”t har dessa kantfall. Vi behöver inte hantera sådana fall i allokeringsfallet, såvida vi inte verkligen tömmer det fysiska adresseringsutrymmet för vår hårdvara (som ovanstående kod hanterar, men det behöver inte hantera ” från förut tilldelad buffert ” separat från ” utan minne ”).