Z Javy do C++ (diskuse)

[Michal Vyskočil]

Kupodivu to jde docela snadno. Nechapu proc se tolik lidi boji C++, ale asi jeste narazim na par pasti.

To mi připomnělo Never trust a programmer who says he knows C++.

[stativ]

Jakmile je programátor za tím údolím, názor na C++ má takový, že C++ je jazyk úplně na hovno, ale přesto ho miluje

[Let_Me_Be]

Hmm, spis ze C++ je naprosto hrozny jazyk, ale vsechno ostatni je jeste horsi.

[deda.jabko]

kdyz uvazim vsechny jazyky ve kterych jsem kdy programoval, tak bych C++ zaradil nekam mezi Perl a Visual Basic, ... ano, existuje par lidi, kteri znaji vsechna skryta zakouti, ale ma to cenu?

[Sten]

Vzhledem k tomu, že ovládám všechny tři, tak znát dobře C++ (stejně jako ten Perl a na rozdíl od toho Visual Basicu) cenu rozhodně má, i když to není pro každého, vyžaduje to hodně abstraktní myšlení, hlavně co se šablon týče. Ale na rozdíl od Perlu v něm můžete programovat i jako začátečník (a šablony omezit na základy STL) a spolu s C jsou snad jedinými jazyky, které se dají použít kdekoliv a propojit s čímkoliv.

[pavlix]

Nauč se programovat v HTML, to ještě nikdo nedokázal :).

[Sten]

Memory leaky se v C++ řeší snadno: zásobníkem a RAII. Při dodržení těchto dvou zjistíte, že C++ má celkově lepší správu paměti než Java a přitom mnohem rychlejší. Akorát u cyklických závislostí musíte dávat pozor, kdy použít silný a kdy slabý chytrý ukazatel.

[Martin Mareš]

Akorát u cyklických závislostí musíte dávat pozor, kdy použít silný a kdy slabý chytrý ukazatel.

Což je pohodlné asi tak jako španělská bota :) Zvlášť když většina ukazatelů vede uvnitř nějakých knihovních datových struktur, o jejichž implementaci nelze spolehlivě nic předpokládat.

[kralyk z abclinuxu]

Jestliže se chceš naučit C++ a přicházíš z Javy, naprosto nejdůležitější je imho tato zásada: Při práci v C++ zapomeň na veškerou Javu.

[Let_Me_Be]

S tim musim souhlasit. Mym hlavnim ukolem pri vyuce Java programatoru je vytlouct jim Javu z hlavy.

[dementni.lojzik]

Pokud chces nejaky dalsi ctivo, tak se mi kdysi docela libilo C++ for Java Programmers (doporucoval bych to ale spis si nekde pujcit nez kupovat, pomerne rychle jsem od toho presel k nejake podrobne ucebnici C++, na jejiz nazev si ted nemuzu vzpomenout, protoze tahle knizka mi brzo prestala stacit). A co se memory leaku tyce, ze zacatku jsme z toho mel taky strach, ale nebylo to tak hrozny Navic pote, co jsem lovil nejake memory leaky v jave, jsem uz davno vystrizlivel z toho, ze gc se o vsechno postala. Naopak mi prijde, ze diky gc jsou ty memory leaky v jave mnohem lip schovany

[Trained.Monkey]

Ja s memory leaky v Jave problem nemam. Ale je pravda ze prohlizet 4GB velky memory dump nemusi vyhovovat kazdemu.

[dementni.lojzik]

Ja to myslel spis tak, ze najit pricinu memory leaku mi prijde v jave minimalne podobne tezke jako v C++, ne-li obtiznejsi. Mozna jsem ale mel jen smulu a potkal jsem v jave jen velmi vypecene memory leaky (nebo je to tim, ze v C++ jsou memory leaky asi castejsi a tedy casto trivialni). Jinak velikost heap dumpu je dalsi vec, 4 GB jeste jde, ale parsovat 16 GB, pripadne vetsi, heap dump je samo o some docela problem...

[kolmis]

A co třeba děláš ve Scale ? Zrovna čtu knihu od pana Oderskyho, je to pěkné :). I pracovní věcí ?

Co se JavaScriptu týče, dnes to není jazyk pro losers, dá se v něm psát poměrně slušně a strukturovaně, vzniklo spoustu projektů, frameworků, s pesoudeinheritencí (prototype.js), prostě nutící tě psát podle guidelines (jQuery). Ale věci jako node.js, to už mi přijde dost na palici.

Naučit se JS je otázka několika dní, stát se JS guru je běh na delší trať (a hlavně na to člověk musí mít náturu).

Můj pohled na C++ (a přechod z Javy) je tento: může se hodit, ale dobrovolně se do templatů, pointerů, maker nořit nebudu. Jen když jde o to udělat specifický úkol a pak pryč do světa, kde se mi libí - Java, Python, Ruby. QT framework neznám, ale dělat něco v C++ pro Windows, z toho mi vždycky vyskočí tlak.

[Bubak]

Ve Scale delam opensource astronomickou aplikaci. Doporucuju prelouskat celou knihu (800 stran), stoji to za to.

O JavaScriptu si porad myslim svoje, slavny Ajax je tu od roku 1998 a porad to je na prd. Az bude mozne copy&paste obycejny obrazek tak o tom mozna zacnu uvazovat.

[xkucf03]

Az bude mozne copy&paste obycejny obrazek

To je otázka prohlížeče, ne jazyka (ten může zůstat, jak je – ne že by se mi JS nějak zvlášť líbil, ale v tomhle je nevinně )

[pavlix]

O JavaScriptu si porad myslim svoje, slavny Ajax je tu od roku 1998 a porad to je na prd. Az bude mozne copy&paste obycejny obrazek tak o tom mozna zacnu uvazovat.

To asi nebude vina Javascriptu :).

[Petr Bravenec]

Knihovny Qt bych se nebál. Je pravda, že je to veliký moloch, ale na druhou stranu tam najdete množství užitečných věcí, které můžete, ale nemusíte používat, a když na to přijde, lze v Qt psát i programy čistě pro povelovou řádku. Odměnou za to dostanete přenositelné prostředí - já programuji v Qt pro Windows, Linux i embedded zařízení. Desktopové aplikace jsem dotáhnul až k naprosté dokonalosti - vše vyvíjím na jediném stroji a překlad pro windows (včetně vytvoření instalačního balíku) řeším jediným přepínačem pro qmake. Moje aplikace pro windows při vývoji windows nikdy nespatřily. V Qt se obvykle ani nemusíte příliš starat o správu paměti - při rozumném programovacím stylu se o vše postará knihovna Qt sama, každý objekt při likvidaci automaticky poslušně zlikviduje i své potomstvo.

[Bubak]

Problem s QT je ze potrebuju aby moje znalosti byly prenositelny treba i na Win32 API. A QT ma svoji verzi od vseho, a dost dobre to nejde. Moj cil neni vypilovat multiplatformi aplikace (k tomu mi bohate staci Swing), ale cist a udrzovat cizi kod.

