gcc-in-cxx: GCC psané v C++

Byla vytvořena větev gcc-in-cxx, kde se bude sada kompilátorů GCC postupně přepisovat z čistého C do C++. Cílem je zjednodušit kód GCC a usnadnit jeho budoucí rozvoj.

18.6.2008 17:23 | Luboš Doležel (Doli) | Zajímavý projekt

Komentáře

[Kyosuke]

Někdo by měl zkontrolovat hasicí přístroje...

[David Watzke]

Hehe. Jen aby to nebylo pomalejší.

[Kyosuke]

Měl jsem na mysli ty plameny, co teď vzplanou...

[xxx]

Třeba jako reakce vznikne projekt gcc-in-asm , aby se kód trochu znepřehlednil.

[Bluebear]

Přestože nejsem fanda funkcionálních jazyků, docela bych rád viděl, jak vypadá GCC přepsané do některého z nich; bylo by to zajímavé z teoretického hlediska (bude to výrazně jednodušší, nebo zhruba stejně složité, nebo totální bordel? Bude to rychlejší nebo pomalejší? Odpadnou všechny memory leaky?)

[bubak]

A co takhle gcc-in-java?

[...............23]

gcc-in-lolcode...

[Luboš Doležel (Doli)]

No já bych raději viděl gcc-in-brainfuck to by byla jiná podívaná.

[Vašek Lorenc]

+1

Případně by se to dalo napsat ještě ve Whitespacu

[Boris Dušek]

"Za trest napíšeš gcc v brainfuck. A nemusíš 100x, stačí jednou."

[Käyttäjä 11133]

Takže nakonec jen napíše překladač z céčka do brainfucku?

[Ladicek]

Mmm, kdepak, tuhle jsem viděl překladač Brainfucku v Brainfucku. Vygenerovaný programem v Céčku

[Karel]

jedine gcc-in-javascript

[Karel]

ale masakr by byl gcc-in-html

[jist]

Myslim, ze to by ani neslo, ale takove

gcc-in-xslt to uz by bylo mozne :)

[Jendа]

gcc-in-basic, gcc-in-php, gcc-in-.NET

[Limoto]

A co třeba gcc-in-kommander?

[Milan Vít]

A co gcc-in-luzny? :P

[Jendа]

gcc-in-bash

[NaiL]

gcc.sh

[Käyttäjä 11133]

Až na to, že HTML není prohramovací jazyk.

[Karel]

No to jste se zas na prednasce neco dovedeli, ze?

[Käyttäjä 11133]

Jenže podstata je v tom, že v JavaScriptu to půjde, ale v HTML ne. Stejně tak by měl jít ten překladač napsat třeba v LaTeXu (to by byo teprve zajímavé ) a o to mi šlo.

[Michal Kubeček]

LaTeX bych do toho nezatahoval, to je jen styl. Co se samotného TeXu týká, moc jistý bych si tím nebyl. Vzhledem k tomu, že už jsem v něm ledacos napsal (a teď nemyslím texty), vím docela dobře, jak omezené (a omezující) jsou jeho možnosti.

[Smazáno]

http://texcatalogue.sarovar.org/entries/basix.html#Docs. Hmmmm...?

[thingie]

Ono stačí málo, že ano. A já bych se skoro nedivil, kdyby se dalo něco vykouzlit i s CSS a HTML. Když jsem viděl nové selektory a tak… Jakože jo, dokázaný to nemám a spíš to nepude, ale pokud byste byly schopni přijmout jako výsledek kompilace to co uvidíte v prohlížeči (nevidim důvod proč ne), tak bych ani to HTML úplně tak moc nezavrhoval

[thingie]

Bwah, tfuj. Byli.

[MJ]

Zajímavý nápad Jak by se ale dal udělat cyklus?

[thingie]

No, teď nejsem v situaci o tom moc přemejšlet

Ale z něčeho tam přece cyklus nebo rekurze jít udělat musí, mi neříkejte že ne

[Filip Jirsák]

HTML je značkovací jazyk, tj. v textu se označují nějaké jeho části. Napsal byste, že kompilátor C jde vytvořit s novinami a barevným zvýrazňovačem? Přitom HTML je pouze elektronická varianta toho zvýrazňovače…

[thingie]

Některé programovací jazyky taky nejsou nic jiného, než pár přepisovacích pravidel, v podstatě. A fungují.

[Filip Jirsák]

Ale v HTML nemáte žádná pravidla, žádné příkazy, žádné instrukce. Máte tam jenom značky.

[thingie]

Já jsem velmi ochotný věřit tomu, že to nejde, protože to asi fakt nijak nejde, ale kdo mě o tom chce zcela přesvědčit musí použít nějaké argumenty Skutečné argumenty.

[MJ]

Dobře: HTML+CSS není turingovsky úplné (jinými slovy ekvivalentní s klasickými programovacími jazyky), protože se v něm nedá napsat program, který se zacyklí.

[thingie]

No, to je sice možná, ale jak to dokázat?

[thingie]

s/možná/hezké/

[MJ]

Třeba absencí jakékoliv konstrukce pro cyklus?

[thingie]

Jop, to by byl poměrně logický krok Ale to taky není hned automaticky dané. Nějaké možnosti zpracování tam přeci jen jsou.

(A ani tohle nám nedokáže, že s HTML+CSS nedokážeme řešit žádné problémy, i když ten vytoužený kompilátor nám to asi dost zhatí, no.)

[MJ]

Já se také nesnažím dokázat, že v HTML+CSS nelze naprogramovat nic, to evidentně není pravda. Například úlohy na vyhledávání podřetězců evidentně naprogramovatelné jsou: pattern bude v CSS, hledaný text ve struktuře elementů v HTML. Snažím se jen ukázat, že to je slabší výpočetní prostředek než obvyklé programovací jazyky. (Naproti tomu třeba o TeXu snadno dokážete, že je stejně silný jako běžné jazyky.)

[thingie]

No, jo, jasně, já to chápu, jenom si nejsem jistý, jestli tomu nevěříme nějak zbytečně moc automaticky a jestli to přece jen nějak nejde. Nikoliv poprvé podotýkám, že se rozhodně kloním k možnosti, že to tak silné není, ale (ale! ) nejsem o tom 100% přesvědčen (narozdíl od ostatních, kteří to berou jako samozřejmý fakt na první pohled). A potřebuju asi něco víc přesvědčivého než se tu zatím prezentovalo, abych byl

[Kyosuke]

Člověk by řekl, že v matematice lze domněnky definitivně dokázat i definitivně vyvrátit. Není třeba ničemu věřit, dokaž ekvivalenci HTML třeba s lambda kalkulem a máš to. Já jsem v něm nic k tomuto účelu dostatečného nenašel.

[thingie]

No, řekl, a většinou měl i pravdu, no. Ale asi z toho víc jak nějakej automat nikdo nevytříská.

[petr_p]

Ti, co ví, že Turingův stroj je ekvivalentní while programu nebo registrovému stroji (velmi jednoduchý je counter machine), tak taky snadno vidí, že jazyk bez podmíněného skoku je poněkud neúplný.

