Rust a webfejlesztésben (is): hatékony API réteg Rust alapokon

HUP

A Rust programozási nyelvre leggyakrabban a C leváltójaként tekintenek, ami előbb-utóbb átveszi majd az uralmat a biztonságkritikus kernelek és alacsony szintű alkalmazások fejlesztésében. Hatékonysága és alkalmazásának sokrétű lehetőségei azonban jóval túlmutatnak a biztonságon, sokkal több területen predesztinálják sikerre. A webalkalmazások, azon belül az API rétegek fejlesztése esetén is jelentős potenciál rejlik a Rustban, kiváltképp ott, ahol a gyorsaság is nagy jelentőséggel bír.

Web- és mobilalkalmazások fejlesztése során csak a munka felét jelenti a felhasználó böngészőjében vagy mobiltelefonján futó frontend alkalmazások elkészítése. Ezek a felületek működésük során egy vagy több üzleti rendszerrel is kommunikálnak, így a kommunikáció sokszínűsége életre hívja a különböző middleware vagy backend for frontend (BFF) rétegeket. Több gyakori probléma merül fel, amikor egy frontend alkalmazást, valamint egy elsősorban üzleti folyamatok és logikák köré szervezett rendszert együttműködésre kell bírni.

[...]

A teljes cikk itt olvasható.

( bzt | 2024. 02. 19., h – 15:35 )

Szerkesztve: 2024. 02. 19., h – 15:35

A Rust programozási nyelvre leggyakrabban a C leváltójaként tekintenek

Csak a konzúmeridióták tekintenek úgy rá. Az öreg rókák pontosan ugyanezt hallották már szórul szóra a C++, Java meg legutóbb a Go kapcsán is, aztán egyikből sem lett semmi, le merem fogadni, ebből sem lesz. A nyakatekert grammarjához képtelenség hatékony fordítót írni, ezért mindig is tetves lassú lesz, míg egy C fordító kevés erőforrással is beéri és ezért baszott gyors, a rapid-development-cycle pedig minden nyelvi csicsát ellensúlyoz hosszútávon. Uff, én szóltam.

Red flag: a legfrissebb Rust fordító már a tavalyi github-os kódokat sem képes lefordítani.

Nem t'om, csak azt tudom, hogy a github-ról leszedett Rust források (ha nem volt rajtuk commit már egy ideje) egyszerűen nem fordulnak le. Persze lehet, sosem fordultak le, de ez nem túl valószínű. Emiatt rákerestem arra, hogy "Rust incompatibility", és baszott sok oldalt feldobott (olyanokat, mint ez vagy ez vagy ez például), aztán rábukkantam erre is, úgyhogy hagytam is az egészet a fenébe.

Az mondjuk egész biztosan nem tesz jót a nyelvnek, hogy közel egy évtized alatt sem sikerült az ABI-t stabilizálni... Emiatt ez inkább a vicc kategória, mint komolyan vehető nyelv. Egyébként az sem igaz, hogy az API ne változott volna, ott is voltak breaking change-k bőven. (Egyébiránt jelenleg is közel 900 (!!!) nyitott, megoldatlan kompatíbilitási jegy van rajta, ami nem jelent semmi jót. Ennek harmada több, mint 5 éves, azaz ha eddig nem javították, valószínűleg ezután sem fogják, és ez több száz jegy.)

Ja, és ezeket nem én állítom, hanem a Rust-ban dolgozó fejlesztők, ha esetleg nem lenne világos. Én csak összeszedtem pár linket, amit a Rust feljesztők állítanak a Rust-ról, ne a hírnököt bántsd!

Ha engem kérdezel, akkor a Rust legeslegnagyobb hibája, ami immáron kijavíthatatlan és ami miatt alkalmatlan bármilyen hosszú távú projektre, az a cargo. Képzeld el, hogy mához tív évre kell majd lefordítanod valamit. Sok sikert egy régi program lefordításához, amikor a mostani szerverek már nem lesznek sehol sem!

Mondjuk a libraryk minden nyelven változnak, fejlődnek. C++ dolgaimhoz is minden felhasznált elemnek saját repóban tartom a forrását, pont emiatt.

Az persze nem mindegy, hogy egy 20 évvel ezelőtti C++ forrást is gond nélkül fordítok le egy mai fordítóval. Óriási előny ez.

A másik, hogy nekem C++-ban sosem voltak gondjaim sem a memóriakezeléssel, sem a többszálú programozással, amikkel a Rustot annyira reklámozzák, pedig sokszor elég nagy és jellemzően folyamatosan hiba nélküli működést igénylő szoftvereken dolgoztam.

C++ rossz hírét jellemzően Java, C# vagy valamilyen scriptnyelv után C++-szal próbálkozó programozók alapozták meg, akik C++-ban is megpróbáltak Java vagy PHP programot írni és nem ment nekik. Rengetegen vannak sajnos ilyenek, még a youtube-on is képesek panaszkodni, szakmailag totál elásva magukat.

Mondjuk a libraryk minden nyelven változnak, fejlődnek.

Ez így van, de a többi nyelv nincs egybevasalva egy csomagkezelővel, mint a Rust a cargo-val. Még dinamikus függvénykönyvtárat sem képes kezelni, azt is a cargo-ba hekkelték bele.

C++-ban például eldöntheted, hogy egy adott verziójú boost-ra építesz egy projektet, és azt archíválhatod a forrásoddal együtt. Rust alatt ez nem lehetséges, mert ott a cargo a netről szedi le neked a csomagokat a háttérben. Pont ezért írtam, hogy 10 év múlva irtó nagy szívás lesz, amikor már nem lesz meg egyik mostani verziójú crate sem a szerveren, már ha egyáltalán létezni fog még a mostani crate szerver 10 év múlva...

A másik, hogy nekem C++-ban sosem voltak gondjaim sem a memóriakezeléssel, sem a többszálú programozással, amikkel a Rustot annyira reklámozzák

Na igen, ebbe nem akartam belemenni, mert eléggé szubjektív, de egyetértünk, nekem is az a véleményem, hogy egy nem is létező problémára ad egy rettentő körülményes és nyakatekert megoldást.

És itt megint visszaköszön ugyanaz, ami az összes többi nyelvnél is reklámszlogen volt (de különösen a Java-nál tolták nagyon), hogy a nyelv fícsöreszettje majd kiváltja a programozói tudást és gyakorlatot. Hát lóf*aszt váltja ki, hogy finoman fogalmazzak, ez oltári nagy hülyeség. Hiába van borrow meg minden a Rust-ban, egy programozónak akkor is értenie kell, hogy a memóriakezelés miért úgy történik, ahogy, különben szar lesz a kód.

Egyébiránt jelenleg is közel 900 (!!!) nyitott, megoldatlan kompatíbilitási jegy van rajta, ami nem jelent semmi jót

Nem nyitottból van 900, hanem lezártból. Nyitott kb. 300 van.

Ennek harmada több, mint 5 éves, azaz ha eddig nem javították, valószínűleg ezután sem fogják, és ez több száz jegy.

A több, mint 5 évesből kevesebb van, mint 100, amik egy része még az 1.0.0 előttről való. Illetve egy része pedig a jövőbeli inkompatibilitások megbeszélése, minimalizálása és megoldása.

Ha már a szövegértést kéred számon másokon, akkor különösen oda kellene figyelned az ilyenekre.

Ha engem kérdezel, akkor a Rust legeslegnagyobb hibája, ami immáron kijavíthatatlan és ami miatt alkalmatlan bármilyen hosszú távú projektre, az a cargo. Képzeld el, hogy mához tív évre kell majd lefordítanod valamit. Sok sikert egy régi program lefordításához, amikor a mostani szerverek már nem lesznek sehol sem!