[kralyk z abclinuxu]

Znalosti Win32 API jsou úplně stejně málo přenositelné jako Qt, to si nevybereš. Každá takováhle platforma je do menší či větší - většinou větší - míry speciální skoro jako jazyk sám.

Nadruhou stranu jak znáš jednu, nebude velký problém adaptovat se na jinou, protože ty principy fungování jsou častokrát stejné nebo podobné...

[xkucf03]

Znalosti Win32 API jsou úplně stejně málo přenositelné jako Qt, to si nevybereš.

Já si celkem vyberu – Qt je perspektivní a multiplatformní. A Win32 je… škoda mluvit

[kralyk z abclinuxu]

No jo, tak to já taky

[Rezza]

Tak pokud chce ciste C++, tak Qt neni nejlepsi priklad. Si ten jazyk znasilnuje po svem - viz. moc napriklad a tedy signaly/sloty, introspekce/reflexe atd., par novych konstruktu... Vyjimky se teze nepouzivaji... Ale jinak na Qt nedam dopustit :))) Kdyz jeste bylo QtJambi, tak ukazka portovani C++ a Java byla pomalu jen tvorena z ruseni & :)

[msk]

Ono sa nieco s QtJambi stalo?

[rADOn]

Ja jsem pred par roky prosel stejnou cestou a nestezuju si. C++ je sice teoreticky daleko narocnejsi, ale prakticky jsem zjistil ze je C++ tak nejak vic promysleny a domysleny. Krasne je to videt na standartni knihovne, je tam toho daleko min, nez v Javovsky, ale muzu se spolehnout ze to co tam je je spickovej kod a najdu ho tam i za deset let. (Ne)pravidelne zemetreseni v Javovske knihovne, php etc. proti tomu pusobi jak studentsky projektik. Dalsi postrehy:

Pointery a podobny vylomeniny jsou neskutecny zlo, ale na rozdil od jinech zel jsem ochotny ho prijmout protoze ma rozumny duvod. A tim neni fasisticka touha vnucovat vlastni prestavy o "spravnem" programovani.

Templaty jsou cira, koncetrovana magie. Chce to sice par mozkovych bunek, ale daji se s tim delat daleko zajimavejsi veci nez jen kontejnery, s luxusem typove kontroly a vykonem opravdoveho kodu.

Pokud clovek zna jen interpretovane jazyky, zjisti ze "programovani" je jen cast skutecnych znalosti C/C++. Skutecna legrace je s knihovnami a dynamickym linkovanim, autotools, balickovanim etc.

C++ neexistuje ve vakuu, spoluprace s jinymi jazyky a vazebni knihovny jsou bezna vec. Javisticka tendence ignorovat vsechno co neni v Jave me dodnes irituje.

Qt je moloch, ale to plati o kazde vetsi knihovne. Viz treba boost. Qt je aspon promysleny a dobre napsany moloch. Pokud chces delat GUI aplikace tak muzu Qt jedine doporucit.

[Let_Me_Be]

Boost je sice moloch, ale zase to je sbirka knihoven, pricemz jdou pouzivat jenom nektere z nich. Qt je sice taky modularni, ale rozhodne ne na takove urovni jako boost.

[Sten]

Asi největší rozdíl je v tom, že Qt má Meta Object Compiler, což z něj dělá prakticky vlastní jazyk, občas s dost problematickou kompatibilitou s jinými knihovnami.

[elviin]

Boost je sice moloch, ...

Molochem bych jej popsal z pohledu na jeho střeva, ale z venku je to api jednotlivých modulů přehledný a pěkně popsaný v dokumentaci. Ale jistě, každý jinak vnímá úroveň molochovitosti;)

[xkucf03]

(Ne)pravidelne zemetreseni v Javovske knihovne

Jaképak hrozné zemětřesení ve standardní knihovně tě potkalo?

ale na rozdil od jinech zel jsem ochotny ho prijmout protoze ma rozumny duvod. A tim neni fasisticka touha vnucovat vlastni prestavy o "spravnem" programovani.

Které třeba?

[rADOn]

(Ne)pravidelne zemetreseni v Javovske knihovne

Jaképak hrozné zemětřesení ve standardní knihovně tě potkalo?

Java 5. Generalni prepis zakladni veci jako jsou kontejnery podle me neni znamkou kdovijak promysleneho navrhu. Ze to bylo uz podruhe (poprve myslim Ve 2ce) duveru zrovna neprida. Ze to nebylo ani naposled, to uz jenom nasere. Jave viditelne schazi autorita s dlouhodobym pohledem jako je Bjorn nebo BDFL.

ale na rozdil od jinech zel jsem ochotny ho prijmout protoze ma rozumny duvod. A tim neni fasisticka touha vnucovat vlastni prestavy o "spravnem" programovani.

Které třeba?

Treba "kazda trida ve vlastnim souboru". Ne ze by to byla spatna praxe, ale... Ja se muzu rozhodnout ze to je spravny pro muj projekt. Muzu si myslet ze to je spravny pro vsechen muj kod. Ale autor jazyka to to vnucuje vsem, ve vsech projektech a za vsech okolnosti.

[podlesh]

Java 5. Generalni prepis zakladni veci jako jsou kontejnery podle me neni znamkou kdovijak promysleneho navrhu

Tady je krásně vidět, že se člověk nezavděčí všem. Někomu vadí že se generiky zavedly hodně zkriplené, aby se zajistila zpětná kompatabilita a místo přepsání se udělaly jen kosmetické změny, jiný brblá že tyto kosmetické a zpětně kompatabilní změny jsou hrozné zemětřesení.

[rADOn]

To je prave omyl. STL je podobne stara jako cela Java (prvni ISO specifikace je dokonce o rok starsi) a afaik se od te doby obesla bez kotrmelcu. Takze ono to jde

[xkucf03]

Asi každý jinak chápeme slovo „kotrmelec“ – já si pod tím představím zpětně nekompatibilní změny (ne přidávání nových funkcí/vlastností).

[rADOn]

Presne tak. Zmeny v STL jsou ponejvice pridavani specializovanejsich kontejneru, std::vector ma porad stejne rozhrani a je porad perfektne funkcni. Naproti tomu kdyz nam slunecni bohove dali java.util.Collection, stary kontejnery byly prakticky pres noc 'deprecated'. Ne ze by nezustala legacy implementace, ale jako ukazka promysleneho vyvoje to neni zrovna oslnujici. Zvlast kdyz uz tehdy bylo jasny ze ty krasny novy knihovny jsou porad jeste natolik blby, ze to bude chtit dalsi zmeny (ktery se afaik staly podnetem pro generics, ale za to uz ruku nedam, od ty doby se jave uspesne vyhybam).

[podlesh]

