( geza42 | 2020. 09. 27., v – 17:16 )

a valami_safe() függvénybe az egész valami_unsafe() inline-olódik a binárisban? 

Nem, arra gondoltam, hogy a valami_safe inline-oldódik be.

Akkor már nem célszerűbb ezt makróval kikapcsolhatóvá tenni?

De igen, nekem ilyesmi a koncepcióm. Annyi különbséggel, hogy a programozási hibák okozzanak megállást a programban, és ne hibakódot adjanak vissza (most ugye debug mode-ról beszélünk). Szóval az assert-et javaslom az ilyen helyzetekre az "#ifdef ... return 1; #endif" helyett. De nyilván ez se teljeskörű szabály, amit mindig mindenhol alkalmazni kell.

 

Hát ez az, hogy "elviekben". Honnan tudjuk, hogy ez a gyakorlatban is fennáll?

Nyilván mindenki máshol húzhatja meg ezt a határt. Pl., ellenőrzöd-e minden összeadás előtt, hogy az eredmény belefér? Nyilván nem (pedig "signed int" esetén ez a C szabvány szerint ez undefined behavior, és "unsigned int" esetén is az overflow csúnya dolgokat tud csinálni). Én nagyon gyakran használom az assertet, ezzel ellenőrzöm a dolgokat. Van olyan software, amit így is hagyok, assertek maradnak benne (mert nem számít a performance, se az, ha esetlegesen elszáll a program. Viszont az igen, hogy a program helyes outputot adjon). De általában release-re kiszedem belőlük (egy alapos tesztelés után). Ezt pl. csak azért mondtam el, mert nekem van memcpy wrapperem, amiben van assert a NULL-ra (és arra vonatkozóan is, hogy nincs overlap). Debug-ban ott a csekk, release-ben pedig minden fut szépen gyorsan.

 

De ezt én nem is vitattam, már mondtam, hogy ez ökölszabály, nem szentírás. Ha nincs mit validálni, akkor nincs mit, de ahhoz elég sok feltételnek együtt kell állnia.

Még 1x: ez nem mindenkinek ökölszabály, és bizonyos esetekben kifejezetten káros. Egy project dönthet úgy, hogy ezt követi, lelke rajta, és utána esetlegesen egy profile-olás után kiszedheti a felesleges csekkolásokat (ha számít egyáltalán a performance). De az is lehet ökölszabály, hogy az interface-en lévő fv-ek ellenőrzik a paramétereket, az alattuk lévők pedig nem. Ez egy másik ökölszabály, ami más, mint amit te mondasz. De ezt már 1x leírtam, szóval ezen se akarok tovább rugózni.

 

A C-vel kapcsolatban pedig csak annyit, hogy "hordozható assembly"-nek is C++-t használnék. Nincs semmi okom arra, hogy leragadjak a C-nél. Meg tudok mindent valósítani C++-ban, amit C-ben meg tudok, kb. ugyanúgy? Igen. Viszont ha valami esetleg kell a C++-ból, akkor az is ott van. Szóval tényleg nem látom, hogy mi a létjogosultsága C-nek azóta, amióta van C++. De nyitott vagyok amúgy mondjuk egy példára, ahol az látszik, hogy igen, itt C fordítót jó használni egy adott feladatra (és a C++ nem jó), mert valamiért. Ha már csak azt az egy dolgot veszem, hogy std::array-t használnék a sima C tömb helyett (ami elkaphatja az index túlcímzést debug mode-ban), már megéri, hogy C++-t használjak (még ha amúgy full C jellegű kódot írok, akkor is).

 

De mind1, szerintem kissé elkanyarodtunk a témától. Én csak annyit szerettem volna megjegyezni, hogy performance és átláthatósági okokból nem tudok egyetérteni a "fv ellenőrizze le a paramétereket" ökölszabállyal: ez sok esetben ez nem jó szabály.