Mások meg pont az egyik legnagyobb előnyének tartják. Létrehoz egy lock fájlt, ahol lockolja minden dependency-jének az adott verzióját. Nem csak verziószám alapján, hanem az adott git commit-hoz lockolja.

pl.:

[[package]]
name = "hello_world"
version = "0.1.0"
dependencies = [
 "regex 1.5.0 (git+https://github.com/rust-lang/regex.git#9f9f693768c584971a4d53bc3c586c33ed3a6831)",
]

Amíg az adott repository elérhető, addig bármikor lekérhető az adott verzió forrása. Egyébként pedig lehozza egy cache-be, amit, ha nagyon fontos dologról van szó vagy nem bízol a szerzőjében, akkor akár el is tárolhatod. Egyébként hasonlóan működik a nix flake is, de ott gyakorlatilag bármi lehet a git repóban. Ezek az eszközök pont arra szolgálnak, hogy reprodukálható legyen a build évek múltán is.

A több, mint 5 évesből kevesebb van, mint 100

Az rohadtul sok biztos-nem-lesz-megoldva-már jegy!

Mások meg pont az egyik legnagyobb előnyének tartják.

Ja, az olyan zöldfülűek, akik még sosem élték meg, hogy egy netes szolgáltatás elmúlik. Erre építeni egy fordítót meg ettől függővé tenni a céges szoftvereket, na az az öntökönszúrás minősített esete.

Amíg az adott repository elérhető, addig bármikor lekérhető az adott verzió forrása.

Hát épp ez az, egyáltalán nem biztos, hogy 10 év múlva is meglesz az a remote repó (vagy épp a függősége, vagy annak a függősége)! Emlékszel Te a geocities-re, tripod-ra, altavista-ra, vagy épp a vbulletin-re? Senki se hitte, hogy egyszer nyomtalanul eltűnhetnek, aztán mégis eltűntek. Sok mostani cég fog menni a levesbe, amikor az AI lufi kipukkan, pont úgy, ahogy dotcom lufi idején történt húsz éve. Nagyon érik már a dolog, nem véletlenül vannak a tömeges elbocsátások az IT óriásoknál.

https://github.com/rust-lang/regex.git#9f9f693768c584971a4d53bc3c586c33ed3a6831

Te halál komolyan azt hiszed, hogy ha bevasalod a github.com-os URL-t, azzal majd megoldódik a dolog? És ha épp elszáll a github, netán fizetőssé teszik, vagy akár végleg lekapcsolják? Hogy akarsz akkor majd régi Rust-os forrásokat lefordítani?

Ezek az eszközök pont arra szolgálnak, hogy reprodukálható legyen a build évek múltán is.

Hát, tekintettel arra, hogy már most is folyton olyan github-os Rust projektekbe futok bele, amik már nem fordulnak le, nem mondanám túl sikeresnek...

A fordítónak volt inkompatibilis változása, egy komoly procedúrájuk van erre: https://rustc-dev-guide.rust-lang.org/bug-fix-procedure.html#tracking-i…

From time to time, we encounter the need to make a bug fix, soundness correction, or other change in the compiler which will cause existing code to stop compiling.

Amit régen a fordító elfogadott, ma már nem biztos, hogy elfogadja, mert bugos volt a fordító régen.

C++ el es virul. Nehezen tanulhato nyelv, ezert ahol nem annyira fontos a hatekonysag, mar van jobb, de a sajat teruleten teljesen jo. A Java megint eleg elterjedt uzleti alkalmazasoknal. Rusthoz kepest foleg, Kotlin akkor mar nagyobb vetelytars.

Persze a Rust is lehet jo megfelelo celra, valami miatt nagyon jon fel.

A strange game. The only winning move is not to play. How about a nice game of chess?

Divat. A memóriakezelés megoldása csak alacsony szinten érhet valamit, webfejlesztésnél a java garbage collector-a van már annyira jó, hogy ne akarjak illyesmivel szívni. Mikor új egy nyelv, még egyszerű, aztán mire beleteszik amit kell, bonyolult lesz. Ez meg már az elején bonyolult.
De valamire biztos jó lesz

A C++ konstruktor/destruktor meg kenterbe ver mind performance-ban, mind biztonságban, mind strukturáltságban (átláthatóságban), mind kiszámíthatóságban kb. mindent.

Aztán persze vannak a C++-nak olyan részei amivel lehet szívni (pl. const correctness, shallow copy/deep copy), de épp a memóriakezelés nem az.

Ez már hittani kérdés :D Én másként látom. A konstruktor/destruktor épp egy komoly hibaforrás ha nem figyel valaki. Biztonságban sem tartom kiemelkedőnek a C++ -ban fejlesztett szoftvereket, sőt! Nyilván sok idő alatt ... de általában nincs sok idő, gyakran elég idő sem. Úgy pedig már sokkal könnyebb hibázni C++ -al mint Java-val, Kotlinnal vagy C#-pal.

Nyilván én is elfogult vagyok azok iránt a programnyelvek iránt amit gyakrabban használok. De a Rust-ot pont nem szólom le. A Rust szerintem nem aktuális hóbort, sokkal több annál nagy potenciállal. Sajnos még nem volt időm igazán elmélyedni a használatában. Eddigi felszínes Rust tapasztalataim alapján valós alternatívája lehet a C++ -nak elsősorban. 

Eddigi felszínes Rust tapasztalataim alapján valós alternatívája lehet a C++ -nak elsősorban.

Esetleg C++ helyett, de semmiképp sem a C helyett. Bár mondjuk én még sosem láttam C++ fordítót segfault-olni. https://github.com/rust-lang/rust/labels/I-crash

Ebben egyetértünk! Nem véletlenül írtam csak C++ -t. 

A segfault-ra, egyrészt jogos megjegyzés, hogy vannak még gyerekbetegségek a Rust-nál. C++ fordítóknak van pár évtizedes múltja a Rust pár évével szemben. Másrészt például a Microsoft C++ fordító máig tele van zavaró hibákkal, legzavaróbb amikor nem az fordul le ami a kódban van. A C++ seniorság egy fontos része, hogy a tapasztalt programozó ismeri már a MS C++ fordító hülyeségeit, de ez szerintem hasonló negatívum mint a segfault. Azt viszont elismerem, hogy a Linuxos világ (gcc) és Apple világ C++ fordítója sokkal jobb állapotban van. 

Nem arra utaltam, hogy most azonnal váltani kellene minden C++ projektnél Rust-ra, hanem a benne rejlő potenciálra gondoltam. 

Ugyanemiatt a C++ a legnehezebb jelenleg hasznalt nyelv. Mert ha akarod, hasznalhatsz benne smart pointert (majdnem GC), megy a new/delete, de ha csak kicsit okosabb C kodot szeretnel, akkor minden olyan, ami C-ben is volt (*alloc, free). Ugyanigy ott van az STL, a C-s stringkezeles, a de a C++-os String class. Egy sima string kiprinteleset meg tudod irni legalabb 5 fele modon (ennek a fele persze C-bol vagy a kernelbol jon), de nem tudod elore, hogy a tobbi fejleszto melyikbol mit hasznalt, szoval meg kell tanulnod mindet. Jo nagyon magas szintre, de HW kozelebe is, ha arra van szukseg.

Ettol fuggetlenul szeretem (sokaig a kedvencem volt), de ha nem kritikus a futasideje, manapsag inkabb Pythont szedek elo.

A strange game. The only winning move is not to play. How about a nice game of chess?

>A C++ konstruktor/destruktor meg kenterbe ver mind performance-ban, ... , mind kiszámíthatóságban kb. mindent.

Kivéve, hogy dinamikus memória allokáció van, ami malloc/free-ben végződik, és fragmentálódás miatt akár kaphatsz OOM-et akkor is, ha egyébként a programod elférne a kijelölt memóriában pusztán a foglalt objektumokat összegezve. Plusz a fragmentálódás miatt a malloc ideje sem kiszámítható, illetve a free ideje sem feltétlenül.

