C/C++ fejlesztő/architekt

Állást kínál

BalaBit IT kft.

Applikációs szintű tűzfal termék (Zorp) fejlesztésére és karbantartására keresünk szenior C/C++ fejlesztőt/architektet.

Feladat: objektum-orientált szemléletben, ámbár C nyelven íródott kódbázis újragondolása és modernizálása C++, illetve C++11 környezetben, folyamatos feature fejlesztés közvetlen ügyféligények alapján, a korábbi verziók javítása, karbantartása.

Pozíció leírás: https://career.balabit.com/hu/job/6927798
Kontakt: Pfeiffer Szilárd (mailto: pfeiffer.szilard@balabit.hu)

(A hirdetés a HUP-Profession szabadkártya felhasználásával került kihelyezésre)

( djszapi | 2014. 04. 24., cs – 15:26 )

Szerintem most, hogy a gcc 4.9 kijott, erdemesebb c++14-ben gondolkodni...

Egyebkent warm fuzzy feeling latni ilyen technologiai iranyt a sok C-s gondolkodasu ember utan a mult evezredbol!

Remelem az azert tiszta, hogy a C++11/14 nem csak threading tamogatasrol szol, hanem sokkal tobb, ami a C-bol (celiranyosan) ki van hagyva, hogy "egyszeru" maradjon a nyelv.

Nem tudom elkepzelni, hogy miert kezdene valaki egy C projectbe, akar meg C11 is, egy uj es nagy szoftverre (50-100K LOC <).

Nyilvan, de ezek nem relevans indokok, ha hosszu tavon gondolkodsz, es talalsz olyat, akit erdekel a C++, es esetleg meg jo is benne. A baj az, ahogy en latom a tapasztalatom alapjan, hogy sokan (foleg idosebbek) leragadtak a 70-80-as evekben, es onnan oket mar nem lehet sajnos kimozditani. Ezert is jo latni ilyen innovaciot, amibe a Balabit is ugy tunik, hogy belevag.

Szerintem az, hogy egy nyelvet ilyen régóta használnak, az pont nem azt jelenti, hogy a nyelv rossz. Az pont azt jelenti, hogy anno sikerült beletenni annyi filozófiát, hogy kiálta az idők próbáját. Ellentétben sok mai nyevvel (elsősorban nem a C++ -ra gondolok), amire kár energiát pazarolni, mert 5 múlva dobhatod a tanultakat a kukába mert elavul.

A C-ben ugyanolyan jól és gyorsan lehet fejleszteni, mint bármelyik nyelven - már ha az illető jól csinálja. Aki meg kutyaütő, annak adhatsz bármilyen nyelvet. ;)

Szerintem a BalaBit is azért vált, mert egyre nehezebb C-s szakit találni. Nekem gyanús, hogy ez inkább kényszer.

Ez attol fugg, neha az implementalas tobb ido egy egyszeru otletre, ha (kozel) nullarol kell ird.

De itt nem is ez a kerdes, hogy az otlet tobb ido-e vagy sem. Itt szerintem a Balabit produktivitasra gondol. Vagyis, ha az otlet tobb ido, akkor is tudsz faragni a szoftver tervezes es implementacios koltsegeken, idon es energian a C++-szal.

Coroner lehet majd kijavit itt engem, mert o tobbet tud a Balabit celjairol, de nekem ez lenne a gondolatom, ha hasonlo helyzetben lenne egy ceg, ahol felelos donteseket kellene, hogy hozzak.

Néhány dolgot egy előző hozzászólásban már leírtam, bár nyilván az csak egy kiragadott lista, amit sokáig lehetne folytatni. A személyes véleményem az, hogy egy ilyen kort (10+ év) megért kódbázis kapcsán nem túl meglepő, hogy az írás idejében jónak, vagy éppen egészen újítónak számító megoldások megítélése a hosszú évek alatt megváltozott, hiszen adott esetben megszületett rájuk a nyelvi támogatás, vagy valamilyen standardizált megoldás, így az akkori nagy ötlet ma már inkább nehezen érthető, kissé szokatlan kuriózum, mint roppant ötletes megoldás. Kiragadott példaként tudnék olyan megoldást megemlíteni, mint amit például a Glib is alkalmaz a származtatás megoldására, ami kétség kívül működik, ugyanakkor közel sem ugyanaz, mint amit a C++ nyelvi szinten adni képes, arról nem is beszélve, hogy amíg csak használnom kell egy-egy osztályt nincs igazán útban, ha írni szeretnék egyet, akkor viszont már igencsak körülményes. Egy másik kiragadott példa akár ugyanonnan (de számos más C kód használ hasonló megoldást) a referenciaszámlálás, ami szintén megoldott és működik is, ugyanakkor kényelmében és szolgáltatási szintjében ugyancsak nem hasonlítható például egy shared pointerhez. A fejlesztő eszközök (pl: IDE) ugyanakkor mit sem tudnak ezekről a megoldásokról, míg például STL-es megolás, vagy egy nyelvi elem esetén komoly támogatást tudnak adni. Azt gondolom a lista hosszasan folytatható (természetesen teljesen függetlenül a Zorp kódjától), de talán ennyi is tükrözi váltás mögött meghúzódó elgondolást.

"Vagyis, ha az otlet tobb ido, akkor is tudsz faragni a szoftver tervezes es implementacios koltsegeken, idon es energian a C++-szal."

Mondjuk az én saját tapasztalatom éppen az ellenkezője. C-ben gyorsabban lekódolok valamit, mint C++-ban. (Kivétel, ha pont olyan dolog kell, amihez van kész C++ library, de C-s pl. nincs megfelelő.) (Arról nem is beszélve, hogy ha nem kell a C/C++ "alacsonyszintűsége", akkor egy magasabb szintű nyelv még jobb lehet.)

Ez azért van, mert C-ben egyszerűen megoldom magát a feladatot, még C++-nál állandóan azon kapom magam, hogy "nice design"-t kezdek csinálni, leragadok valami részletnél, miközben C-ben már kész lennék az egésszel. A C++ olcsó absztrakciókat ad, viszont - ahogyan a Tescóban is mindig vesz az ember pár dolgot, ami nem volt rajta a listáján, mert meglátja és "milyen olcsó" meg "milyen jó" - ezzel választékkal roppant sikeresen elvonja a figyelmemet arról a problémáról, amit éppen meg akartam oldani. A C-ben minden absztrakciónak érezhető költsége van, ezért a premature abstraction kevésbé csábító, és így jobb lesz a kód designja.

A produktivitas nem a kodbol fog fakadni, ezt azert belathatjuk. Ha tudsz c-ben es php-ban is ugyanolyan jol kodolni (feltetelezve hogy nincs szukseges olyan komponensre ami egyikben/masikban van csak meg), akkor nem azert fogod egyiket/masikat valasztani mert abban gyorsabban/lassabban vagy meg (normalis esetben a kodolasi ido minimalis kulonbseget fog jelenteni szazalekosan a project egeszehez kepest) hanem azert, mert az adott nyelv erre a teruletre hatarozottan jobb.
En most fejlesztek C-ben egy adatbazis rendszert eleg hosszu ideje, de nem azert nyulik a project mert C-ben irom, hanem azert mert a hatter dolgokat ki kell talalni, jol. PHP-ban is megirhattam volna, de nem lenne olyan hatekony, viszont sporolhattam volna legalabb 20 ora debugolasi idot bizonyos pontokon (ahol a 20 ora alig merheto a project ossz tavjaban).

// Happy debugging, suckers
#define true (rand() > 10)

Igazabol szornyen altalanositasz egy nagyon specifikus esetbol, amit nyilvanvaloan nem lehet.

Nagyon kis kodbazison kell dolgozz nagyon keves programozassal, ahol C vagy PHP (vagy egy masik magasabb szintu nyelv, pl. C++, D, Go, Python) kb. ugyanaz az ido fejlesztesre.

Ahogy az egyik korai hozzaszolasomban leirtam, minimalis kodbazisra, keves kodolassal a C jo lehet.

Nem hinnem, hogy a Balabit ilyen kis kod bazissal dolgozna, es en is mar evek ota 500-700.000+ LOC kodbazissal dolgozok minimum.

Azzal szerintem, hogy egy adott project eseteben maga a kodolas a legkevesebb munka, jo esetben mindenki egyet ert (ha meg nem, akkor nala van valami elkurva). Annyira meg nem is kicsi az a kodbazis amin dolgozom, de ertelemszeruen ez nem egy evek alatt osszehordott project (kodbazis merete pedig egyertelmuen ezt jelzi), viszont az, hogy amin dolgozom eppen, nem 500e+ LOC bazissal rendelkezik, de cegen belul a legtobb termek boven eleri ezt a kategoriat (es az adatbazis is ezekhesz keszul, szoval overall meg ezt is kijelenthetnem, sot, akkor inkabb ki is jelentem hogy 3m+ kodsor van).
Azzal meg szerintem mindenki egyet fog erteni ismetelten, hogy ha magabiztosan mozogsz az adott nyelven akkor a fo kulonbsegek nem ott fognak megmutatkozni, hogy most az c, c++ vagy javascript, esetleg barmi mas, hanem a project idohanyadanak nagy reszeben kitalalt megoldasok implementalasa, ami minden nyelven lehet szopas/vagy sem.

// Happy debugging, suckers
#define true (rand() > 10)

> Azzal meg szerintem mindenki egyet fog erteni ismetelten, hogy ha magabiztosan mozogsz az adott nyelven akkor a fo kulonbsegek nem ott fognak megmutatkozni, hogy most az c, c++ vagy javascript, esetleg barmi mas.

Igazabol itt joparan nem ertenek ezzel egyet. Szerintem ezt meglatod, ha elolvasod a hozzaszolasokat figyelmesen. Ugy probalod felfesteni, mintha a szoftver design es implementacio egy nagyon elhanyagolhato jarulekos koltseg lenne egy cegnek. Ez nagyon nincs igy, foleg hatalmas projecteken. Szerintem ezzel a fejlesztesi cegek nagy resze nem fog egyet erteni.

Ha az a 3M+ sor C-ben van irva meg designolva, akkor en sok szerencset szeretnek kivanni.

En dolgoztam a Linux kernelen az evek alatt, ami joval nagyobb, mint 3M+ sor, es ugyan objectum orientalt szemleletet probal kovetni, az egesz csak ... fura. Persze ezesetben kb. lehetetlen elkezdeni ujrairni reszeket, foleg, hogy Linus-szal ezt nehez lenne elfogadtatni.

Ellentetben, dolgoztam a Qt/KDE kodbazisan is, es a Qt is millios nagysagrend, es sokkal egyszerubb dolgozni azzal a C++ kodbazissal. Nincsenek mesterkelt dolgok feltalalva, mert a nyelv meg a standard library csak tamogatja a dolgokat, ami nagyon hasznos.

Szerintem ez egy speciális eset, amit írsz.

Én meg láttam pár ellenkező irányú speciális esetet: amikor mindkét megoldás a követelményeknek megfelelő eredményt adott, viszont a C++-ban írt változat több héten át készült, pythonban meg egy eléggé hasonló, a központi részében megegyező változat pár nap alatt készen volt.

Hasonló példa: Pro*C/C++-ban és Motif környezetben megírt UI logika ablakonként 1 hónapos szintidővel az egyik oldalon, és ugyanaz a funkcionalitás Apexben kb. 1 óra alatt összedobálva screenenként (1 új screen = 1 régi ablak).
Persze itt is más lett az eredmény, az egyik egy X-es vastagkliens volt a másik meg egy webalkalmazás, de ugyanazt az adatot jelenítették meg és ugyanazokat a lehetőségeket adták a felhasználónak.

Szóval inkább úgy mondanám, hogy van olyan eset, amikor azért választunk egy nyelvet vagy technológiát, mert a végeredmény szempontjából az jobb, és van, amikor kifejezetten csak a fejlesztési idő és a karbantartás könnyítése miatt.

Hát, valahogy nekem sem jöttek össze hónapos vagy éves megtakarítások abból, hogy az egyenlőségjel helyett strcpy.. kell írni. Jó napok se, órák se, ... :D Inkább azon csodálkozom állandóan, hogy ez egyáltalán érv.. :D Fel nem tudom fogni... :)

"That is alright".

En sem ertem, hogy miert nem a konnyebb uton mesz, meg ha nem is "eves megtakaritas". Egyebkent, ha osszeadod oket, akkor ki fog jonni egy nagyobb projectben sok fejlesztovel.

Szerintem itt mar leterunk az esz ervu beszelgetesrol, mert ha kevesebb munkaval ugyanazt elered (fuggetlenul attol, hogy mennyivel), akkor en nem tudok olyan embert mondani a kornyezetemben, aki nem azon az uton menne, felteve, hogy nem megrogzott manias egy masik dologra.

De ahogy mondtam, az mar szemelyes szempont az esz erv felett erzelmekkel, itt pedig egy technikai projectrol van szo objektiv mutatokkal.

Én a (nem kevés) év során mindig arra törekedtem, hogy lehetőleg ne csak azt oldjam meg szigorúan ami a feladat, hanem olyan legyen a megoldásom hogy a legközelebbi projektnél fel tudjam használni. Így elég szép készletem gyült össze a legkülönbözőbb problémákra. Ha valami új jön, akkor is a projekt nagy részét "összedobálom" a meglévő dolgokból, és így bőven marad idő, hogy az új részeket úgy dolgozzam ki, hogy ne csak az adott projekthez legyen jó. Ha ezt el tudod képzelni, akkor megláthatod magad is, hogy ezzel a szisztémával szinte semmi előnye nincs annak, ha valami C-től különböző nyelvben kódolnék. Nem csekély előnye a dolognak, hogy - sokszorosan - kitesztelt függvényekkel dolgozom, így a hiba lehetősége is sokkal kisebb. A teszteléssel töltött idő - ami nem elhanyagolható egy átlagos projektben -, is jelentősen csökken. Továbbra is csak nézek és nem értem, ugyan mi lenne a C hibája? :)

mert a fejlesztok 90%-a biorobot. Ha szeretned kifejtem ezt bovebben is, de igazabol kar belemenni mert ebbol csak sertodesek lesznek

// Happy debugging, suckers
#define true (rand() > 10)

Kilephetnenk vegre a "rossz" vs. "jo" programozo beszelgetesbol. A beszelgetes arrol szolt, amig nem lett side-trackelve, hogy *jo* programozok mit valasztanank, "that is", aki nem lusta, nem csokkentett kepessegu, hanem csak produktiv es ezaltal a leghasznosabb eleme szeretne valni ennek a vilagnak.

A jo programozo / mernok azt valasztja, amelyik eszkoz eppen a legalkalmasabb az adott feladat elvegzesere.
Es annak meghatarozasara, hogy mi a legalkalmasabb, sokfele szempontot kell megvizsgalni:

  • az adott nyelv/framework mennyire ismert a kollegak koreben, akikkel egyutt megvalositod a feladatot
  • ha vannak junior kollegak a kornyeken, mennyire van szamukra elerheto tanito jellegu szakirodalom, van-e olyan a csapatban, aki normalisan tudja oket mentoralni az adott kornyezetben
  • mennyire konnyen tudunk egy adott libhez/frameworkhoz tamogatast talalni, akkoar fizetoset
  • mik a hardverkovetelmenyek, amiket tamogatni kell

Vannak meg mas okok is, azonban nagyon fontos, hogy a legtobb indok az mindig "szocialis" abban az ertelemben, hogy a fejlesztes kozossegi, nem egy ember csinalja, hanem tobben, es altalaban a csapat folyamatosan cserelodik, ezert sokkal fontosabbak a human faktorok, mint a hardveres faktorok.

Nem kategorizaltam hogy jo vagy rossz, hanem le biorobotoztam oket. Ettol meg lehet jok es minosegi kodot gyartanak, de csak ugy ha megmondod nekik a konkret feladatot es az elvarasokat. Minel kevesebbet kell gondolkodniuk, annal jobb kodot gyartanak es ez foleg a futoszalagos programozasnal latszik nagyon (alapvetoen java programozoknal), ahol van egy profi 30+ alkalmazottal, o megtudja tervezni, kelloen feldarabolja a projectet aztan a vegen csak osszedobalja ami kiesik az emberekbol. Erre tokeletes a java es a c++, nem kell hozza gondolkodni, meg csak nagyon erteni sem, a nyelv a segged ala tol mindent, egyszeru benne jo kodot gyartani. A C-re ez nagyon nem igaz