Koukám, že naznačovat nemá cenu, nemá cenu ani upozorňovat (jako to dělali jiní) a je potřeba to říct naplno: to jsou naprosté hovadiny. Žádné takové kotrmelce ani generální přepsání nebylo. Když byl do JDK přidán Java Collection Framework, tak byly staré kontejnery (Vector a Hashtable) i nadále funkční. V Javě 5 se nic neměnilo - jen byly přidány generiky, ale takovým způsobem že pro starý program se nic nezměnilo (opačnou cestu zvolil Microsoft v .net). Vlastně ani pro nový, pokud vypneme (nebo budeme ignorovat) warningy. V průběhu času přibyla nová rozhraní (Iterable, Queue, ConcurrentMap v 1.5, NavigableMap v 1.6) a samozřejmě i nové implementace.

Přitom stačí si dát trochu práce a není problém nalézt api které se skutečně překopávalo - například GUI (awt - swing) nebo práce se soubory. Nechápu jak si někdo může vybrat zrovna tu jednu část, která je navržena od začátku dobře a nebylo potřeba ji měnit.

[podlesh]

Nevěřím. Určitě existují lidé co si na "kotrmelce" v STL stěžují. Stačí pustit google na různé hate-page.

[Sten]

Jenže ty hate page neříkají nic o zpětné kompatibilitě, ale pouze o neschopnosti těch lidí STL používat.

[podlesh]

A já neříkám nic o schopnosti lidí používat STL nebo o zpětné kompatabilitě, ale o tom zda si lidé stěžují.

[xkucf03]

Java 5. Generalni prepis zakladni veci jako jsou kontejnery…

A rozbilo ti to nějaký kód, který před 5 fungoval? Takové rozbití se mi v Javě stalo jen jednou (v jiných jazycích jako třeba PHP je to daleko častější) a to když přišel Enum a já měl jednu proměnnou pojmenovanou enum – to samozřejmě nešlo zkompilovat, protože enum bylo od té doby klíčové slovo. Co se týče těch generik (nejen v kolekcích) tak to je skvělá věc, mohla být už dříve, ale aspoň, že je od 5. Je to prostě nová funkce, ale psát si to postaru klidně můžeš.

Treba "kazda trida ve vlastnim souboru".

S tím jsem nikdy neměl problém a naopak se mi to líbí (třída se jmenuje jako soubor, dá se v tom dobře vyznat). Java je poměrně jednoduchá a „omezená“ (byť to omezuje minimum* lidí) a to je právě jeden z důvodů jejího úspěchu – ve srovnání s jinými jazyky (C++, Perl, PHP atd.) je snazší číst kód po někom jiném a spolupracovat s ostatníma. Tohle beru jako výhodu, ne nevýhodu.

*) např. kdo by potřeboval mít víc tříd v jednom souboru nebo nemít adresáře a balíčky 1:1?

[rADOn]

Tak ja to napisu jeste jednou – me "kazda trida ve vlastnim souboru" nevadi a v C++ inklinuju k temuz. A pokud je to optimalni v 99% pripadu, nic mi v C++ nebrani to tak v 99% pripadu delat. Jenze drive ci pozdeji narazim na to jedno procento, a pak zacne byt setsakra rozdil jestli se musim drbat s nejakou obechcavkou proto ze k tomu je objektivni duvod (napriklad nejake optimalizace ktere by se jinak nedaly udelat) nebo proto ze nejaky chytrak musi vnucovat svetu svoji subjektivni predstavu "spravneho" programovani.

[xkucf03]

Žádný jazyk přece nebude nikdy 100% dokonalý a vhodný pro daný účel (to bys musel mít pro každý účel a každého programátora jiný jazyk) a i těch 99 % je úspěch. Celé je to potom o vážení výhod a nevýhod – a já to vidím tak, že je daleko větší pravděpodobnost, že budu mít problém se čtením kódu po nějakém bastlíři, který využil příliš volný jazyk k tomu, aby psal jako prase, než pravděpodobnost, že by mě samotného ten jazyk omezoval. A i když třeba na to 1 %, kdy se budu cítit omezovaný, dojde, tak pořád mi to přijde výhodnější, protože jsem si ušetřil výrazně víc práce při čtení kódu po jiných lidech.

[deda.jabko]

Tak ja to napisu jeste jednou – me "kazda trida ve vlastnim souboru" nevadi a v C++ inklinuju k temuz. A pokud je to optimalni v 99% pripadu, nic mi v C++ nebrani to tak v 99% pripadu delat.

jedna trida = jeden soubor je vcelku rozumne pravidlo a spousta lidi k nemu dospeje tak nejak automaticky

ale treba k pravidlu adresar = namespace spousta lidi nedospeje. a to je pak radost cist zdrojaky v C#, kde je jeden namespace rozhozeny pres pet adresaru a v jednom adresari je pet namespacu

[luky]

Treba "kazda trida ve vlastnim souboru".

S tím jsem nikdy neměl problém a naopak se mi to líbí (třída se jmenuje jako soubor, dá se v tom dobře vyznat).

Kdyz se ten kod generuje, tak je to opruz.

[Ladicek]

Java 5. Generalni prepis zakladni veci jako jsou kontejnery podle me neni znamkou kdovijak promysleneho navrhu.

Žádný generální přepis kolekcí se v pětce nekonal, to je nesmysl. Ale takové JDBC, kua, tam jsou nekompatibilní změny skoro v každé verzi.

Jave viditelne schazi autorita s dlouhodobym pohledem jako je Bjorn nebo BDFL.

Plus milión. I kdyby to měl být matlák typu Anderse Hejlsberga nebo toho Bjarna, pořád by to bylo lepší než teď.

Treba "kazda trida ve vlastnim souboru". Ne ze by to byla spatna praxe, ale... Ja se muzu rozhodnout ze to je spravny pro muj projekt. Muzu si myslet ze to je spravny pro vsechen muj kod. Ale autor jazyka to to vnucuje vsem, ve vsech projektech a za vsech okolnosti.

Každá veřejná třída ve vlastním souboru. Ale dneska asi není důvod se v javovském projektu orientovat podle adresářů a souborů, úplně stačí podle balíčků a tříd (s rozumným IDE, samozřejmě). Sice mne to taky občas štve, ale tohle je spíš drobnost.

[pht]

vykonem opravdoveho kodu.

To je už v dnešní době z velké části pasé.

[:::]

kdybys tohle tvrdil pred 10 rokama, kdy to jeste vypadalo ze procesory se budou zrychlovat do nekonecna tak bych se nedivil, ale rikat to dneska, kdyz uz nekolik let jsou procesory porad na stejny frequenci a moc nahoru uz to pravdepodobne nepujde, tomu teda rikam ignorance....

[Vskutečnosti Saýc]

To je ale tezko vec ktera by mela obhajovat C++, protoze psat v C++ kod ktery vyuzije vic procesoru a nebude jednou za mesic padat kvuli chybe kterou nikdy nikdo nenajde umi malokdo. Dava smysl se zamerit na jazyky ze kterych je snadne pristupovat k paralelismu.