Ti, co to neznají, tak si mohou problematiku z oblasti vyčíslitelnosti nastudovat a pak tu kafrat :D

[thingie]

A víme, že máme skutečně jazyk bez podmíněného skoku?

[petr_p]

A víme, že máme skutečně turingovsky úplný jazyk bez podmíněného skoku?

Narážíte na Churchovu tezi?

Že jsou TM a while-programy ekvivalentní dokázáno je. Že je každá efektivně vyčíslitelná funkce implementovatelná TM a obráceně nikoliv, protože se jaksi nepodařilo definovat pojem efektivně vyčíslitelný.

[thingie]

Turingovsky úplný jsem tam ale nikdy říct nechtěl. Jenom to, že si myslím, že nemáme jistotu, že se tam někde ten podmíněný skok přeci jen nemůže objevit. Ono se tam fakt dá dělat docela dost různých přepisů a takových techtlomechtlů.

(A jo, opakuju se strašně moc, ale nevěřim tomu že to tam je. Jenom ještě úplně bezmezně nevěřim tomu, že to tam fakt není.)

[MJ]

To, co potřebujete, není ani tak ta podmínka (mechanismů v CSS, které se dají na podmínky použít, je habaděj), ale nějaký vcelku libovolný mechanismus, který by uměl skočit zpátky.

[Filip Jirsák]

Program je posloupnost instrukcí, které má provádět nějaký stroj (nebo třeba člověk), program bez instrukcí nelze sestrojit. Počet dostupných instrukcí v jazyce HTML je 0, slovy nula. To pro vás není dostatečný argument?

[thingie]

Ne. S definicí programu zde uvedenou nesouhlasím a druhá věta pak sama o sobě argument nestvoří.

[Filip Jirsák]

V tom případě používáte definici programu nekompatibilní se zbytkem světa. Všude se dozvíte, že je to posloupnost nějakých kroků, operací, instrukcí příkazů nebo něčeho podobného. Nevím jakou definici programu používáte vy sám, ale obávám se, že to bude tak obecné, že to rozhodně nebude zaručovat, že tím půjde vytvořit kompilátor nějakého jazyka. Protože kompilátor zase není nic jiného, než posloupnost instrukcí (takže kompilátor je program ve smyslu „definice“, kterou jsem uvedl výše).

[thingie]

Když jsem se posledně díval, tak svět bylo i něco víc než Java, ale pravda, možná už mám pohled zastaralý

[Filip Jirsák]

Buď jste udělal od mého příspěvku k vašemu nějaký obrovský myšlenkový skok, který nejsem schopen usledovat, nebo je váš příspěvek absolutně mimo téma.

[thingie]

No, jak já bych to… Definice na ten program mi prostě nestačí. Nejde asi ani tolik o obecnost, spíš o to, že je taková docela divná. Že by každá posloupnost instrukcí byla nutně programem? Hm. Možná. Na to, jestli se s tím pak dá udělat kompilátor už jsou teorie dostatečně festovní a formálně propracované, takže o to mám obavy zhruba takové, že žádné

[Filip Jirsák]

Že by každá posloupnost instrukcí byla nutně programem?

Já jsem napsal, že každý program je (neprázdnou) posloupností instrukcí, ne že každá posloupnost instrukcí je programem. Navíc když HTML nemá žádnou instrukci, bylo by mi v této debatě tvrzení o každé (neprázdné) posloupnosti instrukcí poněkud na houby.

[thingie]

Svět nejsou jen instrukce, pane.

[deda.jabko]

HTML zadnou mnozinu instrukci nema, ale z HTML+CSS pujde minimalne vytahnou konecny automat a mozna i neco navic. (i kdyz si taky myslim, ze soucasna kombinace nebude turingovsky uplna)

btw. neplette sem porad ty instrukce... rada programovacich jazyku (i programatoru) se bez nich s prehledem obejde....

[Filip Jirsák]

btw. neplette sem porad ty instrukce... rada programovacich jazyku (i programatoru) se bez nich s prehledem obejde....

Programovací jazyk a programátor možná. Ale neobjeví se tam ty instrukce v okamžiku, kdy je ten program prováděn? Jestli se nepletu, tak deklarativní programování znamená, že programátor popíše vlastnosti výsledku a interpret toho programu pak najde postup, jak se k tomu výsledku dobrat. A ten postup je zase posloupnost instrukcí. Z tohoto úhlu pohledu pak HTML je programem, protože prohlížeč převede zdrojový kód (spolu se specifikací a případně doplněním specifikace vývojáři prohlížeče) převede na instrukce, jak stránku zobrazit. Jenže není pak programem už úplně všechno?

[MJ]

Pořád mi není jasné, proč soudíte, že by pro definování sémantiky programu (jinými slovy toho, jaký výstup program vydá pro jaký vstup) měly být nějaké instrukce potřeba.

[Filip Jirsák]

Nevím, jestli není lepší pro tohle používat termín funkce. Jenomže zase když je to deklarativní programování, tak by produktem měl být program, ne funkce… Ale pro definování sémantiky něčeho, co má vstup a odpovídající výstup, instrukce nepotřebuju.

[MJ]

A v čem se má program lišit od funkce? V tom, že je interaktivní? Pak ho můžete popsat jako funkci ze "stavů světa" do "stavů světa".

[Filip Jirsák]

V tom, že funkce pro nějaký vstup dává výstup, program je ale popis způsobu, jakým se ta transformace vstupu na výstup provádí. Alespoň tak vnímám význam toho slova v běžném jazyce. Ale uznávám, že tenhle popis se hodí na program pouze v imperativním programování.

[MJ]

Program (imperativní) je samozřejmě ten postup transformace. Ale jeho sémantika je funkce. Můžete tedy za směle za programovací jazyky prohlásit libovolné formalismy, ve kterých se dají vytvářet objekty, které mají stejnou sémantiku jako programy.

[deda.jabko]

Program je posloupnost instrukcí, které má provádět nějaký stroj (nebo třeba člověk), program bez instrukcí nelze sestrojit.

prominte, ale ta definice fakt neni stastna... co treba funckionalni programovani, kde je program kompozici funkci, co treba logicke programovani, kde je program mnozinou faktu... to nemluvim ani o onom nestastnem turingove stroji, kde program je mnozina stavu, prechodova funkce a takove ty nesmysly...

[Filip Jirsák]

Přechodová funkce je instrukce. Zbytek bych asi nazval spíš počítačové programy, protože s plánem, jak něco udělat (=programem), to nemá mnoho společného. Pokud tedy pojem programování rozšířím z imperativního programování i na deklarativní programování, může být programem (deklarací) cokoliv, protože ta deklarace sama o sobě nedělá nic, aby takový program něco dělal (měl nějaký vedlejší efekt), je k němu potřeba ještě interpret. A ten interpret musí některé deklarace interpretovat opět jako instrukce („něco udělej“). Samozřejmě je pak možné napsat takový interpret, který nějaký HTML kód bude intrepretovat tak, že někde vznikne kompilátor, ale stejně tak může takový kompilátor vzniknout interpretací kávové sedliny.

[thingie]