Egy menedzselt GC nyelvben ezzel szemben ha az alkalmazás összes objektum foglalása belefér a kijelölt területbe, akkor működni fog az idők végezetéig is, és nincs fragmentáció miatt probléma. (Az idők viszont ott is kiszámíthatatlanok, ez igaz, mert a GC bármikor közbeszólhat. Bár trükkök vannak, párhuzamosan futó GC-vel kiszámítható korláton belül tartható a foglalás ideje elvileg, de nem tudom van-e ilyen implementáció egyáltalán.)

Ezek épp azok a kitalált problémák, amiket a java meg tud oldani. Egyszer azzal láttam a java jóságát azzal demózni, hogy egy üres ciklusmagot sokkal gyorsabban lefuttatott mint a C. Ez szinte ugyanaz a szint.

Nem lehetetlen ilyen kódot írni, de az egy elég elcseszett kód. Kb. az kell hozzá, hogy folyamatosan minden page-en maradjon valami kis szemét, de a nagy része meg legyen deallokálva. Na ilyet csak a java képes elkövetni :D

De mérget nem vehetsz rá, hogy sosem fog elfogyni a RAM-od fragmentálódás miatt. Pont ez a lényeg, hogy _teljesen_ nem kiszámítható. Biztonságkritikus rendszerekben sokszor eleve megtiltják a dinamikus allokálást, mert vannak aknák benne. A GC a fragmentálódást kicselezi, cserébe kapsz több nagyobb bajt. De attól még az alapállítás igaz marad, hogy se az allokáció ideje, se az, hogy nem lesz OOM (annak ellenére, hogy számszakilag elég a RAM) nem garantálható, ha a program folyamatosan random foglal objektumokat, előre nem számítható minta szerint.

Amúgy persze _általában_ sokkal hatékonyabb, azt elismerem.

fragmentálódás miatt akár kaphatsz OOM-et

Én is olvastam ilyen propagandát régebben, de hidd el, hülyeség. huszonX év C++ kódolás során sosem futottam bele ilyesmibe. Az allokátorok ennél sokkal jobban vannak megtervezve és C++ alatt egyszerűen cserélhetők is a feladattól függően.

Azt viszont gyakrabban tapasztaltam, hogy a GC-s programok jellemzően legalább 10-szer annyi memóriát fogyasztanak és időnként 100%-on terhelik a CPU-t, miközben semmi hasznosat nem csinálnak (fut a GC).

Az is tanulságos volt, mikor egy 3 brutálisan erős gépet folyamatosan túlterhelő Java alkalmazást C++-ban újraírva 1 alap szervergépgépen 2% alatt fogyasztott CPU-ból és a memóriafogyasztása is elhanyagolható volt.

Szerintem a fentit úgy kell érteni, hogy ezek mind jók, de a C-t nem váltották le... És nem csak a meglévők nem lettek újraírva, hanem teljesen új zöldmezős projektre is simán C-t választanak sok helyen még 2024-ben is. Főleg embedded esetben. Itt egyébként a Rustnak lehetne keresnivalója, de ha mondjuk fel is akarok venni tapasztalt embereket, akkor a Rust nem biztos, hogy jó választás, egy manager nem biztos, hogy bevállalja a döntést, hogy akkor Rust. Szóval ehhez még idő kell, ha egyáltalán mainstreammé válik a Rust.

Kb. a második mondat elejéig lehetett komolyan venni, amit írtál.

Nem lett semmi a C++-ból és a Java-ból? Kis csillió hatalmas alkalmazásokat készítettek és készítenek bennük.

Arról pl. hallottál-e, hogy a világ leggyorsabb tőzsdei rendszerét Javaban írták?

Nem lett semmi a Go-ból? Docker, Kubernetes, ... neked nem mond semmit?

>Valójában ugyanolyan gyors szoftvert lehet fejleszteni mint C++ -ban. Memóriahasználatban nagyobb a Java

Sajnos ez nem igaz, egy rakás szempontból lassabb lesz a Java. Tapasztalatból mondom, mikro-optimalizáltam Java programot teljesítményre. Például úgy, hogy objektum reuse-t implementáltam bele API-k feltugásán keresztül, hogy ne legyen folyton GC egy periodikus programban. Meg lehet közelíteni a C/C++-t, de utolérni nem lehet. Feltéve, hogy ugyanaz az algoritmus van megvalósítva persze. És a megközelítést úgy kell érteni, hogy fel kell rúgni a nyelv szabályait, hogy GC-t, többszörös indirekció csökkentését, cache-be beleférést (itt már Java szinten mágiáról beszélnénk, pedig az igazi teljesítmény optimalizálás C-ben itt kezdődik) lehessen optimalizálni.

És akkor még ott van az elindulás ideje, amit szintén közel lehetetlen Javában gyorsra csinálni. A JIT miatt az indulás sokkal lassabb lesz, és egy ponton túl nem lehet optimalizálni. Egyrészt a bájtkódot gépi kódra kell fordítani, másrészt az összes Java osztály között a referenciák ekkor vannak feloldva név szerint. Tehát az indulás ideje attól fog függeni, hogy milyen hosszúak az azonosítóid a kódodban! Ráadásul pont a publikus azonosítókról van szó! Ez persze csak akkor tűnik fel, amikor kiderül, hogy valahol ez a szűk keresztmetszet, egyébként tényleg teljesen mindegy. De egy C-ben írt statikusan linkelt programot csak bemásolsz a memóriába, és már futtathatod is. Az indítás ideje több nagyságrenddel gyorsabb! Nagyon nem mindegy!

Az Ahead Of Time compile elvileg működhetne, de az eszközök nem tudják. De legutóbb amikor néztem nem volt erre hivatalos eszköz. Valamikor régen volt a GCJ, ami koncepcionálisan jó dolog volt szerintem, de sosem forrt ki és 1.5 körül elsikkadt az a projekt emlékeim szerint.

Amikor azt mondják, hogy ugyanolyan gyors, akkor azt úgy értik, hogy az elindulást és a JVM melegedést nem számoljuk, és kézzel van mikrooptimalizálva a kód úgy, hogy az már a C-hez jobban hasonlít mint Javához. Úgy tényleg _majdnem_ ugyanolyan gyors. Vagy esetleg úgy értik, hogy valami szintetikus dologban ugyanolyan gyors. De hogy általánosságban ugyanolyan gyors lenne, azt ne hidd el!

Úgy mondom ezt, hogy Java fan vagyok, még mindig a kedvenc programozási nyelvem és ökoszisztémám, de attól még tisztában kell lenni a határaival!

Ne fáraszd magad, ezekről amiket leírtál életében nem hallott, vagy ha igen akkor szerinte marhaság. Az "öreg róka" kifejezés amit ő használt a valóságban a tanulásra és fejlődésre képtelen, begyöpösödött, "15 éve így csinálom" embereket takarja.

Valami banknál vagy állami cégnél elüldögélnek nyugdíjas korukig, de hálistennek normális helyeken (értsd, ahol 5 éves vagy frissebb technológiákat használnak) nem szoktal feltűnni, szóval sok vizet nem zavarnak :)

( zolti v | 2024. 02. 19., h – 18:06 )

Szerkesztve: 2024. 02. 19., h – 18:07

Biztos sokan komolyan veszik majd a cikket. Csak gratulálni tudok a címválasztáshoz.

Rust a webfejlesztésben...

( bzt | 2024. 02. 20., k – 08:22 )

Szerkesztve: 2024. 02. 20., k – 08:37

Tényleg komoly gondok vannak egyesek magyar nyelvű szövegértési képességeivel.

