( geza42 | 2020. 09. 26., szo – 21:08 )

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

 

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

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. Ki az, aki minden memcpy/stb. után vizsgálni akarja a visszatérési értékét, hogy minden rendben ment-e?

 

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.