Turingův stroj je na tom vcelku podobně, neb nemá žádné IO. Jaké vedlejší efekty potřebuju ku spočítání 5 + 1, třeba? Až to nejde redukovat, tak sem vyhrál a můžu to dvakrát podtrhnout.

[deda.jabko]

turinguv stroj (zalezi na definici) ma vedlejsi efekty... to je ta nestastna paska... ale lambda kalkul se bez vedlejsich efektu objedu levou zadni.

[thingie]

No, vedlejší efekty. To záleží co se jima myslí. Jak u lambda kalkulu tak u TS je výsledek (pokud to skončí ) daný tím jak vypadá stroj a páska nebo výraz LK. Vždy je to stejné a oba modely jsou si v tom rovné. Pokud říkáme, že TS má vedlejší efekty a LK ne, tak jima asi nemyslíme nic moc zásadního

[deda.jabko]

jo, jasne mate pravdu, to mne ujelo... u toho TS jsem ten vedlejsi efekt uvazoval v malinko posunutem smyslu. samozrejme, oba modely nemaji vedlejsi efekty (teda az na ten vystup).

[MJ]

To je mi ale divná definice… Na to, aby instrukce něco dělala, je přeci také potřeba něco, co ji provádí. Ale to "něco" nemusí být ani u instrukcí, ani u deklarativních konstrukcí nějaký fyzický mechanismus, nýbrž třeba formální popis sémantiky.

[deda.jabko]

prechodova funkce je instrukce

vs.

Program je posloupnost instrukcí

nechci to vytrhavat z kontextu, ale prechodovou funkci u TS muzete chapat jako program, ale porad to bude _funkce_ a ne posloupnost instrukci...

Pokud tedy pojem programování rozšířím z imperativního programování i na deklarativní programování,

aha...

[Filip Jirsák]

Pokud tedy pojem programování rozšířím z imperativního programování i na deklarativní programování,

aha...

Jenomže s takovým rozšířením je program cokoliv, a můžu prohlásit, že kompilátor céčka napíšu třeba ve stromu před barákem. Jenom musím nadefinovat vhodný programovací jazyk, který stromy transformuje na kompilátory.

[thingie]

Ne

[deda.jabko]

ale, ano... jenomze on si z nejakeho duvodu mysli, ze v imperativnim programovani to nejde... a ze v imperativnim programovani neni treba definovat semantika... ;-]

a me by se libilo programovat na stromu spis imperativne... treba takto...

zeleny-list <-> mov ax,0
hnedy-list <-> inc ax
list-s-housenkou <-> dec ax
jabko-s-cervem <-> skoc na jinou vetev
jabko-bez-cerva <-> pokracuj dalsim listem

[thingie]

Jo takhle, tak to jo. Ale tak to už je celkem jedno, čemu jak budeme říkat. Když to bude až na jména program v Céčku, stejně, tak coby

[Filip Jirsák]

V imperativním programování je potřeba definovat sémantiku. Ale všechna mně známá zařízení, na kterých lze provozovat HTML, mají definovánu sémantiku pro nějaké instrukce. Takže pokud chcete, aby ta zařízení něco dělala, musíte jim nějaké instrukce dodat. A sémantika HTML nemá nadefinováno nic, čím by bylo možné HTML na instrukce převádět. Pokud nebudu dodržovat sémantiku HTML a budu je brát pouze jako posloupnost bitů, můžu si s ním dělat samozřejmě co chci a můžu to brát jak jako deklaraci, tak jako posloupnost příkazů. Ale těžko ten vstup pak nazývat HTML…

[deda.jabko]

ja se tady ale nebavim o HTML, ja jsem prohlasil vase tvrzeni ,,Program je posloupnost instrukcí, které má provádět nějaký stroj (nebo třeba člověk), program bez instrukcí nelze sestrojit.'' za nestastne... nebo-li receno slovy humphrey applebyho: ,,odvazne'' ;-]

[Filip Jirsák]

Ano, to tvrzení je špatně, předpokládal jsem, že se bavíme o imperativním programování.

[Ladicek]

Proč ne? Psát v Javě překladač naprosto není problém (i když ukázkové příklady v Modern Compiler Implementation in Java jsou silně odstrašující ).

[Kyosuke]

Ano, ale ještě mnohem menší problém než napsat kompilátor (čehokoli) v Javě je třeba napsat ho dejme tomu v Haskellu. Vlastně i kompilátor Javy by byl mnohem jednodušší v Haskellu než v Javě. (V mém případě ten pokus o zastrašení vyšel, prchám před kafem zbaběle do kouta. )

[Ladicek]

No, tuhle jsem viděl nějakou prezentaci o psaní interpretů v ML či kýho šlaka. To zase zastrašilo mě

[Ladicek]

Jo, vzpomněl jsem si, bylo to v Ocamlu. Ale dohledávat to nebudu

[Mrkva]

Já chci gcc-in-php! :)

[Limoto]

Tak si ho napiš

[Let_Me_Be]

Tyjo, jeste udelam statnice a budu mit vazne pocit, ze jsem umrel a jsem v nebi :)

[lmanik]

to ja mam pocit ze jsme v prd...

[Let_Me_Be]

Proc?

[kozzi]

No treba ja jsem v pr protze ma za chvili stavat a jed do Brna na skolu na zapis, a momentalne jsme tak vykalenej ze nemuzu ani najit postel kam si chcu lehnout

[YYY]

A coz gcc-in-awk ?

[slayn]

a co gcc-in-karel, nebo gcc-in-baltik?

[trekker.dk]

Myslím, že soutěž o gcc-in-nejabsurdnější_možný_jazyk jsi asi vyhrál.

[Käyttäjä 11133]

gcc-in-latex?

[...............23]

to znie jak názov nejakého hardcore geek porna

[NaiL]

gcc-in-žofka

[Bluebear]

Hu.

[Boris Dušek]

Hu hu, šlo by to nějak rozvést?

[Bluebear]

V podstatě jsem chtěl říci, že IMHO přepsání kódu z C do C++ nepřináší žádné výhody, zejména to neudělá kód přehlednějším. Mám dokonce obavy, že efekt bude přesně opačný.

[qiRzT]

A čím se to bude překládat?

[Let_Me_Be]

Stejne jako ted starsi verzi GCC.

[Mrkva]

Vzdycky me zajimalo, cim se kompiloval ten uplne prvni kompilator :)

[Bluebear]

Ten se nekompiloval, ten vyděrovali na štítky ručně rovnou ve strojovém kódu

[Deleted [8409]]

Jiným překladačem

[Käyttäjä 11133]

Což o to, udělal se ve strojovém kódu a pak se přeložil ještě sám sebou.

[Kyosuke]

Úplně první kompilátor byl kompilátor LISPu 1.5. Jak praví technická zpráva AIM-039 z roku 1962, zkompiloval sám sebe - byl jednoduše spuštěn v dosavadním interpretu, ale nějakého šikulku napadlo prostě mu dát jako vstup sebe sama. Tím byl první bootstrap v historii kompilátorů dokončen.

( LISP - stále nová prvenství již po padesát let. )

[Kyosuke]

s/interpretu, ale/interpretu. Nejdřív zkoušeli normální lispové programy, ale pak/

[alblaho]

Že by g++?