[pavlix]

Pokud vím, tak na užití paralelismu je sice specializovaný jazyk výhodou, ale C++ (stejně jako naprostá většina jazyků s třídami) musí bohatě stačit za použití dobré knihovny pro sdílení dat mezi vlánky (píšu v teoretické rovině, nemám namysli nějakou konkrétní).

Neříkám, že to bude nutně ideál, ale použití vláken bez nepochopitelných chyb by tímto způsobem jít dosáhnout mělo.

[deda.jabko]

musí bohatě stačit za použití dobré knihovny pro sdílení dat mezi vlánky

kdyz se divam na vyvoj prog. jazyku tak to vypada spis, ze sdileni dat mezi vlakny je cesta do pekel a bude potreba jazyku, ktere ve jmenu paralelniho programovani budou vyrazne restriktivnejsi nez C++

[pavlix]

To ano... ale já reagoval pouze na to, co psal While.

Btw, nechceš si změnit patičku? Mohla by začínat „Asi před týdnem...“ :).

[Sten]

Pro masivní paralelizaci není potřeba restriktivní programovací jazyk. Je potřeba opatrný programátor.

[deda.jabko]

Pro masivní paralelizaci není potřeba restriktivní programovací jazyk. Je potřeba opatrný programátor.

to je stejne kvalitni tvrzeni jako, ze v assembleru se da taky programovat, jenom je potreba opatrny programator. podivej se na erlang nebo clojure

[Sten]

No, není. C++ umí používat raw pointery. Přesto se moc nepoužívají a nedoporučuje se je používat; jsou jen pro zvláštní případy. Stejně tak C++ umí přistupovat k proměnným z jiných vláken bez synchronizace. Ani to by se nemělo moc používat, opět je to jen pro zvláštní případy. Bohužel spousta programátorů, které znám, nějak chápe, že je potřeba dodržovat to první, ale to druhé už moc nechápou.

Assembler je v tomhle dost mimo, tam se hodně blbě dělají generika. Jediné srovnání by snad šlo s D, ale i to je takové omezenější.

Velice podobné tomu, jak se programuje v Erlangu nebo Clojure, jsou Intel TBB. Používá to C++, umožňuje to všechno, co C++, ale při té paralelizaci je potřeba, aby byl programátor opatrný, co dělá, protože C++ mu dovolí dělat téměř cokoliv. Čemuž je lepší se většinou vyhnout, ale někdy se to může hodit. Proto stačí opatrný programátor. Bohužel v realitě je spousta programů šrot a jakž takž fungují jenom díky tomu, že jejich jazyk nedovolí udělat takovou strašnou chybu, jakou C++ bez problémů umožní. To je IMO hlavní důvod, proč se tolik prosadili Java, C# a SAP.

[deda.jabko]

No, není.

tady nekdo nepochopil metaforu.

Stejně tak C++ umí přistupovat k proměnným z jiných vláken bez synchronizace.

na synchronizaci mas takove bajecne veci, jako zamky, coz je takove ,,goto'' paralelniho programovani. low-level operace, jde to pouzivat, programy funguji, ale casem se z toho stane peklo.

Velice podobné tomu, jak se programuje v Erlangu nebo Clojure, jsou Intel TBB.

To se mi az nechce verit, vazne TBB obsahuji treba transakcni pamet?

Používá to C++, umožňuje to všechno, co C++, ale při té paralelizaci je potřeba, aby byl programátor opatrný, co dělá, protože C++ mu dovolí dělat téměř cokoliv.

ani opatrnost ti casto nepomuze,... treba do posledniho updatu C++ nemelo definovany pametovy model, proto napsat prenositelnou implementaci bezzamkovych struktur bylo nemozne.

[Sten]

TBB přímo ne, ale existují C či C++ knihovny, které ji implementují. Nicméně v TBB není potřeba, protože TBB má konkurentní kontejnery, které mají transakční chování. Pokud byste transakční paměť opravdu potřeboval, lze ji snadno emulovat tak, že příslušné operace provede konstruktor objektu v tom konntejneru.

[kralyk z abclinuxu]

Přesně tak, c++ se v tomhle od paralel-friendly jazyků neliší tím, že neumožňuje dobrý paralelní kód, ale tím, že umožňuje velmi špatný paralelní kód

Krom toho část těchto problémů řeší C++11...

[osel]

Když použiješ třeba čistě funkcionální jazyk, tak paralelní a neparalelní kód jsou naprosto totožné. Rozhodnutí o paralelizaci se dá přenést na runtime knihovnu. V C++ ti bude přepis programu na paralelní s použitím dobré knihovny trvat třeba jenom poloviční dobu.

... použití vláken bez nepochopitelných chyb by tímto způsobem jít dosáhnout mělo.

Tady vidím obrovský rozpor.

[Sten]

Asi jste ještě nikdy neslyšel o C++ knihovně Intel Thread Building Blocks, která do C++ jenom pomocí šablonovacího systému přidává velmi silný paralelizmus. To je krásná ukázka neuvěřitelné síly návrhu C++

Jinak co se týče toho padání jednou za měsíc, s tím jsem se setkal u podivně napsaných aplikací bez rozdílu jazyka. Problém C++ je totiž (jak poznamenal Linus) velké množství špatných programátorů. A C++ má velkou sílu dělat divné věci.

[pht]

kdybys tohle tvrdil pred 10 rokama, kdy to jeste vypadalo ze procesory se budou zrychlovat do nekonecna tak bych se nedivil, ale rikat to dneska, kdyz uz nekolik let jsou procesory porad na stejny frequenci a moc nahoru uz to pravdepodobne nepujde, tomu teda rikam ignorance....

S rychlostmi procesorů to nemá nic společného.

Java už dávno není interpretovaný jazyk, JIT kompilátor toho umí opravdu hodně a rozdíl oproti tomu "opravdovému kódu" začnete cítit až od určité poměrně dost vysoké meze.

[elviin]

Pro zacatek pouzivam vsude smart pointers a nechavam za sebou hromadu memory leaku.

To mi přijde jako protimluv. Můžeš rozepsat, proč si myslíš, že necháváš za sebou leaky při použití smart pointerů.

[JS]

C++ moc neznam, ale od doby, co znam Common Lisp, k tomu muzu rict jen jedno. Nepochopim, proc nesli cestou plnohodnotneho makro systemu misto sablon. Oboji vam umozni strelit se do nohy, ale makro system je aspon obecnejsi.

Podle me je to nejak.. nedomyslene. Na jednu stranu je zde filozofie, ze programatorovi by se melo zabranit strelit se do nohy; jenze tim se mu take zabrani psat efektivni kod a to neni vzdycky zadouci. To je filozofie Javy.

Na druhou stranu, pokud uz mu to dovolime (strelit se do nohy), zpravidla prave za ucelem psani efektivniho kodu, veskera omezeni postradaji (v urcite chvili) smysl. To je filozofie C.

