Základné pravidlá pre písanie kódu v C++

Programujem uz nejaký ten mesiac aj niečo v C++ prešiel som naň z vyšších jazykov je to krásny jazyk

Problém je že mi dáva až príliš veľa slobody a ja potom trávim čas voľbou rôznych alternatív, hrajkám sa s tým čo potom vedie k predčasnej optimalizácii. Ono to vyberanie je super a na C++ sa mi páči že môžem vyberať ale toto sa robí pokiaľ už mám appku hotovú a optimalizujem kritické miesta.

Najlepšie je spraviť si prototyp zistiť či to funguje a podľa prototypu návrh a pri tomto návrhu už myslieť na základné optimalizácie.

A potom nakódiť appku a ďalej ju ešte zrýchliť a zoptimalizovať.

Aby som tento proces rozhodovania urýchlil urobil som si sadu pravidiel Chcem sa opýtať skúsenejšúch C++ kóderov či tá sada pravidiel má niečo do seba alebo je to celé nezmysel. Alebo ak s tou sadou nesúhlasíte napíšte či máte inú sadu, alebo ako by ste vylepšili tú moju

A) alokácia pamate

Najdôležitejšie sú prvé dve pravidlá:

1. tam kde sa vo vyšších jazykoch používajú hodnotové typy (čísla, malé stringy, malé kontainery) s krátkou platnosťou budem preferovať alokáciu na stacku
2. tam kde sa vo vyšších jazykoch používajú referenčné typy alebo veľa hodnôt za sebou (velké pole, velké kontainery, velké stringy) alokujem pamať na halde a použijem
a) shared_ptr ak chcem podobné chovanie ako pri referenciách vo vyšších jazykoch (viac pointerov môže ukazovať na rovnaké miesto v pamati)
b) unique_ptr za podmienky že nechcem aby viac premenných odkazovalo na rovnaké miesto v pamati unique_ptr - výhoda je v tom že sa automaticky uvolní pamať ak už nie
je potrebná (ak chcem pointer premiestniť inde použijem std::move)
c) kedy použiť weak_ptr?

Toto je základný kľúč. A potom už len optimalizácie:

3. ak potrebujem veľmi rýchlu pamať alebo objekty kopírovať hodnotou a som si istý že nepotrebujem využívať pokročilé možnosti OOP (prepisovať virtuálne metódy v predkovi) objekt môžem vytvoriť aj na stacku. V takom prípade sa bude kopírovať hodnotou. Práca s objektom vytvoreným na stacku je rýchlejšia zároveň je ale veľkosť stacku obmedzená preto ak tých objektov bude viac alebo budú zaberať veľa miesta je lepšie ich vytvoriť na halde.

4. ak pri objekte uloženom na stacku chcem podobné výhody ako má halda (nechcem nič kopírovať iba ukazovať na miesto) použijem &

B) bezpečnosť
1. preferovať immutablitu - všade kde sa dá používať const aby som mal istotu že neprepíšem niečo čo prepísať nechcem
2. ak viem že z objektu budem dediť tak pri verejných a chránených memberoch používať virtual / override v tom prípade ich ale treba inštanciovať na halde
3. na binárne dáta nepoužívať char* ale vector<char> keďže char* berie \0 ako ukončovací znak
4. referenčná transparentnosť - funkcie by nemali pristupovať k okolitému svetu funkcia dostáva argumenty a z nich vypočíta výsledok ktorý vráti referenciám sa vyhnúť pokiaľ je to možné (a ja nepotrebujem výkon) ak chcem vrátiť viac hodnôt použujem tuple)

- pri návrhu základnej kostry aplikácie treba klásť dôraz na bezpečnosť.
- ak sa ukáže ukáže že je nejaká časť aplikácie pomalá vykašlať sa na bezpečnosť, immutablitu a referenčnú transparentnosť a zoptimalizovať to tak aby to kritické
miesto bolo rýchlejšie a potom túto menej bezpečnú časť appky riadne potestovať
Odstraněn tag code. (karel)