GCC potřebuje pro bootstrap GCC 2.95, tak holt tenhle fork bude chtít nějaký překladač C++.

[Miloslav Ponkrác]

Ano, na rozdíl od lidí, co tu propagují čisté C si vedoucí velkých projektů uvědomují, že vývoj v C++ je prostě mnohonásobně efektivnější a lepší, výsledný kód je čitelnější a udržovatelnější při dosažení stejných výsledných vlastností programu.

[Kyosuke]

Nejprve jsem ze stylu tohoto příspěvku usoudil, že to bude Radek Hulán nebo Petr Tomeš, ale pak jsem si všiml, že to není ani o Vistě a modré prostatě, ani o Firefoxu a nejrychlejším Javascriptu, ale o C++ a čitelnějším kódu a došlo mi, že tihle dva to asi nebudou.

[alblaho]

Asi tak

[Bluebear]

Omlouvám se, ale nesouhlasím. Mám C++ velmi rád, některé jeho rysy přímo miluju, ale jako všechno má i tenhle jazyk své stinné stránky. Rozhodně nezajistí vysokou efektivitu sám o sobě - programátor ho musí umět a některé rysy C++ se učí setsakra blbě.

Je tam řada věcí, které mají programátorovi usnadnit život, ale něco jim chybí (například: C++ má destruktory a virtuální funkce, ale nemá garbage collector; C++ může vytvářet objekty staticky nebo dynamicky, ale v destruktoru nejde zjistit, který je který; zjišťování typů objektů za běhu je strašně omezené; vícenásobná dědičnost je podporována, ale kdo ji použije, do smrti veselý nebude).

Některé featury C++ jsou extrémně užitečné a brutálně efektivní, ale je strašně snadné použít je špatně a nesprávné použití má fatální následky (templaty, přetěžování operátorů).

Pokud se o C hovoří jako o jazyku, kde je snadné se střelit do nohy, tak C++ je procházka minovým polem s diskotékovým osvětlením. V rukou odborníka je to skvělý nástroj, ale je to jazyk, který přivádí lidi do blázince. (Proto ho mám rád.)

[disorder]

neser kobru bosou nohou ;)

[disorder]

sakra, to som necakal, ze sa tu objavia vsetky tri kobry :D

[Kyosuke]

Možná by GCC mohli přepsat spíš do Dčka, vypadá trošku bezpečněji. Ale přesvědč k něčemu takovému lidi, že jo. Navíc by ten GDC museli taky dodělat. ;/

...ale je to jazyk, který přivádí lidi do blázince. (Proto ho mám rád.)

Toužíš po kamarádech?

[petr]

Je tam řada věcí, které mají programátorovi usnadnit život, ale něco jim chybí (například: C++ má destruktory a virtuální funkce, ale nemá garbage collector; C++ může vytvářet objekty staticky nebo dynamicky, ale v destruktoru nejde zjistit, který je který; zjišťování typů objektů za běhu je strašně omezené; vícenásobná dědičnost je podporována, ale kdo ji použije, do smrti veselý nebude).

Jde to poznat z pointeru

[Deleted [8409]]

Ten problém se zjištěním, zda byla třída vytvořena staticky nebo dynamicky jsem vyřešil Chce to ale v každé třídě alespoň jeden volný bit kam to zapsat.

[Let_Me_Be]

programátor ho musí umět a některé rysy C++ se učí setsakra blbě

Neni pravda, jenom se u C++ clovek musi ucit princip a ne dusledky. Ale uznavam ze predavani jmenem nesedi kazdemu.

ale nemá garbage collector

Na co taky? Garbage collector je pro jazyk typu C++ naprosta zbytecnost. Na 99,9% pripadu mi staci chytry pointer.

templaty, přetěžování operátorů

Fatalni dusledky si spis dokazu predstavit u vyjimek a virtualnich funkci. Pomoci template se neda nic zkazit, maximalne zneprehlednit kod a pretezovani operatoru???

K tomu strileni do nohy:

"C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, it blows away your whole leg." - Bjarne Stroustrup

[rm -rf /]

Programuji v C i v C++ a musim s Vami nesouhlasit. - To jak je kod citelny minimalne z 99% zalezi na tom, kdo ho napsal - Programovani neni mnohonasobne efektivnejsi. Spis bych to videl tak, ze kdyz spocitam podil cas vyvoje v C a cas vyvoje v C++, tak mi vyjde cislo mensi nez 2. - Program stejne vlastnosti rozhodne nema, binarka z prekladace C je znatelne mensi a pokud umite programovat v C++ i v C, tak program z C bude vetsinou i rychlejsi. Dobre je to videt, kdyz se Vas program musi vejit do 512kB flashky.

[Deleted [8409]]

Zase ty mýty o velikosti...

Ale odpověděl jste si sám, program bude tak veliký podle toho, kdo ho napíše.

[petr_p]

Bohužel C++ z principu má větší binárky i překlad je náročnější. Potíž je v early-bindingu symbolů, jejichž tabulka se počítá při překladu. Proto je C++ binárka rychlá, ale paměťové nároky jsou občas šílené.

[Deleted [8409]]

Odpověděl jsem částečně jinde

Otázka je, co berete jako C++ jazyk ? Používáte STL, výjimky, RTTI ? Nemusíte. Já beru stl jako knihovnu, když se mi nehodí (a to nehodí ), tak ji nepoužívám. Ostatní jmenované věci také.

Takže ještě jednou. Je podle vás C++ bez stl, výjimek a RTTI pomalejší než C ? Prosím silný argument

[petr_p]

Překlad programu je pomalejší a překlad i běh programu sežere více paměti než ekvivalentní program v C.

Jde o vlastnosti jazyka jako je (násobná) dědičnost, virtuální metody, které čistě technicky musí někde držet tabulku metod za běhu (paměťová náročnost za běhu), a na druhou stranu snaha o early binding ostatních metod, které zase žerou čas a paměť při překladu.

Ano, můžeme napsat formálně C++ program, který tohle všechno používat nebude, ale to se pak můžeme vrátit k C.

Čistě prakticky vysvětlujte vaši verzi náročnosti C++ mému překladači, který dneska 2 hodiny drtil gnash, na jiném stroji s několika desítky MB paměti představuje překlad centerim noční můru atd.

Nikde jsem netvrdil, že běh C++ programu je pomalejší.

[Let_Me_Be]

Jde o vlastnosti jazyka jako je (násobná) dědičnost, virtuální metody, které čistě technicky musí někde držet tabulku metod za běhu (paměťová náročnost za běhu), a na druhou stranu snaha o early binding ostatních metod, které zase žerou čas a paměť při překladu.

A jak udelas ekvivalentni funkcionalitu v Cecku ty chytraku? Bez tabulky? To bych rad vedel jak.

Delka prekladu nikoho netrapi (ano normalni relativne male projekty v C++ se mi prekladaji desitky minut, no a?).

[Kyosuke]

