> Jó, mind1, nem akarok ezen tovább rugózni amúgy, kb. megbeszéltük.
Szerintem sincs értelme ezt a részt tovább ragozni, már csak azért sem, mert C-ben ezt a hibát el sem követheti az ember, hiszen ott nincs operator overload.
> Ha csak egy plusz elágazásról beszélünk, akkor az be tud inline-olódni (annak minden hátrányával együtt), szóval súlyos overheadnek azért nem mondanám. Ill., nyilván csak akkor van értelme azt a verziót meghívni, ha nem tudjuk kizárni, hogy fennállhat a hiba lehetősége. Persze ezzel visszajuthatunk az elejére, hogy mikor melyik verziót kell használni, és ha a hibakezelés nélküli verziót használjuk, akkor ott a baj.
Mármint, hogy
int valami_unsafe(void *x)
{
// mittudomen
return 0;
}
int valami_safe(void *x)
{
if (x == NULL)
{
return 1;
}
return valami_unsafe(x);
}felállás esetén a valami_safe() függvénybe az egész valami_unsafe() inline-olódik a binárisban? Akkor azzal duplikáltad az egész függvény kódját a binárisban - már ha feltételezzük, hogy mind a kettőre szükség van - ami egy idő után nagyon sokra fog rúgni. Persze, ha az unsafe verziót nem hívjuk meg sehol, akkor az nem kerül külön bele, de akkor meg a végén - a binárisban - ugyanazt kaptad, mint ha csak simán lett volna egy elágazásod, hiszen a call-t inline-osította. Akkor már nem célszerűbb ezt makróval kikapcsolhatóvá tenni?
int valami(void *x)
{
#ifndef VALAMI_RELEASE
if (x == NULL)
{
return 1;
}
#endif
// mittudomen
return 0;
}> "Igen, csinálják is a fordítók szerencsére ezt, ha inline az ellenőrzés kódja, vagy link time optimizationnal van fordítva. Persze ez még messze nem tökéletes, mert sokszor nem tudnak rájönni a felesleges ellenőrzésekre."
Akkor itt is kb. a makrós kapcsolgatás volna inkább célszerűbb, nem?
> Itt most arról az esetről beszélünk, hogy a hiba "elviekben" nem történhet meg, mert az programozó hibát jelent. Tehát, ha egy memcpy-t tutira nem NULL paraméterekkel hívom meg, akkor nem akarok hibakezelést se tenni a hívás után, mivel tudom, hogy soha nem fog rámenni a futás. Ergo nem is akarok lekezelni egy ilyen hibát.
Hát ez az, hogy "elviekben". Honnan tudjuk, hogy ez a gyakorlatban is fennáll?
> Nem arról van szó, hogy összességében sehol se kell validálni, hanem arról, hogy az a szabály, hogy "a fv elején mindig validáljuk a paramétereket" nem feltétlenül állja meg a helyét.
De ezt én nem is vitattam, már mondtam, hogy ez ökölszabály, nem szentírás. Ha nincs mit validálni, akkor nincs mit, de ahhoz elég sok feltételnek együtt kell állnia.
> A C pedig igenis egy rossz programozási nyelv így 2020-ban.
Mire rossz nyelv a C? Mire jobbak a többiek? Alacsonyszintű fejlesztésre, "hordozható assembly"-nek? Vagy alkalmazásfejlesztésre? Az előbbit csak C-ben csinálnám, az utóbbit csak abban nem. A C-nek is megvan a maga létjogosultsága a mai napig.
> (mivel hogy C++-ban is kb. lehet C-ben programozni, és ha kell, akkor ott van a C++ összes jó feature-e).
> Ha ez nem számít, akkor el nem bírom képzelni, miért használna bárki C-t
Azért, mert ha a feladathoz nem kellett a C++ egyetlen extra feature-je sem (nem kezeltél memóriát, stringeket, nincsenek objektumaid, stb.), akkor amit írtál az akkor is C kód, ha C++ fordítóval fordítod le.