"A Fehér Ház is a C és a C++ elhagyására buzdít"

Pedig tenyleg nem mondott ilyet.

Mas hulyeseget mondott: hogy injektaljak be az emberekbe a kezfertotlenitot. Az se sokkal jobb, de a hipo ivas akkor is fake news.

Szerintem simán az a valós érv, hogy több dologra kell odafigyelni, ott van a lehetőség elrontani a bufferméretet, olvasást bele. Okés, fordíthatsz bele valami bounds check-et, de akkor is kilőtted egy rétegét egy védelemnek. Már csak még egy valaki kell, aki kihagyja az opciót a makefile-ból (kicsit bonyi volt, egyszerűsítette, és kidobálja amit nem ért, pl. a "felesleges" compiler opciókat). Ráadásul még kicsi is a library, szóval vagy folyton újrafeltalálják a melegvizet, vagy a standard C library-nál sokkal kevésbé ellenőrzött 3rd party, vagy még rosszabb, saját libraryket használnak egy csomó mindenre. Van teljesítménykritikus dolog, amit érdemes ebben írni, de szerintem egy csomó mindent nem.

https://www.cvedetails.com/vulnerabilities-by-types.php

Na de itt kifejezetten kritikus rendszerekről van szó! Azt még véletlenül sem kezdők dobják össze gyorsba'... Vagy ha igen, akkor tényleg nagyon nagy már a baj!

Mi a kritikus rendszer? Teszem azt, ha egyszerre leallna a online rendeles 90%-a, az kritikus lenne? Szigoruan veve nem, de igen komoly kovetkezmenyei lennenek. Pl. ehezne nehany rendelt kajara szokott ember, nem lenne olcso cipo a gyereknek, stb...

Ha eleg sokan hasznalnak egy rendszert, akarmennyire primitiv, a puszta tomegenel fogva kritikussa valik sajnos.

> ASAN, bound check

Ne nevettess, ezek segítenek, hogy az egyszerű esetek általában jól működjenek. Sehol nincs ahhoz képest, hogy a rendszer garantálja, hogy soha egyetlen memória túlcímzés sem lesz. Egyáltalán nem hűhó, hanem konkrétan rohadt nagy meló bizonyítottan tisztességesen csinálni a memóriaelérés ellenőrzését, és ha rigorózusan jól csinálod, akkor a végén lényegében olyat csinálsz kézzel, mint amit a magasabbszintű nyelv megcsinál automatikusan.

Megbocsajtani nekik valoban nincs okod. Viszont annak utananeznek alaposabban, hogy mit csinal a haborus helyzet a technikai fejlodessel, es annak iranyaival es annak titkossagaval/nyilvanossagaval.

Drukkolhatsz annak, hogy majd 2026-ban az ukran elektron+js alapu szoftverrel rohangalo dronok 16G RAM-mal elverjek az 1G ram alatti huawei chipes C/C++-os firmware-es dronokat. De felhivnam a figyelmed, hogy a drukkolas ellenere van mit felmerni realisan. Mint C-hez erto fejleszto, tenyleg tovabb kene latnod egy sima drukkolasnal, amikor eselyeket mersz.

Nem hiszem, hogy alapos kutatast vegeztel azzal kapcsolatban, hogy milyen kepzesek mennek ma orosz egyetemeken (vs 3 evvel ezelott), es milyen minosegben. Sot, ezzel kapcsolatban valos, objektiv informaciohoz nem nagyon lehet hozzaferni.

Azt nem tudom, hogy most milyen az orosz oktatás, de az biztos, hogy a tudás egy lassan párolgó anyag.

A nagyapádról meg nemcsak azt nem tudom, hogy ki volt (nem nyilvános a valódi neved), de azt sem, hogy hogyan jött ide, ha '56-os volt, ha nem.

Nyilván nem fogják kukába dobni, mert gazdaságilag kivitelezhetetlen lenne. De ahogy COBOL-ról áttértek C-re, ugyanúgy a C is folyamatosan ki lesz vezetve. Nincs ebben semmi katasztrófa.