Rozumné objektové jazyky (což C++ není) využívají pro pozdní vazbu obecná zobrazení, nejčastěji s inline caches pro optimalizaci monomofních a polymorfních (v případě PIC) call sites. Jednoduchá tabulka je pro náročnější požadavky (třeba multiple dispatch, nebo kombinované metody, nebo dynamické změny) úplně k ničemu. Tady vidím největší nedostatek C++ - poměrně primitivní objektový systém, který se bohužel nedá nijak změnit, na rozdíl od kupříkladu programovatelného CLOSu. To už i ty šablony jsou v C++ užitečnější než "objekty" v C++...

[Let_Me_Be]

a pokud umite programovat v C++ i v C, tak program z C bude vetsinou i rychlejsi

Tak to chci videt.

[rm -rf /]

Tak si to zkuste, C je totiz primitivnejsi a prekladac ho vic zoptimalizuje. Napiste si treba main s cyklem, ktery naplni list z stl a z queue.h a pak skonci. A pouzijte icc, u gcc je ten rozdil moc maly. Mozna budete hodne prekvapen, co to icc udela

[Deleted [8409]]

Bavíme se o jazyku nebo o STL ?

Takže fukce void f() v C++ bude pomalejší než funkce void f(void) v C? I když vynechám výjimky (tj jediný důvod proč je binárka větší a možná minimálně pomalejší) ?

Odpověď je NE, rychlost bude naprosto stejná.

K těm výjimkám, Qt a KDE například nepoužívají výjimky, takže argumenty o tom jak C++ je větší a pomalejší nemají smysl.

A teď příklad z praxe. Řekněte mi, jak v čistém C uděléte třeba objekt řetězce s implicitním sdílením dat alá QString z Qt. Možná se vám to podaří, ale jak se s tím bude pracovat ? Na tyto věci je C++ prostě jak dělané a rychlostní penalizace se vám budou dokazovat jen těžce.

[rm -rf /]

Bavíme se o jazyku nebo o STL ?

STL je popsané v ISO C++, takže je součástí jazyka.

Takže fukce void f() v C++ bude pomalejší než funkce void f(void) v C? I když vynechám výjimky (tj jediný důvod proč je binárka větší a možná minimálně pomalejší) ?

Když napíšu funkci v C tak, aby zárověň byla i funkcí v C++, tak budou stejně rychlé. V tom případě to C++ ale nepotřebuji, když ho nepoužívám, že.

A teď příklad z praxe. Řekněte mi, jak v čistém C uděléte třeba objekt řetězce s implicitním sdílením dat alá QString z Qt. Možná se vám to podaří, ale jak se s tím bude pracovat ? Na tyto věci je C++ prostě jak dělané a rychlostní penalizace se vám budou dokazovat jen těžce.

Samozřejmě, že toto umím naprogramovat. Zadarmo Vám to ale psát nebudu :-P

[Let_Me_Be]

Primo z diskuze pod clankem o kterem diskutujeme: http://theory.stanford.edu/~amitp/rants/c++-vs-c/

Cecko nema sablony a reference. C++ je nadmnozina C. Proto at uz si melete cokoliv, nemuze byt C++ pomalejsi nez Cecko. Ciste logicky dusledek predchozich dvou faktu.

C++ umoznuje delat veci, ktere se v Cecku resi silenymi naprosto obskurnimi makro konstrukcemi bez jakekoliv ztraty efektivity vysledneho kodu. Umoznuje psat mnohem robustnejsi kod, ktery je 100x jednodussi psat a ladit.

[MJ]

Mimochodem, není tak úplně pravda, že by C++ bylo nadmnožinou C, pokud za C považujete C99. Složené literály? Restricted pointery? Nebo dokonce pokud srovnáváte s běžnými rozšířeními jazyka C – třeba vnořené funkce? (Pomocí těch se v GCC například dá vytvořit něco jako lambda-funkce.)

To jsou samozřejmě jen drobnosti, které tu a tam dokáží zpříjemnit programování. Jenže do téže kategorie spousta lidí řadí i většinu vymožeností C++

Ono je to bohužel tak, že složité makrové konstrukce se do C++ dají přepsat jen srovnatelně spletitými templaty, opravdová generika nenahradíte ani jedním.

[Let_Me_Be]

Ano, ANSI/ISO C++ (rok 1998) celkem logicky nemuze byt nadmnozinou ISO C (rok 1999, rev. 2001). Rozsireni jazyka mne opravdu nezajimaji.

Ono je to bohužel tak, že složité makrové konstrukce se do C++ dají přepsat jen srovnatelně spletitými templaty, opravdová generika nenahradíte ani jedním.

Cyklus napisu pomoci sablon na par radku. U maker to musi byt pres nekolik souboru. A tohle plati pro vetsinu konstrukci.

[MJ]

Příloha:

• hashtable.h (17565 bytů)

Dobrá tedy, vyzývám vás na souboj

Zkuste ukázat, jak pomocí šablon napsat ekvivalent generických hashovacích tabulek z libucw (viz příloha), který by byl přehlednější, a přitom stejně obecný a stejně rychlý. Já je napsal pomocí maker a přiznávám se, že docela zběsile. Jenže šablonami bych to lépe neuměl. Zkuste to i vy, třeba jste šikovnější a znáte C++ lépe.

[Let_Me_Be]

V tom pripade chci zadani a ne implementaci

Btw. licencovat hlavickovy soubor jako LGPL je trochu na hlavu. Hlavickovy soubor licencovany LGPL je zcela identicky s GPL licenci.

[MJ]

Co modul umí (tedy zadání), je popsáno v komentáři na začátku.

Co se licence týče, je to licence celé knihovny, ze které jsem si soubor vypůjčil, a jistě uznáte, že nedává valný smysl dávat hlavičkovým souborům jinou licenci než zbytku knihovny

[rm -rf /]

Uricte je C++ nadmnozina? Videl jste nekdy C? Co treba takova otevrena struktura, hmm?

Ja nemam problem s psanim makro konstrukci, kdyz si na to zvyknete tak to prost problem neni. Rozhodne ne 100x tezsi, to cislo je uplne mimo.

Jinak tim, co jsem psal jsem myslel to, ze program napsany obvyklymi zpusoby v C++ nebude rychlejsi nez ten samy napsany v C.

[Let_Me_Be]

Co treba takova otevrena struktura, hmm?

Co to je? Mozna to znam pod jinym nazvem, ale otevrena struktura mi opravdu nic nerika.

Jinak tim, co jsem psal jsem myslel to, ze program napsany obvyklymi zpusoby v C++ nebude rychlejsi nez ten samy napsany v C.

Pak to ale neni argument pro C ale pro C++.

[rm -rf /]

Co to je? Mozna to znam pod jinym nazvem, ale otevrena struktura mi opravdu nic nerika.

Otevřená struktura obsahuje otevřené pole.

[Let_Me_Be]

Co je otevrene pole?

[rm -rf /]

To myslite vazne nebo si ze me delate srandu? Vzdyt na webu mate napsano, ze ucite C a C++.

[Let_Me_Be]

Nedelam si srandu jelikoz s pojmem "otevrene pole" jsem se v zivote nesetkal.

[Deleted [8409]]

On myslí asi:

struct A { char a[]; };

Dá se to řešit i jinak, navíc nevím jestli je toto v ISO standardu.

[rm -rf /]

