Oké, akkor ebben a tekintetben faék és megengedő, nem pedig szar.
Megengedő, és emiatt rossz :).
Persze, hogy nem tudok mindenre felkészülni, de ez a Rust nyelv kitalálóira és a Rust fordító íróira és így végsősoron a Rust-ra is igaz, hogy nem tud mindenre felkészülni. Jó dolog, ha egy magasszintű nyelv ad bizonyos védelmi mechanizmusokat, de attól egy lowlevel nyelv nem lesz szar, mert az nem ad. Nem célja.
Igen, nem tud mindenre felkészülni. De ha választhatok, hogy 10% valszínűséggel kapok egy pofont, vagy 0.1% valszínűséggel, akkor inkább az utóbbit választom :) Igen, ez a baj a C-vel, hogy nem ad védelmi mechanizmusokat. Most erre mondhatod, hogy low level, nem célja, hogy adjon. OK, ez egy hozzáállás. Én azt mondom, hogy attól függetlenül, hogy low level, még adhatna védelmi mechanizmusokat. Ha a performance meg tud maradni, a low level is meg tud maradni, akkor mi a baj azzal, hogy esetleg még védelmi mechanizmust is kapsz?
Mérlegelni kell, hogy ha ennyire kétséges, akkor esetleg egy validálást berakni elé. De most nem ezért, vagy azért, de ha a
malloc()és tsai.NULL-t adott vissza, mert kifogytál a tárból, ott C++-ban mit fogsz kapni, ha az objektum konstruktora elszáll a memóriahiány miatt?
Ez az, hogy Rustban nem kell mérlegelned, megspórolhatod azt. Persze, ha a programod ettől függetlenül tartalmaz mondjuk egy túlindexelést, akkor baj lesz belőle. Csak nem mindegy, hogy sechole lesz, vagy csak egy sima, well-defined exit. A C++ le tudja kezelni a memóriahiányt is, ilyenkor dob egy exceptiont. Persze kérdéses, hogy ilyenkor hogyan tud továbbmenni a progi, hogy nincs memória. De, ha valami kritikus rendszert csinálsz, akkor felkészülhetsz ennek a lekezelésére, pl. a progi elején lefoglalod azokat az erőforrásokat, amik kellenek az out_of_memory-nak a kezeléséhez, és akkor ki tudsz lépni szépen. Vagy esetleg felszabadítasz valamit, és újrapróbálod az adott dolgot. De amúgy alapesetben nem gondolom, hogy ezzel bárki is foglalkozik. Az alap beállítású Linux alatt tutira nem, mert ugye a linux szeret több memóriát adni neked, mint amennyi van, szóval out_of_memory helyett OOM lesz, nem igazán szokott a malloc/new null-lal visszatérni alap linuxon.
De ezt még mindig senki nem vitatta, hogy ez nem baj, hogy a nyelv levéd bizonyos dolgokat...
Ok, akkor miről vitatkozunk? :)
Akkor is, ha valami egzotikus chipen kell futnia, össz 4k RAM-mal?
Nyilván ha nincs C++/Rust/whatever megoldás egy adott platformon, akkor marad a C. Erre utaltam valamelyik korábbi hozzászólásomban, hogyha nem muszáj, akkor nem használnék C-t. De ha muszáj, akkor nyilván nincs más megoldás. De mondjuk az az érv, hogy "ugyse használok semmit a C++ feature-eiből, ezért jó a C is", szerintem nem állja meg a helyét. Nem mindegy, hogy melyik compilert hívod meg? És ha mégis kell valami C++ feature, akkor meg ott van. Láttam nem egy olyan projectet ami ilyen gondolkodás mellett indult, C-ben. De aztán csak szükség lett volna C++-ra egy idő után arra, mert bizonyos dolgokat C++-ban jobban meg lehet oldani. De persze itt most nyilván olyan esetekre gondolok, amikor 2KB-d van a kódra, és 48 byte-od a data-ra, mert itt maga a fejlesztés se tart túl sokáig. Valszeg ha kész C-ben, akkor nem kell tovább birizgálni. De mondjuk én még egy ilyennek is C++-al állnék neki, mert egész egyszerűen nincs semmi okom C-t használni.