Prijde mi, ze C++ se to snazi nejak podivne spojit. Na jednu stranu dovoluje programatorum strelit se do nohy, na druhou stranu zavadi arbitrarni omezeni (dana jazykem), ktera jsou filozoficky na opacnem konci.

Common Lisp to naopak resi makry, takze se sice muzete strelit do nohy, ale zaroven si proti tomu vytvorit ochranu pomoci maker. To mi prijde jako lepsi cesta.

[deda.jabko]

C++ moc neznam, ale od doby, co znam Common Lisp, k tomu muzu rict jen jedno. Nepochopim, proc nesli cestou plnohodnotneho makro systemu misto sablon.

Me prijde, ze to bude mit nejakou historickou pricinu a ze driv makra byla v nemilosti. Od spousty C++ programatoru jsem slysel, ze makra jsou zlo, protoze umoznuji delat chyby, ktere jsou pry spatne odhalitelne. Tipoval bych, ze sablony vznikly jako pokus nahradit makra, jenomze, jak ve spatnem hororu, se tento pokus vymkl kontrole a vzniklo z toho, co vzniklo.

Na jednu stranu je zde filozofie, ze programatorovi by se melo zabranit strelit se do nohy; jenze tim se mu take zabrani psat efektivni kod a to neni vzdycky zadouci. To je filozofie Javy.

Oni si programatori vzdycky najdou neco, cim se muzou strelit do nohy. V zadnem jinem jazyce jsem nevidel tolik projektu trpet overengineeringem, jak v Jave.

[kralyk z abclinuxu]

Od spousty C++ programatoru jsem slysel, ze makra jsou zlo, protoze umoznuji delat chyby, ktere jsou pry spatne odhalitelne.

#include <iostream>
#define ABS(x) ((x) >= 0 ? (x) : -(x))

int main()
{
  int x = -3;
  std::cout << ABS(++x) << std::endl;
}

Kolik bude vypsáno?

Makra v C++ jsou zlo, a to především proto, že přinášejí možnost všelijakých špatně viditelných chyb (jako ta výše), ale přitom moc nepřinášejí žádný benefit. V C++ prostě makra k ničemu nepotřebuješ. A když je potřebuješ, tak je něco špatně.

Jediný rozumný důvod pro makra v C++ vidím v některých případech v deklaraci, a i tak bych váhal.

[Heron]

std::cout << ABS(++x) << std::endl;

Nás vždy učili na jednom řádku dělat jednu věc. Věci jako ABS(++x) jsou (podle tohoto pravidla), prasárna sama o sobě, ať jde o makro, nebo třeba volání funkce (kde záleží na pořadí vyhodnocení argumentů). Takže tato past může sklapnout i jinde.

[kralyk z abclinuxu]

Umim si představit, že by byl problém s x++, ale s ++x? Krom toho, mohlo by tam být třeba volání funkce, jejíž výsledek člověk nechce lokálně ukládat. Zavolala by se dvakrát... Mám to odtud, tam mají zla maker shrnutá... Zároveň je ale dodáno, že je člověk přesto občas použije. Imho moc dobré toto faq.

[Petr "Glubo" Sýkora]

IMHO problém netkví v x++ vs. ++x, ale v tom, že dříve, než se vůbec nějaké ++ vyhodnotí, tak preprocesor kód přeloží jako

std::cout << ((++x) >= 0 ? (++x) : -(++x)) << std::endl;

Odkud je již vidět, kde je zakopán pes.

[kralyk z abclinuxu]

To vím, řeč byla o něčem jiném; o tom, že by mohlo ++x způsobit problém ve volání funkce... což moc nevím jaký, leda by se to použilo dvakrát po sobě, což tedy už je prasárna i podle mě...

[deda.jabko]

To vím, řeč byla o něčem jiném; o tom, že by mohlo ++x způsobit problém ve volání funkce... což moc nevím jaký, leda by se to použilo dvakrát po sobě, což tedy už je prasárna i podle mě...

uvazuj treba:

void foo(int, int);
x = 1;
foo(x++, x);

Protoze poradi vyhodnoceni argumentu neni presne specifikovane (nejcasteji jde ovlivnit volaci konvenci), muzes funkci volat s argumenty (2, 2) nebo (2, 1) a porad to bude korektni. Problem taky muze nastat pokud se prekladac rozhodne preskladavat nebo eliminovat argumenty kvuli optimalizaci, a to se pak hleda hur.

[Ladicek]

Že je zhovadilost používat operátory inkrementace a dekrementace jinde než v samostatném příkazu x++; se dá ukázat a bylo mnohokrát ukázáno na mnohem jednodušších příkladech

[kralyk z abclinuxu]

Asi jsem tam měl dát míst toho ++x volání funkce...

[Ladicek]

Pak bych řekl totéž o vedlejších efektech

[xkucf03]

K čemu je pak dobré, že máme x++ i ++x?

[Ladicek]

V zásadě k ničemu. Jo, počkej, pro jednu jedinou situaci – for cyklus. Tam se to občas hodí.

[JS]

Pokud pouzivas PDP-11, muze se to hodit.

[kralyk z abclinuxu]

K čemu je pak dobré, že máme x++ i ++x?

No přece k tomu, aby člověk mohl psát takovýto krásný kód

[Sten]

Třeba při složitějším parsování se běžně používají obě varianty, podle toho, co očekáváte.

[JS]

V C++ prostě makra k ničemu nepotřebuješ. A když je potřebuješ, tak je něco špatně.

Takze treba takove Qt je spatne, kdyz dela veci, ktere se bez hypotetickych maker udelat nedaji? Implementace MOC je napriklad velmi dobry priklad, jak makra v C++ chybi. Nebo takovy SWIG. Nebo.. v podstate pro kazdou aplikaci, kde je treba parsovat C++ by byl dobry makro system uzitecny.

[kralyk z abclinuxu]

No však taky v Qt to používaj prakticky jen pro deklaraci...

v podstate pro kazdou aplikaci, kde je treba parsovat C++ by byl dobry makro system uzitecny.

No to souhlasim... dobrý makro systém by byl fajn

[podlesh]

Já si troufám říct, že šablony v C++ jsou macro systém, akorát (oproti lispu) dost omezený. Ale nevím zda by se dal udělat lepší při splnění podmínky, že výstupem kompilátoru musí být nativní kód neobsahující kompilátor.

[Michal Vyskočil]

Me prijde, ze to bude mit nejakou historickou pricinu a ze driv makra byla v nemilosti. Od spousty C++ programatoru jsem slysel, ze makra jsou zlo, protoze umoznuji delat chyby, ktere jsou pry spatne odhalitelne

Tohle bude to kutlurní nedorozumnění. Pokud programátor v Lispu mluví o makrech, tak rozhodně nemá na mysli C preprocesor. Asi největší výhodou Lispových maker pak vidím v tom, že makrojazyk je prakticky totožný s hlavním jazykem, což rozhodně není případ šablon v C++.

[JS]