// Happy debugging, suckers
#define true (rand() > 10)

Szerintem az tulzas, hogy a C++ programozasban nem kell gondolkodni.

Inkabb azt mondanam, hogy nem az alacsony szintu regota megoldottak problemakkal. De ettol fuggetlenul tervezes, stb, felelossegteljes gondolkodast igenyel, de a C++-szal szamomra ugy tunik, hogy hamarabb eljutsz ehhez a magasabb szintu logikahoz.

Evvel egyébként megmagyaráztad, hogy többek között miért jók a magasabb szintű nyelvek: meg vannak írva a közös dolgok, össze tudsz belőle dobálni valamit, sokszorosan ki vannak tesztelve. Az a különbség, hogy helyetted megírják, helyetted kitesztelik, és ha hibát találnak, könnyű frissíteni minden projektet. Fejből is tudnék írni hashtáblát C-ben, de minek, ha már pl. megvan a .NET-ben? A C nem ettől jó vagy rossz, mert minden nyelvhez lehet kitesztelt library-ket írni.

--

Hogy fejlesztesz ki jo libeket nyelvi elemek nelkul, pl. raii, lambda, template, auto, decltype, operator overloading, inheritance, polymorphism, uniform initialization, constexpr, megfelelo cast-olasok, standard attribute-s pragmak helyett, referencia, move semantics, for each, static_assert, nullptr, strongly typed enum, namespace, kulonbozo fast, save stb integer tipusok, tring literals, stb?

Egy jo libhez a nyelvi elemek nagyban hozzajarulnak.

Én ugyan nem gondolom, hogy a C-nek igazából bármi hibája is lenne, de amikor régen még programozó voltam, jópár év C után elkezdtem a C++-szal ismerkedni, és egy ideig úgy használtam, mint egy jobb C-t.

Azt lehet mondani, hogy neked nincs szükséged azokra a dolgokra, amiket a C++ ad, de azt mondani, hogy a C a legjobb, az kb. azt jelenti, hogy a fejedet a homokba dugod és nem vagy kíváncsi semmi másra.

sokminden ami c++ -ban automatizmus rejtett csapda, c -ben plusz munka explicit, olvasható kód

Azért ezt az aspektust ne próbáljuk már elrejteni... Akinek a gépén nincs ott a hivatalos szabvány PDF-ben (vagy legalább a final draft), az ne döngesse már a mellét C++ programozóként. (Általában beszélek, nem konkrét személyekről.)

A C++-szal mindig is az volt a legnagyobb gyakorlati probléma (eltekintve a korai implementációk minőségétől ill. a horozhatóságtól), hogy hatalmas. Extrém fegyelem kell a használatához. A szabvány újabb iterációi további bővülést hoznak, amelyek (némileg mosdatlan véleményem szerint) jó része ráadásul csak kényelmi; így nem igazán jó irányba mozdult a nyelv.

A véleményem persze nem igazán releváns, mert (szerencsére) hosszú évek óta nem írok (csak néha olvasok) C++ kódot. (Főleg C-ben dolgozom, és igen, a gépemen ott vannak a szabványok / TC-k / final draft-ok.) Azt viszont időről időre látom, hogy mekkora bakot tudnak lőni gyakorló C++ programozók a hiányos nyelvismereteik miatt. (Ismétlem, nem konkrét személyekről beszélek, főleg nem ebből a topicból.)

Általában ezt a linket szoktam beszúrni: http://www.gotw.ca/gotw/

Ha lesz link, kérlek, rakd ide.

Legutóbb én ezt néztem meg (igaz, nem nagyon friss előadás): http://herbsutter.com/2013/02/11/atomic-weapons-the-c-memory-model-and-…

Még annyit akartam szerkeszteni az előző hozzászólásomon (de túl gyorsan reagáltál :)), hogy:

Különféle ad hominem-eknek elébe vágandó megjegyzem, hogy néhány évvel ezelőtt megcsináltam a BalaBit (kemény, C++-t is tartalmazó) felvételi vizsgáját. Kifejezetten jól sikerült (ha jól emlékszem az értékelésre); kaptam ajánlatot. Különféle okok miatt végül nem náluk helyezkedtem el, de azóta is fenntartom a véleményemet (amelyben az akkori interjúnak kifejezetten nagy szerepe van), hogy mind szakmailag, mind a szoftverfejlesztés társadalmi vonatkozásaiban az egyik leghaladóbb cég. Akinek sikerül náluk elhelyezkednie, vállon veregetheti magát.

Sok dolog elhangzott a szálban, itt összevonva reagálnék.

A C-ben ugyanolyan jól és gyorsan lehet fejleszteni, mint bármelyik nyelven - már ha az illető jól csinálja.

Ez azért nem igaz, bár ha olyan nyelvet kell mondani, amiben gyorsabban lehet fejleszteni, mint C-ben, akkor nem a C++-t fogom mondani, hanem valami magasabb szintű nyelvet, pl. Python, vagy Java, Lisp, Ruby stb.

Ezzel nem értek egyet, egyszerűen nem elég jó a típusrendszere, emiatt sokminden ami c++ -ban automatizmus, c -ben plusz munka.

Noha az eredeti állítással sem értek egyet, azzal sem, hogy C-ben a fejlesztés sebessége azért nem optimális, mert "nem elég jó a típusrendszere". Sokkal inkább az automatikus memóriakezelés hiánya, adott esetben a magas szintű concurrency primitívek hiánya, header fájlok, forward deklarációk... ezek sokkal inkább okok.

Azt sem mondanám, hogy a C++-nak jobb típusrendszere van.

sokminden ami c++ -ban rejtett csapda, c -ben explicit, olvasható kód

Ezzel viszont nagyon egyetértek.

Akinek a gépén nincs ott a hivatalos szabvány PDF-ben (vagy legalább a final draft), az ne döngesse már a mellét C++ programozóként.

Én azt gondolom, hogy akinek a szabványt kell bújnia, az nem a szoftverfejlesztő, hanem a language lawyer. Mondjuk elég szomorú, hogy a C++ annyira bonyolult, hogy ez a fogalom egyáltalán létezik.

"Sokkal inkább az automatikus memóriakezelés hiánya"

Ez igaz, de sokkal egyszerűbb példával is el lehet indulni, mondjuk hozzáfűzés egy stringhez (append). Mezei C-ben strlen-nel megnézed mind a 2 string hosszát, realloc-olod az elsőt és memcpy-zod a másodikat. Ez szép meg jó, de a jobb teljesítmény miatt nem jó mindig megkeresni a lezáró nullát. Így létrehozol egy struktúrát, ami a hosszt és a char*-ot is tartalmazza, és hozzá készítesz függvényeket, hogy csak egyszer kelljen megírni őket. Jobb helyeken egységbe zárják ezeket, osztályba és dobnak hozzá operátorokat a kényelmesebb használat miatt. Már ez is megmutatja, hogy alap string kezelésre nem való a C.

A következő lépés persze az, hogy stacken hozd létre a string változódat (példányodat) és biztosítsd, hogy használat után a scope (pl. függvény) ilyen-olyan elhagyásakor fel is szabaduljon. C-ben esetleg több helyen is meg kell hívni a felszabadító függvényt, C++-ban meg ott a destructor.

Ezek nem létező problémák C++ programozóknak, mezei C programozóknak komoly technikai gondok. Ráadásul a C itt semmiféle teljesítménybeli előnyhöz nem juttat, csupán kézzel írod meg pontosan azt, amit a C++ fordító megtesz helyetted.

"header fájlok"

Erről jut eszembe: http://www.objectmentor.com/resources/articles/dip.pdf 8. oldal.

A D es Go nem hasonlithato a C es C++hoz a GC miatt.

A Rust hasonlithato lenne, es jobb nyelvnek is tunik a C++-nal joval, mert szakitottak a C-bol orokolt hulyesegekkel, es uj laprol indultak, ezaltal sokkal innovativabbak tudnak lenni, bar sajnos az "eco-system" nincs ott, emiatt kb. hasznalhaltatlan most komoly celokra jelenleg. Remelhetoleg ez valtozni fog, mert nagyon igeretes projekt.

Szerintem a C++ csak annyira marad jo nyelv, amennyire a C kompatibilitas megengedi, meg akkor is, ha par dolgot mar megtortek. Ide tenyleg egy clean restart kell, mint pl. a Rust.

Ez most nem személyes, csak kijött belőlem :)

A fejlesztett szoftverek hány %-a lehet az, amikor szándékosan NEM SZABAD GC-t használni? Az esetek hány %-a az, amikor tényleg fontos, hogy most én
memóriaterületre írok, és nem egy elméleti tömbbe, amit majd a rendszer valahogy lefordít egy bináris kódba? Ehhez képest mindenki alacsonyszintű
nyelven akar fejleszteni, mert az milyen "hatékony", és különben is ő egy "okos" fejlesztő, aki pontosan tudja, hogy mit csinál, és őt a programnyelv csak
ne korlátozza. Lásd még OpenSSL kód review, érdemes megnézni, hogy milyen javításokat raknak bele, milyen az egész kód.

Nem gondolom, hogy barki vitatna, hogy hiba nem csuszhat be valahol. Azonban annak a valoszinusege mar vitathato. Peldaul, ha elkezded hasznalni a C++ kontenereket, vagy magad irod meg 0-rol, stb, es mindent magad kezelsz C-ben.

Most persze azt lehet mondani, dehat irhatsz ra konyvtarat, es lehet hasznalni, persze, de a C++-ban ezt hivjak standard library-nek, hogy sokkal jobban integralodjon a core-ba. Es ekkor meg nem is emlitettem a nyelvi elemeket.

Ugyanúgy túlindexelheted az std::vector-t is, mint ahogy egy malloc-kal lefoglalt tömböt. Nem igazán értem, hogy az ilyen hibáktól hogyan óvnak meg az STL konténerek.

Som-Som pedig irt Neked egy peldat.

De egy masik trivialis pelda a for each, amikor gyakorlatilag visszakapod mindegyik elemet, anelkul hogy alacsony szintu index-ekkel vacakolnal, amiket ha rosszul hasznalsz, elindexelheted vele a containert.

A masik tipikus pelda a mutato tomb, ahol betehetsz okos mutatokat.

Megint masik pelda, hogy lekerdezheted a meretet.

Megint masik pelda, hogy konnyen beszurhatsz elemet a kozepere.

Megint masik pelda, hogy konnyu algoritmusokat futtatni rajta

* rendezni
* talalni elemeket
* replacelni

... stb.

Na ezek nagyban hianyoznak a C-bol, es "kodold magad" az egesz. A linux kernel is kb. ezt teszi, feltalalja a C++ standard library-t, es hatalmas mennyisegu munka megy a fejlesztesbe meg a karbantartasba, mindemellett termeszetesen folyamatos kellemetlen bugokkal, stb.

Tenyleg rengeteg ilyen eset van. Hosszu lenne minden szivast felsorolni, amikkel az emberek az evtizedek alatt szembesultek, es probaltak kijavitani a C++-ban.

Szerintem nem ez a lényeg. Tök mindegy, hogy pl. Knuth könyve alapján bepötyögöd, a netről másolsz vagy az std::sort-ot használod. Egyik esetben sem te találtad fel a pl. quick sortot.

A lényeg az, hogy vagy a nyelv tolja alád elegáns formában a dolgokat vagy te magad szerencsétlenkedve, csúnyább kóddal jutsz el pontosan ugyan oda. Pl. a fentebb is linkelt általános másoló megoldást írd meg C-ben. Meg lehet írni pl. függvénypointerekkel. De a kód ocsmány lesz, és igazából a C++ fordító is valami hasonlót tesz. Akkor meg ugyanahoz az eredményhez miért szeretnél sokkal rosszabb és lassabb úton eljutni?

"te magad szerencsétlenkedve, csúnyább kóddal jutsz el pontosan ugyan oda."

Ja, mert amit más ír az a tuti, te csak szerencsétlenkedni tudsz és ocsmány kódot írni?
Akkor mindegy, amit nem tesz alád a nyelv, akkor az is ocsmány szerencsétlenkedés lesz, csak egy szinttel feljebb.

Nem értem, miért kérdezed. Ha valamit kézzel kódolsz oda ahelyett, hogy a fordító generálná oda, akkor szerintem azt lehet szerencsétlenkedésnek nevezni. A nagyobb kód meg ez esetben ocsmányabb is, hiszen minden vackot oda kell írni ahelyett, hogy a szín tiszta funkció lenne ott.

Igen, a szerencsétlenkedés és ocsmányság legyen csak egy szinttel lejjebb. Ha ennek nem lenne értelme, akkor sokan kódolnának aktívan Assembly-ben. Szeretsz minden függvényhívásnál a stackkel vacakolni, vagy rábízod a paraméter átadást pl. a C fordítóra? Na ez van a C és C++ viszonyában is.

Igen, teljesen egyetertek Som-Som-mal.

Hardhead: nem vitatjuk, hogy jo programozo vagy, sosem vitattuk, es ezt sem ironikusan irom most. Lehet, hogy jo programozo vagy es meg tudod oldani ugyanazt a feladatot, ugyanolyan jol, vagy meg jobban, mint ahogy masok megoldottak.

De a lenyeg nem ez, a lenyeg azon van, hogy itt egyszer oldod meg a feladatot jol es utana hasznalod kulonbozo projecktekben, ahelyett, hogy egy zseni programozo mindig megirna mindenhol.

A C++ programozok is meg tudnak ugyanazt irni nyilvan, ha jok, de a kerdes nem ez. A kerdes, ahogy fentebb irtam, hogy minek? Egy project akkor mukodik a legjobban, ha minel produktivabb, es ehhez a nyelv valasztas egy nagyon fontos lepes egy szoftver programozos projectben.

Én egyszer oldom meg a feladatot és használom különböző projektekben. Miért kell ehhez C++? Nem értem. Sosem akadályozott meg semmi, hogy olyan kódot írjak, ami más projektekben felhasználható. Sőt! Mindig erre törekedtem! Nem tudod Nekem bebizonyítani, hogy a C erre alkalmatlan, mert pár évtizedes ellenpéldám van.

Ez a szal nem arrol szol, hogy Te mekkora zseni meg tapasztalt vagy.

A kommentek onnan jottek, hogy valaki hogyan tud standard nyelvi elemekkel es konyvtarral fejleszteni mindenfele spanyol viasz feltalalasa es 10-30 ev "tapasztalat" nelkul random libek osszedobalasaval _minden_ _egyes_ _projectbe_ _kulon_ _kulon_.

Ez igazan nem hasznos a vilagnak, hogy Te osszeirkaltal dolgokat magadnak, ami barki mas szamara elerheto elerheto regebb ota a C++-ban. Talan meg sajat nyelvet is irtal custom parser-rel, amit ugyancsak "bedobsz a projectbe", ki tudja, vagy mondhatnam kit segit mindez...

Tovabba, a pelda elegge lesarkitott, mert a standard library csak egy resze a dolgoknak. Hol vannak meg akkor a nyelvi elemek, mint template-k, operator overloading, function overloading, auto, lamdbda, uniform initialization, constexpr, stb. folytathatnam a sort.

Mi tenyleg nem arra vagyunk kivancsiak, hogy neked mekkora tapasztalatod, meg tehetseged van. Ez biztos jo tema egy masik threadben, de itt ez szerintem off-topic. Mi egyszeruen produktivan szeretnek alkotni a vilagban egyutt. Hol lenne az nekem, vagy masnak hasznos, hogy Neked valahol valamikor valahogyan valamerre van egy osszedobott library hegyed?

Ez tenyleg senkin nem segit, es szerintem az a szal kezdi elveszteni a produktivtasat. Ez mar olyan szinten side-track barmifele ujrahasznalhato rendszerszintu gondolkodas nelkul egy produktivabb vilagert, hogy nincs ertelme ezen a vonalon tovabb folytatni.

Nem is azért írtam, hogy én micsoda zseni vagyok, hanem arra gondoltam, hogy ha engem nem akadályozott meg abban, hogy hatékonyan kódoljak, akkor mást sem kell, hogy akadályozzon. Azt hittem, hogy ez világos, de már látom, hogy külön el kell mondani. Ha egyetlen példa van arra, hogy a C lehet hatékony megfelelő hozzáállással, akkor onnantól lehet bármit mondnai a C-re, nem ott van a gond.