Nem lett semmi a C++-ból és a Java-ból?

Nem ezt mondtam. Azt mondtam, abból nem lett semmi, hogy leváltották volna a C-t. És ez tény, mint ahogy az is, hogy a Rust is jó lehet valamire, de egész biztos sosem fogja leváltani a C-t.

Ne fáraszd magad, ezekről amiket leírtál életében nem hallott, vagy ha igen akkor szerinte marhaság.

Az "öreg róka" kifejezés konkrétan azt jelenti, hogy tapasztalattal rendelkező, ha ez nem esett volna le. Egy pár évig Java fejlesztőként kerestem a kenyerem. Egyetemi éveim alatt meg abból éltem, hogy C++-ban fejlesztettem a LibreOffice-t. De ja, még életemben nem hallottam ezekről...

Azt mondtam, abból nem lett semmi, hogy leváltották volna a C-t.

Nem hinném, hogy bármelyik le akarta volna váltani a C-t. Ezek a programozási nyelvek, platformok jól definiált használati esetekre lettek tervezve, arra is használják őket. Ahogy a Javanak, .NET-nek, PHP-nak, Perlnek, AWK-nak meg van a helye, úgy van meg a helye a C-nek, C++-nak, Pascalnak, Adanak, Javascriptnek, Objective-C-nek, Swiftnek stb. Nem tudom, azt az állítást honnan veszed, hogy a célja ezeknek a nyelveknek a C leváltása volt. Ezek a nyelvek egy mérnöki-gazdasági problémát akartak megoldani, ezért készültek, és nem azért, mert Gosling, Wirth, van Rossum, Wall vagy éppen Eich le akarta nyomni a C-t szakmai irigységből. Mint ahogy a C sem azért készült, hogy leváltsa a Fortrant, a Lispet, az OCaml-t.

( bzt | 2024. 02. 20., k – 09:14 )

Szerkesztve: 2024. 02. 20., k – 09:14

Érdekesség: https://madnight.github.io/githut/#/pull_requests/2023/4

A C évek óta konstans, még úgy is, hogy egyáltalán nincs hypolva, és jóval kevesebb C fejlesztő van, mint Rust vagy mondjuk JavaScript fejlesztő. E szerint a lista szerint egyébként csak interpretált scriptnyelvek előzik meg és a Go a github-on, ami mégegyszer, különösen figyelemreméltó úgy, hogy nincs semmi hype mögötte, csak a használhatósága tartja fenn a népszerűségét és NAGYON kevés a C programozó a többi nyelv programozószámához képest.

A C évek óta konstans

Dehogy konstans, folyamatosan jönnek ki az új szabványok, idén várható a legújabb frissítés ( ISO/IEC 9899:2024, közismerten a C23). Olyan finomságokkal, mint %b a bináris kiírásra a printf/scanf függvénycsalád formátumleírójában, #embed direktíva (ez beágyazott fejlesztésben eléggé király tud lenni), nullptr_t szabványos típus a null pointer jelzésére, a typeof() operátor szabványosítása, az enum típusának meghatározása.

Szépen modernizálódik a C, nagyon jól fejlődik.

Ami helyes. Kellenek a jó alapok, pl Rust fordító, Java JVM és Linux kernel alá :D 

Ha már nem megy el a Linux mikrokernel irányba, nem feltétlen baj, ha újabb modulokat/drivereket kicsit bolondbiztosabb módszerekkel fejlesztenek. Jó programozó lassan ér be, de addig is dolgozni kell.

Persze, hogy helyes. Sosem baj az, ha a tapasztalatokat visszacsatolva fejlesztik a nyelvet, a szabványos könyvtárat. Pont az lenne a baj, ha a C még mindig az 1989-es ANSI C lenne (vagy más néven a C90, pontosabban ISO/IEC 9899:1990). Mint ahogy a C++-nál is nagyon helyes, hogy nem a 21 évvel ezelőtti C++03 az alap, ahhoz képest sokkal kifejezőbb kódot lehet írni ma már.
 

Nem értünk egyet. Én kifejezetten imádom az ANSI C-t (ami helyesen C89), és az utóbbi években fokozatosan leszoktam a frissebb szabványokról. Rájöttem ugyanis, hogy mindent meg lehet csinálni C89-el, és sosincs vele gond protolásnál, vagy ha fordítót váltasz, maximálisan hordozható. Minden C fordító garantáltan mindent pontosan ugyanúgy csinál ha ANSI C módba kapcsolod, nincsenek félreértések, nincsenek lekezeletlen nyelvi fícsörök, csak maximális kompatibilitás.

Egyébként az egyik Lua fejlesztőtől olvastam egy értekezést, hogy miért választották az ANSI C-t, onnan jött az ötlet, hogy kényszerítsem magam csak kizárólag ANSI C-re. Most évekkel később egyáltalán nem bántam meg ezt a döntést, sőt. Eleinte persze furcsa volt, és meg kellett szokni, hogy a kommentet le kell zárni és bitfield helyett shiftelés, de mára már rutinból jönnek ezek és nagyon megérte.

Ejnye nem találom most a linket, de a Lua FAQ-ja is rettentő beszédes, mindjárt ezzel nyit (kiemelés tőlem): Lua is implemented in pure ANSI C and compiles unmodified in all known platforms.
Érdemes ízlelgetni ezt: módosítás nélkül, minden ismert platformon.

A C90 az ISO szerinti név, a C89 az ANSI szabvány. A kettő betűre pontosan megegyezik, azonban manapság az ISO-s elnevezést szokás használni.

Ami nagy hátránya az ANSI C-nek, hogy nem tartalmaz platformfüggetlen méretű típusokat (uint8_t és társai), emiatt minden esetben szívás vele a platformfüggetlen binárisok beolvasása, mert szépen sizeof()-olgatni kell mindenhol platformfüggetlen típusok helyett.

nem tartalmaz platformfüggetlen méretű típusokat

Minek is kéne? Látom Te sem érted a különbséget a fordító és a sztandard függvénykönyvtár között. Mondjuk a sok Ruston felnevelkedett zöldfülűtől nehéz is elvárni, mert ott elkövették azt a hibát, hogy egybegyúrták a kettőt. Pedig ez a kettő rohadtul nem ugyanaz, de úgysem fogod ezt megérteni, amíg nem viszel végig legalább egy C projektet, amiben szerepel a "-ffreestanding" kapcsoló.

minden esetben szívás vele a platformfüggetlen binárisok beolvasása, mert szépen sizeof()-olgatni kell mindenhol platformfüggetlen típusok helyett.

Ekkora orbitális hülyeséget rég hallotam! Semmi akadálya, és senki sem gátol meg benne, hogy a következőt használd:#include <stdint.h>.Tökéletesen működik bármelyik C szabvánnyal, így az ANSI C-vel is. (Ráadásul glibcbeli fejlécet direkt ANSI C kompatíbilis módon írták, nincs benne "//" komment... De még ha lenne is, akkor is használhatnál saját fejlécfájlt ugyanerre, amiben kisedeled a komneteket és kész, ki az a hülye, aki tényleg nekiáll sizeof()-olgatni pár typedef sor helyett???).

Konkrétan erről beszélek:

#ifndef _STDINT_H
typedef unsigned char       uint8_t;
typedef unsigned short int  uint16_t;
typedef short int           int16_t;
typedef unsigned int        uint32_t;
#ifndef _UINT64_T
typedef unsigned long int   uint64_t;
#endif
#endif

Ha Te ehelyett a pár sor helyett valaha is nekiálltál sizeof()-olgatni, mint ahogy írod, akkor azt javaslom értékeld át, mennyire jó programozó is vagy valójában. Nem bántásból mondom, hanem jószívű tanácsként.

Az stdint.h az C99, nem bizhatsz benne, hogy ANSI C / C90 támogatás bekapcsolásakor rendelkezésre áll.