Myslim, ze deda.jabko tohle dobre vi, ale pro kralyka a ty pod nim je to dobra poznamka.

Myslim, ze pointa byla, ze se autori C++ chteli vyhnout C makrum nebo jejich rozsireni, proto s tim meli problem, a Lispova makra bud poradne neznali, nebo je mylne povazovali za stejne spatna, a v neposledni rade take meli problem se syntaxi (jak znamo, Lispova makra vyuzivaji (ne)syntaxe Lispu).

Jiste ekvivalence makro jazyka s puvodnim jazykem je vyhoda. Ale me slo spis o to, ze obecne, pokud chcete lidem dovolit delat veci efektivne, musite jim uz z principu dat volne ruce, a proto potrebujete jakykoli makrosystem, byt v obskurnim jazyce. Ze se daji sablony zneuzit na turingovsky uplny jazyk je z meho pohledu spise jejich vedlejsi efekt, nikoli umysl, a to je prave to, co povazuji za problem.

[kralyk z abclinuxu]

No já měl hlavně námitky proti C preprocesoru, resp. jeho použití v C++...

Co se týče maker obecně, tak z hlediska použití programátorem to je sice opravdu hezká věc, ale mám dost pochybnosti o následné kompilaci. Vestavěné struktury jazyka, jako podmínky, cykly a tak dál, může překladač velmi dobře optimalizovat pro danou platformu, když si ale takovýhle konstrukce napíšu v metajazyku a pak je použiju, bude mít kompilátor omezené možnosti je optimalizovat.

[Petr Bravenec]

C preprocesor je věc, která mi u jiných jazyků občas chybí. Programátoři například často používají pojem "zakomentuj to" - ale tím, že jsem dal kus kódu mezi /* a */ jsem nevytvořil komentář, pouze jsem řekl překladači "tuto část kódu nepoužívat". C na tyto případy pamatuje - má preprocesor. Kus kódu v komentáři je jinde tak rozšířený nešvar, že má i vlastní slangové označení: "Zakomentuj to".

V C++ používám preprocesor (kromě deklarací) velmi vyjímečně. Pomocí preprocesoru dokážu stejný kód přeložit pro různé platformy (rozdílné cesty a chování souborů ve windows a v linuxu) či definovat číslo a označení verze překládaného programu až při překladu externím programem. To je zase užitečné, má-li být výstupem překladu projektu už hotový instalační balík s číslem verze odpovídající tomu, co je zabaleno vevnitř.

Někdy vytvářím kód pro zařízení, se kterým se jinak špatně pracuje (různé arm stroje). Program si v takovém případě vytvářím a ladím v linuxu, na arm přenáším až po odladění. Běžně se dostávám do situací, kdy jsou v arm jiné knihovny, než na pc. Pak mohu použít #ifdef kolem každého volání rozdílných funkcí, případně použít makro - wrapper. Kód se použitím maker značně zpřehlední.

Hodně jsem svého času používal makra na procesorech avr. U jednočipů je naprosto kritické, zavolám-li nějakou "funkci" jako skutečnou funkci, nebo ji vytvořím pomocí makra. V prvním případě se uklízí stav procesoru a návratová adresa na zásobník, v druhém případě se vloží do aplikace pouze pár instrukcí procesoru.

Všimněte si, prosím, že kromě komentářů-nekomentářů jde o zcela speciální situace.

[kralyk z abclinuxu]

V C++ používám preprocesor (kromě deklarací) velmi vyjímečně. Pomocí preprocesoru dokážu stejný kód přeložit pro různé platformy (rozdílné cesty a chování souborů ve windows a v linuxu) či definovat číslo a označení verze překládaného programu až při překladu externím programem.

Tohle by imho měl řešit build systém spíš než (samotná) makra. Většina build systémů na to je i vhodnější než pouhá makra. Můžeš v závislosti na systémů includovat celé headery nebo nastavovat include dir, atd... Samozřejmě se přitom ta makra taky občas použijí, neříkám, že ne...

U jednočipů je naprosto kritické, zavolám-li nějakou "funkci" jako skutečnou funkci, nebo ji vytvořím pomocí makra. V prvním případě se uklízí stav procesoru a návratová adresa na zásobník, v druhém případě se vloží do aplikace pouze pár instrukcí procesoru.

Přesně na tohle slouží inline, pakliže to daný kompilátor podporuje...

[JS]

Podivej se do knizky On Lisp od Paula Grahama. Tam je spousta prikladu na typicka Lispova makra. Podle me ta knizka jednoznacne dokazuje, ze makra jsou setsakra uzitecna vec a ne ze ne.

[Ladicek]

Je to sice mimo téma, ale můžeš něco říct (pokud ji znáš) o knížce Let Over Lambda? Mám ji nějakou dobu v shopping listu na Amazonu a pořád si nejsem jistý, jestli jo nebo ne…

[JS]

Cetl jsem ji. Velka cast je ji na webu (chybi tam akorat 2 kapitoly - o optimalizacich, kde predvadi kompilator tridicich siti, a o Forthu, kde implementuje Forth "interpret" na Lispovych seznamech). Konceptualne je tam mnoho zajimaveho, ale prakticky bych to asi k nicemu nepouzil (coz se o makrech v On Lisp rict neda). Rekl bych, ze je to takove (mensi) pokracovani On Lisp, i kdyz ta prakticka hodnota je nizsi. Celkove je to cele dost obskurni a pokud te vylozene nezajimaji dalsi potencialni aplikace maker, asi to nestoji za to.

[JS]

Jeste dodam, ze v podstate ty kapitoly 2-6 jsou takovy uceleny celek, ty 7-8 jsou tak nejak bokem. Takze si muzes precist to co je na webu a o moc neprijdes.

Ma tam zajimavou koncepci, ktere rika "syntakticka dualita". Proste ze je podle nej dulezite minimalizovat pocet zasahu do programu, a tedy je dulezite, aby podobne objekty (chovanim) zachovavaly v programovacim jazyce stejnou syntaxi. Jako priklad uvadi dynamicke a lexikalni promenne (a proc odmita hvezdickovou *syntaxi* pro dynamicke promenne), ktere se chovaji stejne, a tedy lze snadno v programu zamenit lexikalni promennou za dynamickou a naopak (coz ma vyznam v makrech). Stejne tak treba dualita mezi volanim funkce a volanim makra - je snadne nahradit funkci makrem nebo naopak. Nevim, jestli s nim uplne souhlasim, ale rozhodne je to zajimavy postreh.

[Ladicek]

Díky!

[JS]

Ano, ale ja tou otazkou "proc nesli do makro systemu" myslel take trochu jiny makro system, nez nabizi C preprocesor. Polozil jsem ji proto, ze bych rad vedel, zda nekdo vidi nejakou vyhodu se omezit oproti makro systemu (treba a la CL) pomoci sablon a dalsich vynalezu, co C++ nabizi oproti C.