Igen, nem teljesen kerek a többiek érvelése. Tök mindegy, hogy STL, Qt vagy "hardhead" library-t használunk, ugyanúgy újra lehet használni, ha már egyszer megvan. A saját libekkel inkább az a baj, hogy költséges fejleszteni, tesztelni, nem ért annyi ember hozzá, máshonnan átvett kódok/libek nem ezt használják.

De ezek apró részletek. Ha nyelveket akarunk összevetni, akkor a C és C++ összevetésében egy jó példa a containerek használata. C-ben is létezhetnek, miért is ne, de ha a fejed tetejére is állsz, akkor sem lesz olyan szép a kódod, mint pl. C++-ban vagy Javaban. Ráadásul egy rendes C++-os template nem fog nagyon különböző gépi kódban végződni, mint egy C-s megvalósítás, hiszen a template nagyjából típus függő függvények automatikus generálása.

"A saját libekkel inkább az a baj, hogy költséges fejleszteni, tesztelni, nem ért annyi ember hozzá, máshonnan átvett kódok/libek nem ezt használják."

Sajnálom, hogy Te sokkal jobban bízol mások munkájában, mint a sajátodban. Megfelelő szervezésben, felépítésben igen nagy bonyolultságú dolgokat lehet összepakolni - relatíve hamar. Mondjuk, tényleg kell némi szervezői kézség is. Lehet, hogy nem mindenkiben van ez meg és ezért jólesik egy nyelv ami sorvezetőként vezeti, hogy mit csinálhat és mit nem. Én úgy gondolom, hogy aki az akármiylen libeket írja, az ugyanolyan programozó, mint én. Nem bízom kevésbé magamban, mint egy akárhol a nagyvilágban dolgozó - számomra ismeretlen - programozóban. Ha Te mások kódjaiban jobban bízol akkor, OK. elhiszem, ne fejlessz saját libeket, de azért ne gondold, hogy más sem képes minőségi kódot írni.(Kivéve a távoli ismeretlenségbe burkolózó kóderek.) :)

"nem ért annyi ember hozzá,"

Ez csak dokumentáció kérdése. A világ egyik libjéhez se ért bárki születésétől fogva. Már, ha a publikáció - adott esetben - egyáltalán cél.

" máshonnan átvett kódok/libek nem ezt használják."

Hát igen. Ez már igaz. Még sosem történt olyan, hogy kerestem egy libet ami megoldja a gondomat és az az én - esetleg még el sem készült - programrészleteimet használta volna. :D Bár úgy gondolom, hogy ezzel nem vagyok egyedül. :) (Na, jó - nem teljesen igaz, mert - van pár callback függvény amire nem igaz, mert azok így működtek. :D )

"Sajnálom, hogy Te sokkal jobban bízol mások munkájában"

Nem olvastad el figyelmesen, amit írtam. Semmi olyat nem írtam, hogy miben bízom meg vagy miben nem. Én a költségről írtam.

A hozzáértés nem csak dokumentáció kérdése. Sok ember van úgy a munkaerőpiacon, hogy többé-kevésbe ismeri az STL-t vagy a Qt-ot. A te cuccodat megismerni költség.

Nyilván költség az is, ha valaki az STL-ben elront valamit. De az STL (a gcc-vel ellentétben) ritkán szokott hibát tartalmazni.

> Ha egyetlen példa van arra, hogy a C lehet hatékony megfelelő hozzáállással, akkor onnantól lehet bármit mondnai a C-re, nem ott van a gond.

A baj az szerintem, hogy Te valtig azt hiszed, hogy hatekony vagy. Kiallnek Veled egy modern tuzparbajra, ahol nem a kricsni ele megyunk ki pisztolyokkal, hanem egy komplex feladatot kell leprogramoznunk, Te C-ben, En C++-ban. :-)

"Sosem akadályozott meg semmi, hogy olyan kódot írjak, ami más projektekben felhasználható."

A szerzői jog komoly akadály tud lenni. A saját, kódod ha munkaviszony keretében született tulajdonképpen nem a tiéd (már ami az vagyoni jogokat illeti), hanem a cégé, ahol a munkaviszony keretében létrehoztad, így ha nem valamilyen megengedő licencet alkalmazott rá a cég, akkor egyáltalán nem hordozható. Ha mégis, akkor ennek a megengedő licencnek a használatát (ha máshol helyezkedsz el) a másik cég szabályzatainak is meg kell engednie, akkor tudod hordozni, különben nem. Vagyis ha a két cég közül bármelyik szigorúan zárt licenc mellett fejleszt máris ott vannak az akadályok.

Még jó, hogy ez a C++ kódokra nem vonatkozik! :D

Valakinek szólnia kellene már, hogy a OOP szemléletből a "kód újrafelhasználhatóság" egy rosszul kitalált paraméter és tenni kellene valamit, mert az erre valaó törekvés - a szerzői jogok miatt - eleve hibás! :D

A licencével szerintem semmi gond. LGPL, ami nem a legszerencsésebb, de használható pénzért árult, zárt forráskódú termékekhez is.

A többit nem vitatom. Sőt egyenesen furcsállom, hogy miért akarná valaki használni, ha van C++ is, ami rendes nyelvi támogatást is rak az egész mögé.

Majdnem igaz. LGPL-es libbel lehet statikusan is linkelni, de biztosítani kell, hogy módosítani tudja a termék minden jogos felhasználója a libet. Ez macerás. Ezért írtam, hogy "nem a legszerencsésebb".

LGPL-nel nem linkelhetsz statikusan a kodod (bizonyos) szintu felnyitasa nelkul. Ez commercial projectben elfogadhatatlan tud lenni. Ilyen gond nincs a libstdc++ es hasonlo MIT/BSD licenszu projectekkel, szoval a velemenyement tovabbra is fent tartom a nem elegge altalanosan hasznalhato licensz, amit a C++ implementatiok meg standard libek biztositanak.

Használok GLib-et, C mellet elengedhetetlennek tartok valami hasonlót, a Zorp is támaszkodik rá, ugyanakkor én is azon a véleményen vagyok, hogy nem hasonlítható össze a C++ standard libraryvel. Kiragadott példaként csak a típusbiztosságot és az allokációk kezelését említeném.

Pl. embeddedben nagyon fontos, ahol a C++ vetelytarsaval valt a C-nek, vagy ma mar akar a Rust is. Igazabol ha nem zavarnak olyan dolgok, mint GC, stb, a vegen lehet mar python-ra is mehetsz.

Ja es D nem igazan fejlodik, es az egyetlen fordito sem open sourcekent szuletett... A go biztos jo a Google-nek valamire, de nem igazan latom tul nepszeruen hasznalva azon kivul, legalabbis annyira, mint a C, C++, Python, stb.

Szamomra csak egy rosszul elsult Rust-nek tunik, vagyis megprobaltak egy friss ujrakezdessel kijavitani a C++ hibait, de becsusztak dolgok, mint a GC, ami sok ember szamara elkepzelhetetlen egy hatekony es rugalmas nativ nyelvben.

"de becsusztak dolgok, mint a GC, ami sok ember szamara elkepzelhetetlen egy hatekony es rugalmas nativ nyelvben."

Azt hiszem, nekik ideje lenne frissíteni a képzelőerejüket.

Bár ha embeddedről beszélünk, akkor a Go eleve nem arra lett tervezve, hanem inkább szerverprogramok írására.

Szerintem nem jol fejeztem itt ki magam: itt az eredeti forditora gondoltam, ami nagyon sokaig az egyetlen volt, plusz a license sem volt megfelelo GPL-re, ahogy az elso linked alapjan az sem, amit az a link tartalmaz.

Tovabbra is fenn tartom, hogy ezek a szempontok tovabbra sem nyeroek:

* GC.
* nem sok nyelvi fejlodes nem jo. Igazabol a hosszu evtizedek alatt nem lett egyaltalan tul nepszeru, es ez egy jel.
* nincsen megfelelo "eco-system".

https://github.com/D-Programming-Language/dmd/pull/1886

http://wiki.dlang.org/DIP60

+ egy érdekes írás arról, hogy mit lehet vele kezdeni ma:

https://code.facebook.com/posts/476987592402291/under-the-hood-warp-a-f…

----
"Kb. egy hónapja elkezdtem írni egy Coelho-emulátort, ami kattintásra generál random Coelho-kompatibilis tartalmat."
Instant Coelho

Itt az opcio nem fog segiteni. Igazabol ez mar regi tortenet. Az emberek tudjak, hogy van ilyen opcio, de ettol fuggetlenul a hard coded GC ott fog maradni a standard konyvtarban sajnos. Ezen mar sokan atragtak magukat, de ez a max, amit ki tudsz hozni belole, tehat GC marad.

Kétségtelenül igaz amit itt leírnak, de attól még a stack mérete erősen véges, voltaképpen egy karaktertömbről és annak kezdő pozíciójára mutató pointerről beszélünk, ami a nyújtott szolgáltatások mennyiségében és minőségében nehezen hasonlítható össze akár csak a Glib által nyújtott GString, vagy az std::string típusokkal, arról nem is beszélve, hogy egy ilyen közvetlen memóriahasználat esetén mennyire könnyű az adott területet túlolvasni, vagy túlírni, utóbbi esetben ha a stack a tárolási területünk, hirtelen találjuk magunkat komoly bajban.

Az a baj, hogy a hozzaszolasaidbol kiderul, hogy azt gondolod azert hasznalnak az emberek C++-t, es nem C-t, mert nem tudnak C-ben programozni. Nekem is, szerintem coroner-nek is, meg masoknak is szamottevo C tapasztalata van.

Megegyszer, itt nem arrol van szo, hogy lusta meg figyelmetlen, itt az emberi termeszetrol van szo, hogy nem tokeletes (igen, meg Te sem, de kerlek ne vedd ezt szemelyes tamadasnak, mert nem annak szanom!), es ha meg azok is lennenk, akkor is csak egyszer fejlesztenenk ki valami tokeleteset, es nem nullarol ujra, ujra, ujra es ujra.

En szemely szerint C fejlesztot mar csak Linux kernel programozasra vennek fel, es azt is csak objektum orientalt szemlelettel, amit a kernel is kovet, vagy nyilvan olyan munkara egy olyan platform, ahol a vendor nem tamogat C++-t, de ez Hala Istennek nagyon ritka manapsag.

Képzeld el, hogy egy log kiíró aprócska függvényben használod az alloca-t, ami normálisan inline-olódna. Azonban a jobb fordítók az alloca-s függvényeket nem inline-olják, mert valójában sokkal később szabadul csak fel a lefoglalt terület, ami stack túlcsordulást is okozhatna. Teljesítményben még így is kijöhetsz pozitívan a mallochoz képest, de nem feltétlenül érdemes bevállalni érte a kockázatot.

A stackkel amúgy sem érdemes vadul játszani, támadások és váratlan hibák sorát nyithatja meg.

A C nelv tanítását már 25 évvel ezelőtt is úgy kezdték, hogy a C nyelv egy olyan nyelv amit "be kell lakni". Ha pedig már megtetted, akkor eltűnik a fent említett hátrány.

A C nyelvnek meg van az az előnye, hogy a számítógépet programozod és nem valami elvonatkoztatott félig kitalált filózófiával kell küzdened.

Ez így elég erős. A C nyelv egy absztrakció az adott processzor felett, épp úgy, mint bármely másik programozási nyelv. Lehet arról beszélni,
hogy ez "gépközelibb", de nem sok értelme van, amióta ugyanazt a forráskódot egy rakás architektúra fordítjuk. Plusz ott van a "fantasztikus"
standard library, ami nélkül ugye nem sok hasznos programot lehetne írni...

" Lehet arról beszélni, hogy ez "gépközelibb"

Nalátod, hogy érted!

"de nem sok értelme van, amióta ugyanazt a forráskódot egy rakás architektúra fordítjuk."

Mi az, hogy amióta? :D A C-ben pont az a lényege, hogy ha megjelenik egy új proci, akkor az első a C fordító. :)

Lehet, hogy neked erős, de a C-ben memóriában gondolkodik az ember nem csupán változókban. És pont az a jó, hogy közvetlenül hozzáférhetek a memóriához. Nagyon sokszor leegyszerűsíti a megoldást.

Elvesztettem a fonalat, mit szeretnel kifejezni ezzel a valasszal... Ezt irtad korabban:

> Lehet, hogy neked erős, de a C-ben memóriában gondolkodik az ember nem csupán változókban. És pont az a jó, hogy közvetlenül hozzáférhetek a memóriához

Erre reagaltam, hogy memoriat irhatsz C++-ban is, es szamos kernelt irtak C++-ban. Megemlitettem, hogy C++-ban is lemehetsz egeszen ASM-ig. Melyik resze nem fedi a valosagot? Miben lenne itt a C-nek elonye? Nem ertem.

1) Nagyon nagyon regi cikk, mindenki ismeri, semmi uj sincs a nap alatt. Ez 2007-ben volt, es ma 2014-t irunk. A dolgok valtoznak... bar altalaban a C-s emberek eleteben nem. Maradnak a 70 es 80-as evek ...

2) Linus valojaban C++/Qt-vel dolgozott, amikor a buvarkodos es merulos alkalmazasa keszult par honappal ezelott. En is atneztem a C++/Qt valtoztatasait. Hat eleg gyatrak voltak, ami azt illeti, de legalabb csinalja, es erdekli. Ez egy jo jel.

Ha tudsz bármilyen linket, hogy Linusnak azóta megváltozott a véleménye és C++ szakikat enged a Linux kernel forráskódja közelébe, akkor ne fogd vissza magad! Tényleg érdekel.

Ez igy tenyleg nem produktiv, mar reg elvesztem, hogy mit szeretnel mondani... Leirtam, hogy Linus is programozik C++/Qt-ban mas projectben, de tegyuk fel, hogy nem igaz, hogy jon ez a C vs. C++ debate-hez? Van egy velemenye megrogzott C-skent, ami ellen sokan felszolaltak, es? O nem isten, meg csak nem is "authoritative" C++ megnyilatkozas teren... csak egy programozo, akinek sok tapasztalata nincs a C++-szal. Mint mondottam gyenge patch-eket kuldott, de a szandekot tisztelem es nagyra ertekelem. Ha osszevetnenk, itt kozulunk nagyon sokan jobban C es C++-ban osszevetve, mint Linus.

Azt gondoltam, hogy HA MÁR KERNEL, akkor nem térünk el a témától egy búvárprogram irányába...
De úgy látom betelt - és elveszett - a stack tartalma és már sosem fogunk vissztérni a ... :)

>A C nyelvnek meg van az az előnye, hogy a számítógépet programozod és nem valami elvonatkoztatott félig kitalált filózófiával kell küzdened.

Ez a c++ra is igaz. Kevésbé mint a c-re, de a híresztelésekkel ellentétben éppen eléggé ahhoz, hogy tudni lehessen mikor miért mi történik.

T& kb. ugyanaz, mint T *const. A linkelt stack overflow oldalon egyébként hülyeségeket állítanak:

"A pointer can point to NULL while reference can never point to NULL."
Ez nem igaz.

"A pointer can be re-assigned any number of times while a reference can not be reassigned after initialization."
T *const-ot sem tudsz újra-assignolni.

A valódi különbségek:
- szintaxis
- const T&-hez lehet konstansokat vagy ideiglenes értékeket kötni.
- function overloadingnál másképp működnek.

> "A pointer can point to NULL while reference can never point to NULL."
> Ez nem igaz.

Nem ertem, hogy ez miert ne lenne igaz...

> "A pointer can be re-assigned any number of times while a reference can not be reassigned after initialization."
> T *const-ot sem tudsz újra-assignolni.

* Dehogy. Ez csak egy const_cast kerdese a pointerre, es szevasz.

* Tovabba, itt a T* es T&-t jellemezte.

?
Persze, hogy rossz ötlet, mondtam hogy jó ötlet?
Ezzel a kiragadott csúnya, de illusztratív példával ezt akartam alátámasztani, hogy ez valóban igaz, és mint ilyen, nem igaz hogy nem igaz:

"A pointer can point to NULL while reference can never point to NULL."

