hogy miért rossz és pazarlás C-ben az a pár elágazásnyi védelem, amikor a C++ egy nagyságrenddel bonyolultabb hibakezelést valósít meg?
Én nem mondtam ilyet sehol, hogy rossz és pazarlás. Miből gondolod, hogy erről ez a véleményem? Mert amúgy nem ez... Hiába dumálok itt mondjuk exceptionokról amúgy, a saját hobbi dolgaimban én se használom, a sima visszatéréses megoldást jobban szeretem. Bár az out of mem kezelése mondjuk kivétel lenne, ott használnám az exceptionokat, ha érdekelne az out of mem. De nem érdekel :)
Honnan tudja a C++, hogy mikor van a kód bizonyos pontjain exception miatti kilépés? Ezt hogy állapítja meg, ahhoz nem kell vizsgálat?
Írtam már, de akkor úgy látszik az info áramlás nem a legjobb, vagy rosszul írtam le :) A throw csinálja. Mikor valahol meghívódik egy throw, akkor ő intézi az egészet. Szóval nem az van, hogyha throw van, akkor visszatér a fv "rendesen", csak valahova odaírja, hogy "exception volt", amit a hívó fél csekkol. Nincs semmiféle ilyesmi. Hanem az van, hogy a throw (ott, ahol az exception dobódik) keresi ki a táblázatból, hogy mit kell csinálnia. Felmászik a stack-en, exception handlert keres, közben meghívja a kilépett fv-ek dtor-át. Gyakorlatilag a throw-ból lesz egy goto, ami "kapásból" ráugrik a handlerre. Remélem így már világos. Szóval pl. tudnia kell arról, hogy hogyan kell a stack-en végigmászni. Ehhez a fordító csinál neki infot az ELF-be, ha jól emlékszek az .eh_frame section való erre. Meg tudnia kell, hogy a kód egy adott pontján melyik objectek élnek, hogy meg tudja hívni a dtor-okat. Ezeket mind el kell tennie táblázatba. És igen amúgy, emiatt a bináris mérete nagyobb lesz. De a bináris mérete attól is nagyobb lenne, ha ugyanezt a funkcionalitást te kézzel kódolod le. Az összes malloc() utáni ellenőrzés sincs ingyen, ill. az összes cleanup kód se. Még az is előfordulhat, hogy az exceptionos megoldás a kisebb (mivel eléggé kompakt formában tárolja a táblázatot). Bár mondjuk azért meglepődnék rajta :)
de itt az volt a kérdés, hogy a C++-os megközelítéssel lesz az extra mechanizmusok miatt extra kód és extra idő is.
Ha mondasz konkrét példát, akkor lehet tudok rá mondani valamit, de így... Milyen extra mechanizmusok? Épp ezt mondom, hogy szerintem ez egy rossz beidegződés, hogy a C++ "biztos odatesz felesleges, extra dolgokat". Általában nem tesz, mert nincs rá oka. Ha a C-vel analog dolgot valósítod meg, akkor nem lesznek felesleges dolgok. Persze lehet, hogy vannak kivételek, de általában ez igaz.
Félreérted, én nem vagyok C++ hater
Szerintem nem is mondtam ilyet. Meg amúgy nem is gondoltam.
Azt vitatom, hogy a C-nek ne lenne előnye. Hordozhatóság, többnyire sebesség és méret
Meg azt se mondtam, hogy a C-nek ne lehetne előnye. A hordozhatóság egyértelműen előnye, mert a legtöbb mindenre megvan. Bár így 2021-ben szerintem ez már nem akkora dolog mondjuk a C++-szal szemben, de valami különbség azért biztosan van. A sebességgel és mérettel viszont (szokás szerint) nem értek egyet. Rajtad, a programozón múlik, hogy hogyan használod. Nem a nyelv fogja meghatározni, hogy milyen sebességgel fog menni, ill., hogy mekkora lesz a kód. Hanem te, hogy a rendelkezésre álló eszközök közül melyikeket használod. Nem minden használt eszköznek van overheadje. Sőt, inkább az ellenkezője igaz, ugye az a mondás, hogy "pay what you use". Ami a core language-re igaz is szerintem nagy vonalakban. A standard library-re már kevésbé.
Oké, de akkor megint ott vagyunk, mint korábban már sokszor, hogy akkor C kódot írtunk, nem C++ kódot.
Mert attól még, hogy 1-2 feature-re nemet mondasz, még használhatod a maradékot. Nem lesz még belőle C kód. De mindegy, túlragoztuk a témát szerintem.
Félreérted: értettem én, hogy mire adtad a példát, csak engem ettől függetlenül is érdekelne az optimális megoldás.
Ezt nem annyira értem. 64-bites fordításnál egyik fordító se hozott optimális megoldást, viszont ha odatettem kézzel a memcmp-t, akkor már mindegyik kihozta az optimális megoldást, amit mutattam. Az az optimális megoldás. Ha arra gondolsz, hogy mi az a megoldás, ami minden esetben optimális (32 és 64 biten is), olyan valszeg erre a problémára éppen most nincs. Hacsak oda nem teszel egy #ifdef-et. Pont ez a baj, hogy még mindig nem lehet megbízni a fordítókban, és még mindig az asm-et kell lesni, hogy vajon mit ront el, és utána vajon hogyan lehet rávenni arra, hogy mégis legyen szíves valamennyire optimális kódot kipréselni magából. Ami akkor tud nagy örömet okozni, ha mindezt mondjuk 3 fordítóval is el kell játszani.