Je to tam uz pekne dlouho. Nepamatuji si, ze by to tam nebylo. Vsechno se da resit jinak, ale zrovna od Vas, kteremu se jina reseni (ala GObject) nelibi, bych takovou odpoved necekal.

[Deleted [8409]]

A co mi brání to udělat v C++ jako:

struct A 
{ 
  ...

  char a[1]; 
};

Tímto jsem získal to samé v bledě modrém. Tento postup dokonce používám, ale otázka je, k čemu se toto normálnímu programátorovi hodí ? Vždyť tuto techniku využije někdo, kdo opravdu ví co dělá a čeho tím dosáhne. Popravdě ani ten předchozí příklad z C [] jsem snad nikde neviděl (a to do zdrojáků čumím pořád).

[Deleted [8409]]

Ještě dodatek k tomu GObject.

Ne nelíbí, nelíbí se mi řešení, kvůli kterým se lidi rozhodnou psat další řešení, protože s původním řešením se s tím nedá pracovat. Mluvím o jazyce Vala a dalších X pokusech udělat vrstvu pro Gtk v C++.

[Kyosuke]

Na mě Gtk+ udělalo dojem, že bylo navrženo ne jako nástroj "pro přímou spotřebu", ale jako docela dobře definované API v čistém C (s "metamodelem" v podobě GObjectu) pro bindingy z vyšších jazyků. V tomto směru se s Gtk+ dá zřejmě pracovat mnohem lépe než třeba s Qt - přinejmenším bindingů pro Gtk+ jsem napočítal více, než bindingů pro jiné toolkity. Později jsem to dokonce našel v dokumentaci: [Bindings] are relatively easy to create because GTK+ is designed with them in mind. V případě "přímé spotřeby" se aspoň spousta z těch "ukecanějších" věcí dá docela dobře hádat. Pokud někdo píše GUI v Cčku, troufnu si to označit za "jeho problém".

[Let_Me_Be]

Tak tohle rozhodne v standardu neni. Jakou to ma vubec semantiku?

[Let_Me_Be]

Hmm, tak to tam prece jenom je. Zvlastni, ze jsem se s tim zatim nikdy nesetkal. Ale stejne mi nejak unika zpusob jak se to ma pouzivat.

Abych se vratil k C++, tak tohle v C++ opravdu nepotrebuji. Od ceho mame operator[]?

[Let_Me_Be]

Mno, nic, budu pokracovat ve samomluve, kdyz uz mne to tak chytlo. Po nastudovani jak se to vlastne pouziva uz musim rict ze C++ asi opravdu nema ekvivalent. Zase se ale uz vubec nedivim ze jsem se s tim zatim nesetkal, ty omezeni pouziti jsou tak velike, ze to je opravdu exotika.

[Kyosuke]

Vy učíte Cčko a nevíte, jak se používá?

[Deleted [8409]]

Tady už se jedná o vyšší Céčko, možná i CéCéčko

[rm -rf /]

Opravdu zvlastni, taky se podivuji, ze to clovek, co C i C++ uci, nevi. A stve me, jak dlouho jste tu svoji pocatecni lez (C++ je nadmnozina C) obhajoval, hlavne ten vyrok na ktery ted sam reagujete. Proc napisete, ze to ve stdandardu neni, kdyz jste ho necetl nebo si ho uz napamatujete? Proc mi lzete "primo do monitoru"?

Tuto nekompatibilitu jsem si vybral proto, ze se opravdu v C obcas pouziva (a asi by se pouzivala vic nebyt te nekompatibility). Napriklad na datove souborory, ktere zacinaji hlavickou a pak nasleduji data - namapujete je do pameti a pretypujete na strukturu s otevrenym polem. Kod je pak hezky citelny. Pak se to jeste da pouzit kdekoliv, kde potrebujete neco + nafukovaci pole. Naposledy jsem na to narazil v jedne trie, ktera bere v uvahu hiearchii pameti a kde se setri kazdy bit.

[Let_Me_Be]

Ucim primarne C++ ale jo, uznavam, mel bych to znat. Nicmene realne jde o usetreni jednoho malocu v pripade struct { t* x; }; pripadne niceho struct { t x[1]; }; (semanticky v podstate identicka zalezitost) jak napsal nekdo o par prispevku vys.

Nevim jestli tohle bylo v ANSI C ze ktereho aktualni norma C++ vychazi (mam tady pouze ISO standard), pokud bylo, tak jde o opravdu podivnou zalezitost.

[rm -rf /]

Do C++ toho neproslo z C vic. Pokud Vas to zajima a nechcete cist normy, tak si zkuste vygooglovat nejaky vycuc, pred lety jsem na takovy narazil.

struct { t* x; }; toto zabira o velikost pointeru vic, coz nemusi byt nezanedbatelne pokud tech struktur mate miliony.

struct { t x[1]; }; toto zvetsi samotnou strukturu, pri pretypovani se to chova podobne, akorat na vas prekladac bude hazet warningy, ze lezete za konec pole.

[MJ]

Mimochodem, zaručuje norma C++, že takové přetypování můžete provést? Céčková na to má poměrně přesná (a přísná) pravidla, probublala také do C++?

[Let_Me_Be]

C++ ma mnohem prisnejsi pravidla pretypovani, ale je tam samozrejme i klasicke Ceckove pretypovani a reinterpret cast zchrousta skoro vsechno.

[Let_Me_Be]

akorat na vas prekladac bude hazet warningy, ze lezete za konec pole

Co pouzivate za kompilator? To by se mi docela hodilo.

[rm -rf /]

icc a gcc, vetsinou oba.

[Deleted [8409]]

toto zvetsi samotnou strukturu

Ano, ale tady se bavíme o přetypování, nebo vytvoření struktury / třídy pomocí malloc(). Jen v málo případech budu vytvářet takovou strukturu na zásobníku, a to se opět dá udělat například pomocí šablony a dědičosti:

// Použít spolu s druhým příkladem
template<int N>
struct TempA : public A
{
private:
  unsigned char _storage[N - 1];
};

akorat na vas prekladac bude hazet warningy

To se mi nikdy nestalo, navíc v C++ přece můžeme napsat getter:

struct A 
{
  ...

  unsigned char _data[1];

  inline unsigned char* data() { return _data; }
};

Velikost můžu vypočítat jako sizeof(A)-sizeof(unsigned char) popřípadě si na to napsat inline statickou funkci. Problém vyřešen.

Moje řešení nebude ani pomalejší a ani nebude zabírat víc paměti. Je ekvivalentní tomu z C. Protože C++ tuto možnost nativně neumožňuje, tak jsem si pomohl korektním způsobem a docílil stejné funkcionality.

Jen tak pro zajímavost:)

Tuto techniku co jsem napsal používá například Qt toolkit pro primitivní třídy jako QString, QVector, atd. Všechny jsou implicitně sdílené. Abych mohl porovnat implementaci tak jsem se teď podíval na zdrojáky glib, kde je string definovaný takto:

struct _GString
{
  gchar  *str;
  gsize len;    
  gsize allocated_len;
};

