miért szar a C-ben az a pár elágazás, az miért pazarlás és miért jó ez a sokkal bonyolultabb hibakezelési mechanizmus C++-ban?
Szerintem ez nem a velem való vitában jött elő, legalábbis én nem mondtam ilyesmit.
Egyértelmű a C++ előnye, ha időre mész, de ha teljesítményre, vagy sebességre?
Ha most konkrétan ezt az out of mem-es példát nézzük, akkor egyértelmű a C++ előnye nem csak programozási időben, hanem teljesítményt nézve is. Leírtam már, de leírom még egyszer: ha nincs exception, akkor a kódod nem fut rá semmiféle ellenőrzésre. Amíg nincs exception, addig a C++-os verzió gyorsabban fog futni, mint a C-s verzió, mivel a C-s verzió ugye állandóan ellenőrizgeti a malloc() visszatérési értékét. És ebben az esetben mondjuk az exception-nak az overheadje, mikor ténylegesen eldobódik, valszeg senkit se érdekel, mivel az out of mem kezelése sokkal több időt fog elvinni.
C-ben ha OOP módon programozok, akkor van egy
struct-om, meg egy raklap függvényem, ami azon operál. Itt a "konstruktor" kimerül egymalloc()-ban és annak lekezelésében, ami itt egy darabif, C++-ban meg az van, amit leírtál és gondolom, maguk az OOP részek sem sima struct-okra fordulnak le, hanem ott is lesz mindenféle referenciatáblázattól elkezdve minden egyéb adat és láthatatlan segédrutin is.
Hát, ezt nem igazán mondanám. Ha almát az almával hasonlítasz, akkor nem igazán van a C++-nak olyan overheadje, amire utalsz. Ha C-ben csak struct-od van, akkor C++-ban is használj csak struct-ot. Ha C-ben írsz valami fv-t, ami inicializálja a malloc() által visszaadott memóriaterületet, akkor C++-ban ctor-t írsz. És kb. tökugyanaz lesz belőle, nincs overhead. Ha C-ben fv pointerekkel csinálsz polymorphizmust, akkor C++-ban virtuális fv-t használsz, ami belül ugyanúgy fv pointer lesz, stb. Általánosságban elmondható magáról a nyelvről, kevés olyan dolog van benne, aminek olyan komoly overheadje van, ami mondjuk C-ben nem lenne, ha kézzel implementálod le. Nyilván lehetnek meglepő dolgok bizonyos esetekben, hogy a C++ fordító valamiből miért csinál valami olyasmit, amit nem vársz tőle, de némi tapasztalattal ezeket el lehet kerülni. Ill., persze, van pár olyan dolog sajnos, aminek van overheadje a "kényelem", vagy éppen egy rosszul megdesignolt ABI miatt. A C++ baromi bonyolult nyelv, nagyon sok idő kell hozzá, mire rendesen megtanulja az ember. A C-t sokkal könnyebb megtanulni. Szóval komoly befeketetést igényel, megértem, hogy sokan nem szeretik, feleslegesen bonyolultnak tartják (ennek egy része igaz is mondjuk). De ha megtanultad, akkor kapsz egy sokkal jobb eszközt, mint a C.
Inkább amúgy azzal van gond néha, hogy a C++-os alap megoldás nem annyira flexibilis, mint kéne. Pl., ha saját C-s OOP-d van, akkor ott azzal azt csinálsz, amit akarsz, úgy designolod meg, ahogy az neked jó. Ha a C++-os virtuális fv-es megoldást alkalmazod, akkor ott megvan, hogy az mit tud, és kész, nem tudod kibővíteni a designját. Hogy egy példát hozzak: 1-2x előfordult már, hogy tök jó lett volna 1-2 virtuális fv-nek a címét átírni az objectben, hogy későbbiekben másképp viselkedjen. Ezt C++-ban, 1-2 speckó esetet kivéve nem lehet megcsinálni. De ha a saját OOP-det úgy designolod meg, hogy minden objectben ott vannak a fv pointerek (tehát nem csak 1 ptr van a virtuális táblára), akkor ott azokkal a pointerekkel azt csinálsz, amit akarsz. Flexibilisebb. Csak ugye azon az áron, hogy több dolgot kell kézzel megcsinálni.
A C egyértelműen kevesebb és gyorsabb kódot fog adni.
Nem, ahogy már utaltam rá. Ha sok exceptiont dobálsz, akkor igen, lassabb lesz mint az `if`-es megoldás. De ha kevés exception dobás van, akkor gyorsabb lehet. Meg, senki se kötelez rá, hogy exceptiont dobálj. Ha neked az nem tetszik, akkor kezeld a hibákat ugyanúgy, ahogy C-ben, a dolog megengedett. Linusnak is ez volt az egyik érve a C++ ellen, hogy az exceptionnak egy csomó minden hátránya van. Igen, ez igaz. Akkor nem kell használni, ennyi. De mondjuk bizonyos dolgokra még akkor is megéri használni. Pl., out of mem-re, vagy más rendkívül váratlan eseményre szerintem az ideális megoldás. A C++ ad egy nagyon nagy eszközkészletet a C-re építve, a programozóra van bízva, hogy ezek közül melyikeket használja.
Látom, de ez a megoldás 64-bites CPU-t igényel.
Igen, de szerintem nem ez a lényeg. Arról beszéltem, hogy a fordítók esetenként még tudnak nagyon szuboptimális kódot generálni, és hoztam rá egy aktuális példát.