> Ugye konkrétan a mátrix szorzásra reagáltál úgy, hogy ott az operator[]-hoz végülis mehet az ellenőrzés, mivel csak "egy elágazás". Nyilván az operator[] az inline lesz, függetlenül attól, hogy van-e benne ellenőrzés vagy nincs (ha performace-ra megyünk). Szerintem viszont hiba indexellenőrzést tenni bele (arról nem is beszélve, hogy mátrix szorzásnál legalább 2 index operator kell - a 2 mátrixból egy-egy - és utána lesz 1 szorzás+összeadás, ami 1 instruction manapság, pár órajel. Ebben az esetben simán lehet, hogy 2x-es lassulást okoz a felesleges ellenőrzés).
A mátrixnál már más is mondta, hogy okozhat optim problémát, én meg mondtam, hogy akkor ez specifikus eset, amihez specifikus megoldás kell. Egy ciklus belsejében nyilván nincs értelme újraellenőrizgetni a dolgot. Nem is mondtam ilyet, olyat meg pláne nem, hogy kőbe vannak vésve a validálási pontok, ez ilyen ökölszabály, hogy a bemenetet illik leellenőrizni.
> Hát, a libc dolog az érdekes. Őszintén szólva én egyetértek azzal, hogy ne ellenőrizzen. A libc-nek ez a része, ami itt felmerült (stringek, memcpy), igaziból nem egy API, hanem inkább utility fv-ek. Ha valaki szeretné, simán csinálhat wrapper fv-eket ezek köré, amik csekkolják a NULL-t. Engem zavarna, ha tudnám, hogy én mindig nem-NULL paraméterrel hívom az adott fv-t, de az belül még csekkolja. Illetve, nem csak hogy zavarna, hanem lassabb futást is eredményezne.
Ezt is javasolták már feljebb, a safe-wrappert, én meg erre mondtam, hogy ez a fajta ellenőrzés, hogy plusz egy nested-függvényhívás, ez sokkal súlyosabb overhead lesz, mint az egy darab elágazás a függvényen belül.
> Nem feltétlenül a plusz elágazás miatt a memcpy()-ben (és társaiban), hanem amiatt, hogy emiatt a fordító kevésbé tud optimalizálni, ha a memcpy() több garanciát ad. Hogy miért? A gyakran használt ilyesmi fv-eket a fordító kioptimalizálja, ha tudja. Pl., ha lehet tudni a memcpy-nél a másolandó blokk méretét fordítási időben, és az nem túl nagy, akkor odatesz pár load/store instructiont a memcpy helyett. Ha még NULL-ra is csekkolnia kellene, az jelentősen lassítana.
Ennyi erővel azt is csinálhatná a fordító, amit fentebb asch javasolt, hogy ha látja, hogy "kint" leellenőrizték a hívás előtt, akkor belülről kidobja az ellenőrzést. Mert mi van, ha nem ellenőrizték le? Akkor jönnek a crash-ek, meg a sechole-ok.
> Nem beszélve arról, hogyha ezekbe hibakezelést akarunk tenni, akkor (hogy értelme is legyen) minden ilyen fv-nek kéne hibát visszaadnia, és azt le is kellene kezelni. Ez eléggé megdobná a program méretét, és nehezebben átláthatóvá tenné a (felesleges) hibakezelésével.
Most komolyan pár if, meg return miatti plusz kB-okon akadunk fent, miközben több GB-os "framework"-ökre épül szinte az egész szoftvervilág? :(
> Ki az, aki minden memcpy/stb. után vizsgálni akarja a visszatérési értékét, hogy minden rendben ment-e?
Én. Nekem valami defektus miatt a mániám, hogy ha egy függvény visszaadhat valamilyen hibakódot, akkor azt lekezelem. Talán az agyamra ment ifjú koromban a windóz azzal, hogy nem tudjuk milyen hiba történt, de rászívtál, büdös júzer...
Sz*rk.: Itt mondjuk te is hasonlókat írtál két éve:
Szerintem ugyanazt mondjuk. Én csak azt mondom, hogy a "csak ha tudsz hozzáadni plusz infot" általában fent áll. Ha nem teszi meg a programozó, akkor lusta, és ennek az az eredménye az esetek egy részében, hogy rossz minőségű hibaüzenetet kap a user (vagy kerül a logba). Vagy épp az, hogy a hibát le lehetne kezelni normálisan, és nem a usernek kellene újra megpróbálnia.Szerintem mindenki látott már "Hiba történt, próbáld újra" jellegű hibaüzenetet. Kb. ez az eredménye annak, ha vki a kód tetején kapja el az exceptiont.
Most akkor miről vitatkozunk?
> Sajnos a C nyelv ilyen lett, már régen abba kellett volna hagyni a használatát, és áttérni C++-ra, vagy (ha az elmúlt 10 évet nézem) valami még modernebbre, ami tud garanciát adni az ilyen memóriafelülírós dolgokra. A C++-t azért említem, mert pár szabály betartásával simán lehet olyan kódot írni, ami védett az ilyen jellegű hibák ellen. Nyilván ez a C-re is igaz, de akkor már nagyon kényelmetlen lenne használni.
C vs. C++ vitába nem szeretnék belemenni (szerintem nem is ugyanarra való a két nyelv), viszont azt azért ideírnám, hogy sérülékeny, vagy összeomlós kódot bármiben lehet írni (pont, mint FORTRAN kódot); a hülye programozó ellen a C++ sem véd. Azt viszont valahogy nem nagyon tudom értelmezni, hogy össznépileg megszavazzuk, hogy validálni nem kell, aztán meg a C rossz, mert segfault és buffer overflow...