Az a kérdés szerintem, hogy mit akarsz elérni. Ha azt, hogy viszonylag hamar tudjon valamit csinálni, amiről úgy érzi, hogy "ejha, de király, és én írtam", arra jobb szerintem kicsit absztrahálni, és nem a gépközeli dolgokkal kezdeni. Ne legyen túl nehéz, és legyen látszatja, az motivál. A technika órán sem kezded azzal, hogy odaadod vödörben egy 21 köves svájci óra darabjait, hogy na, rakjuk össze, hanem a fémépítő kiskocsival.

Az én meglátásom az, hogy el kell különülnie a szakágaknak. Van akinek az lesz a specialitása, hogy a low-level dolgokhoz ért és van aki meg mondjuk valami bonyolult probléma matekjához ért és azt akarja, hogy a programnyelv/fordítókörnyezet/runtime/engine megoldja neki anélkül, hogy foglalkoznia kellene azzal, hogy mi folyik alacsony szinten. Ezzel szerintem nincs akkora baj.

Azt a trendet problémásnak látom én is, hogy bizonyos feladatokat amikre korábban volt hatékony, jól működő megoldás (pl. vastagkliens GUI-k), ma már szinte mindenki beágyazott browseren futó html+css+javascript kombóval próbálja megoldani. Azt is problémásnak látom, hogy hihetetlenül népszerűek lettek a hatékonytalanul futó, interpretált, egyszálas GIL-es scriptnyelvek mindenféle teljesítménykritikus szerver oldali alkalmazásban. (Aztán lehet küzdeni, hogy deploy-old container clusterekbe 100 példányban, meg hogy lehetne mégis többszálúsítani a python-t stb.)

A DOS, Turbo Pascal, Turbo C stb. világhoz azért sem kéne visszatérni, mert ott rengeteg dolgot az határozott meg, hogy a PC architektúra kialakításakor milyen buta, mondjuk úgy nem jövőbiztos hackeket tervezési döntéseket hoztak, amiket utána kompatibilitás miatt évtizedekig hurcolt az egész PC-s világ magával. Szerintem a near meg far pointereket szerintem nem kívánja vissza senki, a VGA bank switching-et sem és ez még csak a jéghegy csúcsa. :) És sok más régi dologgal is ez a baj. A low-level világban is vannak bőven jobb, technikailag okafogyott örökölt limitációktól már mentes megoldások.

Csak ismételni tudom magam: GC esetén esélyed sincs szabályozni, mennyi memóriát is foglal éppen a program. Nem látsz rá olyan alapvető dolgokra, pl. hogy mikor fut, épp ezért tervezni sem tudsz vele. Rendszerkritikus alkalmazásokra nem való ilyen nyelv.

Itt egyébként konkrétan az történt, hogy valamiért nem indult el a GC időben, ezért felhalmozódtak a foglalások. Senki nem látta ezt előre, és a tesztkörnyezetben sem fordult soha elő, ezért lett a keret meghatározva úgy, ahogy. Nem a terheléssel volt baj, az nem volt nagyobb az átlagosnál, nem is azzal, hogy ne lett volna kellő ráhagyás a keretre, hanem azzal, hogy nem ütemeződött be a GC valamiért. Vagy beütemeződött, csak nem futott le, ez nem derült ki egyértelműen a logokból, csak az, hogy a memória nem szabadult fel, ezért felhalmozódott. Ha C-t hasznháltak volna, ahol muszáj programatikusan felszabadítanod és pont emiatt erre teszt is írható, ez nem fordulhatott volna elő.

Ez egy konkrét implementációra igaz.

Az több, mint elég. Egy állítás cáfolásához bőven elég egyetlen ellenpélda.

A Pascal is fejlődik, van AnsiString, WideString, UnicodeString, már nem megkötés a 255 maximális hossz.