No, samozrejme, ty konstrukce v metajazyku se typicky pisi na zaklade vestavenych podminek a cyklu, a proto je kompilator optimalizovat muze docela dobre. Nehlede na to, ze si vlastne muzes cast toho kompilatoru (tu vyssi uroven) v tech makrech napsat sam a v CL se to casto take tak dela.

[podlesh]

IMHO je to z toho důvodu, že na výstupu kompilátoru C++ se očekává "holý" kód - tedy takový který neobsahuje kompilátor (ani jeho ekvivalent). Dá se vůbec za této podmínky implementovat něco mocnějšího než jsou šablony?

Již jsem reagoval ale zde je to lepší...

[JS]

Myslim, ze uz jsem na to v podstate odpovedel. Sablony v C++ jsou turingovsky uplne jako vedlejsi efekt, ne jako umysl navrhu. Z tohoto pohledu samozrejme uz mocnejsi jazyk naimplementovat nelze. Ovsem z jemnejsiho pohledu, z ktereho ne vsechny turingovsky uplne jazyky jsou si rovnocenne, to slo udelat daleko lepe. Napriklad slo prave umoznit tomu makro systemu lepe parsovat C++ kod.

[JS]

Jeste neco - spousta lidi si plete makro system a veci jako eval. To jsou zcela nezavisle veci. Makro system je vyhodnocovani ve fazi pred kompilaci. S behem programu to nijak nesouvisi, ani neni nijak zvlast potreba adaptovat kompilator, protoze ten dostava uz (makry prepracovany) zdrojovy kod podle specifikace.

[kralyk z abclinuxu]

S behem programu to nijak nesouvisi, ani neni nijak zvlast potreba adaptovat kompilator, protoze ten dostava uz (makry prepracovany) zdrojovy kod podle specifikace.

No jo, jenže jaký zdrojový kód ten kompilátor dostane není lhostejné.

Jestliže kompilátor dostane (například) jeden for cyklus, může to optimalizovat lépe, než když dostane nepředvídatelné houští všelijakých goto.

[Petr Bravenec]

1. Kód předložený kompilátoru závisí jen na mě, bez ohledu na makra.

2. C++ není Fortran.

3. Kompilátoru je úplně jedno, jestli jsem to předvídal, nebo ne.

[Petr Bravenec]

Makra v C jsou jako koření v kuchyni. Nakrájejte půl kila hovězího na plátky, rozdrťte patnáct kuliček pepře a poduste to. Bude vám to chutnat. Ale zkuste to v poměru 1:1 - půl kila hovězího a půl kila pepře... chtěl bych vidět váš kyselý xicht

[prqek]

Kyselý? Ale jinak hezký příměr.

[JS]

Tenhle argument je samozrejme naprosto nesmyslny. Makra se samozrejme pisi tak, aby produkovala ten nejvhodnejsi kod v danem pripade, tedy pokud je pro tu danou aplikaci dosazitelne napsat tam cyklus misto goto, da se tam cyklus. Je to proste jako kdyby ten kod psal clovek, akorat se s tim nemusi delat.

Na makrech zkratka neni nic spatneho ani magickeho. Je to uzitecny nastroj/koncept, stejne jako napriklad je jim funkce nebo knihovna.

[Ondrej 'SanTiago' Zajicek]

Jestliže kompilátor dostane (například) jeden for cyklus, může to optimalizovat lépe, než když dostane nepředvídatelné houští všelijakých goto

Pokud vim, tak optimalizace se stejne vetsionu delaji nad nejakou vnitrni reprezentaci (napr. control flow graph), kde uz je vcelku jedno, zda v programu byl for cyklus nebo smes goto.

[deda.jabko]

vetsina dnesnich prekladacu jako jednu z prvnich veci udela preklad do vnitrni reprezentace na bazi SSA nebo CPS a pak uz je pomalu nemozne poznat jestli tam byl for, goto, nebo tail-call.

[Petr Bravenec]

když si ale takovýhle konstrukce napíšu v metajazyku a pak je použiju, bude mít kompilátor omezené možnosti je optimalizovat.

Kompilátor to nepozná. Kompilátor se ke kódu dostane až po zpracování preprocesorem.

[Ivan]

A programator se nedostane k tomu co je skutecnym vstupem pro kompilator.

[Petr "Glubo" Sýkora]

A programator se nedostane k tomu co je skutecnym vstupem pro kompilator.

gcc -E foo.cpp

[deda.jabko]

Myslim, ze deda.jabko tohle dobre vi, ale pro kralyka a ty pod nim je to dobra poznamka.

Myslim, ze pointa byla, ze se autori C++ chteli vyhnout C makrum nebo jejich rozsireni, proto s tim meli problem, a Lispova makra bud poradne neznali, nebo je mylne povazovali za stejne spatna, a v neposledni rade take meli problem se syntaxi (jak znamo, Lispova makra vyuzivaji (ne)syntaxe Lispu).

Presne tak jsem to myslel.

[Michal Vyskočil]

Myslim, ze deda.jabko tohle dobre vi, ale pro kralyka a ty pod nim je to dobra poznamka.

Já vím, že autor Schemika tento rozdíl asi postřehl. Jenom jsem svoji reakci přišpendlil na špatné místo.

[Ondrej 'SanTiago' Zajicek]

C++ moc neznam, ale od doby, co znam Common Lisp, k tomu muzu rict jen jedno. Nepochopim, proc nesli cestou plnohodnotneho makro systemu misto sablon. Oboji vam umozni strelit se do nohy, ale makro system je aspon obecnejsi.

Lispovy system maker je dost silne vazany na to, ze nativni lispove struktury (seznamy a symboly) prirozene reprezentuji Lispovy zdrojovy kod. Takze makrojazyk pro Lisp je vcelku prirozene reseni, pro jine jazyky to v podstate znamena navrhnout druhy programovaci jazyk.

Jinak lisp-style makra maji take spoustu problemu a napr. ve Scheme lisp-style makra opustili a misto toho maji vice deklarativni (a hure pochopitelny) makrojazyk (alespon tedy v R5RS, R6RS jsem nestudoval).

Jinak genericky makrojazyk je urcite uzitecna vec, ale metaprogramovani je obecne slozite a problematicke a mam pocit, ze nejcasteji uziti maker je stejne na obchazeni limitaci jazyka - v C je to nepritomnost generickych konstrukci, v Lispu/Scheme pak nemoznost zmenit namespace volaneho resp. nepritomnost nejake obdoby call-by-reference. Vyuzivat makrojazyk pro tyto pripady zbytecne veci komplikuje, takze rozumne reseni je do jazyka dodat potrebnou funkcionalitu a makra nechat jen na ty veci, na ktere jsou opravdu potreba. Proste pouzivat

C++ je IMHO v tomto opacny extrem, kde se, mam dojem, sablony pouzivaji z duvodu nepritomnosti vhodnejsiho prostredku na veci, ktere jsou za hranici obecnosti problemu, pro kterou se sablony hodi.