Ha meg már használsz C99-es könyvtárat, miért nem használod az egész C99-et?

Amúgy a fenti kódod nem hordozható, ARM-on az unsigned long ugyanúgy 32 bit, mint az unsigned int.

Miért kell neked *pontosan* akkora változó?

Az ANSI C típusok garantálják, hogy a char legalább 8 bit, az int legalább 16 bit, a long int pedig legalább 32 bit.

És bármelyiket kérheted előjellel és anélkül is. Ez alapján már jól belőhető, hogy mit lehet benne eltárolni.

Ha meg fájlba írsz, azt meg lehet tenni bitmaszkolással/shifteléssel portábilisen. Igen, kicsit több kód, mint direktben kiírni, de cserébe mindig ugyanaz lesz.

Oké, beolvasom byte-onként - és milyen típusban tárolom el az endianitáshelyes beolvasás után?

Ha a spec azt mondja, hogy az adott mező egy előjel nélküli 32 bites egész, akkor úgy tudok ennek a tárolására minden körülmények között hordozható kódot írni, ha ezt egy uint32_t-ben tárolom el, és nem valamilyen platformspecifikumban.

ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ Próbálod osztani itt az észt, miközben nyilvánvalóan segghülyevagy a C-hez, és még csak arra sem vagy képes venni a fáradságot, hogy guglizz egyet, és akkor legalább nem égnél így be.

Szánalmas. Komolyan itt tart ma már a szakma, ez az általános színvonal, hogy már egy gulgi is túl sok? ChatGPT nem köpte ki a helyes választ, vagy mi? Szomorú!

Amúgy a fenti kódod nem hordozható, ARM-on az unsigned long ugyanúgy 32 bit, mint az unsigned int.

Lófaszt! ARM-on is AArch64 alatt az unsigned long 64 bites. De ha hordozható kód a cél, akkor typedef __UINT64_TYPE__ uint64_t oszt' csók, mindig, mindenhol működik, csak egy hozzá nem értő idióta áll neki sizeof()-olgatni.

ARM-on is AArch64 alatt az unsigned long 64 bites.

Csak AArch64-en, de ARMv7-en már nem. Épp ezért nem mondhatod, hogy az unsigned long int az 64 bit mindig, ha ARM-ról van szó, hiszen ezen típusok mérete szabvány szerint platformfüggő. Na, ezért nagy szívás az ANSI C.

Amit meg linkeltél, az GCC extension, nem érhető el minden C fordítóval, nem szabványos eszköz. Most akkor szabványos C-ről beszélgetünk, vagy arról, amit a GCC támogat?

Lófaszt! A built-in mindenhol ugyanaz! És ráadásul a word size még csak nem is az architektúrán múlik! Keress csak arra, hogy LLP64/LP64/ILP64/ILLP64, ez mind ugyanarra az architektúrára érvényes.

Mondom én, úgy próbálod itt osztani az észt, hogy a legalapvetőbb fogalmakkal sem vagy tisztában. Te csak kerüld el JÓ messze a C-t, neked a Rust való!

Rajtad kívül senki sem hiszi, hogy a wordfüggetlen változók GCC specifikusak lennének... Egyébként meg Clang, pontosan UGYANEZEKET a makrókat használja. SŐT! Még a JavaScript-re fordító emscripten alatt is használhatók, ha ANSI C-ből fordítanál vele. De még a szutyok, köztudottan nem szabványos MSVC alatt is működnek.

Csak Te hiszed azt, hogy ANSI C alatt nem lehet fix méretű változókat használni, ráadásul azt is megmondtam már, abban is tévedésben vagy, hogy ez platformfüggő lenne. Nem, nem a platformtól függ, hanem adatmodell függő. Látszik, hogy még soha életedben nem írtál egyetlen egy portolható C forrást sem, mégis próbálod itt osztani az észt, de minek.

A C99 standard types azok nem makrók, hanem (a szabvány szövegezése szerint) typedef nevek.

Az stdint.h-ban a makrók azok a típusok határaira vonatkoznak.

For each type described herein that the implementation provides,  <stdint.h> shalldeclare that typedef name and define the associated macros.

És amúgy azért használhatók ezek, mert ez C99-nek a része. Ha fogok egy 1998-as ANSI C környezetet, azt sem fogja tudni, mi az az stdint.h. Pont azért nem, mert csak ANSI C-ről van szó, és nem C99-ről.

Te valójában azt csinálod, hogy ANSI C nyelvi elemekkel használsz C99-es könyvtárakat. Ez a valódi portolhatóság szempontjából nem jelent jót, sokan csinálják így. És ez vezet sok-sok kompatibilitási gondhoz, lásd NevemTeve szenvedéseit a portolhatónak meg platformfüggetlennek mondott kódokról.

Keress csak arra, hogy LLP64/LP64/ILP64/ILLP64, ez mind ugyanarra az architektúrára érvényes.

Fent platformot említettem és nem architektúrát. Ez utóbbi csak része a platformnak. Ugyanazon architektúrán is lehet többféle data model. Platformfüggetlen kód viszont architektúrától és data modeltől függetlenül működik jól, ehhez kellenek a platformfüggetlen méretű egész típusok.

A Luánál amúgy kiemelted, hogy "compiles unmodified in all known platforms", de nem ez a fontos, hanem hogy ugyanúgy viselkedik-e minden platformon. És ez viszont nem igaz.

Standard Lua uses 64-bit integers and double-precision (64-bit) floats, but you can also compile Lua so that it uses 32-bit integers and/or single-precision (32-bit) floats. The option with 32 bits for both integers and floats is particularly attractive for small machines and embedded systems. (See macro LUA_32BITS in file luaconf.h.)

Azaz a Lua viselkedése nem platformfüggetlen. Egy adott Lua script máshogy fog viselkedni platformonként, a LUA_32BITS fordítási értékétől függően.

Én is tudok könnyen írni olyan kódot, ami minden platformon ugyanúgy, minden warning nélkül lefordul, de nem viselkedik ugyanúgy.

És ezzel hol is bizonyítottad szerinted, hogy "muszáj sizeof()-olni ANSI C alatt"?

ehhez kellenek a platformfüggetlen méretű egész típusok.

És amiket a fordító biztosít, nem pedig a C nyelv szabványa. Tudod, fordító != függvénykönyvtár meg fejlécfájlok, de már mondtam, hogy "-ffreestanding", amit láthatóan nem értesz.Teljesen tévedésben vagy, ha komolyan azt hiszed, ANSI C alatt nem lehet fix méretű változókat használni, akár freestanding módban is, de minek is magyarázom?

Egy adott Lua script máshogy fog viselkedni platformonként, a LUA_32BITS fordítási értékétől függően.

Naná, és ennek mi köze bármiféle platformhoz is? Ez egy Lua konfig define! Azt ugye tudod, mi a különbség a predefined macro, stdinc defined és a 3rd party lib define-ja között?

És amiket a fordító biztosít, nem pedig a C nyelv szabványa.

Épp azért kell a szabványnak biztosítania (ahogy ezt C99-ben megteszi), hogy valóban hordozható kódod legyen, ne a fordítótól függj, ha platformfüggetlen, hordozható kódot kell írnod.

Mert akkor a kódod lefordul clanggal, GCC-vel, IBM XL-lel, MSVC-vel, Oracle C compilerrel, meg ami éppen rendelkezésre áll, mert a kódod hordozható, és nem függ fordítótól.

Mint ahogyan, ha van egy ANSI C compilerem, annak minden ANSI C kódot le kell fordítania. Ha például írsz egy kódot, amiben van stdint.h használat, de előveszel egy 1992-es ANSI C compilert, nem fogja tudni lefordítani, mert nem tudja, mi az az stdint.h. Pedig ha valóban ANSI C kódot írsz, nem használsz olyan system headert, ami szabványos ANSI C-ben nincs benne, csak későbbiekben.