1. Tévedsz. Itt nincs pointer dereferencia, csak pointert konvertálom referenciává. Próbáld ki, ha nekem nem hiszel.
2. Mire is hozzak én más példát? Én azt állítom, hogy tévedsz, amikor azt mondod, hogy reference mutathat NULL-ra. Ezt azon a hibás példán akartam bemutatni, amiről tévesen azt hittem, hogy te arra célzol. Nem tudok más példát, szerintem nincs erre példa, hiszen az állításom pont az, hogy ilyen nincs.

OK, reszben igazad van, leellenoriztem. Most nem tudom eloidezni a crash-t, de a multban (6 eve kb.) csinaltam ilyet, es akkor amit hasznaltam compilert, azon crashelt. Valoszinuleg a compiler nem volt a legmegfelelobb, vagy siman UB.

Viszont a Stack Overflow-s cikket tovabbra sem ertem miert hibas. Nezzuk is meg mit mond a Stack Overflow-s (magasan felszavazott) valasz:

"Pointer can be assigned NULL directly, whereas reference cannot. If you try hard enough, and you know how, you can make the address of a reference NULL. Likewise, if you try hard enough you can have a reference to a pointer, and then that reference can contain NULL."

Meg peldat is ad erre. Amit mondasz, azt o is irja, hogy ha eleg kemenyen probalkozol, akkor meg lehet oldani. Azt is meg tudnad tenni, hogy beinicializalod valamire, es utana atallitod a pointert nullara. Ezt ertik szerintem a "kemenyed probalod" alatt.

Szerkesztes: aha, rajottem, hogy a kerdesre mondjatok ezt, es nem a korrekt valaszra. Kijavitottam a kerdest, koszonom!

Én azt állítom, hogy tévedsz, amikor azt mondod, hogy reference mutathat NULL-ra.

Egy pointerbe minden további nélkül be lehet rakni NULL-t, sőt, nagyon sok könyvtári függvény, ami pointereket használ, művel ilyet.
Ezek után ha a referenciát a pointer által mutatott objektumra inicializáljátok, akkor lesz egy referenciátok, amiben egy NULL-pointer van. Ez itt még minden további nélkül lefut, mivel a referencia implementációját tekintve belül egy kutya közönséges pointer, a referencia inicializálása a pointer által mutatott objektumra pedig nem más, mint az egyik pointer (esetünkben NULL) átmásolása a másik pointerbe (a referenciába).
Majd amikor ezt a referenciát használni szeretnéd, akkor kapsz egy jól irányzott Segfaultot, és nem az inicializálásnál.

x.cc:
#include <stdio.h>
int main()
{
char *ptr = NULL;
char &c = *ptr;
printf("address: %p", &c);
fflush(stdout);
printf("char: %c", c);
return 0;
}

# g++ -g -O2 -Wall -o x x.cc
# gdb x
...
address: (nil)
Program received signal SIGSEGV, Segmentation fault.
main () at x.cc:8
8 printf("char: %c", c);

Én személy szerint szeretem a C nyelvet, de számos tényező mellett nem tudok szó nélkül elmenni.

  • lehet ugyan objektum-orientált szemlélet mellett fejleszteni (ahogy azt a Zorp kódja is mutatja), de roppant nehézkes. Se típusbiztosság, se erőforrás-kezelés (nem csak memória, hanem általában), se kivételek, se konstruktorok, se ...
  • az objektum-orientált elvek (pl: SOLID) alkalmazása csak részben, áttételesen, külön gondolkodással lehetséges, ami szerintem könnyen mehet a hosszú távú fenntarthatóság rovására. No persze tetszőleges nyelven lehet (és szokás is) karbantarthatatlan kódot írni.
  • a unit tesztelés sem lehetetlen, de könnyűnek sem könnyű , ami viszont gátat jelent a TDD alkalmazásával szemben. Természetesen át lehet ugrani azt a gátat, de ha már ugrani kell, az erőfeszítés, ha erőfeszítés akkor könnyen választja az ember fia a könnyebnek tűnő utat, ...

Ez egy rettentoen leegyszerusitett lista, es mar ez is eleg ahhoz, hogy elmenjen a kedvem a C-tol. Neha kuldok Linux kernel patcheket, es jo latni, hogy a kernel objektum orientaltan van felepitve, de ugyanakkor lehet latni, hogy mennyire egyszerubb lenne az elet egy multi-paradigm nyelvvel.

Kemeny ...

Persze, mindent megcsinalhatsz C-ben is, ezt nem vitatta senki, csak a kerdes, hogy melyik fog tobb penzbe, energiaba es idobe kerulni a cegnek:

1) Megirod 0-rol es maintaineled.

2) Hasznalom, mert kesz van es stabil.

Szerintem ez egy altalanos ervenyu (szerintem nagy) kulonbseg a ket keszlet kozott.

Igy van, azzal nem számolnak a fejlesztők, hogy milyen drága is alacsony szintű nyelven fejleszteni. Csak és kizárólag akkor szabad alacsony szintű nyelvhez
nyúlni, ha nincs más lehetőség.

3. Használom, azt hiszem hogy satbil, de nem az. Aztán túrom a netet, hogy mi van, de csak azt találom, hogy több százan ugyanazt kérdezik, mint én... Fejlesztés helyett tovább túrom a netet, hátha net utolsó bugyrában rátalálok a megoldás fonalára...
Na, itt veszik el minden előny.

Amig nincs kello nyelvismeret, addig tanulni kell a nyelvet valoban, de ez nem C++ specifikus.

Ez a pelda, amit emlitesz, barmilyen nyelvre igaz, hogy hianyozhatnak dolgok, vagy vannak benne bugok. Ettol fuggetlenul egy jo nyelvben nem az a tobbseg, meg tudni kell hogy mikor mit lehet hasznalni. Ez sem C++ specifikus.

Az elony ott van, amikor tudod, hogy az std::string rock szolid, es nem kell sajat char* management-t irnod. Ez csak nyilvan egy pelda a sok kozul, de ez olyan terulet, amit eleg nehez utni, igazabol szerintem nem lehet C-ben, vagy nagyon nehez es ritka.

De megegyszer: ez csak egy a sok kozul.

de ez nem C++ specifikus.

Az viszont igen, hogy mennyi energia használható szinten elsajátítani a nyelvet (használható = ne csináljon olyat a programod, amit nem várnál tőle). A C++-nál ez sajnos elég rossz mérőszámot ad...

Az elony ott van, amikor tudod, hogy az std::string rock szolid, es nem kell sajat char* management-t irnod.

A hátrány meg ott van, hogy meg kell tanulnod az std::string működését. Add oda egy egyetemistának egy félév C++ tanulás után az std::string header fájlját, hogy magyarrázza el az összes benne levő karaktert, mi miért van ott, hogy működik, stb.

Ha megirod nullarol ugyanazt, akkor nem kell tudnod a mukodeset? Dehogynem.

Az egyetemistas allitasra meg annyit reagalnak, hogy tobb evig volt a feladatom, hogy egyetemistasoknak segitsek Google Summer of Code projectekben, es igazabol a tapasztalatom az, hogy felev az eleg durva tulzas a std::string hasznalatanak megtanulasara.

Kemeny ...

Megirod 0-rol es maintaineled.

Ez az egész kb. olyan szintű probléma, mint headerfájlokban a függvényfejlécek megismétlése... a maintenance is...
Ha valaki a C-t vagy C++-t eddig el tudta viselni, akkor ez már ne tartsa vissza...

C++ 


class IFoo {
public:
  virtual int spam() = 0;
  virtual void egg(int) = 0;
};

class Foo : public IFoo {
public:
  Foo();
  virtual int spam();
  virtual void egg(int);
private:
  // ide jönnek az adattagok
};

Foo::Foo()
{
  // tagok inicializálása
}

int Foo::spam()
{
  // implementáció
}

void Foo::egg(int value)
{
  // implementáció
}

C 


struct _IFoo_VTable {
  int (*spam)(void *self_);
  void (*egg)(void *self_, int);
};

typedef struct _IFoo {
  const struct _IFoo_VTable *vtab;
} *IFoo;

struct Foo {
  struct _IFoo _;
  // ide jönnek az adattagok
};

int Foo_spam(void *self_)
{
  struct Foo self = self_;
  // implementáció
}

void Foo_egg(void *self_, int value)
{
  struct Foo self = self_;
  // implementáció
}

static const struct _IFoo_VTable Foo_vtab = {
  Foo_spam,
  Foo_egg
};

struct Foo *newFoo(struct Foo *self)
{
  if (self == NULL)
    self = malloc(sizeof(*self));
  self->_.vtab = &Foo_vtab;
  // tagok inicializálása
  return self;
}

#define spam(obj) ((obj)->vtab->spam((obj)))
#define egg(obj,value) ((obj)->vtab->spam((obj), (value)))

Igen, a C-s változat kicsit hosszabb, de ez érthető, hiszen a C++-t eredetileg pont ez a pár sor megspórolása végett találták ki.

Jobb nyelven:

interface IFoo {

int spam();
void egg(int param);
};

class Foo implements IFoo{

public Foo(){

}

@Override
int spam(){

}

@Override
void egg(int param){

}

};

ennyi. Nincsenek header-ek (minek, arra ott az interface), nincsenek olyan hackek, mint a függvény = 0, WTF, nehéz lett volna az absztrakt szót bevezetni, ha
már az interface-t nem sikerült...

Az egész problémát, amit keresztbe-kasul workaroundolunk, c#, java, meg egyéb nyelveken már réges-régen megoldották szépen, tisztán,
biztonságosan. Ott a namespace, ott az interface, pont mindenre elég.

Elolvastad a proposal-t? Megnezted, hogy intelligens IDE-k mar nagyon regota megoldjak a problemat a szamodra?

Meg egyebkent is, ez egy C-s oroklodes. Ha ezt valaminek a rovasara szeretned irni, akkor ird a C-nek, mert az egesz header dolog onnan jon. En nagyon nem szeretem, de ellenben a C-s emberekkel, a C++-s emberek valojaban eloalltak egy igen jo proposal-lal relative regen.

Mondjuk =0 kevesebb gépelés, és mind az abstract -ot, mind az =0 -t meg kell egyszer tanulni, ami kb. ugyanakkora befektetés. Miért lenne egy másfajta jelölés "hack", azt én nem tudom.
Interface -re javában azért van szükség, mert nincs többszörös öröklődés. Ez amolyan többszörös öröklődés light. c++ -hoz nem adna újat, mert már alapból van többszörös öröklődés.
"Jobb nyelv" hehehe.

A tegnapi Bjarne Stroustrup előadás után legszívesebben én is már holnap C++1y feature-öket használnák, de egyelőre GCC csak Debian sid/experimental alatt érhető el, Ubuntuban pedig egyáltalán nem, Clang esetén annyiban jobb a helyzet, hogy Ubuntu Trusty alatt van még 3.5 is, szóval még a Clang használatát is érdemes lehet megfontolni GCC helyett/mellett.

( djszapi | 2014. 05. 02., p – 21:17 )

Paran azt hoztak fel, hogy tobb ismeretet igenyel a C++. Ebben teljesen egyetertek. Azonban azzal mar nem, hogy ha elsajatitod ezeket a dolgokat, akkor nem vagy sokkal produktivabb. Egy pelda a matematikabol: az alap muveletekkel meg lehet oldani a dolgokat, szorzas, osztas, kivonas, osszeadas, stb. Azonban egy komoly matematikus nem fog ilyen alacsony szintre lemenni, amikor komplex matematikai problemakkal talalkozik. Tudni fog a quaternion-rol, integralas, derivalas, stb. Igen, ez tenyleg tobblet tudast igenyel, de ettol leszel aztan produktivabb. Lehetne mas peldakat felsorolni, hogy peldaul miert hasznalunk abc-t fustjelek helyett, stb, mert ez irast es olvasast igenyel az ABC-re, ami komplexebb, stb, de itt produktivitas szolt a C++ oldalan, es en bevallalom a tobb feature-t ezert. Szamomra ez egy eredmenyes "trade-off".

Szerintem csak az a gond a C++-szal, hogy maga sem tudja mi akar lenni... Egy drivert vagy kernelt kenyelmesen meg lehet irni C-ben is, sokkal kevesebb fuggoseggel es jobb kontrollal a program mukodese felett. Egy grafikus alkalmazasra viszont valoszinuleg kenyelmesebb a Java, C#, esetleg Python es meg mindig meg lehet irni 1-2 reszet a programnak C-ben ha valoban ott van egy bottleneck.

:) Erzesem szerint ketto kozott pont van egy "gap" es a cegek ahol dolgoztam/dolgozok pont ezt a rest tomik be a c++-al. Megpedig back-end vezerlo rendszerek. Nekem nincs jo tapasztalatom a java es object-c memoria kezelessel, bar lehet h "csak kifogtam" az alkalmazasokat. Mac OSX alatt pl a mail alkalamazas 1 honap alatt kepes volt 80MB-rol 1.6 GB-ra hizni (folyamatos/este sleep uzem mellett es elobb utobb elfogyott a 16GB a tobbi "remek" program miatt is) es ha mar nagyobb figyelemet kell forditani a memoria kezelesre akkor meg c++ illetve Qt remekul megfelel erre.
Erre c nyelv tul alacsony, java es tarsai nem megfeleloen kontrolalhatok es ezek nem olyan alkalmazasok hogy par ora futas utan lekapcsoljak oket, illetve az eszkozok memoria merete sem sok sok GB (amire fejlesztunk beagyazott kutyu 2 GB-al rendelkezik), viszont c++ (Qt-vel megtamogatva) remek erre a celra. - szerintem.

Nem lovoldoztem en sehova - csak a tapasztalatomat irtam le. Kontrol alatt azt is ertem h a memoria felszabaditasok is manualisan - tervezetten, alacsony szinten - tortennek, nem pedig amikor a GC jonak latja. Amugy java programobol is be lehet allitani a max heap meretet? (Csak kivancsi vagyok)

Minden esetre ha nivos java programok iroi nem allitottak be a megfelelo meretet hanem alap beallitasokkal bezabaltak a memoriat az szamomra negativ dolgot jelent.

Az alap beallitas a maximum heap meretre: max(fizikai memoria negyede, 1GB).
Azaz 2GB ram eseten max 1GB a heap, amit megehet.
1GB RAM eseten 256MB.

Nem a programo irojatol, hanem az inditaskori heap beallitasoktol fugg, hogy egy adott java processz mennyi heapet hasznal, te is allithatod processzenként.

Programbol nem tudod allitani, es ez igy van jol.

"És miért van arra szükség, hogy kézzel szabadíts fel memóriát?"

Nezzunk meg egy eleg gyakori muveletet:
MyObject bigObject = new MyObject;

Ezekkel van tele a programunk. Ezek az objektumok akkor szabadulnak fel, ha az oket tartalmazo objektum torlodik. Csak akkor. (Jol tudom? Ebben nem vagyok biztos, vagy a GC automatikusan torli ha mar nem hasznalja semmi?)
(Guugli2:
The most important thing to remember about Java memory management is "nullify" your reference.

Only objects that are not referenced are to be garbage collected.

For example, objects in the following code is never get collected and your memory will be full just to do nothing.

List objs = new ArrayList();
for (int i = 0; i < Integer.MAX_VALUE; i++) objs.add(new Object());

But if you don't reference those object ... you can loop as much as you like without memory problem.

List objs = new ArrayList();
for (int i = 0; i < Integer.MAX_VALUE; i++) new Object();

So what ever you do, make sure you remove reference to object to no longer used (set reference to null or clear collection).
)

Hogyan lehetne javitani a hatekonysagon? (Gyors googli) Ha mar nem kell a fenti obektum akkor:
bigObject = null;
Igaz ez? Mennyire gyakori ez a modszer a java programozok kozott? Mert ez is manualis felszabaditast jelent..ergo nem sok elonyet latom a GC-nek.

"Ha cpp akkor nem használsz referenciaszámlálót?"
De igen, ellenben ha nem kell mar torlom is ki. Qt eseten meghivom a deleteLater()-t illetve shared pointer eseten a megfelelo metodust. Igy legalabb nem tellik be a 16GB memoria negyede...

Nem tudlak követni.
Ha már nem referálod az objektumot, akkor gc eltakaríthatja, ez kindergarten level knowledge. Viszont többször van az, hogy nem kell explicite null -ra állítani a referenciát, ha egyszerűen kimegy scope-ból, az is jó.
shared_ptr -nek milyen metódusát is hívod meg? A shared_ptr lényege, hogy nincs egy meghatározott owner, addig él az objektum, amíg nem 0 a refcount. Megintcsak, előrébb hozni ezt, ha nullptr -re állítod, illetve weak_ptr -eket vezetsz be (ez utóbbi megfelelőjére is van lehetőség Javaban is, Objective C -ben is), nem igazán ebben áll a c++ előnye, illetve a gc hiányának előnye.

