( TCH | 2020. 09. 27., v – 20:19 )

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

Ja ok, bocsi, nem volt egyértelmű.

> 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.

Teljeskörű szabály nincs, de az garantáltan rossz hozzáállás, hogy semmit sem validálunk (nem, nem te mondtad).

> 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).

Természetesen csak akkor ellenőrzök az összeadás előtt, ha szükséges. Bár többnyire inkább a végeredményt ellenőrzöm le, hogy jó-e, pl. tömbindexnél.

> É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.

A végére csak konszenzusra jutunk.

> 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.

"Ha valami esetleg kell", csak ha nem használsz semmit a C++-ból, akkor az C kód lesz.

> 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.

Nem az, hogy "nem jó", hanem, hogy értelmetlen. Pl. - mondok egy primitív példát - van egy baromi egyszerű mikrokontrolleres környezeted, ami kb. abból áll, hogy van mondjuk kemény 4 db memóriacímed, amiről különféle szenzorértékeket, ill. I/O lábak szintjeit tudod beolvasni és van 8 másik memóriacímed, amikre 7 szegmenses kijelzők vannak aggatva, amiken a bejövő vackokat kijelzed. Itt gyakorlatilag semmi mást nem csinálsz, mint memóriacímeket piszkálsz, bitmaszkolsz, meg számolgatsz. Ezt persze akár assemblyben is meg lehetne írni, de akkor írhatod újra, ha mondjuk "fent" úgy döntenek, hogy architektúra csere van, viszont a feladat maga semmilyen szinten (sem sebességileg, sem méretileg) nem igényli, hogy assemblyben írd meg. És légy szíves ne írd azt, hogy ezt te inkább bedrótozod valami chipbe, mert nem ez volt a lényeg. :P Amire ki akarok lyukadni, hogy van olyan környezet és olyan feladat, ahol a C++ nem az, hogy nem jó, hanem egyszerűen értelmetlen, mert nincs amit használj belőle; ha abban is írod meg a kódodat, az tkp. C kód lesz.