Z toho vyplívá, že Qt je z hlediska řetězců efektivnější i ve spotřebě paměti i rychlosti (v glib se musí udělat 2x alokace paměti pro vytvoření řetězce). Takže více záleží opravdu na zkušenostech a přemýšlení programátora než na tom, jestli se to píše v C nebo C++. Pokud nedělám knihovnu typu libjpeg nebo dbus, je pro mě C++ jasná volba.

[Deleted [8409]]

STL je popsané v ISO C++, takže je součástí jazyka.

Ale když mi nevyhovuje tak ho snad používat nemusím nebo můžu používat jinou knihovnu, takže toto není argument. To je jako bych napsal, že jazyk C je pomalý, protože knihova XYZ je pomalá nebo špatně napsaná.

Když napíšu funkci v C tak, aby zárověň byla i funkcí v C++, tak budou stejně rychlé. V tom případě to C++ ale nepotřebuji, když ho nepoužívám, že.

Jenže ty C++ funkce nejsou v ničem jiné než ty v C. To, že funkce třídy skrývají argument 'this' je snad každému jasné, tak v čem se liší?

Samozřejmě, že toto umím naprogramovat. Zadarmo Vám to ale psát nebudu :-P

Ale šlo mi o to, jak se vám s tím bude pracovat ?

...

Jediné, proč má podle mě jazyk C smysl jsou knihovny typu libpng atd, víme proč... Ale v jiných oblastech jako třeba vývoj GUI aplikace je použítí C šílenost. Všechny ty konstrukce v Gtk alá GObject jsou jen náhražky, které jsou v C++ a dalších jazycích naprosto triviální a běžné (dědičnost).

[Cubic]

ja jsem čekal kdy se tu objevíte. Škoda, že to skutečně neni gcc-in-java, jinak bych si opět užíval jak roznášíte javisty na kopytech , musím říct že Vaše přítomnost v diskuzi je předvídatelná stejně jako páně Kubečkova pokud je řeč o ifconfigu

[trekker.dk]

Až na to, že páně Kubeček své tvrzení většinou podpoří fakty, kdežto tady není nic jiného, než výkřik do tmy složený ze subjektivních dojmů.

[Cubic]

O tom samozrejme muj vyzblebt nebyl.

[disorder]

ja mam pocit, ze to tiez berie ako svatu vojnu, ked protestuje proti jednoduchemu pouzitiu ifconfig ked to viem z hlavy a funguje to. uplne ina vec je zlozitejsia konfiguracia...

[Cubic]

moc to nedrazdi :))

[Michal Kubeček]

Tak to je opravdu jen pocit. V těch diskusích nejde ani tak o ty, kdo si zafixovali, že "ifconfig je v podstatě v pořádku", a které ani sebenázornější argumenty nepřesvědčí o opaku. Jde hlavně o to, aby se tahle nebezpečná teze nevtloukala hned od začátku do hlavy dalším a dalším generacím těch, kdo se to teprve učí. Konzervativci, kteří kvůli svým návykům raději setrvávají u (již devět a půl roku) nefunkčního nástroje, než by věnovali pár minut seznámení se s novými, holt asi budou muset "vymřít".

[disorder]

to je blbost, ja som narazil na obmedzenia ifconfig uz davno a to som s nim nechcel robit ziadne zazraky

pri ifconfig nie je mozne zotrvat, pretoze je to v zlozitejsich pripadoch nefunkcny nastroj (v jednoduchych funguje rovnako dobre a navyse sa to lahsie pamata)

[springer]

, musim se priznat, ze trpim stejnou chorobou, jak je tu neco o kompilerovani, C++ apod , tak hned hledam, co k tomu rika pan inzenyr. Asi bychom se meli dat vysetrit. Jinak pozoruji, ze Deda Jabko mu zacina delat konkurenci ...

[deda.jabko]

jakou konkurenci? ;-] ted jsem se prave krotil... a vubec jsem tu nenavrhl prekladac gcc-in-scheme, protoze vsichni vime, ze ve schemu se pisou zasadne prekladace schemu. (i kdyz osobne si myslim, ze gcc-in-erlang, by mohl byt husty... hlavne paralelni kompilace... ;-]) i komentaru k obskurnosti c++ jsem se dneska vystrihal... protoze, je to marny, je to marny, je to marny... ;-]

[MJ]

Pokud je to pravda, tak kde je ten mnohonásobně lepší C++-kový fork kernelu, který už musel nutně dávno vzniknout?

[Majkls]

Pokud si dobře pamatuji, tak když zalistujeme do starších jaderných novin, tak tam najdeme jakousi jízlivou poznámku na adresu C++:

C++ je děsný jazyk. A ještě horší ho dělá skutečnost, že ho používá spousta podprůměrných programátorů, takže je možné z něj vygenerovat totální a naprosté srágory. Upřímně, i kdyby C nesloužilo k *ničemu* jinému než k odrazování C++ programátorů, tak by to pořád stálo za to.
-- Linus Torvalds

Smozřejmě Linus není bůh, nicméně pokud zde někdo četl The art of UNIX programming, tak asi tuší, proč to Linus říká. Jinak štvalo by mě, že musím kvůli gcc tahat do systému jakousi c++ knihovnu. Ale nakonec zase o tolik nejde. Při nejhorším se to bude místo hodiny kompilovat tři. Hlavně aby vyprodukovaný kód byl opravdu lepší, když to chtějí tolik zefektivnit.

[Michal Kubeček]

Argumenty z té diskuse ve své většině ukazují pouze to, že Linux C++ nerozumí, protože si na něj udělal názor ještě dříve, než ho poznal. Navíc jsou to vesměs argumenty hovořící specificky proti použití C++ pro jádro, ne proti C++ pro aplikace. Bohužel si je ale řada lidí zkratkovitě překládá jako "Linus řekl, že je C++ špatné, tak je špatné."

[Let_Me_Be]

Spis bych rekl ze pretrvava myslenka ze C++ stoji za prd, protoze pred 15 lety stalo za prd.

[Michal Kubeček]

Ten konec IMHO měl znít "...protože před 15 lety stály za prd jeho implementace."

[Majkls]

Zdá se, že jste můj příspěvek nedočetl a nečetl jste ani zmiňovanou knihu. Citát jsem uvedl proto, že je podle mě trefný (byl to můj názor i bez Linuse). Problém C++ je (dle jednoho citátu) asi takový, že poslední člověk, který mu rozuměl byl nejpíš jeho autor. Spousta lidí používá c++ úplně nesmyslně, což dělá z kódu guláš. To je podle mě reálný problém.

[Michal Kubeček]

Většinu té knihy jsem četl (váš příspěvek jsem četl celý).

Spousta lidí používá c++ úplně nesmyslně, což dělá z kódu guláš. To je podle mě reálný problém.

To je IMHO pravda pro každý dostatečně rozšířený jazyk. Ale nevidím to jako problém jazyka, ale problém toho, že se programováním zabývá spousta neumětelů (jako ostatně každou činností, která vypadá trochu lukrativně, a kde poptávka převyšuje nabídku dostatečně kvalifikovaných sil). Kdybych uvažoval jako vy, musel bych dojít k závěru, že počítače jako takové jsou špatné, protože je spousta lidí používá naprosto nesmyslným způsobem.