ha csinálsz mondjuk egy metódusban egy objektumot, amire van egy referencia:

void xxx(){
Myobject o = new Myobject();
o.myMethod();
}

Az o egy referencia egy metódusra. Ahogy kilépsz a függvényből, a referencia megszünik, az objektum pedig majd valamikor felszabaditásra kerül (a gc majd eldönti, h mikor)

Ha listába pakolsz, ami mondjuk csak egy metódusban van, és kilépsz, ugyanez fog történni. A gond akkor van, amikor ergy hosszú életű objektum listájába pakolsz és elfelejtesz törölni. Ezt viszont profiler neked azonnal kiszúrja, melyik listában van gáz,az melyik objektumé, és mi van benne, uh 2 percnél tovább még nem kellett keresnem (NAGY kódbázisban)

Null-ra soha nem szoktunk referenciát állítani, ezt cppből átszabadultak szokták csinálni. :-)

Miért jobb mint a referenciaszámlálás: pl. odavissza referencia helyzetet is kezeli, de még egy rakás más dolgot is. Egyébként cpphez is van gc. Ami még nagy előny a java és c#, az az, hogy nem kell azzal foglalkozni, hogy most valami pointer, vagy referencia, hogy adjam át, hogy hozzam létre, stb.

Ez a probléma a C++-ban is ugyanúgy létezik.

Ha jól van megtervezve a program, akkor úgy van a kód függvényekbe strukturálva, hogy amikor egy objektumra már nincs szükség, akkor utána nem sokkal a rá hivatkozó referencia kimegy a scope-ból. Így nem kell explicit =null sem. Persze erre nem kell folyamatosan görcsösen figyelni, ha egyszerűen azt látod, hogy túl nagyra ment a memóriafogyasztás, akkor megnézed, hogy mi fogyaszt, és ha látod, hogy sok dologra már nincs is szükség, akkor szépen refaktorálod a kódot.

"Egy drivert vagy kernelt kenyelmesen meg lehet irni C-ben is, sokkal kevesebb fuggoseggel es jobb kontrollal a program mukodese felett."

Ez nem igaz. Miert ne irhatnam C++-ban ezeket, es nem kell olyan dolgokkal bohockodni, ami C++-ban mar nyelvi elem?

--
NetBSD - Simplicity is prerequisite for reliability

* Apple reszben abban irta az OS X-t.

* Symbian

* BeOS

* L4Ka microkernel

* Haiku OS

* K42

* BareBones

* Windows driverek

* ScmRTOS

es meg sokan masok. Az, hogy a Linux sosem ment el ilyen iranyba, az csak Linus-on mult es mul. :(

Egyebkent szivem szerint C++-t sem hasznalnek, hanem valoszinuleg Rust (*), de az eszem azt diktalja, hogy nincs meg meg az eco-system Rustre. Pont az a baja a C++-nak, hogy nem tiszta lappal indult, hanem a hulyesegeket orokolte a C-bol, es kompatibilitas cimszo alatt cipeli tovabb. Szoval a C++-t ideiglenes workaround-kent kezelem a C-re, de semmikepp sem hosszutavu megoldaskent.

* http://blog.irukado.org/2013/10/c-time/

"Pont az a baja a C++-nak, hogy nem tiszta lappal indult, hanem a hulyesegeket orokolte a C-bol, es kompatibilitas cimszo alatt cipeli tovabb."

Anélkül viszont kb annyian használnák mint az Ada-t...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Adat igazabol egyre tobben hasznaljak, most hogy eloalltak egy uj verzioval a standard-re, nem regiben.

Egyebkent lehet, hogy meglepodsz ha ranezel a rust-ra.

Igazabol meglepoen sokan hasznaljak, annak ellenere hogy uj, foleg senior C++ fejlesztok tertek at a tapasztalatom szerint, akik ertik, hogy a C-vel kompatibilitas az evolution breaking, es tiszta lappal nagyobb innovaciot lehet letrehozni.

Szoval nem hinnem, hogy ez point igy van, ahogy mondod, hogy tovabb kell cipelni ezt.

Az teny, hogy kell egy kis ido mig az ecosystem felepul, es ezert hasznalom a kisebb rosszat (C++0, hallgatva az eszemre. Hivhatsz pragmatikusnak is. :) De nagyon erdekel, hogy mi fog tortenni a Rust-tal!

Ránéztem. Már többször is. Nem visz rá a lélek.

A nagy C++ leváltásra, és tiszta lappal indulásra meg ott a D, már 10 éve. Így első ránézésre nem is látom miben nyújt többet a Rust mint a D. A perverz vonzódás a ! jelekhez mindkettőben tetten érhető... :)

D-ből sem lett sok minden, és a Rust-nak sem jósolok többet. Ecosystem akkor épül fel, ha emberek, sőt cégek használják. Azok meg akkor kezdik használni ha van ecosystem. Kivéve ha valami olyat nyújt ami sokkal több-jobb mint amit a már meglévő nyelvek nyújtanak (Fortran, C, C++), vagy ha saját fejlesztés (Java, C#).
Ez utóbbihoz viszont komoly fejlesztőgárda és pénz kellenek, nem egy mozilla szint.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

A Rust nem hasonlithato annyira a D-hez. Eleg sok a kulonbseg, hol is kezdjem... Tehat:

* D-nel mandatory GC van, meg ha probalod kikapcsolni, akkor is ott marad a standard konyvtarban mar a GC miatt sem. Rust memory-safe, no danling pointers, no data races. Peldaul olvashatsz a blogomon a borrow pointer concept-rol:

http://lpapp.blogspot.co.uk/2013/07/c-and-compile-time-guaranteed-point…

* A D-nek volt par evtizede, hogy bizonyitson, de nem annyira sikerult. Ezzel szemben a Rust eleg uj

* Az elso implementacio, ami sokaig elerheto volt, gyakorlatilag nem free es open source volt. A Rust teljesen free es open source.

* Nincsenek iterator invalidaciok.

* D template-ket hasznal, rust meg generics-eket + type classokat (hasonloan a Haskell-hez), meg hygienic AST makrokat.

* Rust nem hasznal tradicionalis OOP-t sem.

stb, sok mas.

Egyebkent pedig a Mozilla hasznalja, de tudok mas cegekrol is akik elkezdtek, igaz azok kisebbek. Ha felmesz irc-re, lathatod, gyakorlatilag mar nagyobb a community ott, mint a C++-s IRC-e. (554 vs. 517 ember).. Eleg nagy Rust community jott ossze ott, es foleg, akik kiabrandultak a C++-bol, a kellemetlen dolgok miatt, amiket orokolt a C-tol.

En remelem, hogy ez messzire eljuthat meg. Maskulonben nagyon nehez lesz a C++-bol kirobbanni, es rengeteg dolgot nem lehet megvaltoztatni kompatibilitas miatt az idealis iranyba. :(

Nehezen tudom elképzelni, hogy memory safe és mindent olyan hatékonyan meg tud csinálni, mint a C. Gyanítom, hogy vagy a memory safety nem teljes, vagy pedig nem helyettesítője a C-nek.

Mert ami a C-ben nincs meg, a C++-ban viszont igen az altalaban nem ABI kompatibilis kulonbozo forditok kozott, igy nem szivesen hasznalod kernelben. Ugyanigy problemas, hogy rengeteg dolgot nem is hasznalhatsz ami a C++-ban megvan, igy kifejezetten vigyazni kell, hogy ne hasznalja senki. A harmadik problema pedig az, hogy amint C++-t keversz a programba, nem sok lehetoseged van mast hasznalni. A driver framework-ok ha C++-ban keszulnek akkor C-bol nem lehet oket hasznalni. Kb. ennyi a gond. A C pont ezen a teruleten eros.

Szerintem erdemes lehet megismerkedned a Qt bindingokkal, pl. QtC (C), PyQt/PySide (Python), QtRuby (Ruby), QtJambi (Java), es meg sorolhatnam; egy olyan hatalmas C++ projectre, mint a Qt. A C-s emberkek mindig ezzel az egyetlen dologgal probalnak takarozni (a bloat-n kivul, akarmit is jelentsen az), az en tapasztalatom szerint. De ha megnezed ezt a Qt project eseten, azutan lehet majd maskepp latod a dolgokat. Ezek regota megoldott ugyek igazabol. Nem sok uj van a nap alatt ilyen teren.

AFAIK, a QtC halott...
Az ilyen bindingok megoldjak az API kompatibilitast, de az ABI kompatibilitast nem. Fentebb irtad a BeOS-t mint peldat C++-ban irt rendszerre*, tehat gondolom tisztaban vagy a Haiku GCC2 es GCC4 inkompatibilitasi szenvedeseivel is. Tisztan C API eseten ez nem lenne problema, de mivel minden C++, igy van egy komoly fuggoseguk a forditon.

*AFAIK, legbelul a BeOS/Haiku is C es csak a kulsobb reteget hasznalnak C++-t.

Az ABI kompatibilitásnak semmi köze a nyelvhez. Sem a C++ sem a C szabvány nem ír elő ABI-t.

Win-en a C ABI és a COM "standard", míg a C++ ABI nem. Linuxon meg az Itanium C++ ABI lett szabványosítva, és a gcc is azt használja 3.2 óta. (Azaz a gcc 2.9 még nem, és innen ered a Haiku problámája.)

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

+1.

Tovabba, hogy a QtC "halott" (unmaintained, inkabb) az furcsa indok ebben a szovegkornyezetben. Nyilvan az, hogy nem csinalja valaki tovabb a bindingokat szabadidejeben fizetetlenul, nem azt jelenti, hogy a core problemak nem lettek megoldva a C++ -> C binding kapcsan, es nem szolgal valos peldakepp.

Na mindegy. Ez csak egy pelda volt a sok letezo C binding kozul.

Mondjuk azt tovabbra sem ertem, hogy miert szeretne valaki a C-vel takarozni, hogy barmilyen nyelven bindolhato, es ezert tartsuk meg, amikor a Qt-nak is van bindingja kb. minden major nyelvre, ahol hasznalnak Qt-t.

"Mondjuk azt tovabbra sem ertem, hogy miert szeretne valaki a C-vel takarozni, hogy barmilyen nyelven bindolhato, es ezert tartsuk meg, amikor a Qt-nak is van bindingja kb. minden major nyelvre, ahol hasznalnak Qt-t."

Azért mert bármilyen nyelven bindolható. Általában egyszerűen, gyakran automatikusan lehet belőle az adott nyelvhez illő struktúrákat generálni.
Azaz jó esetben csak 1 bindinget kell "kézzel" létrehozni N helyett.

Illetve általában technikailag minden nyelvhez készült binding C-n keresztül valósul meg, mivel az az egyetlen amit minden más támogat. Sose néztem, de biztos, hogy a QtJambi is C-s felületen keresztül kommunikál a Java-val, illetve pl pythonban is egy speciális C-s API-t kell létrehozni, hogy pythonból osztályoknak stb. látszanak.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Nem ertem tovabbra sem: hogy tudsz egyszer megirni egy bindingot kulonbozo nyelvekre, amikor az idiomatic mukodes az teljesen mas tud lenni kulonbozo nyelvekre, sot igazabol framework-rol framework-re? Ha ez igy lenne, akkor C-s libekre nem irodtak volna kulon nyelvben bindingok, pl. openssl, mert akkor mind csak generalva lett volna. Ami nyelvben oke, a masikban lehet, hogy nem, es tobbnyire, mint nem, nem is okes, ezaltal gyakorlatilag kb. mindet kell majd kezzel (is) irni.

Tovabba, manapsag mar a nyelveknek van FFI-je is segitsegkeppen.

(Egyebkent a QtJambi JNI-n keresztul megy, tehat a Java-nak a C interface-n)

"Nem ertem tovabbra sem: hogy tudsz egyszer megirni egy bindingot kulonbozo nyelvekre, amikor az idiomatic mukodes az teljesen mas tud lenni kulonbozo nyelvekre, sot igazabol framework-rol framework-re?"

Vagy úgy, hogy a binding "idegen" marad és lesz egy c-sezrű felülete, vagy úgy mint pl a glib rendszerek, némi külső segítséggel és szigorú név policyval.

"Egyebkent a QtJambi JNI-n keresztul megy, tehat a Java-nak a C interface-n"
Azaz tehát még is kellett egy köztes C api. Jelen esetben nem publikus, de van. Erről beszélek.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

"... nem ABI kompatibilis ..."

Kit erdekel? En irom az ABI-t.

"... rengeteg dolgot nem is hasznalhatsz ami a C++-ban megvan, igy kifejezetten vigyazni kell, hogy ne hasznalja senki ..."

Egyedul az exception-ok problemasak, de az is csak interrupt kontextben. Ha valaki akarna, akkor megcsinalhatja. Ha nem, akkor a toolchainben ki kell kapcsolni, nelkule is jol mukodik a nyelv (lasd Qt, XBOX SDK).

"A driver framework-ok ha C++-ban keszulnek akkor C-bol nem lehet oket hasznalni."

Nyilvan ha C++ API-t adok, akkor C++-bol kell hasznalni. Ha Java vagy Python API-t adik, akkor meg azt. Ez nem erv. :-)

Az, hogy C++-bol lehet C-t hivni az nem a C, hanem C++ erdeme. Mellesleg C++ -> C wrapper trivialisan keszitheto, ha igeny van ra, vagy akar lehet eleve azt adni egy C++ rendszer fele.

"A C pont ezen a teruleten eros."

Melyiken?

--
NetBSD - Simplicity is prerequisite for reliability

"Kit erdekel? En irom az ABI-t."
Azert ez egy kicsit eros, nem?
"Az, hogy C++-bol lehet C-t hivni az nem a C, hanem C++ erdeme."
Hat, ez messze nem a c++ erdeme, hanem a szabvanynak amit masok tartanak, a c++ meg beletaknyol egy jofajta "mangling" alkalmazasaval.
Raadaskent c -bol is tudsz c++-t hivni, mert miert ne tehetned? Meg mukodni is fog, barmilyen meglepo, csupan csak nem szep es nem elegans a megvalositas koszonhetoen az onmagaval sem mindig kompatibilis "name decoration"-nek amit sikerult mindenfele szabaly alapjan belehaxolni hogy egyaltalan mukodjon az a taknyolas

// Happy debugging, suckers
#define true (rand() > 10)

En eleve nem ertem, hogy miert hivnal C++ kodot C-bol egy uj szoftverre. Ha csak az az indok, hogy a C-t lehet hivni sok nyelvbol, ezert irsz C kodot, akar C++ kod hivasaval, akkor szamomra az egesz szisztema gyanus. C++-bol bindingolhatsz igazabol mindegyik dominans nyelvre relative konnyeden. Ha ezt megteheted, akkor mi szukseg a C-re? Szerintem egy C interface kellemetlen tud lenni... Peldak:

===== C =====

#define foomultiply(a, b) (a)*(b)

void swap(int *a, int *b) {int temp = *a; *a = *b; *b = temp; }

enum FooBar {
OneFooBar,
TwoFooBar,
InvalidFooBar;
};

enum FooBaz {
OneFooBaz,
TwoFooBaz,
InvalidFooBaz,
};

void do_foo(void);
void do_foo_integer(int);
void do_foo_bool(bool); /* not standard until C99! */
void do_foo_string_and_float(char*, float);
void do_foo_function_pointer(void*);

void bool do_foo_error_occured();

void print_hello(hello);
void print_world(world);

===== C++ =====

namepace Foo { /* can be class, too, obviously */

template < class T >
T multiply(T a, T b) { return a*b; }

// just use std::swap or reference
void swap(int &a, int &b) {int temp = a; a = b; b = temp; }

class Enum Bar {
One,
Two,
Invalid
};

class Enum Baz {
One,
Two,
Invalid
};
void do();
void do(int);
void do(bool);
void do(string, float);
void do(function);

// No need for explicit error check in each part of the stack; just catch the exception

operator<<(std::ostream& os, const hello&);
operator<<(std::ostream& os, const world&);
};

Es akkor raadasul nem is a global teruletet szorod tele. De ez csak par pelda a gaz C interface elvek kozul. Direkt nem is emlitettem a classokat, mert szamomra nem az a varazsa a C++-nak. Szerintem a rust ezt jobban megoldotta trait-tekkel, mint a C++ class-ok. Na mindegy. En nagy ivben kerulom a C interface-ket, amennyire csak lehet.

|Szerintem egy C interface kellemetlen tud lenni...|

Izles kerdese.

Azert a C kod meg mindig veri a C++-t readability-ben. OK, C++ tunhet olvashatobbnak, felteve hogy nem zavar, hogy a compiler maskent ertelmezi a kodot, mint egy human olvaso.

Tudnek meg rengeteg api peldat adni, static_assert vs. #error, stb, de probald meg a fenti C api-t hasznalni, irj ra kliens kodot, majd irj ugyanarra a C++-ra kliens kodot es hasonlitsd ossze. Tobbet fogsz gepelni (joval) es ezaltal olvasni maintenance alatt, kevesbe lesz type-safe, stb. Ebben semmi izles kerdese sincs, ez nem filozofia. :-)

"Tobbet fogsz gepelni (joval), kevesbe lesz type-safe, stb"
Ahaha, tobbet? minel?
a type-safe mar erdekesebb dolog, de ebben azert a c++ sem jeleskedik jobban;)

