No, neco to do sebe ma, ale ja na to nahlizim trochu jinak - nejdriv to naprogramuju tak, abych se v tom vyznal i po letech, bylo to prehledne, bezpecne a fungovalo to spravne.

Potom zkusim, jak rychle/velke/nenazrane to je a jestli je to vubec problem. Pokud ano, tak otestuju, kde to nejvic drhne a tam to zacnu zlepsovat. Pokud to zlepseni nestaci, vyprofiluju nove uzke hrdlo a optimalizuju tam ... dokud to neni dost dokonale, nebo dokud me to bavi. Je vyrazny rozdil usetrit par sekund v setupu, ktery probehne jen jednou a usetrit par milisekund ve smycce, kterou to probehne milionkrat (asi tak tisicinasobny ).

Naopak pokud to nechodi spravne a bezpecne, tak je zrychlovani na nic (jako cely program v tu chvili), takze ma pro me ta spravnost a bezpecnost vyrazne vyssi vyznam, nez rychlost a velikost. (A to i na embeded mikroprocesorech, kde se bavime o desitkach kB na program a jednotkach kB na data - i tam velikost resim az kdyz musim a pokud je to vyrazne driv, nez to je funkci, tak je to znameni, ze na to jdu spatne, mam to psat a ladit po mensich castech a eventualne to i rozhodit mezi vic pocitacu, nebo pouzit zcela jiny pristup)

Co se haldy a stacku tyce, tak stack pouzivam pro promenne lokalni, haldu pro promenne sdilene z vic mist (ono se to beztak bere z jedne pameti, akorat z jine strany a de/alokace na halde je pomalejsi a muze delat problemy s fragmentaci pameti) - i kdyz ono to dost casto vychazi podobne jako ta tvoje pravidla, jen k tomu vede jina filosofie.

Ad 4. naprosto OK reseni, pokud se ti podari ZAJISTIT (z principu veci), ze se o ten objekt prestanou zajimat vsichni ostatni driv, nez skonci funkce, ktera ho na stacku vytvorila - v opacnem pripade ti ho proste bestialne uvolni a to misto budou pouzivat jine funkce (ci halda), psat tam ruzne jine veci a kazde pouziti takovehoto objektu jednak muze vracet/pouzivat spatne a principialne i nesmyslne hodnoty, jednak ti muze zbortit prakticky cokoli kdekoli, vcetne navratovych adres funkci - coz je oboji peklo na koleckach nejak odchytat a opravovat, protoze se to chova, jak se tomu zrovna zlibi (a na potvoru to muze fungovat zakerne spravne i pri ruznych testech - nez se to rozhodne fungovat jinak).
Ovsem ZAJISTIT to nemusi byt trivialni (ci mozne) a alokace na halde je pak jistejsi reseni. (Ale ono s zivotem objektu je stejne potreba VZDY zachazet opatrne a s rozvahou.)

B) 2. pro instance na halde/zasobniku/staticke plati stejna pravidla jako pro 4. - tedy muze to byt i na stacku, pokud ZAJISTIS, ze se to bude pouzivat spravne.

B) 3. char* nebere nic nijak - je to proste ukazatel na znak (ale v tvem pripade je mnohem lepsi pouzivat neco jako uint8_t* nebo jaky binarni format tam mas ulozeny), co se zajima o \0 jsou funkce pro praci s retezci (ktere bys na neretezce pouzivat prave kvuli tomu nemel, na to jsou funkce jine)