előveszel egy 1992-es ANSI C compilert

Ugyan minek tennék ilyent? Pont azzal érvelek a C mellett, hogy a legmodernebb fordítók is gond nélkül képesek lefordítani a régesrégi forrásokat!

nem tudja, mi az az stdint.h

Tévedés! Az stdint.h mindig, minden jelenleg elérhető fordítóban van, akkor is, ha lemezen nem található. Nem tűnt fel, hogy a fordító forrását linkeltem és nem egy libc forrását?

Maradjunk annyiban, hogy amit állítasz, hogy lehetetlen, azt én rendszeresen használom számos projektben, olyanokban is, ahol állítható a fordító meg multiplatformok, és remekül működik...
Szóval mondogasd csak tovább a hülyeségeidet, hogy lehetetlen, addig is én hiba és gond nélkül használom! ;P

Vita lezárva, működő PoC cáfolja az állításod, ezen nincs mit ragozni.

De a legmodernebb forditok nem csak az ANSI C-vel, hanem a modernebbekkel is megbirkoznak. Mondjuk a C99-cel, ha mar ugyis C99-es feature-t hasznalsz belole. Ha meg olyannal probalnad forditani, ami ezt nem tudja, abban az stdint sem biztos, hogy benne van (vagy nem ebben a formaban).

Persze portolaskor egyszerubb irni egy sajat stdint.h-t, mint az egeszet ANSI C-re portolni, szoval igy is van valami ertelme, de ez attol meg nem fog menni alapbol egy regi forditon - marpedig azt irod, hogy pont ezert csinalod.

A strange game. The only winning move is not to play. How about a nice game of chess?

Mondjuk a C99-cel, ha mar ugyis C99-es feature-t hasznalsz belole.

Ha már írtál volna valaha életedben C fordítót, akkor tudnád, mekkora baromságot mondtál most. A C89 ezerszer gyorsabban fordul és optimálisabb kódot generál, főleg azért, mert egyszerűbb a grammarja. Nem éri meg váltani csupán csak pár typedef miatt.

De a legmodernebb forditok nem csak az ANSI C-vel, hanem a modernebbekkel is megbirkoznak.

Hát rohadtul nem!
- vess egy pillantást a Clang statuszra (csak az ANSI C-re van garancia, a többi már csak "nagyon valószínű", meg "esélyes"), de a Clang issue trackere is eléggé beszédes,
- az MSVC sem támogat minden C99-et, csak a C89-et (jó sokat kell legörgetni azon az oldalon, de ott van feketén-fehéren),
- TCC-t (ANSI C fullosan garantált, C99 már nem annyira, későbbi bővítések egyáltalán nem), vagy
- ha meg hozzáveszed az emcc-t is a webappok miatt, akkor végképp felejtős minden bővítmény a portolható kódnál.

Ha csupán ANSI C-re szorítkozol, akkor nincs ilyen gond, azt minden C fordító garantálja, és azt valóban tudják is. Sőt azt még az olyan hobbi fordítók is helyesen fordítják, mint mondjuk a SmallerC vagy a ChibiCC stb.

nem fog menni alapbol egy regi forditon - marpedig azt irod, hogy pont ezert csinalod

Soha, sehol nem írtam ilyent. Pont hogy az ellenkezőjét mondtam, egy kicsit rá kéne feküdni a magyar nyelvű szövegértésre, mert látom Neked sem erősséged. Mindig, minden rendszeren a legfrissebb fordítót használom (igen, a régi forrásokra is).

Egyébként nem értem, mi értelme megpróbálni meggyőzni arról, hogy nem lehetséges megcsinálni azt, ami a gyakorlatban már megcsináltam és működik. Ez valami perverzió nálatok?

Te írtad:

Rájöttem ugyanis, hogy mindent meg lehet csinálni C89-el, és sosincs vele gond protolásnál, vagy ha fordítót váltasz, maximálisan hordozható. Minden C fordító garantáltan mindent pontosan ugyanúgy csinál ha ANSI C módba kapcsolod

 

Miközben meg a kódodat nem lehetne lefordítani egy 100% ANSI C kompatibilis 1992-es C fordítóval. Most saját magadnak mondasz ellent, azzal is, amikor azt mondod egy másik szálban, hogy azok a builtinek, amiket csak a GCC biztosít, és nem portolhatóak, elengedhetetlenek.

Most akkor minden megoldható ANSI C-vel, vagy nem oldható meg minden ANSI C-vel, és maximálisan hordozható-e?

Ugyan PM-ben azt írtam, hogy igazából mindegy, de csak nem hagyott nyugodni a dolog.

Szóval nem, nem nettó személyeskedés volt, amit bzt írt, mert volt benne egy érdemi állítás, hogy persicsb még mindig nem érti, amit bzt magyaráz. És nem csak persicsb: az egész topicban a kollégák egy része konzekvensen nem értette bzt kommentjeit; nem egyszer kellett leírnia, hogy nem azt írta, amire reagáltak, amit hisznek, hogy mondott. (Szóval valahol érthető a frusztrációja.) És én ezt +1-eztem be, hogy még mindig nem érti a lényeget. Nem pedig a személyeskedést. Nem a ledorongolással értettem egyet, hanem a C védelmével. De olyan gomb nincs, hogy +1 csak erre, vagy arra, csak olyan, hogy simán +1. Hozzászólni pedig nem akartam (pedig az elején nagy volt a kísértés, hogy beírjam egynémelyik kollégának, hogy totál félreértette, amit bzt mondott).

Viszont tekintve, hogy neked ez volt az egyetlen kommented az egész topicban, azaz az egész szakmai topichoz csak annyit tudtál hozzátenni, hogy a trécéhá mit pluszegyezett be (mert az releváns és érdekes), nekem úgy tűnik, hogy te csak azért jöttél ide, hogy szórakozz velem. Gondolom erre is lesz valami beszólásod, leoltásod, fals belemagyrázásod, vagy hiteltelenítős kamud (bár most speciel nem tudtam eldönteni, hogy direkt hazudtál, vagy csak te se értetted, amit bzt mond és benézted). Nekem viszont már se időm, se kedvem, se egészségem nincs egy újabb flamewar-hoz, meg nem is akarom szétoffolni a topicot; szóval bocs, de részemről ennyi volt.

Oldschool Computer - http://oscomp.hu

Szóval nem, nem nettó személyeskedés volt, amit bzt írt, mert volt benne egy érdemi állítás, hogy persicsb még mindig nem érti, amit bzt magyaráz

Aztán mire válaszoltam volna írtad, hogy hagyjuk :) Nézd, szleng szemantikán nem fogok veled összeveszni. Ez a komment egy merő masszív személyeskedés. Szerintem az, amikor az egész komment egy degradáló személy elleni támadás, az nettó, akkor is, ha volt benne mondanivaló is. Ha szerinted nem nettó, akkor képzelj oda egy másmilyen melléknevet, vagy simán csak hagyd el.

De olyan gomb nincs, hogy +1 csak erre, vagy arra, csak olyan, hogy simán +1. Hozzászólni pedig nem akartam (pedig az elején nagy volt a kísértés, hogy beírjam egynémelyik kollégának, hogy totál félreértette, amit bzt mondott).

Dehogynincs, válasznak hívják, ahova le lehet írni, hogy ugyan értem, hogy mit mondasz, és azzal egyetértek, viszont a személyeskedést nem kéne ....

Viszont tekintve, hogy neked ez volt az egyetlen kommented az egész topicban, azaz az egész szakmai topichoz csak annyit tudtál hozzátenni, hogy a trécéhá mit pluszegyezett be (mert az releváns és érdekes), nekem úgy tűnik, hogy te csak azért jöttél ide, hogy szórakozz velem.