[Martin Mareš]

Lispovy system maker je dost silne vazany na to, ze nativni lispove struktury (seznamy a symboly) prirozene reprezentuji Lispovy zdrojovy kod.

Ne nutně – i v jiných jazycích mohou makra pracovat nad syntaktickým stromem kódu. Pokud si pamatuji, tohle umí jak Perl6, tak nějaké rozšíření Haskellu.

Čím dál víc mi připadá, že používat jako preprocesor tentýž jazyk (do libovolné hloubky vnoření, samozřejmě) je jediná možnost, která doopravdy dává smysl.

[happy barney]

hmm, toto si pridaj do todo: Guru of the Week, vrelo odporucam kazdemu kto zvladol prvu stovku z "Stroustrup: The C++ Programming Language (3rd)"

[Bedňa]

Pozri sa na U++

Pekné vysvetlenie prečo používať U++

Shrnuto a podtrženo, v U++ se snažíme dodržovat tyto zásady:

• Správa paměti je implementační detail, na úrovni rozhraní nemá co dělat.
• delete je nízkoúrovňová operace, které by se měla používat co nejméně. Většina koncových aplikací v U++ ji nepoužívá vůbec.
• new má legitimní použití pouze ve velice speciálních případech, většinou souvisejících s polymorfií.
• Chytré sdílené ukazatele jsou to nejhorší, co mohlo C++ potkat.

[mirec]

Čo binárna kompatibilita?

[Bedňa]

Prečo binárna je multiplatformné.

[mirec]

Aby som pri každom update nemusel všetko prekompilovávať. Aby som mal jedinú verziu, ktorá pobeží na prakticky všetkých distribúciách. Aby mi desatinková aktualizácia nerozbila celú aplikáciu ... Proste ako keby mi pri prechode z Qt 4.7.3 na 4.7.4 prestala aplikácia fungovať len preto, že veľkosť jedného objektu sa zvýši povedzme o 32 bitov tak rovno zahadzujem knižnicu keď už pre nič iné tak pre neexistujúcu binárnu kompatibilitu. Preto vo verejnom rozhraní nepoužívam zásadne celé objekty, ale len referencie (výnimočne pointre).

[Bedňa]

Pre mňa je zárukou spoľahlivosti líder projektu Mirek Fídler, asi by to trebalo dohľadať na nete. Inak problémy môžu občas nastať všade, vývoj ide ku predu a pri implementovaní novej funkcionality to niekde môže zadrhnúť, to nieje bug ale fjučúra, takto by sme mohli pochovať všetko. Samozrejme stotinkové aktualizácie musia byť binárne kompatibilné.

[mirec]

Ako môžu byť kompatibilné bez hrabania na pointre? Neraz som robil stotinkovú aktualizáciu kvôli bugu pri určitom use case, s ktorým som nerátal a musel som kvôli tomu trochu prekopať vnútro triedy. Keďže ale dátovú časť tried väčšinou tvorí opaque pointer nenastane žiaden problém (jedine ak by snáď niekto využíval bug). Zmena implementácie vnútra triedy / pridanie tried / pridanie metód je bezpečná operácia pri ktorej všetko vyrieší linker. Samotné objekty ale linker neporieši. Preto radšej robím s pevnou veľkosťou (32bit / 64bit / ... podľa platformy) objektov.

Ako C++ nie je jazyk pre každého, nerád by som bol ak by sa niekto z C++ snažil urobiť niečo, čo nie je. Je to proste nízkoúrovňový jazyk so všetkým, čo k tomu patrí a kto chce niečo iné má fúru iných jazykov. Kto chce v C++ robiť kvalitný kód musí prejsť dlhou a ťažkou cestou. Ono to trvá kým sa človek naučí používať podmnožinu tak komplexného jazyka ako je C++, ktorú bude často používať. Ak si človek ale zvykne na C++ nie je to o moc zložitejšie ako vo vyšších jazykoch.

[Bedňa]

Na nízkoúrovňové programovanie tu mám C, však on sa Pavlix ozve Frameworky tu máme od toho aby si neriešil stále to isté a dookola niekde v kóde to zas zabudol ošetriť. U++ ale ide ešte ďalej, porovnaj QT, U++ a to nieje všetko.

[pavlix]

Volal mě někdo?

[Bedňa]

Kua že rýchlosť

[pavlix]

Akorát u tématu, kde absolutně nemám co dodat :).

[Bedňa]

Som myslel že sa vyjadriš k C a C++ :)

[pavlix]

Proč bych měl? :)

[Bedňa]

Mal som pocit, že povieš niečo k C a C++

[pavlix]

Ale já nevím proč :).

[kralyk z abclinuxu]

Nepřijde mi, že by to porovnání mělo nějakou vypovídací hodnotu. Ten příklad z Qt zaprvý už v Qt nemůžu najít (nejspíš něco staršího) a zadruhý je to příklad, který je psaný tak, aby byl názorný, ne co nejkratší. Krom toho jak na to koukám, Qt toho umí mnohem víc než U++. Ale neříkám, že je U++ špatný, vypadá to celkem dobře.

[Bedňa]

QT je výborný projekt, ale v U++ majú správu pamäte vymakanú, je to C++ inak.

[mirec]

Last edit by dolik on 06/24/2010

Zaujímav v roku 2010 porovnávať niečo s už niekoľko rokov nepoužívaným frameworkom (Qt3).

Rovnako zaujímavé porovnávať layout vytvorený v kóde s layoutom v nejakom vlastnom jazyku pre layouty (len tak pre zaujímavosť s Qt si stačí layout naklikať a celé ui uložiť v designéri, ale to nie je tak podstatné).

Takže keď už chcem nejako rozpitvávať spýtam sa ako urobím takú vec ako 3 buttony rovnakej šírky (ak je náhodou na nejakom dlhší text než tlačidlo tak sa samozrejme musí trochu ukrojiť z okolitých tlačidiel / automaticky zväčšiť okno). Kód pre Qt vyzerá asi takto:

QVBoxLayout *layout = new QVBoxLayout(this);
layout->addWidget(new QPushButton("But1"));
layout->addWidget(new QPushButton("But2"));
layout->addWidget(new QPushButton("Dllllllllllllllllllhy text"));

Nechcem tu teraz Qt nejako chváliť, som jedným z jeho kritikov minimálne kvôli modelom, použitiu int-ov namiesto size_t a pod. Chcem len poukázať na to, aké sú tieto porovnania nezmyselné. Objektívnym kritériom nemôže byť ani tak počet riadkov, ani nejaké na prvý pohľad hneď jasné kritérium, ale len a len dlhodobá práca s frameworkom. Ja si osobne na U++ okrem zjavných nedostatkov nedovolím nič povedať pretože s nim nepracujem dostatočne dlho na to, aby som odhalil nedostatky, ktoré ma budú pri práci zdržiavať.

[__dark__]

A už se umí to U++ zkompilovat do dynamické knihovny ?