// Happy debugging, suckers
#define true (rand() > 10)

Tipikus esete, amikor kod is lett irva a benga makro rendszerevel a C-nek, a C++ template-jevel szemben, es meg azutan is valaki azt allitja, hogy a makro type-safe; vagy pelda is lett irva tipusos enumra, stb; emlithetnem a jobban type-safe c++ castokat, stb, no comment... Lehet ide eszerv nem eleg. :)

"Lehet ide eszerv nem eleg. :)"
Igen, ez valoban igaz, de akkor epp ideje lenne hogy valami ilyesmivel is eloallnal, mert mi mar kezdjuk unni:)

// Happy debugging, suckers
#define true (rand() > 10)

A makrók csak szöveges helyettesítést végeznek, utána ugyanúgy lefut a type-checker, azt nem tudják kikapcsolni.

emlithetnem a jobban type-safe c++ castokat

Te miről beszélsz? Bekapcsolt warningokkal minden normális C compiler szól az olyan castokra, ami C++-ban illegális lenne. Ez alól egyetlen kivétel a void* castolása T*-ra, de az meg a malloc miatt úgy van jól, ahogy a C-ben van.

gcc -Wall -Wpedantic main.c

enum Foo {
Bar,
Baz,
Invalid
};

int main()
{
enum Foo foo = 7;
int a;
foo = Bar;
a = foo;
return a;
}

Lehet meglepodsz, amikor nem latsz egy warningot sem. Probald ki ugyanezt modern C++-ban. Nem hogy warningot kapnal, hanem meg forditasi hibat megfelelo inicializacioval static_cast nelkul.


/* egyik header */

typedef enum {
    CHAR_DATA,
    UNSIGNED_CHAR_DATA,
    INT_DATA,
    UNSIGNED_INT_DATA,
    FLOAT_DATA,
    DOUBLE_DATA
} DATA_TYPES;

/* másik header */

typedef enum {
    UNSIGNED_CHAR_PIXEL,
    FLOAT_PIXEL
} PIXEL_TYPES;

typedef struct {
    char* data;
    PIXEL_TYPES type;
} Image;

/* kód a harmadik file-ban */

Image* load_image(const char* filename)
{
    char* rawData = 0;
    /* ... */
    Image* img = (Image*)malloc(sizeof(Image));
    img->data = rawData;
    img->type = UNSIGNED_CHAR_DATA;
    return img;
}

C++: error
C: semmi, még warning se -Wall mellett (gcc)

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

enum Foo foo = 7;
azert vagod hogy ez egy code review alkalmaval nem menne at, sot, en a kezedet is eltornem erte. Ne olyan peldaval gyere, amikor hulye valaki, ennel nagyobb bakit ossze lehet hozni c++-ban (meg ugy mindenben). Szoval ez nem erv, ez egy vicc csak

// Happy debugging, suckers
#define true (rand() > 10)

Ehhez nem kell "blablabla"-nak lenni, hogy ilyet csinalj. Barmelyik tapasztalt programozo vethet hibat, hiszen nem szuletnek hibamentes programok elsore nagy szoftverekben. Ez igazabol barkivel elofordulhat, hogy hiba becsuszik, es elo is fordul. Nyilvan ez egy egyszeru pelda volt, de ezt nehezebb lenne eszrevenni, amikor egy integer valtozot assignolsz, ami enumosan van elnevezve, stb.

Kb ez a baj az egesz thread-del. C-sek: "a C hatekonyabb, es a C++ nem nyujt semmi elonyt a hatekonyabb fejlesztesre", de a masik oldalon meg amikor lefolytatunk konkret vitakat a standard konyvtarrol meg nyelvi elemekrol, akkor meg "megirom magamnak 0-rol" vagy "codereview kell egy ilyen alap dolog kiszureshez". Igazabol, meg a codereview-n is valami at fog csorogni sajnos sok esetben.

Ezek nagyon koltseges es idoigenyes dolgok, amikor letezo konyvtar es nyelvi elemek segitik a fejlesztest, pl. a fenti esetben, hogy valami le se forduljon, ezaltal megakadalyozva, hogy code review rabolna barkinek az idejet. Ez csak egy volt a sok kozul, rengeteg ilyen van. Persze, kerlek adj C++-s peldat, amit C-ben egyszerubb megoldani, mert a C jobban tipusossa tette, stb.

Haladjunk sorban, mert mar kezd kicsit bosszanto lenni az allando ferditesed/nem akarom megerteni/mindenki mas hulye en vagyok az isten mert xm loc-on dolgozom mentalitasod.

"a C hatekonyabb, es a C++ nem nyujt semmi elonyt a hatekonyabb fejlesztesre"
Ilyet senki, egyedul te mondtal (olvasd nyugodtan vissza), amit mindenki allitott, hogy a c messze nem annyira lassito tenyezo, mint ahogy beallitod.

"megirom magamnak 0-rol"
Ilyet se irt le senki konkretan, csak te akarod mindig azt hinni, hogy library egyedul c++-hoz letezik, a tobbi nyelv egy kalap szar.

"codereview kell egy ilyen alap dolog kiszureshez"
Senki nem mondott ilyet, viszont ekkora faszsagot egy ldev nem csinal (mert nem hulye a szakmajahoz jo eselyel), ha meg j., akkor a review-nal ugy is kiderul (es elveszik a kedvet hogy tobbet ilyet tegyen). Vagy c++ alatt nem lehet faszsagot csinalni? Dehogynem, a baromsag nem nyelv specifikus

"Ezek nagyon koltseges es idoigenyes dolgok, amikor letezo konyvtar es nyelvi elemek segitik a fejlesztest, pl. a fenti esetben"
Lehet neked idoigenyes, en nem erzem annak (a fejlesztessel toltott idom meg ezt irja ala, de teny hogy valamivel lassabb, ezt senki nem vitatta).

"Persze, kerlek adj C++-s peldat, amit C-ben egyszerubb megoldani, mert a C jobban tipusossa tette, stb."
Te probalsz meg peldalozni, alapvetoen faszsagokkal. Ez szemlelet, hozzaallas es tapasztalat kerdese, ki miben halad jobban, mit erez kenyelmesnek. Nekem nem okoz problemat csinalni egy hashmap-et, kb 4 perccel tobb mint ha a seggembol huztam volna elo, cserebe viszont ugy alakitom ahogy azt az adott feladat megkoveteli.
A jelenlegi projectem alkalmaval is hasznalhattam volna c++ -t es rabaszhattam volna az std-re mindent (mert igazabol pont ezeket valositja meg, amiket en is), de biztos vagyok benne hogy futasi idoben eg es fold lenne a kulonbseg.

Johetsz peldakkal, bablakkal meg onmagad egekig magasztalasaval, de rolad csak annyi jon le, hogy valahol melyen csak azt hiszed tokeletesnek, amit te mondasz es te csinalsz. Sajnos volt dolgom ilyen fejlesztovel, remelhetoleg soha tobbet nem futok bele ilyen szemelyisegbe.

// Happy debugging, suckers
#define true (rand() > 10)

Egyszer egy Herb Sutter előadást néztem, amikor előadta a Stroustruptól csent random számok beszúrása "rendezett" std::vectorba és std::listbe benchmark példát. És Sutter felteszi a kérdést a közönségnek, hogy nyilván kis elemszám esetén a vektor gyorsabb, na de vajon hány elemnél előzi meg (sebességben) az std::list az std::vector-t? 10? 100? 500?

Ekkor elgondolkodtam, hogy vajon egyszerűen ennyire hülyének nézi a közönségét, vagy ő maga sem sokkal okosabb ennél a szintnél... Nekem teljesen nyilvánvaló volt, hogy az std::list mindig lassabb lesz, std::set-tel kellene próbálkoznia, hogy nagy elemszámra valami gyorsabbat kapjon, mint a vector. Szóval mi volt a válasz, amit Herb Sutter felfedett: Stroustrup megcsinálta a benchmarkot félmillió elemig, és még félmilliónál is gyorsabb volt az std::vector... (What a surprise!)

Visszatérve a hasító táblákra:

Tudhatnád, hogy egy hash table container megírása nem egy bonyolult művelet, és hogy a hash table teljesítménye elsősorban nem is a konténer milyenségétől függ (hogy pl. prím vagy kettőhatvány-e a táblaméret), hanem elsősorban a hasítófüggvénytől, annak jóságától és sebességétől.

Namost, ha user-defined type a kulcs a konténerben, akkor ugyanúgy neked kell a hasítófüggvényt megírni akkor is, ha standard C++ konténert használsz, ha pedig built-in type (integer, string, floating-point), akkor pedig bármikor találsz az interneten azonnal bekopizható hash függvényt, ami ugyanolyan jó (sőt, lehet hogy ugyanaz), mint a C++ standard implementáció.

Érdekes lenne még egy olyat nézni, hogy az adathalmaz méretétől függően hogy változik a sebesség/memória foglalás, plusz csak egy szálon tesztelni,
plusz ugye arról volt szó, hogy általános célokra nem fejlesztünk algoritmust, nem pedig célfeladatra, ez két külön dolog...

Egyetertek.

Igazabol nem ertem, hogy C++-ban miert ne tudna valaki fejleszteni nem altalanos algoritmusokat, ha nagyon kell.

De az is elkepzelheto, hogy nem irt gyorsabbat, vagy a kulonbseg elhanyagolhato, es csak foloslegesen szivott. :)

Ezt benchmark, use case, meg implementacio nelkul nehez kommentelni erdemben.

Meg ha igaz is, ez nem C elony, mert nyilvan C++-ban is tudsz ilyet irni.

Latom te direkt vagy ertetlen.
"Igazabol nem ertem, hogy C++-ban miert ne tudna valaki fejleszteni nem altalanos algoritmusokat, ha nagyon kell."
g++ -al is fordithattam volna a c-s cuccot, attol meg nem lett volna ertelme annak hogy a beepitett dolgokat hasznaljam.
"De az is elkepzelheto, hogy nem irt gyorsabbat, vagy a kulonbseg elhanyagolhato, es csak foloslegesen szivott. :)"
Lehet hogy neked szivas egy hash map leimplementalasa, engem egyaltalan nem hatraltatott, sot... Lehet ez okozza a belso frusztracioidat, nem gondolod?
"Ezt benchmark, use case, meg implementacio nelkul nehez kommentelni erdemben."
Itt egyszeru osszehasonlitas volt arrol, hogy c++ std vs. sajat megoldas. Kar itt a benchmarkot fikazni, egy threaden is jobb volt minden teren es idoben sem volt lassabb leimplementalni. A tobb threadet csak azert raktam bele, hogy akkor nezzuk meg multithread kornyezetben, ahol helybol elverzik az std.
A multithread-et meg azt hogy ismert adatbol indulunk ki, ne nevezzuk mar "use case"-nek

// Happy debugging, suckers
#define true (rand() > 10)

"g++ -al is fordithattam volna a c-s cuccot, attol meg nem lett volna ertelme annak hogy a beepitett dolgokat hasznaljam."

Ja, persze, mert te csak corner case-ket irsz...

"Lehet hogy neked szivas egy hash map leimplementalasa, engem egyaltalan nem hatraltatott, sot... Lehet ez okozza a belso frusztracioidat, nem gondolod?"

Tovabbra is csak hangosan nevetek. :D Ha ezt frusztracionak hivod, legyen ugy. :) Tovabbra sem adtal semmifele _valodi_ use case-t, valodi reprodukalhato stabil benchmark-t, pontos es lefordithato koddal belefoglalva. Ezek hianyaban ez csak random dobalozas.

"Itt egyszeru osszehasonlitas volt arrol, hogy c++ std vs. sajat megoldas. Kar itt a benchmarkot fikazni, egy threaden is jobb volt minden teren es idoben sem volt lassabb leimplementalni. A tobb threadet csak azert raktam bele, hogy akkor nezzuk meg multithread kornyezetben, ahol helybol elverzik az std.
A multithread-et meg azt hogy ismert adatbol indulunk ki, ne nevezzuk mar "use case"-nek"

Kar, hogy nem tudjuk reprodukalni, informacio hianyaban, de meg ha tudnank is, ahogy masok mondtak: alma vs. korte, ertelmetlen. Senki nem allitotta itt soha, hogy a standard konyvtar az 1% corner case-kre valo.

Ebbol bazinagy flame lesz hogy biztos direkt elszartam, meg azt nem ugy kellett volna, blabla:

Csak gyors teszt volt es komplex megoldast valasztottam, mert ez inkabb elofordul mint egy "statikus benchmark". Azonos input (jelen pillanatban 0-tol 10m-ig tarto szamok) illetve egy teljesen random 64bit-es szam, nem minden hashmap, ennel sokkal komplikaltabb az adatszerkezet es a feloldas is. A feloldas tobb szintu, a teljes menete a 64 bites szammal kezdodik, majd 3 melysegben a rangelt szamok.
Azonos eselyel indultak a versenyzok (multithread kornyezetben, 16 magon), a c++ eseteben ez ertelemszeruen azt jelentette, hogy a lookup-oknal mutexeket kellett hasznalnom ami jelentosen rontotta a teljesitmenyt. Az input specialis, ezt c++ eseten nem tudtam kihasznalni mivel sem a vector, sem a hash map-et nem birizgaltam, a sajat c megoldasomban jelentos memoria megtakaritasokat tudtam igy veghezvinni.

5 perc futas volt mindkettonek engedve, az eredmenyeket ez alapjan atlagoltam, az input file-om 500 mega volt
Vegeredmeny: c++ / sajat c
Memoria: 14gb / 380mb
Sebesseg (query/sec): 117e / 392m

Biztos tudtam volna fentebb tornaszni a c++ kodot sebessegben, illetve memoriaban lefele, de igazabol csak a standard cuccok hasznalataval max ha 20-30%-ot nyerek a jelenlegi tempon.

Az elkeszitesi ido kozel azonos volt, ez koszonheto annak hogy az elmult 4-5 honapban masszivan c-vel foglalkoztam csak

Konkluzio: ha a sebesseg fontos, ugy is magadnak implementalsz, itt a c szerintem elonyben tud kijonni a c++-al szemben. Ha nem fontos a sebesseg, akkor az ember ugy is ujra hasznositja korabbi kodjait, nem kell mindent feltalalni ujra, masreszt egy egyszeru map-et 1-2 perc alatt osszedob az ember, az ido nagy reszet fejlesztes kozben meg nem az ilyen kodok gyartasa teszi ki, hanem az adott problema megoldasa es az utkereses

// Happy debugging, suckers
#define true (rand() > 10)