B) 4. vykaslat se na bezpecnost je az ta zcela posledni zoufala moznost a i tak to znamena, ze to mas resit jinak. Casto jde najit i jine reseni, ktere zajisti bezpecnost uz pred kritickou casti a pak se da ta kriticka optimalizovat mnohem lepe (myslim bezpecnost proti vnejsimu utoku - bezpecnost proti chybe programatora je neco zcela jineho). Pripomel bych zde Asimova, kde se v jedne povidce problem se tremi robotickymi zakony (ktere vyzaduji velky a slozity pozitronicky mozek) vyresi tim, ze se problem predefinuje tak, aby je reseni NEMOHLO porusit, ani kdyz o nich samo nevi - robot tak uzce zamereny, ze dela jen jednu vec a tu dela spravne nemusi poslouchat prikazy cloveka, nebot neni co by mu bylo mozno rozumne prikazovat atd. ... takze pro kriticke (nejen) casti pouzij stare zname osvedcene "rozdel a panuj" na tak male casti, ze bezpecnost pujde zajistit trivialne a nebudes mit s ni problemy.

Dobre testy jsou fajn (opravdu velice moc fajn, minimalne ti zajisti vetsi klid pri vetsich {o/u}pravach, ze ti nejaka zmena nerozbila neco v jine vzdalene casti), ale az na vyjimky se jimi neda pokryt vsechno, takze bezpecnost a spravnost je potreba resit uz pri navrhu a programovani, testy velice snadno neco zasadniho "prehlednou".

A rozhodne je dobre, ze se takovymahle vecma zabyvas. I kdybys dospel k ne zcela dokonalemu reseni, bude to vzdy vyrazne lepsi, nez to nechat plavat.

A jeste jednou duraznim, ze povazuju prehlednost a citelnost za NAPROSTO ZASADNI, zejmena v oblastech, kde musis tezce optimalizovat. Komentare a uhledny kod nestoji zadny vykon a zadne misto v pameti (a zdrojak, ktery by se ti nevesel na soucasne disky nemas jak rozumne napsat) a pomoci nich se da udelat rozumne citelny i samomodifikujici se kod v assembleru, kde se pouziva treba i skakani doprostred instrukci (coz je temna magie, kterou ted ROZHODNE NECHCES zkouset).

Rozdeleni projektu na vic casti vyrazne pomaha, stejne jako foldovani - zlate pravidlo je, ze bys nemel pokud mozno nikdy pracovat na casti vyrazne vetsi, nez se ti vejde na jednu obrazovku

A jako samozrejmost beru vydatne pouzivani verzovaciho systemu (ja pouzivam (a povazuju za nejlepsi) GIT, ale jsou i jine a rozhodne lepsi nejaky, nez zadny). Diky nemu nemam problem delat i brutalni prestavby, zkouset divoke napady a testovat zbesile hypotezy - klidne muzu jit i nekolika smery naraz s vedomim toho, ze se muzu kdykoli vratit k cemukoli funkcnimu, nebo naopak klidne nekdy v budoucnu uspesne cesty zase pospojovat, nebo z nich vybrat jen to, co je na nich dobre. Zalozeni nove vetve nestoji nic (zlomek sekundy a soubor o delce par znaku) a svoboda, kterou to poskytuje je uzasna. (Pokud to snad jeste nedelas, tak zacni hned, investovana prace i cas se ti velice rychle vrati)

A samozrejme kommituju zmeny velice casto, kdykoli neco chodi, kdykoli narazim na chybu ci problem, kdykooli odchazim od pocitace na vic nez par minut (napr. na obed) a kdykoli me napadne. Pokud dojdu rozumneho vysledku, neni problem shrnout celou vetev do jednoho (ci vice) uceleneho kommitu, ktery vypada, ze jsem byl osvicen zhury a napsal danou cast na prvni pokus zcela bez chyb - a nasledne tu vetev zahodit. Pokud naopak rozbiju neco, co uz chodilo, tak se par disekcema dostanu presne na misto, ve kterem ta chyba vznikla a kdyz ty zmeny jsou jen par radku, tak neni problem chybu najit a odstranit. (dnes treba na jedne z veci, co jsem delal 13 verzi behem hodiny a pul, tedy v prumeru kazdych 7 minut, vcetne kompletniho releasu, instalace a testu - proste pohoda)

(BTW: vetsina z vyse napsaneho se vztahuje na vsechny jazyky a prostredi)