... és igen, ezért írtam be, mert szerintem valakitől, aki ennyire érzékeny erre, hogy mindenhova személyeskedést lát, akkor is ha nincs, és olyankor a mondanivaló többi része is automatikusan kuka szerinte, attól bizony rettentően visszatetsző, és durván kettős mérce, mikor egy ilyen masszívan személyeskedő kommentet lepluszegyezik, csak azért, mert éppen egyetért a mondandójával. Ha te ezt szórakozásnak látod, lelked rajta.

Aztán mire válaszoltam volna írtad, hogy hagyjuk :)

Valóban így történt. Nem akartam vele foglalkozni, de nem hagyott nyugodni a dolog. Viszont ezek szerint akkor a PM-et megkaptad, tehát attól, hogy azt mondtam, hogy hagyjuk, még nyugodtan megörökíthetted volna az utókornak, hogy tévedtél, a trécéhá mégsem a személyeskedést pluszegyezte be. (Vagy legalább válaszolhattál volna rá valamit, mert így konkrétan azt se tudtam, hogy átment-e, vagy se.) Becsületesebb lett volna.

Nézd, szleng szemantikán nem fogok veled összeveszni. Ez a komment egy merő masszív személyeskedés. Szerintem az, amikor az egész komment egy degradáló személy elleni támadás, az nettó, akkor is, ha volt benne mondanivaló is. Ha szerinted nem nettó, akkor képzelj oda egy másmilyen melléknevet, vagy simán csak hagyd el.

Egy szóval nem mondtam, hogy nem személyeskedő. Az. (Bár érthető a frusztrációja, hiszen kapott ő is, úgy, hogy nem is értették, amit mond.) Hogy ki mit gondol nettónak (szerintem a nettó az, amiben tényleg semmi más nincs, csak anyázás, tehát nem egy állítás, amit személyeskedve tettek, hanem amikor tényleg az egész komment csak személyeskedés, állítás nélkül, de itt nem az egész komment volt az, volt egy állítás benne), az mellékes, mert én nem a személyeskedés részével értettem egyet, hanem a C védelmével, az nekem se tetszett, hogy személyeskedett, dehát mit csináljak; nem akartam hozzászólni. (Lehet hiba volt.) Ez persze nincs ráírva a +1-re, de részedről a jóhiszemű forgatókönyv valami olyasmi lett volna, hogy megkérdezed, hogy ezt most miért. És akkor leírom, hogy mert az érdemi résszel, a C védelmével egyetértek. De nem a jóhiszemű utat választottad. Akár tévedtél, akár hazudtál, a rosszhiszeműség áll. Miért volt rá szükség?
(Egyébként, ha persicsb-nek rosszul esett, akkor elnézést, tényleg nem ellene szólt. (Bár szerintem a legkevésbé sem érdekli.))

Dehogynincs, válasznak hívják, ahova le lehet írni, hogy ugyan értem, hogy mit mondasz, és azzal egyetértek, viszont a személyeskedést nem kéne ....

Igen, csak nem akartam beszállni, mint mondtam. Időm sincs, meg most már teljesen tropa az egészségem is.

... és igen, ezért írtam be, mert szerintem valakitől, aki ennyire érzékeny erre, hogy mindenhova személyeskedést lát, akkor is ha nincs,

Biztos volt olyan, hogy oda is személyeskedést láttam, ahol nem volt (de semmiképpen sem mindenhova), de hát a rossz tapasztalatok...

és olyankor a mondanivaló többi része is automatikusan kuka szerinte,

Legjobb tudomásom szerint meg szoktam válaszolni a személyeskedő posztokra is és nem kukázom az egészet.

attól bizony rettentően visszatetsző, és durván kettős mérce, mikor egy ilyen masszívan személyeskedő kommentet lepluszegyezik, csak azért, mert éppen egyetért a mondandójával.

Én nem érzem annak, főleg azért, mert amit itt leírtál rólam, annak megint a fele sem igaz. Pont, ahogy a kommentemben megjósoltam, hogy valami ilyesmit fogsz csinálni. Látod? Honnan tudhatnám én azt, hogy ezt te most komolyan gondolod, vagy direkt csinálod?

Ha te ezt szórakozásnak látod, lelked rajta.

A rossz tapasztalatok. Meg hát az sem segített a dolgon, hogy - most már beismerten - tényleg csak azért szólj hozzá a témához, hogy técéházz egyet. Ezek után felmerül a kérdés, hogy vajon mennyire komolyanvehető az állítás, hogy én mindenhova csak odalátom a személyeskedést. Meg az a kérdés is, hogy ha tényleg nem szórakozásból csináltad, akkor miért? Még ha te komolyan azt is gondolod rólam, hogy mindenhova személyeskedést látok és szerinted tényleg annyira visszatetsző, hogy ezek után bepluszegyezek egy személyeskedő kommentet, úgy, hogy nem írom oda, hogy nem a személyeskedésre ment a +1; akkor is: ez elég indok arra, hogy csak ezért hozzászólj, hogy beszólj? Minek? Mi volt a cél? Ha nem a szórakozás, akkor mi? Meg akartál szégyeníteni? Az még rosszabb, mint ha szórakozni akartál volna...

Egyébként nem akarjuk privátban folytatni? Nem kéne szétoffolni a topikot, viszont most már kíváncsi vagyok a miértekre.

Oldschool Computer - http://oscomp.hu

Ne haragudj, nem fogok veled megint egy hosszú kanyarba belemenni, teljesen értelmetlen (és egyébként sem értekezek privátban, tudom, hogy vannak itt a háttérben ilyenek, engem ez nem érdekel, fórumozni járok ide). Nekem is vannak rossz tapasztalataim, számtalanszor vádoltál már személyeskedéssel, mikor nem tettem, most is már megint a becsületemnél tartunk (sőt, már privátban is ott tartottunk), ezért szóvátettem, hogy kilóg a lóláb. Ez bizony ilyen, van, hogy az ember orrát beletolják abba, amit csinál. És magyarázhatod rohadt hosszan, hogy nem úgy van, ha azt a kommentet neked címzik, már rohadt hosszan tajtékoztál volna. Már azért is rohadt hosszan írsz, mert valaki leírta azt az egyszerű tényt, hogy lepluszegyezted. Szóval te foglalkozz a saját lelkiismereteddel (vagy ne, te dolgod), az enyémet hagyd meg nekem :)