[hwsoft]

No a o cem presne ted mluvis? Celkem me zas prekvapuji lide, kteri napsali tak maximalne neco na PC, ale o embeded systemech nevi nic, ale hlasi svoji pravdu jako obecne pouzitelnou.

Dat C++ na embeded je u cenove citlivych zarizeni nesmysl, narocnost na pamet je nasobne vyssi nez v C. O rychlosti ani nemluvim, v C++ neni mozne "ciste" neprogramovat cteni a zapis na port v plne rychlosti. Musi se pouzit primo assembler, pripadne zavolat podprogram v C. (i C program se musi vetsinou #pragmou usmernit, aby to bylo skutecne stabilni a rychle).

[Deleted [8409]]

Dovedu si představit program pro embedded zařízení napsaný v C++. Ty funkce v asm můžu použít i z C++ a třeba je udělat inline.

Ještě tady nezazněl ani jeden argument proč je to C++ tak strašně pomalé a veliké. Bavme se prosím o jazyce a ne o knihovnách (na nějakém osmibitu asi nebudu potřebovat stl, výjimky nebo dynamic_cast).

Otázka spíš je, kdo potřebuje C++ na takovém zařízení ? Toto je prostě sektor, kde C bohatě stačí...

[Let_Me_Be]

Jediny duvod proc se to nepouziva je ze tvurcum embeded systemu se nechce investovat do tvorby C++ kompilatoru (coz uznavam ze neni zcela trivialni zalezitost).

[Deleted [8409]]

My jsme ve škole měli nějaký 8 bit (tuším motorola hcs cosi), pro který jsem psal v C. Tuším, že IDE bylo CodeWarrior a byla tam možnost použít i C++, takže to šlo

Ale na to abych rozsvítil diodu nepotřebuju objekty, to je fakt zbytečné

[cronin]

Prednasajuci na predmete Umela inteligencia sa nam raz vyhrazal takymi vecami ako interpretel ProLog-u napisany v ProLog-u.

[Martin]

Kdyby tak místo toho radši pořádně zamakali na LLVM.

[Kyosuke]

Kdo jsou ti mýtičtí "oni"? Tvůrci GCC, co nemají s autory LLVM nic společného?

[Martin]

"Oni" jsou ti, kdo chtějí přehledné, snadno spravovatelné a rozšiřitelné "gcc" a jsou ochotni podílet se na jeho vývoji (a nelpí zas tak úplně na tom, že jejich výtvor musí být založený přímo na původním gcc).

LLVM je navíc alespoň částečně psané v C++ a má i další výhody oproti "starému" gcc. Viz www.llvm.org. Navíc vývojáři GCC a LLVM se alespoň částečně překrývají.

Jednu dobu se dokonce uvažovalo nad částečnou integrací LLVM do gcc, bohužel z toho nakonec sešlo - http://gcc.gnu.org/ml/gcc/2005-11/msg00888.html

[Kyosuke]

Spousta nápadů je na první pohled skvělá, na druhý už jenom velice dobrá a s každým dalším se vynořují nějaké ty problémy. GCC bych si netroufnul označit za "staré", ono se toho v něm děje docela hodně, třeba OpenMP ve frontendu a GIMPLE v backendu. Takže netuším, proč ty řeči o "lpění na starém GCC". Vlastnosti LLVM jsou mi celkem známy, ale otázka je, jestli přepsat půlku GCC kvůli LLVM by v současnosti přineslo víc výhod, než kolik by to zabralo času (který by se dal využít k implementaci chybějících vlastností přímo v GCC). Myslíte, že kdyby to bylo takhle jednoznačné, že by se to už bylo nestalo? Bohužel asi nepůjde jen o "LLVM umí tohle a GCC ne, takže musíme integrovat LLVM". Osobně necítím potřebu nad tím brečet, pokud to bude užitečné, někdo to časem udělá. Do té doby, řekl bych, bude GCC prostě fungovat, a vývojáři obou projektů si jsou konvergence jistě vědomi.

[Martin]

No, teď už ale diskutujeme o úplně něčem jiném, než na co jste původně reagoval.

Jinak to, že se i dnes v gcc odehrává spousta vývoje ještě neznamená, že není staré. Za ta léta vývoje nabaloval původně jednoduchý překladač spoustu funkcionality a v současnosti je IMHO gcc zralé na pořádný redesign. Nemyslím si, že prosté přepsání do C++ něco podstatného vyřeší. Jen pro zajímavost, čeho je možné dosáhnout pomocí promyšlené architektury - http://clang.llvm.org/features.html#performance (týká se clang frontendu, tj. nejmladší části LLVM).

LLVM by mohlo být právě tím redesignem. Netvrdím, že současné LLVM může posloužit jako kompletní náhrada za gcc. Pořád ještě nepodporuje spoustu jazyků a architektur, které podporuje gcc.

Prostě si myslím, že pokud někdo není spokojený se současným stavem gcc, je ochotný s tím něco udělat a nelpí na tom, že jeho výtvor musí být založený přímo na původním gcc (což má mimochodem úplně jiný význam než "lpění na starém GCC"), přispívat do LLVM by mohla být užitečnější činnost než přepisovat gcc do C++. Tak to vidím já, ale klidně ať si vývojáři píší třeba ten gcc-in-brainfuck, když je to bude bavit nebo to budou považovat za užitečné.

[MJ]

Mimochodem, dá se na stránkách LLVM a clangu najít nějaký benchmark, který by neměřil rychlost kompilace, ale rychlost vygenerovaného kódu?

[Michal Kubeček]

To mi připomíná, jak jsem se kdysi dávno po jedné prezentaci Kylixu (kde je mu dneska konec), kde se bili v hruď, jak rychle ten jejich kompilátor překládá, ale nepadla jediná zmínka o rychlosti výsledného kódu, zeptal přednášejícího, jak vypadá rychlost výsledného kódu v porovnání s gcc. Chvíli to vypadalo, že nerozumí, na co se ho to ptám a pak začal zmateně povídat, že tohle ještě netestovali, protože optimalizace se dělají až nakonec…

[Martin]

Benchmarky clangu se logicky týkají jen rychlosti kompilace, je to frontend. Pro benchmarky LLVM stačí googlit. Třeba http://lucille.atso-net.jp/blog/?p=430

Přímo na webu LLVM jsou "Nightly Test Results" na adrese http://llvm.org/nightlytest/ Ty ale nejsou moc přehledné.

[MJ]

Pro benchmarky LLVM stačí googlit. Třeba http://lucille.atso-net.jp/blog/?p=430

To není zrovna reprezentativní benchmark – je to v podstatě jedna těsná floating-pointová smyčka. Prakticky pro každý kompilátor najdete příklad kódu, který je efektivnější než u konkurence Zkoušel jsem najít něco obecnějšího, třeba SpecINT, ale zatím se mi to nepodařilo.

Přímo na webu LLVM jsou "Nightly Test Results" na adrese http://llvm.org/nightlytest/ Ty ale nejsou moc přehledné.

No, hlavně v nich není vůbec nic o rychlosti výsledného kódu, jsou to testy korektnosti překladače.

[Gogulux]

gcc-in-python