Szép példa csak értelmetlen. Amit te összehasonlítottál az a feladatra optimalizált saját kód vs. általános elemekből összedobott megoldás.
Ugyanezt kipróbálhattad volna egy tetszőles C-s konténereket tartalmazó lib és a saját verziód között.
Sőt, mivel a saját kódod minden bizonnyal lefordul C++-ként (vagy triviálisan átírható), ezért valójában a konklúziód is marhaság...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Igazából az összes c kód lefordul c++-ként (nagyon nagyon minimális kivétellel), szóval igazából akkor minden egy marhaság a te analógiád szerint.
A példám azért lett komplex, mert egyszerű műveleteket nem nehéz c alatt sem elvégezni, minden bizonyára legalább +20 másodpercet vesz el az életemből hogy nem a beépítettet használom. A komplex példa meg pont a hátrányokra mutat rá, hogy vagy így, vagy úgy, de van az a pont (és az esetek nagy részében még ennél is komplexebb feladatokat végzünk) ahol igazából értelmét veszti egy általános megoldás használata. Szóval a konklúzióm csak abban az esetben marhaság, ha a fejlesztés kategóriájában a "bontson szét egy mondatot elemeire" nevezzük task-nak, de ebben az esetben egy érettségizőnek tapasztalat hiányában valóban hasznos lehet

// Happy debugging, suckers
#define true (rand() > 10)

Hogy saját munkatapasztalatból induljak ki, nálunk az esetek 90%-ban elég a beépített megoldások használata, és a maradék 10% az,
amikor performancia probléma van, ekkor kimérjük, hogy melyik kódrésznél, és ekkor használunk komplex algoritmusokat (amit te
nagyon szépen kifejtettél). Viszont nincs annál gázosabb, amikor az újdonsült ifjú (vagy nem olyan ifjú) titán nem a nyelv által
nyújtott elemeket használja, hanem majd ő jól megírja, aztán utána mindenki szív vele. Szabad saját elemeket használni, de csak
akkor, ha tényleg indokolt.

Igen, de ez utóbbi példád c++ -ra vonatkozik (mármint az újdonsült ifjú) rész. A mondandóm lényege még mindig az (csak páran nem veszik a fáradtságot hogy megértsék), hogy alap helyzetben az ember olyan helyeken használja csak a beépített dolgokat úgy is, ami nem kritikus (pl.: sebesség szempontjából), ott pedig kellő tapasztalattal c-ben sem sokkal több idő a megvalósítás. Egy kicsivel nagyobb komplexitásnál pedig már nincs különbség, mivel saját alapon esik neki az ember úgy is, nyelvtől függetlenűl, ahol nem egy hash list megírása viszi el az időt hanem maga a probléma megoldása (és itt már a nyelvi elemek sem fognak segíteni semmiben). Szemben másokkal, én nem azt hangoztatom hogy a c++ szar (ők ezt a c-re mondják), hanem hogy nem vesz el annyi időt mint amennyit állítanak.

"Hogy saját munkatapasztalatból induljak ki, nálunk az esetek 90%-ban elég a beépített megoldások használata, és a maradék 10% az,"
Ez lényegében terület függő erősen, van ahol a bash script is elegendő lenne performancia tekintetében, van ahol pedig fpga kupacot csinálnak egy feladat megoldása érdekében és ez nem vonatkoztatható le magára a nyelvre.

// Happy debugging, suckers
#define true (rand() > 10)

Semmifele frusztracio sincs, bar bemeselheted magadnak, ha ez boldogabba tesz. Ha tenyleg azt gondolod, hogy 20 mp alatt jossz ra algoritmusokra, es implementalod oket, akkor ehhez mit lehet szolni azon kivul, hogy hangosan nevetek (frusztracio ellenkezoje), es nem veszlek komolyan? Van barmifele ertelme valaszolni egy olyanra, amit meg Te magad sem hiszel el, ha meg igen, akkor eleg hiszekeny vagy?

"hogy 20 mp alatt jossz ra algoritmusokra, es implementalod oket"
Egy hash map eseteben? De igy Mar ertem! Szoval a "rutin" szo nem mond neked semmit a fejlesztes kapcsan, mar minden vilagos!:)

// Happy debugging, suckers
#define true (rand() > 10)

Kezdem azt gondolni, hogy a C++ azoknak való, akik okosabbnak akarják érezni magukat az átlag (pl. Java) programozónál, ugyanakkor nem rendelkeznek elegendően mély szaktudással ahhoz, hogy kisujjból használják a reallocot vagy implementáljanak egy láncolt listát vagy egy hash table-t, hogy értsék az egyes magas szintű absztrakciók árát és implementációját, hogy képesek legyenek a nyelvi elemekkel való legózáson túl maguk is absztrahálni, hogy értsék mi is kell a run-time és performance-hoz és mi a programmer productivity-hez...

Amit írsz, az önmagában igaz, mert a C++, meg az OOP úgy általában semmi más, csak szintaktikai csicsa. Pl. template-ek helyett lehet C makrókkal játszani, operátorok helyett lehet függvényeket írni, eltérő paraméterű, de azonos nevű metódusok helyett különböző nevű függvényeket írni, polimorfizmusra függvénypointer táblát létrehozni. Kivétel kezelés meg C-hez is van: http://code.google.com/p/exceptions4c/

A csicsa csak abban segít, hogy emberközelibb és ne gépközelibb legyen a kód. Erre pedig azért lehet szükség, mert egyelőre a kódot nagyrészt emberek írják és emberek olvassák el. Ennyi.

Pedig igaza van, az OOP egy szemlélet/módszertan ami nem ad olyan megkerülhetetlen dolgot, amit procedurális megközelítéssel ne tudnál elérni. Az hogy ez bizonyos nyelvek alatt hogyan van megvalósítva, az már valóban más téma, de ő nem ezt firtatta

// Happy debugging, suckers
#define true (rand() > 10)

Az OOP nyilván egy módszertan (egy absztrakció). De C-ben is tudsz OOP módszertannal dolgozni, legfeljebb nem szerencsés. A C++ hozzá adja a C-hez az OOP-hez kellemes szintaktikai csicsákat.

De nem én vagyok az egyetlen, aki a nyelv által való megvalósítást a módszertanhoz odakeveri. Uncle Bob: "passing an object is just a convenient way to pass a bunch of function pointers."

Nem árt az absztrakciók mögé látni, hogy a C++ OOP nyelvi elemei önmagukban csak csicsák, nem csinálnak semmiféle rejtélyes dolgot és nem hoznak be teljesítménybeli hátrányt. Avagy Stroustrup tollából: "C++ is "a better C" in the sense that it supports the styles of programming done using C with better type checking and more notational support (without loss of efficiency)"
http://www.stroustrup.com/bs_faq.html#difference

Igen, de ezt írtam is korábban. Illetve annyiban azért nem igaz, hogy a C többé-kevésbé platformfüggetlen, ami azért több, mint csicsa, hiszen nem kell sokszor lekódolni u.a.-t. Egy C++ template viszont csicsa, hiszen C-ben is el lehet kerülni a típusfüggő függvények sokszori megírását.

Igen, "tobbe-kevesbe", ez a helyes megfogalmazas. :)

Egyfelol, sajnos rengeteg hasznos fuggveny igazabol "csak" POSIX-os.

Masfelol, a Windowsosok (Microsoft, MSVC) meg a C99-ig sem jutottak el, es tobb, mint valoszinu, hogy nem is fognak, tehat.

Azert az eleg eros kijelentes, hogy a template csak "csicsa". Igazabol ez egy egesz meta-programming nyelvszerkezet.

Makrokkal sok dolgot nem is fogsz tudni megcsinalni ugy, mint templatekkel. De ha meg is tudnad, akkor is csak a szivas lenne vele nagyon durvan.

Egy pelda a variadic template alternativaja. Igen, tudom, hogy C99-ben van variadic macro, de mivel MSVC/MS nem hajlando odaig eljutni, stb, ez egy pelda a sok kozul.

Megint masik pelda a rekurzitas, de sok mas is van a tarsolyban.

Windows? Az meg micsoda?

Ismerek egy nagy szoftvercéget, akik felhőszolgáltatásokban és üzleti alkalmazásokban utaznak. Készítenek is mindenféle appot OS X-re, iOS-ra, Androidra és persze általános böngészőre, így desktop Linuxra is. Gyártanak Android telefonokat is. Elég jól megy nekik. Valami Microsoft vagy mi a nevük.

A C++ szabvány sem írja elő az intek méretét.
Ugyanígy szívás a dolog ott is. HTH.
Ugyanis az std:size_t is gépfüggő.

Ami előírja a primitív típusok pontos méretét, az pl. a Java.

A rutinos Mcsiv: nezd mar, mintha c-ben is lennenek garantalt meretu tipusok, egyebkent meg a standard tipusok architekturafuggoek, nem veletlenul:) De ennek megertesehez esz is kene, ahelyett hogy alapveto bullshitekkel dobaloznal, raadaskent szomoru a headerben a "(since C++11)", nem ertem hogy a verprofiknak (mint te) szant C++ -ban csak ezzel kerult be.

// Happy debugging, suckers
#define true (rand() > 10)

Azert azt vagod hogy a C99 es a C++11 kozott kicsit tobb mint 10 ev kulonbseg van... Raadaskent az utobbi problema a C++ alatt van, C99 supportja mar van egy ideje a visual studionak. Szoval megkerlek megint, ne dobalozz mar bullshitekkel.

Szerk.: Probald mar meg egyszer atgondolni es leirni a gondolataidat, mert kovethetetlen az allando szerkesztesek miatt

// Happy debugging, suckers
#define true (rand() > 10)

Szerintem nem igazan erted a kulonbseget a C fordito es a Visual Studio C++ kozott. A ketto TELJESEN kulonbozo dolog. A C es C++ fordito NEM ugyanaz.

Hagyj ismeteljem meg: a microsoftnak esze agaban sincs a C-t a C89 utan tamogatni. Amit latsz az a C++ fordito, mert azt tamogatjak.

http://www.infoq.com/news/2012/05/vs_c99_support

Igazabol ezen a teren teljesen egyetertek a Microsoft-tal; en sem tamogatnam a C-t tovabb, mert minek.

En visual studio-rol beszeltem, ami egy termek (es azon belul meg eleg sokminden mas is van, pl visual basic;)). Annak ellenere hogy szerinted esze agaban sincs tamogatni, a 2013-as tamogatja a C99 -et (biztos a csunya manok csempesztek bele)

// Happy debugging, suckers
#define true (rand() > 10)

Dehogy tamogatja... bizonyos dolgokat beletettek, de meg mindig nincsenek alapdolgok, mint bool, stb, es tekintve hogy egy mennyi evig nem tettek semmit, nem remelem itt progress-t egyaltalan. Ezen pontban, nincs cross-platform c99 kod, amig ilyen alapdolgokat, mint egy bool-t nem tamogat...

Ahogy elnezem errol is elfelejtettek nekik szolni:
stdbool.h
bool, true, false, __bool_true_false_are_defined

Szerk.: Annyira jo hogy osszevissza szerkesztgetsz mindent. Konyorgok ismet, gondold mar at, mert igy semmi ertelme neked valaszolgatni hogy fel percenkent atirod a hozzaszolast

// Happy debugging, suckers
#define true (rand() > 10)

Fogalmam sincs, hogy mirol beszelsz. A hivatalos dokumentacio itt van az intekre vonatkozoan:

http://msdn.microsoft.com/en-us/library/29dh1w7z.aspx

A bool meg csak ugy tunik az RTM release-re lett megcsinalva:

http://blogs.msdn.com/b/vcblog/archive/2013/07/19/c99-library-support-i…

Igazabol laza 15 ev kulonbseg van kb. a C es C++ kozott Windowson, de ketseges, hogy ha a C89 -> C99 mindossze egy emberoltobe kerult, akkor egyaltalan megcsinaljak-e a C11-t az elkovetkezo 1-2 evtizedben.

Az allitas tovabbra is jogos, nincsen portolhato C kod, csak regi C kod, de az meg ... meg gagyibb, mint az uj.

Szerintem en itt befejeztem a vele valo vitatkozast. Egyreszt mert annyi latszik, hogy zsigerbol utalod a C-t (korabban mar kifejtettem a frusztracioidat), illetve onmagadnak lazan ellentmondasz. Lazan kijelentetted a fixed width tipusok eseteben hogy a windows szar mert nem tamogatja, aztan te magad linkelsz olyat ahol megis, beszelsz itt arrol hogy a szabvanyokat sem tamogatja, aztan csak elokerul hogy megis (raadaskent egyszerre jott a C++11-el, szoval a hatalmas "mi c++ fejlesztok nem szivunk ezzel" megis szivtak ezzel).

Semmi ertelmet nem latom hogy hozzaszolj, csak bullshitelsz allandoan, ossze vissza beszelsz es zsigerbol fikazol. Ahol lentebb meg nem sikerult megdontened a sajat hulyeseg, oda meg nem irtal tobbet mert nem volt mit

// Happy debugging, suckers
#define true (rand() > 10)

1) A Microsoft nem tamogatta a bool-t 2013 RTM-ig, es tovabbra sem tamogat megfelelo inteket. Tehat gyakorlatilag meg a VS is kesobb kapta meg a bool tamogatast (2-3 evre ra), mint alapveto C++11 feature-ket.

2) C++11 messze nem a 2013-mal jott, mert mar rengeteg dolog megvolt a VS2010-ben.

3) A 2013-mal mar jott nehany 2014 feature is.

Laza 15 ev kulonbseg. Megegyszer, ezt nem en mondom, hogy a C++ a fo irany a Microsoft-nal, hanem a Microsoft maga. Valoszinuleg megcsinalta sok-sok ev utan C99-t reszben, mert mar untak a nyafogast, de ahogy ok maguk irjak, az embereknek tobbet kellene C++-t hasznalni.

A VS2013 rettentoen gyerekcipos. Konnyen lehetseges, hogy nem fognak sok energiat C99 bugfixekbe sem az implementaciojukban. Ilyen kornyezetben en nem mondanam ra, hogy cross-platform, ahol egy desktop OS szolgaltato azt mondja, hogy hasznalj C++-t.

Nem sok dologban ertek egy az MS-sel, de ezen a teren igen.

Megint bullshitelsz: ugyan annyira volt C99 tamogatas a vs2010-ben, mint c++11, kb semennyire, es akkor mar linkelgetek en is:
http://msdn.microsoft.com/en-us/library/hh567368.aspx
Ha tamogatasnak hivod azt (rengeteg dolog), hogy a tablazatban "no" van 90%-ban, akkor igen, tamogatta a c++11-et, de legalabb annyira mint a c99-et

De latom meg mindig nem sikerul atgondolni a mondandodat (allandoan szerkesztgetsz). En innentol meg se nyitom ezt a threadet. Osszeszedetlen vagy, ossze vissza beszelsz es bullshitelsz

// Happy debugging, suckers
#define true (rand() > 10)

Egyaltalan nem. A C99-rol itt egy olvasmany a VS2010-es idokbol:

http://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/

Tovabbra is fenn tartom, hogy a C nem cross-platform, mert az MS egyszeruen nem akarja normalisan tamogatni, es a C programozas egy szivas ebbol kifolyolag, ha csak nem mesz bele, hogy osregi C-t kell hasznalj egy stabil szoftverben, legalabbis valamekkora reszben, hogy teljesen portolhato legyen.

Tovabba a pelda meg mindig ott van, nincsenek meg mostsem normalis int tamogatas benne, mint a C++11-ben van, ami az alapja volt a non-cross-platform dolognak.

Az, hogy 4 feature-t tamogat a Microsoft a sok C99 feature-bol, azt nem igazan neveznem valami eros C99 tamogatasnak.

Ezt már írtam neki korábban, hogy a visual studio != windows, de azokra amikbe nem tud belekötni már nem érkezik többet válasz. Rengeteg ilyen "sikeresen lezárt" thread van már ebben a post-ban:)

// Happy debugging, suckers
#define true (rand() > 10)

Akkor mar itt valaszolok a maradekra miutan szerkesztetted:
"Ezen pontban, nincs cross-platform c99 kod, amig ilyen alapdolgokat, mint egy bool-t nem tamogat..."
Annak ellenere hogy bullshit-elsz, azert az ne a nyelv hibaja legyen mar, hogy egy fordito nem tamogatja az uj szabvanyokat. Van mas fordito is, windows-ra is

// Happy debugging, suckers
#define true (rand() > 10)

Persze, kerlek adj C++-s peldat, amit C-ben egyszerubb megoldani, mert a C jobban tipusossa tette, stb.

Stroustrup gondosan ügyelt rá, hogy ilyet ne nagyon lehessen mutatni, így aztán a C++ gyengeségei ennél jóval szofisztikáltabbak.

De azért itt egy példa: 

p = malloc(sizeof(*p));

Ezt kérem egyszerűbben megoldani C++-ban! (Ha ki kell írni, hogy milyen típusú pointer p, akkor az nem egyszerűbb.)