Tekintve, hogy te meg megpróbáltad megmagyarázni, hogy ez aztán akkora egy bűn, hogy odanyomtam egy pluszegyre, úgy, hogy nem fejtettem ki, hogy nem a személyeskedésre ment (és érdekes módon, most meg, hogy kifejtettem, most meg ez a baj; van rajtam sapka, nincs rajtam sapka), így nyilván leírtam, hogy nem a beszólásra ment a +1, hanem szakmailag side-oltam bzt-vel, mint aktív C-kóder és semmi visszatetsző nincs abban, hogy csak egy +1-et nyomtam, komment nélkül (egyébként képzeld, vaciláltam rajta, mert a stílus nekem se tetszett), már csak azért sem, mert amit rólam leírtál, hogy ezt indokold, annak (már megint) a fele sem igaz, csak (már megint) megpróbálsz belémrúgni. Tudniillik, még mindig ott tartunk, hogy csak azért szóltál hozzá egy topichoz, amihez én hozzá sem szóltam, hogy técéházz egyet. Oké, lehet, hogy tévedésből, de akkor is az lett volna a normális, a becsületes, hogy amikor mondom, hogy nem (akár privátban, akár publicban), akkor mondod, hogy ja nem, tévedtél, de nem, te a privát response után inkább hallgattál, a public után meg inkább megpróbáltad megideologizálni, ráadásul olyan állításokkal, amiknek a fele sem igaz. Nem nálam lóg ki a lóláb, nem én mérek kettős mércével, ha nem te, engem. Hogy rugdoshass. Ha nincs miért, akkor majd kreálsz rá okot is.
Én meg ilyen vagyok, ha belémrúgnak, megpróbálom megvédeni magam. Azt viszont nem sikerült megválaszolnod, hogy miért is csinálod ezt. Mondjuk a szórakozást explicit tagadtad, a megszégyenítési kísérletet meg egyáltalán nem, szóval jobb híján vehetjük úgy, hogy ez volt a célod. Hogy miért, az sem derült ki. Csak sejteni lehet, hogy azért, mert ennyire rühellsz valami miatt. (Egyébként, ha tényleg volt olyan, hogy ha a rossz tapasztalatok miatt adott esetben igazságtalanul vádoltalak személyeskedéssel, azt sajnálom. Nekem nem volt célom, hogy belédrúgjak. (Vagy bárki másba, én mindig csak védekezni szoktam. Engem szoktak támadni unpopular opinion miatt.) Viszont ezek után szerintem nem szaladhattam túl sokszor lukra veled.)
Most is: folytassuk privátban? Nem, te nem akarod megbeszélni, de azért a magadét mondod tovább, a rugdosódást folytatod, próbálsz belenyomni a sárba. Publicban. Mert nem a kérdés tisztázása a lényeg, hanem az én nyilvános mocskolásom. Offoljunk szét még egy topicot a técéhá fikázásával. Biztos semmi rosszindulat nincs a cselekedeteid mögött.
Így aztán az utókornak végül nem azt sikerült megörökíteni, hogy a técéhá egy gyenge pillanatában hova nyomott pluszegyet, hanem, hogy kroozo egy ilyen semmiséget próbált meg halálos bűnné felfújni, csak, hogy belerúghasson a técéhába.

Szerintem ezen gondolkodj el. "Vagy ne, te dolgod."

Oldschool Computer - http://oscomp.hu

Nézd, tényleg nem szeretnék ebbe hosszabban belemászni, se itt, se privátban. Semmi kedvem megnézni, mit fogsz szólni, ha én is lebecstelenezlek meg lehazugozlak pl az olyan gyöngyszemekért, hogy én halálos bűnné fújom fel.

Egy valóban kimaradt, hogy vettem, hogy nem értesz vele mégis egyet, örülök (bár azt is látom, hogy mégiscsak megmagyarázod, hogy érthető), köszönöm.

És kérdésedre válaszolva, azért írtam be, hogy hátha észre veszed magad egy kicsit, ha meglátod a tükröt. Elismerem, valóban nem a legszerencsésebben talán. Viszont az is látszik, hogy nem, nem veszed.

Én ezt itt lezártam, nem fogok többet reagálni.

Én nem becsteleneztelek le, csak azt mondtam, hogy úgy lett volna becsületes, ha a korrekciót is kiírod. És ezt még a legelején - privátban - írtam, tehát igazán nem mondhatod, hogy csak utólag magyarázom bele, amikor ezzel kezdtem...
A halálos bűn költői túlzás volt, de tényleg elég durván felfújtad.

(Érthető != egyetértek vele.)

Kicsit nehéz meglátni egy "tükröt" úgy, hogy amiket te a tükörbe vízionáltál (azaz rólam írtál), annak a fele sem igaz (tehát nem tükör, lévén nem engem mutat), másrészt meg egy egysoros odaszúrást elég nehéz tükörként értelmezni.

Oldschool Computer - http://oscomp.hu

Egyebkent a -ffreestanding-nak van gyakorlati relevanciaja a libc implementalasan kivul?

Igen van. Nekem számos olyan projektem van, ahol nincs OS, pl. rendszerbetöltők, bare metal alatt is muszáj működnie függvénykönyvtárak, libc (azaz POSIX/WIN32 API) agnosztikus függvénykönyvtárak, operációs rendszer nélkül futó alkalmazások, vagy épp a POSIX-UEFI (ami egy POSIX szabványos réteg UEFI alkalmazások számára, bár ez valóban tekinthető egy elfajzott libc-nek). Ezeken túl még mikrokontroller programozás, embedded eszköz programozás, IoT eszköz programozás, stb. stb. stb.

De ezutobbiban is inkabb a `-fno-builtin` ami fontos(abb) lehet, nem is a freestanding mivolta.

Azt a kapcsolót pont, hogy sosem akarod megadni. Vannak dolgok, amik lehetetlenek builtin-ek nélkül, még freestanding módban is iszonyat nagy szükség van rájuk. Például "__builtin_va_start", ezt lehetetlen portolhatóan implementálni, ehhez mindenképp a fordító builtin-jére van szükség. De a "__builtin_memcpy" és "__builtin_memcmp" is roppant hasznos, mivel ezekre a fordító akkor is generálhat hivatkozásokat, mégha direktben nem is hívod meg ezeket a függvényeket.

Például "__builtin_va_start", ezt lehetetlen portolhatóan implementálni, ehhez mindenképp a fordító builtin-jére van szükség

De ez egy implementációs részlet a C90-ben lévő stdarg.h-hoz (ami freestanding mode-ban is elérhető).
Használj rendesen C90-et, és lesz portolható va_start()-od, és nem kell a fordító builtinje. Eleve a __builtin_va_start csak azért létezik a GCC-ben, hogy a portolható va_start()-ot implementálják. Írhatnál hordozható, portolható kódot, van megoldás, de nem teszed, sőt, konkrét fordítóhoz kötöd magad.

Lásd: https://gcc.gnu.org/onlinedocs/gcc/Standards.html

a conforming freestanding implementation is only required to provide certain library facilities: those in <float.h>, <limits.h>, <stdarg.h>, and <stddef.h>; since AMD1, also those in <iso646.h>; since C99, also those in <stdbool.h> and <stdint.h>; and since C11, also those in <stdalign.h> and <stdnoreturn.h>.

Megint ott tartunk, mint az stdint.h-nál, hogy olyan dolgokra, amikre van portolható megoldás, csak éppen eldobod a portolhatóságot, hogy azt mondhasd, hogy ANSI C-d van. Pedig használhatnál rendesen ANSI C-t.

( bzt | 2024. 02. 20., k – 20:13 )

persicsb: kérlek fordíts figyelmet a szövegértésedre, mert kriminális.

Dehogy konstans, folyamatosan jönnek ki az új szabványok, idén várható a legújabb frissítés

Te már megint tök másról beszélsz. Azt írtam, hogy a github-on a C nyelvű repók aktivitása konstans, nem azt, hogy a szabvány konstans (egyébként az is konstans, mert utólag nem változtatható meg a C89 vagy a C99, és ráadásul minden C fordítónak egyértelműen megadható, mikori szabvány szerint dolgozzon). Arra utaltam, hogy folyamatosan használatban vannak C nyelvű github repók, még annak ellenére is, hogy egyáltalán nincs hype a nyelv körül, és kifejezetten kevés a C programozó.

Nem hinném, hogy bármelyik le akarta volna váltani a C-t.

Márpedig mindegyiket ezzel reklámozták, pont úgy, ahogy most a Rustot is ezzel reklámozzák, lásd topiknyitó. Ha nem tűnt volna fel, a hozzászólásom kifejezetten erről a "leváltja a C-t" baromságról szólt, semmi másról.

( asch v | 2024. 02. 21., sze – 14:30 )

Szerkesztve: 2024. 02. 21., sze – 14:30

A sok kommentelés után el is olvastam a cikket! Színvonalas, jó cikknek találtam. Köszönet a szerzőnek és a hupnak megosztásért! Gratula a szerzőnek! Szinte irígy vagyok, hogy milyen jó kis projekt lehet.