Funksjoner som returnerer strenger, god stil?

Jeg ekko @ratchet_freak i de fleste tilfeller (kanskje med en liten tweak for sizeof buffer over 128) men jeg vil hoppe inn her med et merkelig svar. Hva med å være rar? Hvorfor ikke, i tillegg til problemene med å få rare blikk fra kollegaene våre og måtte være ekstra overbevisende? Og jeg tilbyr dette:

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

Og eksempelbruk:

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

Hvis du gjorde det på denne måten, kan du gjøre tildeleren din veldig effektiv (mer effektiv enn malloc både når det gjelder allokering / deallokasjonskostnader og også forbedret referanselokalitet for minnetilgang. og samle minne på en sekvensiell måte fra store sammenhengende blokker (med den første blokken som ikke engang krever en haug al plassering – den kan tildeles på bunken). Det forenkler feilhåndtering. Også, og dette kan være mest diskutabelt, men jeg tror det er praktisk talt åpenbart når det gjelder hvordan det gjør det klart for innringeren at det kommer til å tildele minne til tildeleren du sender inn, og krever eksplisitt frigjøring (allocator_purge i dette tilfellet) uten å måtte dokumentere slik oppførsel i hver eneste mulige funksjon hvis du bruker denne stilen konsekvent. Aksepteringen av tildelingsparameteren gjør det forhåpentligvis ganske opplagt.

Jeg vet ikke. Jeg får motargumenter her som å implementere en enklest mulig arenaallokering mulig (bare bruk maksimal justering for alle forespørsler) og å takle det er for mye arbeid. Min stumme tanke er som, hva er vi, Python-programmerere? Kan like godt bruke Python i så fall. Bruk Python hvis disse detaljene ikke betyr noe. Jeg er seriøs. Jeg har hatt mange C-programmeringskollegaer som med stor sannsynlighet ville skrive ikke bare mer korrekt kode, men muligens enda mer effektiv med Python, siden de ignorerer ting som referanselokalitet mens de snubler over feil som de skaper til venstre og høyre. Jeg gjør ikke » t se hva det er som er så skummelt med noen enkle arenaallokatorer her hvis vi er C-programmerere som er opptatt av ting som datalokalitet og optimalt instruksjonsvalg, og dette er uten tvil mye mindre å tenke på enn i det minste de typer grensesnitt som krever innringere for å eksplisitt frigjøre hver enkelt ting som grensesnittet kan returnere. En skikkelig C-programmerer utfordrer loopy call til malloc slik jeg ser det, spesielt når det ser ut som et hotspot i profilen deres. Fra mitt ståsted må det være mer » oomph » til en begrunnelse for fortsatt å være C-programmerer i 2020, og vi kan » t viker unna ting som minnefordeler lenger.

Og dette har ikke kant tilfeller av å tildele en buffer i fast størrelse der vi tildeler, for eksempel, 256 byte og den resulterende strengen er større. Selv om funksjonene våre unngår bufferoverskridelser (som med sprintf_s), er det mer kode for å gjenopprette riktig fra slike feil som kreves, som vi kan utelate med tildelersaken, siden den ikke «t har disse kanttilfellene. Vi trenger ikke å håndtere slike saker i tildelingssaken, med mindre vi virkelig bruker det fysiske adresseringsområdet til maskinvaren vår (som koden ovenfor håndterer, men den trenger ikke å håndtere » ut av forhåndsallokert buffer » separat fra » uten minne «).