Raw pointer, yuck! Igen, ez mar meg is mutatja a C-s hozzaallast sajat memoria managelesre, amikor mar regota vannak smart pointerek.

Egyebkent meg semmifele explicit cast-ra sincs szukseg egyaltalan, es eleg egyszeru megoldani:

p = new decay< decltype(*p) >::type;

Na de hisz ez több karakter... Ráadásul C++11-et is használsz benne.. Szóval 2011-ben még nem tart ott az advanced C++ technológia, ahol az ócska C már kezdetektől?

Hash define vagy template fuggveny a baratod, ha ilyen meggondolatlan dolgot ismetelni szeretnel, de termeszetesen inkabb tipusbiztonsagra kellene torekedned, smart pointerekre, stb.

A tipusos programozas sokkal tobb elonnyel jar (debug elkerulese, stb), mint nehany karakter megsporolasa egy ilyen corner case eseten. Peldaul ezt irhatnad veletlenul, aminel a fordito nem szol, es majd debuggolhatsz, mig a C++-s verziohoz a compiler nem fog aszisztalni, p es q kulonbozo tipusra mutatnak!

p = malloc(sizeof(*q)); /* Yuck, oopsie! */

Sot, igazabol ide meg a typedef is eleg lenne, es new mytypedef, es akkor csak egy helyen valtoztatod, szoval meg C++11 elott is volt alternative az explicit cast elkerulesere, na mindegy.

Hat meglepo, hogy ez Teged ujonnan ert, hogy nem kell explicit castolas, bar ez alapjan akkor gyanitom sok hasznos feature-t nem ismersz, ami miatt lehet olyan az allaspontod amilyen.

Igazabol mar C++14 is van egy ideje technikailag vegleges formajaban.

Hala Istennek a C++ 2011-ben nem tart ott, ahol a C kezdeteknel. Szomoru lennek, ha ez lenne a helyzet.

"a typedef is eleg lenne, es new mytypedef"
"Hat meglepo, hogy ez Teged ujonnan ert, hogy nem kell explicit castolas"

Jól elbeszélgetsz magaddal, én egy szóval nem említettem az explicit castolást, hanem a típus kiírásáról beszéltem. new mytypedef ugyanúgy a típus kiírása, mint a (mytypedef *) malloc(...).

Arról volt szó, hogy C++-ban a decltype bevezetéséig heap allokációnál még egyszer ki kellett írni a típust. Így a következő kódban:

Foo *p;
p = new Foo;

ha p típusát megváltoztatod, akkor két helyen kell átírni a típust, míg a C-s változatban csak egy helyen:

struct foo *p;
p = malloc(sizeof(*p));

Egyszeruen nem ertem milyen ket helyrol van szo:

typedef struct foo mytypedef; // "struct foo" can be changed here later, if needed, and all the rest should just work.
mytypedef *p;
p = new mytypedef;

Tehat egy helyen kell atirni, nem ketto, ahogy allitod. Tovabba a Te kododra tovabbra is fennall a veszely mindazzal kapcsolatban, amirol fentebb beszeltem, hiaba ugrod at a lenyeget. :)

Az, hogy a C-sek leragadnak a multevezredben a nyelveknel, es nem nyitottok uj es jobb dolgokra valtani, mert mashoz szoktak hozza, ami epp akkor jo volt, az nem csoda, bar kar.

Felreertes ne essek, ez a problema nem csak a C-sekkel all fent, bar Veluk kulonosen, hanem a C++-sokkal is a Rust fele stb. Konzervativak az emberek.

Ha mar valaki explicit castolast csinal, a C++ tipusossa teszi ezt:

* const_cast: const es volatile (el)castolasa.

* static_cast: forditas ideju dontes.

* dynamic_cast: futasideju objectek kozott.

* reinterpret_cast: "barmi", igazabol nem barmi, de olyan ertelemben barmi, hogy ami kimaradt fentebb, pl. datastreamek eseten az adat serializalasahoz a castolas "raw" byte-kba.

Tovabba a Qt tamogat tobb framework specifikus castot is, ugy mint:

* qobject_cast

* qgraphicsitem_cast

stb.

C-ben van meg egy "univerzalis" cast, aminel siman vethetsz hibakat, amit nem szerettel volna, es a fordito abszolut nem fog segiteni a castolas tipusat illetoen. Hogy ez miert "Sot, igazabol a c++ rosszabb is picit" az rejtely...

"Azert a C kod meg mindig veri a C++-t readability-ben. OK, C++ tunhet olvashatobbnak, felteve hogy nem zavar, hogy a compiler maskent ertelmezi a kodot, mint egy human olvaso."

Képzelj el egy Assembly programozót, aki meglát egy C kódot. Ránéz egy függvény paraméterlistájára, van benne mondjuk egy int. Az ASM kódoló erre azt mondja, hogy zavarja, hogy nem látja, hogy az az int minden használatakor a stackről olvasódik-e vagy betöltődik egy regiszterbe és onnan olvassák mindig. Zavaros neki, hogy egyáltalán le lesz-e stackre téve vagy nem, mert pl. a függvény inline-olódik. Szegény ASM kódoló csak néz és azt mondja, hogy a C olvashatatlan. Na így van ez a C és C++ viszonyában is. Egy C kódoló retteg, hogy melyik függvényre lesz bindolva a hívás, mintha az esetek többségében nem volna triviális.

Viszont ha kicsit is humánabb beállítottsága van valakinek, nem bitek folynak az ereiben, akkor örül neki, hogy vannak operátorok, amiktől olyan emberi megjelenése lehet a kódnak, hogy nem kell paraméter típusonként külön függvénynevekkel hivatkozni, bejönnek neki a template-ek.

De OOP nyelvek között is nagy eltérés van. A C++ egy fapados kastély, ahol lépcső helyett összetákolt palló van. A Java meg mozgólépcsős, őrületbe kergetve az embert, ha nem pont úgy haladna, mint ahogy megálmodtak neki. A C++ template-ek normálisan típusfüggő függvények lesznek, így statikusan bindolódnak. Na, erre pont nem alkalmas a Java generics.

Azért egy fvg nem lesz csak ugy inline, a parametereket meg szepen behatarolja az abi hogy mit/mikor es hogyan. Ellenben szerintem eleg keves azon asm programozok szama, akik ne birkoznanak meg a c-vel, sokkal jobban fogjak utalni a c++-t ezen a teren, hidd el;) A "mov ecx, pThis" a legtöbb asm programozó szívét megdobogtatja:D

// Happy debugging, suckers
#define true (rand() > 10)

"Azért egy fvg nem lesz csak ugy inline"

Mondjuk gcc -O3-nál azért csak előfordulhat, nem? Egy static inline esetén triviális, de más modul esetén is működhet.

"A "mov ecx, pThis" a legtöbb asm programozó szívét megdobogtatja"

Ezt mondod te. Más meg azt mondhatja, hogy egy template a legtöbb C programozó szívét megdobogtatja. :D

Aki anelkul hasznal O3-at hogy tudna mit csinal, azt a c++ sem menti meg (igazabol semmi sem fogja megmenteni). Ne abbol induljunk ki hogy mit lehet hulyen csinalni, mert erre a c++ eseten tobb, asm eseten megtobb pelda hozhato

"Ezt mondod te. Más meg azt mondhatja, hogy egy template a legtöbb C programozó szívét megdobogtatja. :D"
Vagyis az asm programozo es a c programozo is a c++-t.....;)

// Happy debugging, suckers
#define true (rand() > 10)

Nem tartom megfelelőnek a hasonlatot, ugyanis C++-ban nem egyértelmű, hogy egy szintaxishoz primitív vagy user-defined behaviour tartozik.

c = a * b;

Ez lehet egy sima integer vagy floating-point szorzás C-ben (egy mul gépi utasítás + esetleg néhány load/store), C++-ban pedig lehet ugyanaz mint C-ben, vagy lehet 1, 2 vagy több függvényhívás. Sőt

f(a);

C++-ban lehet, hogy több függvényt is meghív (másoló konstruktor pl.).

Ártatlannak néz ki a C++ kód, de huncut dolgok történhetnek a felszín alatt.

"
c = a * b;

Ez lehet egy sima integer vagy floating-point szorzás C-ben"

Jó de melyik? Mert ugye nem mindegy. Honnan tudod, hogy melyik? Onnan, hogy megnézed a, b, és c típusait.
(BTW simán lehet itt még konverzió is, akár 3 db is, ha a három változó nem egyforma típusú.)

Ugyanez van C++-ban. Ha látod, hogy mik a típusok, tudod mi fog történni. Nincs itt semmi meglepetés, még csak nem is történik más mint 3 int esetében...

"
f(a);

C++-ban lehet, hogy több függvényt is meghív (másoló konstruktor pl.)."

Megint csak nem történik semmi csoda, vagy rendkívüli, C-ben is meghívódik a másoló konstruktor (akár egy egész struct lemásolódik ha nem vigyáz az ember), sőt konverzió is történhet.

Az új dolog a C++-ban, hogy a saját típusok is tudnak úgy működni mint a beépítettek, és nem kell nekik külön elbánás.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Ez azért nem ennyire egyszerű.

Akár integer, akár floating-point szorzás történik, még ha közben konverzió is bekövetkezik, néhány dolgot mindenképpen tudhatunk:
1. A szorzásnak semmiféle mellékhatása nincs.
2. A szorzás mindenképpen véges idő után befejeződik.
3. A primitív szorzás ideje O(1).

Ha a szorzás jel egy függvényhívást rejt, akkor a következőket tudjuk:
(semmit)

Hasonlóképpen a C "másoló konstruktoráról" is pontosan tudjuk, hogy mellékhatása nincs, és véget ér O(sizeof(a)) időn belül. A C++ másoló konstruktoráról pedig semmit sem tudunk.

Ha van egy konkrét feladatod, azt tök mindegy, hogy C vagy C++, meg kell oldani. Ha valamit meg tudsz mellékhatás nélkül és kiszámítható futásidejűre csinálni C-ben, az C++-ban is pontosan u.a. lesz. Miért lenne más? És ez fordítva is igaz, ha a feladat olyan, hogy másolni kell valami nagy izét, akkor másolni kell, függetlenül attól, hogy C++ copy constructornak vagy C-beli másoló függvénynek hívod.

Szerintem itt az a probléma, hogy kihagyunk egy fontos (!) tényezőt az összehasonlításból: a programozás élvezeti értékét.
Ez pedig teljesen szubjektív. Ha neki a C-ben programozás okozza a nagyobb örömet, vagy nekem a cpp -ben, akkor ezen nehéz, és nem is szükséges változtatni.

Igen, nem kell valtoztatni, pont ez benne a szep, de azert mert te jobban magadenak erzed a masik nyelvet es szereted a szines szagos feature-oket, nem kezded el leszarozni a masik nyelvet:)

// Happy debugging, suckers
#define true (rand() > 10)

Attol fugg, hogy ki a munkaltato. ;-) Lehet a Balabit nem ertene egyet, hogy kit fizet.

A business elet nem feltetlen "elvezet faktor" altal vezerelt. Peldaul nyilvan nem vennel fel valakit, akinek az ASM okoz oromot, vagy fogadnad el egy regi kolleganak a felvetest, mert igy erezne jol magat.

Egyebkent persze, csak ez szubjektiv, amin sokat nem kell targyalni, viszont objektivan jo latni a dolgokat, meg ha par embernek nem is tetszik.

Koszi! Nyertel nekem 3 sort! Egy masik forumon, ahol rohogunk rajtad, fogadtunk hogy vagy olyan -mast idezek: "egoista kocsog"- hogy a fenti hozzaszolasom hatasara elkezdesz minden thread vegere hozzaszolast irni. Igy lenne inkabb lotto otosom:)

u.i.: mivel ez az utolso hozzaszolasom ahhoz amit irsz: a leheto legrosszabb mentalitast viseled magadon, miszerint te szartad a spanyol viaszt es csak az a mervado/elfogadott/trendi/egyeblofasz amit te mondasz. Remelem stabil a munkahelyed, nagyon sok helyen hullanak ki az ilyen mentalitast kovetok. (egyebkent meg nem biztos hogy megnyertem, dupla vagy semmiben dont a kovetkezo commented, remelem hozol nekem egy duplat)

// Happy debugging, suckers
#define true (rand() > 10)

Azért ez kicsit erős nem? Nem érzem hogy leszarozott volna valamit, arról beszélt, hogy szerinte nem érdemes c-ben projektet kezdeni. Hadd legyenek mar az emberek lelkesek valamiben nem? Ez viszont gyakran azzal jár, hogy a különböző, de egyformán lelkes emberek véleménye ütközik.

Fentebb rengeteg helyen elhangzott tőle ennél brutálisabb érvelés is. Nem az volt a baj, hogy különböző véleményen voltunk, hanem hogy ő volt az egyetlen aki mást fikázott, mindenki más a saját álláspontját hangoztatta. (lasd mar a leges legelso komment)

// Happy debugging, suckers
#define true (rand() > 10)

Ha én munkáltató vagyok, nekem az a fontos, hogy a fejlesztő CSAPAT termelékeny legyen, magyarul adott idő alatt a legtöbb feature-t tudja létrehozni,
összeintegrálni más rendszerekkel, hogy jobb és jobban eladható terméket hozzanak létre.

Az itt állandóan előjövő performancia dolog csak egy kis szelete a biznisznek. Lehet, hogy a konkurens cég terméke kicsit lassabb, de 5x annyit tud,
ezért senki nem fogja a mi termékünket megvenni.

"Attol fugg, hogy ki a munkaltato." Azért ez nem egészen így van. A munka élvezeti értéke kiemelkedően fontos, hiszen az ember jelentős részét munkával tölti, ergo meghatározza egész életének minőségét.
Önmagunkat nem tudjuk lecserélni (persze folyamatosan változunk, de ez lassú, sokszor észre sem vesszük) A munkáltatót viszont le lehet cserélni (az alkalmazottat is, nyilván). Ez része a rendszernek.

Éppen ezért érdemes az operator +-t úgy implementálni egy tetszőleges típusra, hogy:
1. ne legyen mellékhatása
2. fusson le
3. adott, fix méretű típus mellett legyen O(1) (pl valarray, fix méretű mátrix, etc.), ha a típus nem fix méretű, akkor is valami értelmes futásidő (string, általános mátrix, stb.)

Hülye programozótól semmi nem véd meg, de a probléma ugyanaz mint mikor meghívok egy "print" nevű fv-t. Általában elvárom, hogy valamit kiírjon valahova a kiírt objektum változtatása nélkül, véges időben, stb, és ne a partíciómat formázza. De erre nincs semmi garancia...

A fv-ek neve fontos. A print legyen print, a + meg legyen +.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Mig autocomplete letezik, ezt az elvet a "pont leszarom" kategoriaba tudom sorolni, ki tudok valasztani 6 fn nevet ahelyett hogy ugyanazon nev mellett 6 valtozatot neznek. Raadaskent a binding az a tipikus dirty hack esete egy compiled language-nel, amikor rakenyszerultel arra, hogy egy kozbenso reteget hoztal letre csak azert, mert az adott nyelv szarik az elvekre (lasd az elobbi hozzaszolasomat).
De ha mar itt tartunk, a c++ -t osszehozni java-val sokkal bonyolultabb, mint pl c-vel, ugyanazert amit fentebb irtam.
Ertem en hogy ez egy kenyszer volt, csak azert hogy egyaltalan eletkepes mukodokepes legyen a nyelv, de ezt mintapeldakent emliteni, azert eleg nagy blodseg.

// Happy debugging, suckers
#define true (rand() > 10)

Gyönyörű példája, hogy mikor akarok C++ kódot hívni C-ből egy plugin architektúra (konkrétan tudok létező példát mondani az iparból, ahol ezt így csinálják).

Dinamikusan betöltött shared library-ből szeretnél elérni egy definiált interfésszel rendelkező C++-osztályt. Nyilván elég gány lenne, ha a mangled nevekre hivatkozol, úgyhogy egy C-ben írt factory eljárás fogja létrehozni neked az objektumot, amit aztán használhatsz a programodból.

Nyilván nem árt, ha a shared könyvtárban és az őt használó programban is ugyanaz az osztály interfésze, szóval tudnak itt gányok lenni (pl. ha az osztálydeklarációban felcseréled két tagfüggvény sorrendjét, akkor már borul az egész).