Dotaz: Jaký má smysl C++?

[Bystroushaak]

Lehce provokativní dotaz: Můžete někdo napsat nějaké důvody které by mě měly motivovat absorbovat C++?

Mám docela rád C a respektuju ho. Je to jednoduchej, fajn jazyk. C#, Java jsou taky fajn a D je totálně super. Taky mám za sebou 2 roky C++ na střední a semestr na VŠ a pořád mi nějaké ty věci chybí (STL). Dneska jsem si řekl, že se sebevzdělám, otevřel jsem Mistrovství v C++ a začal ho číst a dospěl jsem k názoru, že to nevydržím. Už se mi podařilo absorbovat velkou část D a absolutně nechápu, proč někdo používá tak dementní jazyk jako je C++.

Nechci provokovat, fakt ne. Chci změnit můj názor na C++, ale čím víc do něj pronikám, tím víc mi připadá jako špatnej vtip. Vždyť je to tak giganticky kolosální sbírka vyjímek, podivností a omezenosti. Proč v tom někdo vůbec dělá?

Nedávno jsem zahlédl foreach v C++, prvně jsem ho nepochopil, pak nevěřícně zíral a pak se začal smát. Vážně, co někdo na C++ vidí? Potřebuju nějakou motivaci, nebo to vzdám, Mistrovství v C++ pohodím někde na nádraží a budu radši dělat něco užitečnějšího.

Odpovědi

[zulu]

Jdi s tím do blogu. Nejlépe na jiném serveru.

[Bystroushaak]

?

Mám problém který se týká programování a žádám radu/pomoc od programátorů. Tohle je poradna, sekce o programování.

Co je podle tebe špatně? Že to není zákys nad konkrétním technickým řešením?

[Josef Kufner]

Neboj, umístil jsi to tu dobře.

[bambas]

Pokud k tomu nemas co rict, tak bez do riti. Nejlepe do jine nez te jeho.

[__dark__]

Pokud nenapíšeš nic konkrétně, tak ti asi těžko někdo odpoví. Já nepoužívám D, ale zase nepíšu o něm hateblog. Knihy jsou super, ale zase bych se nesnažil použít každou věc, co tam píšou. C++ je bohatý jazyk, který není nutné používat komplet.

Pokud chceš přemýšlet o výhodách/nevýhodách C++, tak si vem nějakou knihovnu, třeba webkit, a zkus to napsat v D.

[Bystroushaak]

Ale ne, ja nechci obhajovat D a tvrdit jak je lepší. Nejspíš jsem ho ani neměl zmiňovat.

Z mého pohledu je C++ zastaralý, dost ubohý jazyk, na kterém se podepisuje roubování, jak do něj rvali nové vlastnosti. To co dnes ostatní jazyky berou jako samozřejmost, tak normální že o tom nikoho ani nenapadne přemýšlet se podle toho co jsem zatím zjistil dělá v C++ tak krkolomně že je to až neuvěřitelné. Navíc ty standardy (které jsou navíc kompilátory divně podporované, viz string ve struktuře) jednou za milénium, hrůza a děs.

Tak nějak jsem čekal že mi někdo řekne - C++ je dobré, protože támhleto, neměl bys ho zatracovat, protože tohle, má svou vnitřní krásu a vlastně dává smysl.

C++ je bohatý jazyk, který není nutné používat komplet.

Ehm, bohatý v čem? Mě to fakt nedochází, STL vypadá jen jako sada modulů která umožňuje složitě dělat to co je v ostatních jazycích přirozené (foreach, kontejnery a vůbec složitější datové struktury/algoritmy nezávislé na typu). API veskrze na úrovni C (nebo jsem na něj prostě nenarazil). Jediné bohatství kterého jsem si vědom spočívá v tom, že je jako windows - lidi ho masivně používají.

---

Možná že moje předchozí příspěvky působily jako že jsem zkušený, nebo si to aspoň myslím, ale opak je pravdou. Nejsem sice začátečník, úvody a sytaxi už mám za sebou, něco pár desítek svých miniprojektů jsem už v lecčem napsal, zkoušky udělal. Teď řeším co dál. Kde je ta další meta? Jak se stát něčím víc? Všichni se tolik věnují začátečníkům, až vytvářejí tak silnou kouřovou clonu, že přes ní není vidět co dělat poté, co přestanete být začátečníci.

[__dark__]

Ale ne, ja nechci obhajovat D a tvrdit jak je lepší. Nejspíš jsem ho ani neměl zmiňovat.

Ale zmínil. Pokud máš rád D, tak ho prostě používej a zapomeň na C++. Mám ale pocit, že to s tím D nebude tak růžové, proč jinak bys tu řešil C++?

Z mého pohledu je C++ zastaralý, dost ubohý jazyk, na kterém se podepisuje roubování, jak do něj rvali nové vlastnosti. To co dnes ostatní jazyky berou jako samozřejmost, tak normální že o tom nikoho ani nenapadne přemýšlet se podle toho co jsem zatím zjistil dělá v C++ tak krkolomně že je to až neuvěřitelné. Navíc ty standardy (které jsou navíc kompilátory divně podporované, viz string ve struktuře) jednou za milénium, hrůza a děs.

Řekni konkrétně, co ti vadí.

Tak nějak jsem čekal že mi někdo řekne - C++ je dobré, protože támhleto, neměl bys ho zatracovat, protože tohle, má svou vnitřní krásu a vlastně dává smysl.

Na to si musíš udělat pohled sám. Já neznám jiný jazyk než C++, ve kterém bych mohl psát nízkoúrovňově i vysokoúrovňově.

Ehm, bohatý v čem? Mě to fakt nedochází, STL vypadá jen jako sada modulů která umožňuje složitě dělat to co je v ostatních jazycích přirozené (foreach, kontejnery a vůbec složitější datové struktury/algoritmy nezávislé na typu). API veskrze na úrovni C (nebo jsem na něj prostě nenarazil). Jediné bohatství kterého jsem si vědom spočívá v tom, že je jako windows - lidi ho masivně používají.

Já třeba STL nepoužívám, protože se mi nelíbí jeho návrh. To samé platí o jiných věcech. Kontejnery si můžeš naprogramovat vlastní, memory alokátory napsat vlastní, sakra jaký jazyk ti dává takovou svobodu? V C++ můžeš psát cokoliv.

Možná že moje předchozí příspěvky působily jako že jsem zkušený, nebo si to aspoň myslím, ale opak je pravdou. Nejsem sice začátečník, úvody a sytaxi už mám za sebou, něco pár desítek svých miniprojektů jsem už v lecčem napsal, zkoušky udělal. Teď řeším co dál. Kde je ta další meta? Jak se stát něčím víc? Všichni se tolik věnují začátečníkům, až vytvářejí tak silnou kouřovou clonu, že přes ní není vidět co dělat poté, co přestanete být začátečníci.

Začni něco programovat. Já fakt nevím, jak vnímáš programování. Pro mě je programování zábava a business, pro některé jen business, a pro další jen zábava (a od toho se odvíjí použité jazyky). Pokud nechceš používat C++, tak ho nepoužívej a zkus si vydělat v jiném jazyce, třeba tom D. Pak uvidíš, jestli tvoje představy nebyly jen zbytečně zaujaté. Kdybys programoval 10 let v D a 10 let v C++, rád bych si přečetl tvoje názory, ale takto je to prostě jen takový výkřik do tmy.

[Bystroushaak]

Ale zmínil. Pokud máš rád D, tak ho prostě používej a zapomeň na C++. Mám ale pocit, že to s tím D nebude tak růžové, proč jinak bys tu řešil C++?

Prostě proto že je to lingua franca a do nedávna jsem měl za to, že by mělo patřit ke vzdělání každého programátora.

Kdybys programoval 10 let v D a 10 let v C++, rád bych si přečetl tvoje názory, ale takto je to prostě jen takový výkřik do tmy.

Protože to zase bereš jako obhajobu D a machrování s tím že je lepší. Já to fakt neměl v úmyslu, zmínil jsem D jen proto, že je to podobný jazyk a poslední dobou jsem se ho učil.

Cílem celého tohohle threadu nemělo být přesvědčovat všechny ostatní o tom že D/whatever je lepší, ale přesvědčit mě, že C++ za to stojí.

Začni něco programovat. Já fakt nevím, jak vnímáš programování.

Programuju něco skoro pořád. Hlavně v pythonu. Zábava, prostředek sebevyjádření, způsob realizace vlastních cílů, v nepříliš vzdálené době možná způsob obživy.

[rADOn]

API veskrze na úrovni C (nebo jsem na něj prostě nenarazil).

Však o to právě jde. STL je víceméně rovnocená ANSI C co se týče efektivity, ale přidává podstatně inteligentnější překladač. Třeba iterátory se mi velmi zalíbily když jsem si uvědomil, že vlastně pracuji s ukazateli, ale bez spousty drbání okolo a s podstatně lepší (byť ne dokonalou) typovou kontrolou. Jazyku které mají hezčí kontejnery je možná spousta, ale výkonově není srovnatelný žádný z nich.

[JS]

Ja C++ sice taky nemusim, ale je treba videt veci v historicke perspektive. A tech je nekolik:

1. Jazyk C++ se snazilo a snazi resit nektere nedostatky C; jestli to dela dobre nebo ne je jina otazka. Spousta C-ckaru si mysli (treba Linus), ze C++ je nadbytecne - takove veci jako tridy nebo vyjimky ze nejsou v podstate potreba. Ale to asi nebude tvuj pripad - jak sam pises, libi se ti D (a Java/C#), takze zrejme tento smer vyvoje uznavas.

2. Samozrejme, bylo by idealni*, kdyby nekdo prisel s D misto C++. Problem ovsem je, ze D se mohlo poucit z chyb C++, naopak to neslo. Historicky - a jelikoz delam na mainframu, takze je mi tento koncept velmi znamy, to mi ver - jde temer vzdy vyvoj od slozitych bastlu s mnoha vyjimkami k jednodussim. I kdyz se to zda nelogicke.

3. Samozrejme, bylo by idealni, kdyby nekdo prisel s D misto C++. Dalsi vec je, ze dulezitym kriteriem pro adopci jazyka je zpetna kompatibilita. Cim vic je jazyk odlisny od neceho znameho, tim to ma tezsi. Dneska by treba lide znali v 90. letech C++ meli problem prijmout Javu - tehdy to problem nebyl, protoze byla o poznani jednodussi. Stejne tak, originalni C++ bylo pomerne jednoduchou nadstavbou C, ne temer odlisnym jazykem jako dnes. To je realita evoluce.

4. C++ ma stale svoje (i kdyz zmensujici se) misto ve velkych, rychlych aplikacich (treba desktop - viz KDE, nebo hry), a je take spousta spousta legacy kodu, protoze bylo dlouho cislo 1. A pokud hledas komercni duvod, proc se ucit C++, tohle je on. Samozrejme, idealni by bylo, kdybychom mohli vsechny programatory a aplikace v C++ pres noc zkonvertovat do D, ale to bohuzel nejde.

* Skutecne idealni by bylo, kdyby tehdy lide misto C++ presli na Common Lisp. Doporucuji i tobe se na nej podivat, minimalne pro rozsireni obzoru, jak nektere veci resit (genericke funkce, signaly,..). Ne vzdy vyhrava nejlepsi reseni, to je holt realita.

[Heron]

jde temer vzdy vyvoj od slozitych bastlu s mnoha vyjimkami k jednodussim

+1

Dokonalé není to, kam už není co přidat, ale to, odkud už nejde nic odebrat.

Dneska by treba lide znali v 90. letech C++ meli problem prijmout Javu - tehdy to problem nebyl, protoze byla o poznani jednodussi.

Tohle mě osobně třeba na Javě vadí. Místo odebírání a zjedodušování se tam přidávají věci, které šly (a IMHO nijak krkolomě) dělat i ve "staré" javě. Neříkám, že jsou k ničemu, to jistě ne, ale ten jazyk se bez nic obešel.

[Josef Kufner]

Jo, C++ je taková historická ukázka toho, jak se to dělat nemá.

Jinak doporučuju se podívat do knihovny Qt. Její vývojáři hodili většinu konstrukcí C++ do koše a používají jen jeho celkem malou podmnožinu – základní věci okolo tříd, všude jen prosté pointery na objekty, minimum šablon (občas nějaký ten QList, jinak nic). A přidání signálů a slotů byl skvělý nápad.

Výsledkem je velice příjemné prostředí, kde kód je jednoduchý, přehledný a přitom rychlý.

[Michal Kubeček]

Jinak doporučuju se podívat do knihovny Qt.

A pak se pro změnu podívejte třeba na nějaký tutorial Gtk. Tam si na každém druhém řádku říkáte, o co by to bylo jednodušší a přehlednější, kdyby to bylo napsané v C++.

Její vývojáři hodili většinu konstrukcí C++ do koše a používají jen jeho celkem malou podmnožinu

To, že se na konkrétní projekt hodí použít jen část toho, co jazyk umí, přeci neznamená, že je ten jazyk špatně navržený. Pro jiný projekt se zase může mnohem lépe hodit použít celou mašinerii templates a container classes ze standardní C++ knihovny.

Naopak, jednou z klasických začátečnických chyb je představa, že za každou cenu musím využít všechno, co mi jazyk nabízí. Když jsem s C++ začínal, také jsem si představoval, že musím overloadovat operátory a používat templates jen pro ten pocit, aniž by to reálně přinášelo cokoli jiného než jen znepřehlednění zdrojáků. Problém je, když někdo takhle jen nahlédne do dveří, zůstane u představy, že C++ programy takhle vypadat musejí, na základě toho jazyk odsoudí a plive na něj po fórech.

Ano, je spousta programů napsaných v C++, ze kterých se chce člověku zvracet. Jenže přesně totéž se dá říct o céčku nebo Javě - a vlastně kterémkoli jazyce. A ani v jednom případě to automaticky neznamená, že ty jazyky jsou špatné.

[Bilbo]

Ano, je spousta programů napsaných v C++, ze kterých se chce člověku zvracet. Jenže přesně totéž se dá říct o céčku nebo Javě - a vlastně kterémkoli jazyce. A ani v jednom případě to automaticky neznamená, že ty jazyky jsou špatné.

Jo, ale jsou jazyky, kde napsat nepřehlednou změť, co třeba i nějak funguje jde snadno (např. Perl, kde sice mám za 5 minut utilitku co bych ji v C++ psal 2 hodinym, ale když se na to podívám za týden, tak už se ve vlastním kódu nevyznám), a pak jsou jazyky, kde už jazyk sám o sobě čistotu kódu trochu hlídá (např. Java). C++ bez templatů a přetěžování operátorů může vyústit v poměrně přehledný kód (není tam tolik věcí co by svádělo k výrobě bordelu), ale když se to s operátory a templaty přežene, tak vznikne změť ve které se není snadné vyznat.

[:::]

javu bych moc za priklad nedaval, to je prasarna jenom pro lidi s chorym mozkem...

Ja jsem v tom kdysi z donuceni neco psal a prekladac porad drzkoval neco o neobslouzenych vyjimkach. V ty chvili jsem tu vyjimku resit nechtel, ale kdyby zobrazil warning tak bych to nakonec opravil. Prekladac se ale rozhodl ze je chytrejsi nez ja a ze dokud vsechny vyjimky neobslouzim tak nic kompilovat nebude.

Nakonec jsem to vyresil tak ze jsem kolem celyho tela tech funkci dal:

try
{
...
}
catch(Exception e) {}

a bylo to vyreseny. Vim, prasarna, ale ten prekladac me proste nedal jinou moznost... btw. nakonec to v tom programu zustalo...

[Bystroushaak]

Od toho je tam možnost překladači sdělit, že metoda vyjímku neobsluhuje a vyhazuje jí dál. Viz throws.

[:::]

to vim, jenze tu vyjimku potom musis osetrit ve volajici metode, atd. nebo tam pridat vsude throws az po main()

Jinak ja bych tu vyjimku v ty funkci nakonec obslouzil, ale v ty chvili jse se chtel soustredit na neco jinyho a timhle se nezabyvat...

[rastos]

Používaš nejaké IDE? Eclipse ti napr. vygeneruje try-catch blok a do catch dá // TODO: a zoznam TODO je vidno v nejakom view-e, takže na ne nezabudneš. To že budeš na ošetrovanie chybových stavov kašlať iba chvíľu, nefunguje. Funguje to možno kým máš do 200 riadkov kódu, potom ale nie. A každý program, ktorý má 100 riadkov kódu má potenciál na nárast nad 200 riadkov

[moira]

Jinak ja bych tu vyjimku v ty funkci nakonec obslouzil...

jo to známe, já bych... nakonec jsi to stejně neudělal. ;)
Jinak co jsi tam napsal je vrchol prasení (překladač za to opravdu nemůže). A to ne proto, žes to celý zavřel do jednoho bloku try/catch, ale protože v obsluze výjimky ani neuděláš printStackTrace. Asi jsi ještě nikdy nehledal chybu v kódu, který "přece funguje bez problémů". Je ale zajímavé, že lidi co prskaj na Javu pak v ní bez mkrnutí oka napíšou podobný pííp.

[:::]

1. prekladac za to opravdu muze, protoze tim ze te nuti delat veci ktery delat nechces tak te dotlaci k takovymuhle obchazeni...

2. to ze je to prasarna je me jsany a pisu to uz v prvnim prispevku

[alkoholik]

Je to uplne jinak.
Chces psat jako prase a prekladac se brani.
Ve finale je obrovsky rozdil mezi javovym a c++kovym kodem od lidi jako jsi ty. C++ k odpornemu totiz navadi.

[podlesh]

No, pozor, s těmi obecnými závěry bych byl opatrnější.

V Javě se samozřejmě píše jako prase normálně. Rozdíl je v tom, že prasácký bastl v Javě jakž-takž chodí a zkušený člověk ho dokáže provozovat na produkčním systému. Bastl v C++ se dá akorát tak poslat do /dev/null

To je tajemství úspěchu Javy (a PHP, to je podobná situace).

[alkoholik]

A to je skutecna odpoved na celou tuhle diskuzi.
;)

[Matlák]

+0xFFFFFFFFFFFFFFFF

[podlesh]

To je long nebo long long?

[:::]

neosetrit vyjimku znamena psat jako prase?

[alkoholik]

Ne, ale predstirat, ze tam zadna obsluha byt nemusi/nema, je prasarna.
Vite co. Otevrete si knizku o C++, prectete si o main() a zakladnich knihovnich funkcich (Hello world!). Pak si pustte MS VS, zalozte projekt a zkuste najit neco, co se v knizce popsanemu prikladu alespon trochu podoba.

[JS]

Ne, ale predstirat, ze tam zadna obsluha byt nemusi/nema, je prasarna.

Nemusi byt. V programu, ktery mam jen jako prototyp, to prasarna neni.

Samozrejme, podle teorie autoru a zastancu Javy je programovani tovarni vyroba, nikoli inzenyrstvi, a proto prototyp nikdy nepotrebujeme, protoze neexistuji zadna prekvapeni, vsechno je hned zname a jasne, a muzeme zacit vytvaret hned hotovy produkt v cele sve krase.

(Timto odpovidam i podleshovi.)

[podlesh]

(Timto odpovidam i podleshovi.)

To není pravda, já jsem psal o něčem jiném. Problém toho že programování není (přes veškerou snahu) inženýrství (tedy "tovární výroba") platí všude a jeho souvislost se staticky typovanými jazyky rozhodně nemůžu považovat za prokázanou.

[podlesh]

Teď mi došlo, že jsem úplně zapomněl na Haskell! To je jazyk který tento problém celkem pěkně vyřešil. Pravda, musel na to jít zcela z jiné strany. Experiment v Javě se rozhodně nedá považovat za úspěšný (každý zastánce checked exceptions musí uznat že jejich použití je vhodné maximálně někdy).

Pravda, nevím zda je Haskell vhodný na "inženýrství" podle vašich vkusů.

[JS]

Predne, inzenyrstvi a tovarni vyroba neni totez. Inzenyrstvi je navrh, a to znamena, ze neni jeste vsechno jasne, jak to bude v realnem svete fungovat. Muze se napriklad ukazat, ze ta nova lepsi architektura je proti te stare necitelne prilis pomala. Nebo se muze ukazat, ze ta krasna knihovna, co chceme pouzit, neni uplne to prave. Dabel je temer vzdycky v detailech. Proto ma smysl vyrobit prototyp, ktery neresi chyby, ale ukazuje problemy tohoto typu. Ze se to v SW prumyslu az tak casto nedela je jiny problem.

Naopak tovarni vyroba je - kdyz to vyrobite podle specifikace, bude to zarucene fungovat. Tak se pristupuje k vyrobe SW, a je to IMHO dost zoufale.

Haskell mi moc sympaticky neni (na muj vkus je prilis jednostranny, davam prednost multiparadigmatickym jazykum jako Python nebo Common Lisp), ale hodlam se do nej nekdy, az budu mit naladu, pustit. Myslim, ze celkova vize Haskellu dava dobry smysl a jsou tam dobre napady, ale na nektere je jeste prilis brzy a nektere jsou neprakticke. Brookse bych si taky rad precetl, a myslim, ze bych s nim celkem souhlasil.

Co se tyce jeste toho inzenyrstvi, tu filozofii "napsat program nahrubo a pak ho upravovat" mam od Paula Grahama, podle ktereho ji dobre vyjadruje Common Lisp a ja s nim souhlasim.

[JS]

Jo a jeste - nemyslim, ze ten problem Javy, o kterem mluvim, souvisi s absenci metaprogramovani. Metaprogramovani povazuji za dobrou vec, ale existuji lide, kteri ho odmitaji, a maji proto sve dobre filozoficke duvody. Krasne je to videt na jazyce Go, ktere ackoli metaprogramovani nema, nesdili tu podivnou filozofii Javy, jak jsem ji nastinil.

[podlesh]

Samozřejmě je otázka o jakém problému vůbec mluvíme

Podivná filozofie Javy není nic zas tak podivného, je to jen rozšíření konceptu statického typování. Ten problém z toho plyne, je to prostě příklad nevýhody statické kontroly typů (resp. jeho analogie). Můžeme tedy

• kritizovat celý koncept (což je v pořádku, viz LISP, ale je to na samostatný flamewar)
• požadovat kompromis (žádná statická kontrola výjimek - např. C#)
• zamyslet se nad plnou, prakticky použitelnou implementací (což si v Javě nelze moc dobře představit a zřejmě to vyžaduje úplně jiné pojetí)

[podlesh]

Predne, inzenyrstvi a tovarni vyroba neni totez. Inzenyrstvi je navrh, a to znamena, ze neni jeste vsechno jasne, jak to bude v realnem svete fungovat. Muze se napriklad ukazat, ze ta nova lepsi architektura je proti te stare necitelne prilis pomala. Nebo se muze ukazat, ze ta krasna knihovna, co chceme pouzit, neni uplne to prave. Dabel je temer vzdycky v detailech. Proto ma smysl vyrobit prototyp, ktery neresi chyby, ale ukazuje problemy tohoto typu. Ze se to v SW prumyslu az tak casto nedela je jiny problem.

Naopak tovarni vyroba je - kdyz to vyrobite podle specifikace, bude to zarucene fungovat. Tak se pristupuje k vyrobe SW, a je to IMHO dost zoufale.

To že se nejprve dělá prototyp či model je sice hezké, ale hlavní vlastností inženýrství je právě to že výsledkem je jasná specifikace podle které to bude zaručeně fungovat. Takže ano, není to totéž, ale je tam silná souvislost: inženýrství implikuje tovární výrobu. Nebo lepé řečeno to je naopak: tovární výroba vyžaduje inženýrství. No a jelikož SW inženýrství má docela zásadní problémy, tak tovární výroba nefunguje. Bohužel je stále rozšířen názor, že výroba SW je inženýrství a tedy že tovární výroba fungovat bude...

Samozřejmě, to je zase terminologická diskuse, nechci se moc hádat o tom co vlastně znamená slovo inženýrství - důležité ale je, že ten problém IMO není ve vytváření prototypů (to se dělá a ne vždy to pomůže, ďábel totiž právě bývá v detailech jako jsou chybové stavy) ale právě ve vytváření specifikací.

Co se tyce jeste toho inzenyrstvi, tu filozofii "napsat program nahrubo a pak ho upravovat" mam od Paula Grahama, podle ktereho ji dobre vyjadruje Common Lisp a ja s nim souhlasim.

Souhlasím, ale IMHO spíš odpovídá řemeslné výrobě. Jeden z důvodu proč osobně razím heslo, že výroba SW je řemeslo.

[JS]

Kdyz mas specifikaci, o ktere vis, ze funguje, pak uz mas v podstate funkcni program. Proto je vyroba programu inzenyrstvi a ne tovarna.

Proste, programy nejsou fyzicke veci. U fyzickych veci, pokud vime, jak ji vyrobit, a ze vyrobena bude fungovat, jak chceme, pak je jeste nutne ji vyrobit. U programu ten posledni krok odpada, protoze jakmile mas kompletni plan (blueprint), mas i hotovy program.

Remeslo spojuje oboji - jak navrh (inzenyrstvi, i kdyz v mensim mnozstvi), tak vyrobu.

[podlesh]

Ano, programy nejsou fyzické věci a nelze vyrobit blueprint/specifikaci která přesně popisuje jak to bude fungovat. Respektive to nikdo nedokáže, ale mnoho lidí se o to pokouší.

Uznávám, postavením vzhůru nohama (nevyrábí se vůbec nic, jenom se navrhuje) získáme zajímavou perspektivu. Ale ne zas tak zásadně aby z toho byly nějaké praktické důsledky.

Remeslo spojuje oboji - jak navrh (inzenyrstvi, i kdyz v mensim mnozstvi), tak vyrobu.

Tak nevím - je to souhlas nebo nesouhlas? Pokud nesouhlas, v čem přesně?

[podlesh]

Btw, když na to přišla řeč, doporučuji si přečíst věci od Fredericka Brookse, a to jak z roku 1975, tak z roku 1987 a 1995. Právě to plynutí času tomu dává pěknou perspektivu - i když s tím asi filosoficky moc souhlasit nebudete...

[mirec]

Nikto tu nepredstiera, že obsluha výnimky je zbytočná. Nechápem ale prečo by kompilátor mal nútiť k napísaniu obsluhy. Radšej program skompilovať s varovaním než dokopať programátora aby to narýchlo obalil do jednej veľkej výnimky a nakoniec na to zabudol.

[Bilbo]

Obecně si překladač vynucuje aby člověk ošetřoval vyjímky. Většinou je to dobré (člověk nepíše jako prase), ale jsou i situace, kdy tahle vlastnost Javy poněkud vadí (např. když základní třída nehází vyjímky, ale potomek jo "... overridden method does not throw ... ") - přidat ošetření přímo do potomka nemusí být vždy vhodné (někdy je lepší aby exception vybublala o něco výše a až tam byla ošetřena) a změnit bázovou třídu může znamenat překopání spousty dalšího kódu (aby házel/ošetřoval vyjímky co nikdy nehodí, resp. nemohou nastat).

[JS]

Souhlasim s extremni lamou. Tahle filozofie Javy je uchylna, hned ze 2 dvou duvodu:

1. Kdyz uz neco nekde byt musi, proc to tam musim psat? Proc to proste nedela prekladac implicitne? Od ceho jsou varovani?

2. Druhy duvod je, ze se tenhle druh zbytecneho nasili (vsechny vyjimky musi byt osetrene, vsechny funkce musi byt ve tride, atd.) resi generovanim kodu. Coz spojuje nevyhody obojiho - nemate varovani, ze jste to opominul, a neosetrena vyjimka trci v kodu, o duplikaci kodu nemluve.

Cela ta filozofie vychazi z mylne predstavy, ze programovani je tovarni vyroba a ne inzenyrstvi. Jazyky skutecne navrzene proto druhe totiz umoznuji nejdriv napsat program "nahrubo", a pak teprve ho vylepsovat.

[moira]

1. Kdyz uz neco nekde byt musi, proc to tam musim psat? Proc to proste nedela prekladac implicitne? Od ceho jsou varovani?

Co má překladač dělat implicitně? Napsat za tebe obsluhu výjimky? Bohužel ten požadavek tam je a překladač s tím nic nemůže udělat. Na druhou stranu bych se bez povinného ošetření / deklarace vyhození výjimky taky obešel, někdy to opravdu otravuje.

2. Druhy duvod je, ze se tenhle druh zbytecneho nasili (vsechny vyjimky musi byt osetrene, vsechny funkce musi byt ve tride, atd.) resi generovanim kodu. Coz spojuje nevyhody obojiho - nemate varovani, ze jste to opominul, a neosetrena vyjimka trci v kodu, o duplikaci kodu nemluve.

Všechny výjimky nemusí být ošetřené, nevím jak jsi na to přišel. Požadavek, že metoda je součástí třídy je také asi podle tebe u objektového jazyka nečekaný (a to Java zdaleka není čistě objektová). A když fakt nechceš tu obsluhu psát, tak tam přidáš throws a necháš to probublat nahoru. V rozumném IDE otázka jednoho kliknutí myši. Tomu poslednímu nerozumím, to varování nemám jen případě, že jsem prase a "obsluhu" vyřeším prázdným blokem. To ale opravdu není problém jazyka ani překladače, jak se extremni lama pokouší dokázat.

Na druhou stranu přiznávám, že kdybych měl všechno (zdaleka nemyslím jen výjimky), co se v Javě musí psát ťukat ručně, tak mi to taky bude vadit. Ale naštěstí IDE tento problém poměrně efektivně řeší.

[podlesh]

1) Co tam má být implicitně? Z hlavy mě napadají hned 4 základní strategie jak výjimku ošetřit. Záleží na tom co ta výjimka znamená a to si překladač skutečně implicitně neudělá.

No a varování jsou od toho, aby je extrémní lamy ignorovaly.

2) Cože? Řeší se to ruční prací. To je samozřejmě pomalé, náchylné k chybám a občas se na to lidi vy.... pokud nemají disciplínu. A nebo se rovnou všude používat unchecked výjimky, jako to dělají jiné jazyky.

Když se nad tím zamyslíte, tak je vidět že problém je jinde - v Javě chybí možnosti metaprogramování. Není možné si definovat makro (nebo nějakou jinou konstrukci, je otázkou jak by vypadala) které tu výjimku ošetří správným způsobem (ať už třeba zkonvertovat na jinou výjimku, nebo třeba nejdřív Xkrát blok opakovat a pokud se to ani jednou nepovede tak vyhodit jinou výjimku, unchecked).

Absence metaprogramování vadí samozřejmě i jinde, ale právě u výjimek vadí nejvíc - neexistuje jiná možnost než to pořád řešit ručně, nebo se na to vykašlat jako konkurenční jazyky a používat unchecked exceptions (AFAIK jediný jazyk ve kterém se výjimky dají nějak solidně řešit je Common Lisp).

Cela ta filozofie vychazi z mylne predstavy, ze programovani je tovarni vyroba a ne inzenyrstvi. Jazyky skutecne navrzene proto druhe totiz umoznuji nejdriv napsat program "nahrubo", a pak teprve ho vylepsovat.

Inženýrství? To je přeci totéž co tovární výroba. Asi myslíte umění nebo věda...

Každopádně, v naprosté většině případů platí že se program napíše "nahrubo" a pak se na něj nesahne dokud není potřeba něco opravit.

[Sten]

A proč bych měl dělat něco jako odchytávání výjimek a printStackTrace explicitně, když to jde implicitně (jako to má třeba Python nebo některé druhy libstdc++)?

[podlesh]

Implicitně to má pro neošetřené výjimky na vrcholu zásobníku i Java (a C# a další, AFAIK). Problém je jak označit, že tu výjimku chci ignorovat tady a pokračovat.

[Bystroushaak]

Díky za hodnotnou odpověď. Na lisp teď koukám s tím, jak vychází jako seriál v Robot revue.

[JS]

No, koukam co je v tom serialu na webu, ale nerad bych, aby doslo k nejake mylce - Common Lisp neni jen takova hracka jak to prezentuje ten serial, na svoji dobu ma peknou standardni knihovnu (napr. ne vsechno musi byt seznam - ja s oblibou pouzivam hash tabulky), a spousta veci je tam resena velmi zajimave.

[Bystroushaak]

Zatím tam vyšel jen úvod do samotného lispu, nevím jak moc s tím autoři budou pokračovat.

[Kit]

Také jsem si na Robot revue chtěl něco o Lispu přečíst, ale kromě upoutávek na články jsem na jejich webu nic nenašel. Přitom na jiných webech je toho spousta, včetně tutoriálů.

[Ales Hakl]

Ve chvili, kdy se v nazvu clanku o (Common) Lispu vyskytuje souslovi "umela inteligence", tak nelze rozumne predpokladat, ze takovy clanek bude davat smysl.

[Bystroushaak]

Mám za to, že využití pro umělou inteligenci je jedno z nejčastějších použití lispu, proč by tedy takový článek neměl dávat smysl? Obzvlášť v časopise o robotice, kde se umělé inteligenci věnují poměrně pravidelně?

[Ales Hakl]

A to je prave ten problem. Z takovych clanku pak vychazi tenhle vas dojem :)

Dnes to jedno z nejcastejsich pouziti rozhodne neni a pred temi 30-40 lety kdy bylo se pod pojmem "umela inteligence" myslelo neco uplne jineho nez dnes.

[rADOn]

Právě jsi popřel sám sebe

[ubuntak]

Nevim jestli bohuzel nebo bohudik, ale musim s tebou souhlasit. Kdysi sem zacal programovat Pascal Cecko. A clovek se najednou doslechl o OOP a C++. Tak sem se koukl na C++, ale v te dobe uz jsem koketoval s Javou. No co bys rekl C++ sem zavrhl, protoze ma presne ty nedostatky, ktere si popsal a Java vyhrala. Dnes preferuju Javu a Csharp. Na C jsem nezanevrela a obcas jej pouziju pri reseni uloh, ktere vyzaduji jemne casovani. Ale C++ to je prasarna. Musime si vsak uvedomit ze v C++ se tvori 90procent her, je rychli a preklad neprobyha do byte codu(java, .net, ...), ktery je pak predan runtimu.

[skunkOS]

Tohle je jen taková snužka jakýchsi dojmů pocitů v pár větách. Pokud se ti c++ nelíbí, tak ho prostě nedělej a dělej si to svoje Déčko. Jenže asi ti unikají některé věci.

C++ je multiplatformní. (určitě více než D). C++ je tu dlouho a jeho penetrace do IT sféry je obrovská, a proto je hodně požadováno na IT pozicích.

[Bystroushaak]

Tohle je jen taková snužka jakýchsi dojmů pocitů v pár větách.

Ehm. Tím tohle myslíš tvůj, nebo můj příspěvek?

C++ je multiplatformní. (určitě více než D).

Vzhledem k tomu, že D je součástí gnu compileru (gdc) a existují i překladače překládající do čistého C, nějak se mi moc nezdá že C++ je víc multiplatformější.

[vlastagf]

Tvůj.

Tobě C++ přijde dementní, aniž by jsi uvedl důvody.

Jestli je C++ nějaké, tak rozhodně není omezené.

Jaký foreach máš na mysli? C# vs C++, ohromná legrace.

foreach (type item in set) { /* do something to item */ }

for (int& i: myint) { std::cout << i; }

V C++ dělám a upřímně, všechno se mi na něm taky nelíbí, ale pořád mi přijde jako nejmenší zlo oproti C#, Javě a dynamickým jazykům. A nechci po nikom, aby mě přesvědčoval o opaku. Navíc mám pocit, že o ti ani nejde, vzhledem k tónu, se chceš jen hádat.

[Bystroushaak]

Tobě C++ přijde dementní, aniž by jsi uvedl důvody.

Já o tom nechci nikoho přesvědčovat, proto jsem neuváděl proč.

Jaký foreach máš na mysli?

for_each

Navíc mám pocit, že o ti ani nejde, vzhledem k tónu, se chceš jen hádat.

Já už nevím jak to mám napsat jinak. Smrtelně vážnej dopis, vytisklej na papíru co se používá k na těch pozvánkách k pohřbu? Lidi už jsou tak zvyklí na flame, že pomalu není možné se vážně dotázat na něco netradičního, protože v tom každý hledá něco víc.

[Josef Kufner]

Wow. Myslím, že jsi právě velmi názorně ukázal, proč je C++ špatný jazyk.

Ale aby to nebylo zastak jednostranné, tady máš hezčí foreach.

A jen tak pro srovnání, ať jsou hezky vedle sebe:

template<class T> struct print : public unary_function<T, void> {
  print(ostream& out) : os(out), count(0) {}
  void operator() (T x) { os << x << ' '; ++count; }
  ostream& os;
  int count;
};
int main() {
  int A[] = {1, 4, 2, 8, 5, 7};
  const int N = sizeof(A) / sizeof(int);
  print<int> P = for_each(A, A + N, print<int>(cout));
  cout << endl << P.count << " objects printed." << endl;
}

---

 QList<int> list;
 list << 1 << 4 << 2 << 8 << 5 << 7;
 foreach (const QString &str, list) {
     qDebug() << str;
 }
 qDebug() << list.count() << "objects printed.";

[mirec]

list<int> A = {1, 4, 2, 8, 5, 7};
for_each(A.begin(), A.end(), [](int x)->void { cout << x << endl; } );
cout << A.size() << " objects printed." << endl;

aby to nebolo tak jednostranné.

[Bystroushaak]

Koukám že ta Qt knihovna dělá z C++ nový jazyk.

[Josef Kufner]

Slyšel jsem něco o tom, že autorům se prý děsně líbilo ObjectiveC …

[Sten]

Qt taky není úplně C++, je to takový C with Classes s prasáckým preprocesorem

[vlastagf]

Ty se na nic neptáš, ničím neargumentuješ, nic nechceš, jen říkáš: "Ne, ne, ne.".

[Sten]

for_each, který je pro funktory, na místě, kde by měl být foreach (resp. ve „starém“ C++ for nad iterátory), který je pro blok kódu, je jenom neznalost programátora, ne chyba jazyka. Přesněji je to proto, že všichni po C++ začali jako foreach nazývat něco, co do té doby bylo for a (ten původní) for_each byl něco úplně jiného.

[Bystroushaak]

Tak nevim jestli je to tím friscem co jsem před chvílí vypil, ale nechápu.. Jestli tohle není bordel, tak už nevim co je :P

[Sten]

Bordel je jenom v tom, že C++ jako for_each nazývá něco trochu jiného, než co později ostatní jazyky nazvaly foreach (a co se předtím nazývalo jenom for).

[Šangala]

Je to jen takové povídání, navíc už do dotazu vstupuje s předem připraveným závěrem .
Jsou lidi co to nechápou, ale vidím Javu a uteču k C++, vidím C# a dodělám si některé knihovny raději v C++, uvidím Delphi „už zas, to bude nuda a řešení blbostí, zlaté C++“, vidím PHP „super to si zas můžu dělat absolutně co chci, doufám, že nemusím s nikým spolupracovat “
Proč, nevím. U Javy, to může být způsobeno v mém nitru zahnízděné informaci, že zas degraduji hardware na čtvrtinu a taky se v ní nepohybuji jistě, C# nemám šajn co mě k tomu vede, u Delphi je to asi spousta nedostatků, hlavně z minulosti.
A co tak jazyk C+? (Jakože dělám C++ ale mixuji to s C )

[Bystroushaak]

A není to prostě proto, že jsi se C++ naučil první a umíš ho nejlíp? Osobně taky o dost radši dělám v pythonu..

[Šangala]

Není, měl jsem to spíše (ty hlavní):
C, Turbo Pascal + Delphi (od počátků věků), C++, PHP, C#, Java?.
Asi mi tam spíš vyhovuje ta možnost pracovat na nízké úrovni efektivně, ale současně možnost použití šablon, kontejnerů atd. a v neposlední řadě, pro někoho zavrženíhodná vícenásobná dědičnost.
Hm, Python, super jazyk, ale ne pro mě, rád si formátuji kód jak já potřebuji, ne jak jazyk .

[Josef Kufner]

Tak interfacy jsou v mnohém lepší než vícenásobná dědičnost. Hlavně v tom, jak to pak vypadá v generované dokumentaci.

[Šangala]

Neříkám tak ani tak, mně totiž sedí k různým účelům obojí.
C++ nebráni dělat interface, abstraktní class nebo interface, není v tom praktický rozdíl - je to jen slovíčkaření. I když někdy „si“ rozlišuji abstraktní class a interface, buď prefixem, či v dokumentaci nebo obojí , ale jedná se jen o členění pro snazší orientaci.
Ale C# a Java neumožňují vícenásobnou dědičnost a sem tam se k vůli to píše 2× tolik zbytečně.
Je to o přístupu, ale někdy se pak také bojuje (v Java, C#) s tím, že se chce aby to byl „špinavý“ interface, který obsahuje nějakou prkotinu kódu, protože se bude prostě dělat v 99.99 % stejně.

[Josef Kufner]

ale jedná se jen o členění pro snazší orientaci.

To je ale hned po samotné funkčnosti ten nejdůležitější důvod.

[Šangala]

Slovíčkem „jen“ jsem chtěl vyjádřit, jazyk C++ nemá interface, jak jej známe z C# či Javy.
A celým textem, že sice C++ nemá interface a návrh založený na interface je třeba hlídat mimo jazyk, je-li to třeba, ale nic nebrání tomu je tvořit a navíc umožňuje vícenásobnou dědičnost.

[JS]

Otazka ovsem je, zda by neco takoveho melo byt soucasti syntaxe a semantiky programovaciho jazyka. Me prijde jako lepsi vyjadrit ten umysl programatora nejakymi metadaty, a mit program, ktery to na zaklade tech metadat zkontroluje.

[Josef Kufner]

A zdrojový kód je celkem dobré místo na uložení takových metadat.

[Sten]

BitC?

[Michal Kubeček]

Rozhodně větší než tenhle "dotaz" v poradně… :-)

Pro řadu lidí je C++ dobrým kompromisem mezi pohodlným, ale neefektivním programováním v Javě nebo C# na jedné straně a vysoce efektivním, ale často nepohodlným programováním v C na straně druhé. Pokud vás C++ neoslovilo, je to váš názor, ale nepočítejte s tím, že jeho kategorické odsouzení někým, kdo jazyk v podstatě nezná, přesvědčí vývojáře existujících projektů, že mají C++ zavrhnout a přepsat vše do C nebo Javy.

Jazyky jako D nemá smysl řešit, jejich zastoupení je natolik mizivé, že jakmile je použijete, odsoudíte projekt do kategorie "one man show".

[Sapo]

Naopak, ja si myslim, ze taketo otazky maju zmysel. Aj vasa odpoved ma zmysel su v nej dobre argumenty a nazor si kazdy urobi sam, podla vlastnych potrieb.

Asi kazdy z nas by chcel pouzivat elagantny, krasny, efektivny, univerzalny, vykonny a lahko pouzitelny prog. jazyk a asi aj preto preto vznika tolko novych prog. jazykov.

S aktualnou realitou "na trhu prog. jazykov" sa kazdy vysporiada podla svojho, ale klast si otazky co dalej je dolezite. Najma pre tych, ktory programovaci jazyk nepovazuju len za svoju "lopatu" vo "fabrike".

[rastos]

Naopak, ja si myslim, ze taketo otazky maju zmysel.

Zmysel tá otázka má. Ale nepatrí do poradne. Odpoveďou (nech už je akákoľvek) totiž nie je rada ale názor. Neviem si predstaviť, že niekto bude prehľadávať poradňu, pretože potrebujem riešenie problému o ktorom sa tu diskutuje. Skutočne to patrí do blogu.

A keď už som tu: zmysel C++ vidím v tom, že je objektové a pritom jeho výstupom je jednoducho ".exe". Nie bytekód vykonávaný javou, ani nie skript vykonávaný pythonom, ... Na systém neinštaluješ celý podsystém (JRE/Python/Perl/... ), ktorému stačí podhodiť (v podstate dátový) súbor a ten podsystém dokáže na systéme prakticky čokoľvek. (nehovorím o extrémoch ako je java kompilovaná do exe, alebo MS office, s VB interpreterom)

C++ nie je samozrejme všeliek, ale sú situácie, kedy je vhodné.

[Bystroushaak]

Díky za názor. Stojím si za tím, že blog by měl sdělovat nějakou myšlenku, když už se tam člověk na něco ptá, tak by měl i něco dát. Pokud budu do blogu cpát jen dotazy, jaký smysl má pak poradna?

[Michal Kubeček]

Myšlenka "nenávidím C++" byla sdělena dostatečně zřetelně… :-)

[Bystroushaak]

Hm, tak to jsem jí sdělil špatně. Mělo to být

C++ po zkoumání a přemýšlení nad ním vypadá jako totálně nepoužitelný krám. Jsem jen člověk, určitě jsem v tomhle udělal chybu, vždyť ho přece používá tolik lidí! Prosím, řekněte mi někdo, že se mi to jen zdálo a ukažte mi, že za to stojí.

[jkb]

my jsme se rozhodli pro C++, protoze:

- jak pise rastos, chteli jsme pro clienta jedno .exe (distribuce treba jako putty). To skutecne funguje, uzivatel si na webove strance naklikne novou verzi clienta a stahne si ho na pocitatc - na plochu - a hotovo.

- vsechny graficke toolkity jsou vlastne jen pro c++, gtk je proti wx, qt, fltk, fox mnohem mene vykone - a proto jsme nuceni pro client pouzivat c++

Nase chybejici zkusenosti s C++ obchazime tak, ze stejne programujeme v C (proto take nemuzeme zdrojaky ukazat)

[Bystroushaak]

Ok, díky za odpověď.

[Voty]

Jeden důvod může být ekonomický. Po C++ je na trhu práce větší práce větší poptávka než po D. Další důvody mohou být účel použití, C# a Java jsou na spoustu nízkoúrovňových věcí nepoužitelné. Další důvod může být to, že v C/C++ je již napsaná spousta knihoven a jejich použití je v C++ poměrně přímočaré (narozdíl od Javy, kde je to leckdy peklo). Další důvody mohou být osobní, Java je IMHO jazyk, který mě nutí dělat věci "správně", bohužel i případech, kdy se mi to nehodí.

Ovšem pokud děláš věci, kde je lépe použít jiný jazyk, není nutné se C++ učit. Proto je těch jazyků tolik. Já (dělajíc v C++) taky neříkám ostatním co na tom PHP vidí, vždyť v tom driver nikdy nemůžou napsat :)

Jen bych se pozastavil u věty "(C++ je) giganticky kolosální sbírka vyjímek, podivností a omezenosti", kdy mi naopak přijde, že C++ těch omezení (z hlediska programátora) má výrazně méně než Java.

[Bystroushaak]

Díky za odpověď.

Ovšem pokud děláš věci, kde je lépe použít jiný jazyk, není nutné se C++ učit.

Já chci umět všechno, ne jen úzce zaměřené věci.

[Voty]

Záleží na definici slova umět. Je docela rozdíl, umět v jazyku něco spáchat, nebo umět jazyk opravdu dobře ovládat.

Podobnost s přirozenými jazyky je nasnadě. Kdybych se je chtěl naučit všechny (nejsem génius), tak vždy na úkor toho, že jeden se naučím opravdu dobře a do hloubky.

[Bystroushaak]

Jo. Tohle všechno já chápu. V C++ jsem schopný něco spáchat, tenhle thread jsem založil kvůli tomu zda má cenu se ho pokusit poznat skutečně do hloubky.

[mirec]

Jazyk C++ nemá zmysel sa učiť štúdiom vlastností. Lepšie je začať povedzme ako už bolo spomínané s Qt, ktoré ponúka aj nádhradu STL. V nejakom peknom IDE ako Qt Creator človek ani nevníma, že píše v nízkoúrovňovom jazyku. Netreba sa prakticky zaoberať vecami ako alokácia pamäte (porieši automaticky QObject), jednoducho programovanie vyzerá ako vo vysokoúrovňovom jazyku a vypadne z toho obyčajná binárka. Takto nejako som začínal ja. Až keď som vedel bez problémov programovať s Qt začal som sa zaoberať tým ako vyvíjať efektívnejšie, naučil som sa používať časti boost-u, stl a rôzne detaily jazyka.

[l4m4]

Může někdo napsat nějaké důvody, které by mě měly motivovat absorbovat hru na hoboj?

Když se ti něco nelíbí a nezajímá tě to, tak to prostě nedělej a nezamořuj tím poradnu. Je to snadné.

[Josef Kufner]

A nebylo by lepší se snažit takové věci zlepšit? S takovýmhle přístupem bysme se brzy utopili v hnoji.

[BlackShark]

Jaký by mělo smysl vylepšovat hoboj aby to zajímalo víc lidí? Pokud chcete vylepčené C++, máte k dispozici D, Javu, C# a milion dalších věcí.

[Bystroushaak]

Možná kdyby ses zeptal na fóru o muzice, našel bys odpověď. Já se zeptal na serveru o linuxu v sekci programování a stojím si za tím, že sem tahle otázka patří.

Když se ti něco nelíbí a nezajímá tě to, tak to prostě nedělej a nezamořuj tím poradnu. Je to snadné.

To je právě ta chyba. Mě to zajímá, ale jsem z toho zhnusen.

[BlackShark]

Pokud jste zhnusen, pak Vás asi těžko nějaký argument přesvědčí abyste to používal. Asi jako chtít argument pro normálního chlapa aby se nechal vo... od jiného chlapa. Tím bude zhnusen, takže ho mu těžko dáte argument, který zázračně zajístí, že zhnusen nebude.

Argumenty jste zde už dostal (rozšíření, kompromis mezi výkonem a pohodlím, knihovny). Těžko dostanete nějaký jiný nazor. Pokud čekáte, že Vás zde ve vašem přesvědčení někdo podpoří, tak ano, zhruba polovina lidí Vás podpoří a 2. polovina Vám bude říkat, že je C++ dobrý jazyk. Když budete furt tlačit na pilu vyvoláte akorát flame.

[Bystroushaak]

No, možná jsem to přepískl, zhnusen není to správné slovo. Myslel jsem to takhle.

Pokud čekáte, že Vás zde ve vašem přesvědčení někdo podpoří, tak ano, zhruba polovina lidí Vás podpoří a 2. polovina Vám bude říkat, že je C++ dobrý jazyk. Když budete furt tlačit na pilu vyvoláte akorát flame.

Ne, to nečekám, chtěl jsem přece pravý opak!

Mám názor, pohled relativního začátečníka, který C++ zatím nelichotí a chtěl jsem aby mi byl vyvrácen někým kdo C++ rozumí líp než já. Aby mě prostě argumenty někdo přesvědčil, že jsem to pochopil špatně. Jenže vzhledem k tomu co jsem se zatím dozvěděl to vypadá, že se mnou částečně souhlasí všichni, protože jediné argumenty byly "používá to každý" a "je to výkonné" :/

[BlackShark]

No to si myslím, že je poměrně padný argument. V Jave, C#, PHP v tom v ničem nenapíšete driver zařízení. Neudělate v tom aplikaci pro nějaké malé zařízení s AVRkem (např.). Ty jazyky co se Vám líbí tak mají nějaký VM, který bude zase napsaný v C/C++. Prostě ať se Vám to líbí nebo ne, tak pokud to myslíte s programováním vážně, tak se s C++ s největší pravděpodobností setkáte.

Berte to tak, že v C/C++ napíšete všechno, v C++ o něco málo jednodušeji. A pokud se Vám například nelíbí STL, pak přeci můžete udělat přesně to samé, co můžete udělat v C. Prostě to nepoužívat. Rozdíl je v tom, že v C++ to používat NEMUSÍTE, ale v C NEMůUŽETE. A to je podle mě podstatný rozdíl.

Pokud bych chtěl psát například hru, tak ji 100% napíši v C++, protože oproti C to bude prostě jednodušší. A psát to v Javě nebo C# nema smysl, pokud si to maji zahrát i lidé,kteří nemají PC z NASA.

Pokud Vám nevadí "těžkopádnost" C na to co děláte, používejte to. Pokud Vám vyhovuje D pužívejte to. C++ lidé používají pro to, protože k řešení jejich problému bylo nejvhodnější a ne pro, že je někdo ukamenoval argumenty, že je dobré/blbé.

Objektové programování má zkrátka něco do sebe a oproti procedurálnímu přináši nesporné výhody (to ostatně víte, když používáte D) a v C to objektově nejde. To jde v C++. Tečka. Vybrat si musíte sám podle požadavků. Víc asi nemá cenu to rozebírat.

[Bystroushaak]

Díky. V podstatě jsem si na základě rad a reakcí udělal názor, chvíli ještě počkám a pak bych to rád uzavřel.

[pozortucnak]

1) Jednak chci poděkovat za tuto položenou otázku. Také nevím co si o C++ myslet...

2) takový výkřik do tmy... co říkáte na jazyk Vala?

3) Když už tu bylo zmíněno Qt a kdosi naznačil že se práce v Qt více přibližuje vyšším jazykům, zajímalo by mě, co je na tom pravdy? A jsou tu i jiné frameworky pro C++?

[Bystroushaak]

Vala vypadá zajímavě, ale nemám s ní žádnou zkušenost, snad se s ní někdy seznámím trochu víc. Zatím chci proniknout do D.

Qt neznám, nikdy jsem ho nepoužil (no dobře, možná jednou v pythonu). Někdo výše ukázal foreach z Qt, vypadá to že Qt se místo vymyšlení vlastního jazyka snaží zkulturnit C++.

[Michal Kubeček]

Mám názor, pohled relativního začátečníka, který C++ zatím nelichotí a chtěl jsem aby mi byl vyvrácen někým kdo C++ rozumí líp než já.

A toho jste chtěl docílit tím, že jste začal vykřikovat věci jako:

absolutně nechápu, proč někdo používá tak dementní jazyk jako je C++ … čím víc do něj pronikám, tím víc mi připadá jako špatnej vtip. Vždyť je to tak giganticky kolosální sbírka vyjímek, podivností a omezenosti. Proč v tom někdo vůbec dělá? … prvně jsem ho nepochopil, pak nevěřícně zíral a pak se začal smát … Vážně, co někdo na C++ vidí? … Mistrovství v C++ pohodím někde na nádraží a budu radši dělat něco užitečnějšího.

Ale možná máte úplnou pravdu a nechápaví jsme my, protože tohle je naprosto normální způsob, jak vyjádřit, že něčemu nerozumíte a potřebujete to vysvětlit…

[Bystroushaak]

Ale možná máte úplnou pravdu a nechápaví jsme my, protože tohle je naprosto normální způsob, jak vyjádřit, že něčemu nerozumíte a potřebujete to vysvětlit…

Hm. To proto že jsem do toho částečně nevědomky promítl víc věcí najednou. Je to dotaz, žádost o pomoc, vyjádření pocitu a zároveň průzkum bojem s cílem otestovat kompaktnost názoru střetem s názory zkušenějších programátorů. Postupně jsem svůj názor na základě reakcí upravoval a spolu s tím měnil svůj postoj a požadavky. Možná to byla chyba. Spokojen?

[Radovan]

Je tahle odpověď dost jasná?

[Bystroushaak]

Znám to. Jinak ne, je to přesný opak. Nestojím o přitakávače, chtěl jsem někoho kdo mi ukáže opak.

[:::]

ja treba pouzivam c++, protoze me umoznuje psat vysokourovnove a pri tom je vysledek efektivni. D neznam, takze je v tomhle smeru nemuzu srovnat...

jinak ja kdyz jsem zacinal s c (obycehny c, ne c++) tak jsem si taky rikal kdo takovou obludnost mohl vymyslet... (v ty dobe jsem znal jenom pascal). To je podle me prirozenej odpor mozku k uceni se rozsahlejch novejch veci...

[Bystroushaak]

Ale já s C problém nemám, nikdy jsem neměl. C++ navíc do jisté míry znám, když to vezmu chronologicky, byl to asi třetí programovací jazyk co jsem se začal učit, python byl čtvrtý a přesto ho mám dost rád a nikdy jsem s ním neměl problém, stejně jako s D, který byl asi sedmý.

Když to vezmu přísně chronologicky, tak pascal -> php -> [basic] -> (c++) -> pyton -> java -> c# -> D. Hranaté závorky jsou lehký kurz, kulaté znamenají že jsem v tom nenapsal víc jak 1000 řádek vlastních projektů.

Tím že by to bylo něco nového to tedy fakt není.

[skunkOS]

1000 řádek je uboze málo, kámo. Fakt velmi málo. To nestačí ani na to, abys získal takový větší povědomí o tom programovacím jazyku.

[Bystroushaak]

No, to chápu, proto jsem četl ty učebnice a několik tutoriálů na webu.

[loki]

Zustan u javy. C++ je pro chlapy

[loki]

Tim nechci rict, ze by java byla spatna. Ale proste c++ opravdu pro kazdeho neni. A nez to lamat pres koleno, tak je lepsi zustat u toho, co te bavi && zivi.

[pht]

U projektů v C++ jsem několikrát byl a když to porovnám s "moderními" jazyky Java, C#, Ruby, etc. tak asi takto a zejména:

1) Kromě MSVC neexistuje rozumné IDE které by umělo pořádně refactoring.

2) Použitelnost testovacích frameworků je podstatně nižší.

Tyhle dvě věci mají asi největší dopad na produktivitu - rychlost jakou vytváříte program. Jinak samozřejmě ty obvyklé věci, jako manuální správa paměti, RAII, brutální učící křivka, všechno si udělat sám a teprv pak nad tím dělat to co mám dělat...

Proklamovaná výhoda - "rychlost" je ve skutečnosti zavádějící, protože rychlost až na krev je obecně potřeba jen ve velmi omezených částech kódu a všechny ty "pomalé" jazyky mají možnost volat nativní procedury které si můžete napsat třeba v assembleru nebo C.

[Kojot]

Myslim si, ze zrovna C++ neni stastne se zacit takto ucit. Nejvice se na C++ nastvete, pokud od toho ocekavate komfort "vyssich" objektovych nebo dynamickych jazyku jako Java, .NET jazyky, Python, Smalltalk apod., ktere toho nabizi uz primo z popisu jazyka pri praci s objekty mnohem vice. V praxi vyuzivam v C++ vetsinou jen tridy (zadny komplikovany vicenasobny dedicnosti, jen obal dat s metodami), abstraktni tridy(jako interface v Jave/.NET), obcas sablony na nejaky specializovany kontejner, a obcas vyjimky.

Jinak foreach je az ve standardu C++0x, kterej ani nevim jestli je uz uzavren, natoz aby byl nejak siroce pouzivan C++ prekladaci. Takze nevim co jste cetl, ale radeji bych na to zatim zapomnel.

[Sten]

Autor si totiž plete for_each a foreach. for_each je šablonová funkce, která je v STL od počátku, ale je určena pro volání funktorů. foreach je původně z Boostu (kde funguje dobře i v C++98) a v C++2011 se vlastně vůbec nejmenuje foreach, ale je to jiný zápis pro for: for (int &i: kontejnet) {...}. Tak půlka překladačů jej už podporuje (mj. GCC a Clang).

[Bystroushaak]

Pečlivě jsem posoudil všechny odpovědi a dospěl k rozhodnutí. Vzhledem k tomu, že jediná zde zmíněná pozitivní vlastnost samotného C++ jakožto jazyka je výkon, rozhodl jsem se, že ho dál zkoumat nebudu, protože za to nestojí. Nejsem úplnej C++ analfabet, měl jsem ho dva roky na střední a semestr na VŠ, takže to snad stačí.

Abych se nerozhodoval ukvapeně, prolistoval jsem všech ~1100 stránek Mistrovství v C++ a dospěl ke stejnému názoru - nemá co nabídnout.

Pokračovat v sebevzdělávání (hlubším studiu jazyka) budu v Pythonu a D.

Všem děkuji za odpovědi a omlouvám se pokud jsem někoho svým dotazem naštval.

[:::]

pokud nedelas nic kde je potreba rychlost tak python je celkem dobra volba. Jeste bych se podival na perl.

[Bilbo]

Neexistence klasického for cyklu (ne, dělat for cyklus tak, že alokuji pole od jedné do N, a pak přes něj iteruji je dosti úchylné), šílená 2D syntaxe (aneb je nutné přesně indentovat a pokud má člověk jinou představu o počtu mezer v tabu než kompilátor, tak prostě smůla ... ) a již zmiňovaná pomalost (neexistence JIT kompilátoru nebo něčeho podobného), která je oproti kompilovaným jazykům, nebo aspoň bytekódovým s JIT vcelku značná. Python má pár zajímavých vlastností, ale na většinu věcí to není dobrá volba.

Perl je dobrý na malé utilitky (během pár minut zflikovat něco na převod z formátu A do formátu B, případně na parsování nebo filtraci logů), ale psát v tom něco většího bych nezkoušel, Perl vcelku svádí k "prasáckému" psaní kódu a vyznat se i ve vlastních zdrojácích rok po napsání bývá netriviální (někdy nepomůžou ani hustě zanechávané komentáře)

[pavlix]

Neexistence klasického for cyklu (ne, dělat for cyklus tak, že alokuji pole od jedné do N, a pak přes něj iteruji je dosti úchylné)

Pokud myslíš „klasický“ for cyklus z C, tak je to jen alternativní zápis while, tedy v pythonu je.

pokud má člověk jinou představu o počtu mezer v tabu než kompilátor, tak prostě smůla

Kombinování tabů a mezer je prasárna snad všude.

[Bystroushaak]

Python má pár zajímavých vlastností, ale na většinu věcí to není dobrá volba.

Přijde mi to přesně naopak - python má pár nepěkných vlastností a na většinu věcí to je dobrá volba.

[Sten]

Python má generátory, něco, co C neumí (ale C++ ano), takže for cyklus lze napsat i bez alokace pole: for i in xrange(10):.

Odsazování je běžné v pseudokódu a Python se snaží být spustitelný pseudokód. Překladač nezajímá, jak odsazujete, pokud odstazujete konzistentně (ale to po vás budou požadovat i v coding standards u jiných jazyků).

JIT existuje, jmenuje se PyPy, ale zatím nepodporuje všechny konstrukce. Python ale hlavně funguje jako skriptovací jazyk nad céčkovými knihovnami, takže ta rychlost může být snadno mnohem vyšší, než dosahuje Java.

[Bilbo]

Python má generátory, něco, co C neumí (ale C++ ano), takže for cyklus lze napsat i bez alokace pole: for i in xrange(10):.

Teď už je to možná lepší, ale kdysi byl ten obyčejný předgenerovaný range v manuálu a ve většině examplů co ležely na netu. Je to sice spíš blbost některých uživatelů než velký nedostatek jazyka, nicméně řadí to Python do kategorie jazyků "svádí k prasárnám".

Odsazování je běžné v pseudokódu a Python se snaží být spustitelný pseudokód. Překladač nezajímá, jak odsazujete, pokud odstazujete konzistentně (ale to po vás budou požadovat i v coding standards u jiných jazyků).

Tam je rozdíl, že coding standards musí člověk dodržovat až v okamžiku commitu, takže když si někam do zdrojáku pastnu nějaký debugovací kód o kterém vím, že před commitem půjde zase pryč, tak ho nemusím v jazycích co nevyžadují přesné odsazení formátovat. A jsou i vyjímečné případy, kdy je lepší něco poodsazovat pro přehlednost trochu jinak než jak je to v coding standards,

JIT existuje, jmenuje se PyPy, ale zatím nepodporuje všechny konstrukce. Python ale hlavně funguje jako skriptovací jazyk nad céčkovými knihovnami, takže ta rychlost může být snadno mnohem vyšší, než dosahuje Java.

Java (nebo skoro cokoliv) nad céčkovými knihovnami bude taky rychlá :) Jak moc použitelné je PyPy s částí jazyka co to podporuje? I když jak na stránce projektu vidím odstavec "Known differences that are not going to be fixed" tak koukám, že s univerzální použitelností to asi nebude tak žhavé ...

Tuším někde někdo zmiňoval, že konstrukce a široké možnosti jazyka (možnost přicpávat různé funkce a atributy skoro do čehokoliv, o věcech typu "eval" nemluvě) výrobu dobrého JIT kompilátoru vcelku dosti znesnadňují až znemožňují.

[Ash]

Nutnost odsazovat mi vadí hlavně z tohoho důvodu, že pak někdy když člověk zakomentuje jednu řádku, tak musí dvacet dalších přeformátovat. Pokud ví, že řádku zase brzy odkomentuje a bude muset přeformátovávat zpět, tak to jen vnáší riziko chyby.

[Sten]

Nemusí: if True: (či if False:, pokud chcete zakomentovat celý blok)

Navíc změnit odsazení u celého bloku zvládne mnoho schopnějších editorů na pár klávesových zkratek (či kliků).

[Ash]

Jistě, obezličky... Ještě změnit source-highlighting aby to obarvovalo jako komentář :( Odsazení celého bloku na pár kláves používám, ale to nijak neřeší problém, je potřeba zbytek aktivního kódu posunout (správně) a pak zase (správně) zpět, což je otrava. Makro pro automatické zakomentování bloku a automatickou opravu odsazení zbytku kódu by to jistě vyřešilo :P

[Sten]

K poslednímu: eval by ani tak nevadil, prostě se to v evalu spustí v interpretu, ale pythonovský přístup, že všechno (včetně funkcí) je duck-typovaný objekt, je docela problém přeložit do něčeho blízkého strojovému kódu, aniž by tím utrpěl design jazyka. Autoři Pythonu tedy raději šli jednodušší cestou: pomalý kód lze snadno přepsat do externího modulu (a IMO hodně jednodušeji než třeba u té Javy).

Python bych tedy spíše viděl jako skriptovací jazyk pro propojení mnoha externích knihoven než jako plnohodnotný jazyk pro psaní všeho.

[pavlix]

Python bych tedy spíše viděl jako skriptovací jazyk pro propojení mnoha externích knihoven než jako plnohodnotný jazyk pro psaní všeho.

Tedy v podstatě ideální aplikační jazyk pro psaný jakýchkoli frontendů a případně na prototypy core funkcionality, která se v případě potřeby napíše v C.

[Bilbo]

Duck typing sice znamená, že volání skoro čehokoliv na skoro čemkoliv je typicky nějaký lookup do tabulky funkcí objektu (kdy pro název funkce a typ parametrů z tabulky vyleze adresa funkce nebo NULL), ale i tenhle kód by šel přeložit do strojáku (byť oproti např. Javě ne moc efektivnímu). Možná že plně funkční implementace fungující se současným pythonem tu není taky proto, že by to i přes sebelepší snahu bylo pořád šíleně pomalé....

Jinak idea že v C++ se napíše jádro a pak se to obalí aby to šlo použít v pythonu asi nebude tak jednoduchá. V jednom projektu jsme to zkoušeli, ale dopadlo to nakonec tak, že já jsem napsal C++ část a ten kdo psal pythoní wrapper nakonec prohlásil že na to kašle, že je to šílené a že to radši místo v Pythonu celé napíše v C++.

Předpokládám, že u JNI i u pythonu je vcelku problém mapování ze složitějších struktur pro C++ (např. map<něco, něco> ) na odpovídající struktury u Javy a Pythonu (pokud se mají předávat dovnitř a ven ...).

[pavlix]

Jinak idea že v C++ se napíše jádro a pak se to obalí aby to šlo použít v pythonu asi nebude tak jednoduchá. V jednom projektu jsme to zkoušeli, ale dopadlo to nakonec tak, že já jsem napsal C++ část a ten kdo psal pythoní wrapper nakonec prohlásil že na to kašle, že je to šílené a že to radši místo v Pythonu celé napíše v C++.

Njn, to je tak když se kombinují jazyky, které se rozcházejí... moduly pro python se boudou IMO daleko lépe psát standardně v C než se patlat s C++.

[Sten]

Taky už jsem psal několik aplikací využívající Python jako skriptovací jazyk a C++ jako core functionality a mohu zodpovědně prohlásit, že při použití Boost.Python je propojení C++ a Pythonu hračka včetně toho mapování std::map<něco, něco> do Pythonu a to bez ohledu na to, jak složité je to uvnitř (to mapování nefunguje tak, že se to přeloží do pythonní mapy, ale že se udělá objekt chovající se stejně jako mapa, který obaluje tu std::map — vyhnete se tak zbytečnému kopírování; obráceně se ale už kopíruje, tam to moc jinak nejde). Na druhou stranu, pokud budete používat Python C API a propojovat to s C++, tak to bude šílené a strašně se nadřete.

[pavlix]

Díky za info.

[Bilbo]

Takže Boost.Python .... teď už to zůstane asi v C++, ale už mám tip do přístě :)

[Kojot]

A co Objective-C++ :D.

[Michal Kubeček]

Pokud jste si z diskuse odnesl tohle, pak už zbývá jen ocitovat klasika: "Pane kolego, tato debata byla naprosto nesmyslná. Zapomeňte, prosím, že jste se mne na cokoli ptal a že jsem vám cokoli odpovídal."

[Bystroushaak]

Odnesl jsem si lecos. Například že velká část zde diskutující používá C++ jen částečně, protože jim na něm něco vadí. Přehodnotil jsem názor, že na tom můžu být podobně a když k tomu budu nucen, používat ho jen po OOP, bez STL, poněkud svéráznějším způsobem.

Další věc je, že většina lidí si zřejmě C++ vědomě nevybrala (z dvou prakticky stejně funkčních jazyků) a nikdy ho neporovnávala a nedívala se na něj moc kriticky. Pro ně to bylo buď ostatní, ne tak užitečné jazyky (C/Pascal/PHP atp..), nebo C++. Pro mě ne.

Nakonec jsem si odnesl několik poznatků z lidské psychologie, ale funguje to spíš na intuitivní úrovni než na vědomé, takže je teď nepopíšu, co přesně to bylo mi dojde až časem.

[__dark__]

No vidíš, podle mě zase diskuze jasně naznačila, že C++ má široké zastoupení na trhu, a lze si jeho osvojením vydělat hodně peněz Je to bohatý jazyk, ale jak už tu psalo více lidí, nění to jazyk pro každého. Já osobně uvítám, když tento jazyk budou používat lidé, kteří mu rozumí;)

[Bystroushaak]

No vidíš, podle mě zase diskuze jasně naznačila, že C++ má široké zastoupení na trhu, a lze si jeho osvojením vydělat hodně peněz

To jsem věděl už předtím.

Já osobně uvítám, když tento jazyk budou používat lidé, kteří mu rozumí;)

Nikdy jsem pokud se nepletu nepsal že mu nerozumím, nebo že mi dělá nějaký problém něco z něj pochopit.

[Michal Kubeček]

Nikdy jsem pokud se nepletu nepsal že mu nerozumím

Explicitně ne, ale je to dostatečně zřetelné.

nebo že mi dělá nějaký problém něco z něj pochopit.

Pochopit jazyk neznamená naučit se jeho syntaktické konstrukce a v případě C++ to platí dvojnásob. To, že jsem tu a tam něco opravoval v perlových skriptech a nedávno prováděl netriviální backport v YCP, neznamená, že o sobě mohu tvrdit, že jsem ty jazyky pochopil. Na druhou stranu, po těch letech praxe si to už o C++ tvrdit troufám, přestože složitější triky s templates z hlavy nesypu a když jednou za uherský rok potřebuji použít pointer na metodu, raději si syntaxi nejdřív někde zkontroluji. Právě u tak bohatých jazyků jako C++ je nejdůležitější cit pro to, co používat běžně, co občas, co jednou za čas a co třeba nepoužít nikdy (což ale pořád neznamená, že někdo jiný s jiným přístupem a jinými potřebami nemůže mít to rozdělení diametrálně odlišné). Ten cit nezískáte přečtením učebnice ani napsáním pár prográmků.

Váš problém není v tom, že byste nepochopil, jak fungují templates nebo jiné prvky jazyka C++. Je v tom, že si myslíte, že přečtení jedné učebnice a pár příspěvků v diskusi (k nimž jste navíc přistupoval už s předem uzavřeným názorem a to, co v nich nebylo souladu s tímto názorem, jste ignoroval) vám dalo dostatečné pochopení a nadhled, abyste mohl hodnotit, jestli je ten jazyk dobrý nebo špatný (nebo dokonce dementní).

[Bystroushaak]

Neexistuje nic jako objektivní hodnocení jazyka jestli je dobrý, špatný nebo dementní. Je to můj subjektivní názor a po nikom nechci aby ho přejímal.

Jasně jsem psal, že jsem C++ měl na střední i na VŠ a nepřečetl jsem jednu učebnici, ale hned několik. Nadhled tedy nějaký mám. Problém většiny učebnic je, že popisují jen základní rysy a Mistrovství v C++ se docela dost věnuje i těm pokročilejším. Snažil jsem se jazyk lépe pochopit, ale čím víc do toho pronikám, tím blběji to vypadá. Na základě zde uvedené diskuze jsem se rozhodl, že víc už to nemá cenu, ten jazyk za to prostě nestojí (což je opět můj subjektivní názor).

Právě u tak bohatých jazyků jako C++ je nejdůležitější cit pro to, co používat běžně, co občas, co jednou za čas a co třeba nepoužít nikdy (což ale pořád neznamená, že někdo jiný s jiným přístupem a jinými potřebami nemůže mít to rozdělení diametrálně odlišné).

Je možné že se pletu, ale na základě informací co jsem zde získal to vypadá tak, že každý programátor používá jen určitou část C++, která mu vyhovuje, když to přeženu, tak vlastní dialekt. Někteří dokonce používají knihovny (Qt), které z něj dělají jiný jazyk nekompatibilní se sebou samým. To mi zrovna jako výhoda nepřijde.

[Voty]

Je možné že se pletu, ale na základě informací co jsem zde získal to vypadá tak, že každý programátor používá jen určitou část C++, která mu vyhovuje, když to přeženu, tak vlastní dialekt. Někteří dokonce používají knihovny (Qt), které z něj dělají jiný jazyk nekompatibilní se sebou samým. To mi zrovna jako výhoda nepřijde.

A to mě naopak jako výhoda přijde. C++ je poměrně univerzální jazyk, ve kterém se dají věci dělat různými způsoby. Což znamená, že uživatele nesvazuje více než je nutné. Rozhodně nebylo cílem C++, aby každý používal všechny jeho aspekty, ale aby si každý (uživatel/projekt) vybral tu cestu, která se mu hodí. To není obhajoba C++, to je prostě fakt :)

Nicméně, rozhodnutí jaký jazyk se učit je více-méně nezávislé na jazyku samotném, ale především na předpokládaném využití (stále se snažím naznačit, že tvůj myšlenkový postup je pochybný). Opět utíkám k analogii s přirozenými jazyky, kdy si také vybírám jazyk, od kterého očekávám široké uplatnění a je mi dost jedno, že Esperanto je (asi) úžasně logické, když se s ním nikde nedomluvím.

[pavlix]

A to mě naopak jako výhoda přijde. C++ je poměrně univerzální jazyk, ve kterém se dají věci dělat různými způsoby. Což znamená, že uživatele nesvazuje více než je nutné. Rozhodně nebylo cílem C++, aby každý používal všechny jeho aspekty, ale aby si každý (uživatel/projekt) vybral tu cestu, která se mu hodí. To není obhajoba C++, to je prostě fakt :)

Obecně vzato bych s tebou uměl i souhlasit... kdybys nemluvil o C++.

Líbí se mi některé flexibilnější jazyky, které nevnucují jeden konkrétní způsob a dávají programátorovi flexibilní prostředky a možnost vyřádit se. Ale přijde mi (subjektivně), že C++ mezi ně nepatří a jeho flexibilita jako výhoda moc nefunguje.

[__dark__]

Jasně jsem psal, že jsem C++ měl na střední i na VŠ a nepřečetl jsem jednu učebnici, ale hned několik

Ještě jsem neviděl programátora, který by se jazyk naučil přečtením knih. Až napíšeš v C++ milión řádků kódu, tak můžeš tento dotaz v poradně zopakovat, a věř mi, že tvoje argumentační schopnosti budou úplně jinde. Teď si ale de-fakto v pozici, kdy pomlouváš jazyk, o kterém z praktického hlediska (psals tu 1000 řádků) nevíš zhola nic

Někteří dokonce používají knihovny (Qt), které z něj dělají jiný jazyk nekompatibilní se sebou samým

Prosimtě, nešiř tu bludy! Qt je obyčejná knihovna pro C++, která podporuje možná více překladačů, které si schopný vyjmenovat. Řeší nějaký problém (více problémů), jako třeba stl, boost, webkit, atd... Pokud je C++ tak na nic, tak proč se v tom píšou komerční aplikace, hry, překladače, jiné jazyky, webové prohlížeče, atd...?

Prostě otevři oči Já jsem tu nedávno psal do diskuze celkem záporné věci o JS, a tento víkend chci zkusit node.js

[Bystroushaak]

Až napíšeš v C++ milión řádků kódu, tak můžeš tento dotaz v poradně zopakovat, a věř mi, že tvoje argumentační schopnosti budou úplně jinde.

Takže tvrdíš, že na to abych si o jazyku mohl udělat názor (a tedy zjistil jestli mi vůbec stojí za to mu věnovat čas abych ho mohl plně pochopit) musím napsat milion řádků? To vypadá jako deadlock. Milion řádků nenapíšu protože nevím jestli za to stojí a nevím jestli za to stojí, protože jsem nenapsal milion řádků. Nice.

Teď si ale de-fakto v pozici, kdy pomlouváš jazyk, o kterém z praktického hlediska (psals tu 1000 řádků) nevíš zhola nic

No, však ani netvrdím že ne. Proto jsem založil tohle vlákno jako dotaz s jistou žádostí o to aby mi někdo pomohl změnit názor. Kdybych chtěl pomlouvat, napíšu blog.

Pokud je C++ tak na nic, tak proč se v tom píšou komerční aplikace, hry, překladače, jiné jazyky, webové prohlížeče, atd...?

Zatím mám pocit že je to ze stejného důvodu jako hlavní motivace která zazněla několikrát v této diskuzi - používají ho všichni ostatní. Trochu to připomíná windows, nemyslíš?

Prosimtě, nešiř tu bludy! Qt je obyčejná knihovna pro C++, která podporuje možná více překladačů, které si schopný vyjmenovat.

Neměl jsem v plánu šířit bludy. Šlo mi o to že Qt zavádí novou syntaxi a nová klíčová slova, co jsem tak pochopil. Defakto tak z C++ dělá jiný jazyk. Ale možná jsem to pochopil špatně.

[Kit]

Šlo mi o to že Qt zavádí novou syntaxi a nová klíčová slova, co jsem tak pochopil. Defakto tak z C++ dělá jiný jazyk. Ale možná jsem to pochopil špatně.

IMHO jsi to pochopil správně. Pokud nějakou knihovnou změníš syntaxi, tvoříš nový jazyk. Pokud je změna konzistentní se zbytkem aplikace, je to v pořádku.

Pokud bys hledal jazyk, ve kterém si můžeš vytvořit vlastní syntaxi i metodiku používání, zkus už zmíněný Common Lisp.

[Šangala]

Zatím mám pocit že je to ze stejného důvodu jako hlavní motivace která zazněla několikrát v této diskuzi - používají ho všichni ostatní. Trochu to připomíná windows, nemyslíš?

„Ne, je to proto, že je to super universální jazyk“.
PS: Pokud jazyk bude používat 7 lidí tak je to jazyk k ničemu… (nebo na velmi specifickou věc).

Ale jinak doporučuji dát se na politiku, uplatníte svou schopnost, dělat závěry v souladu ze svým přesvědčením, bez ohledu na názory ostatních, které jste si „vyžádal“.

[Bystroushaak]

Pokud jazyk bude používat 7 lidí tak je to jazyk k ničemu… (nebo na velmi specifickou věc).

Libovolný jazyk který dnes používá osm a více lidí určitou dobu používalo sedm lidí.

Ale jinak doporučuji dát se na politiku, uplatníte svou schopnost, dělat závěry v souladu ze svým přesvědčením, bez ohledu na názory ostatních, které jste si „vyžádal“.

To vám vadí že automaticky nepřejímám názory ostatních a prvně o nich přemýšlím, dávám je do kontextu mého vidění světa, porovnávám je, zkoumám motivaci řečníka a až teprve poté je možná přijmu za své? Nebo čistě ten fakt, že po té co jsem vyslechl názory ostatních jsem neprohlásil "sláva, už vidím, c++ je lék na vše a vlastně vůbec ten nejlepšejší jazyk pod sluncem" ?

[Šangala]

Nevadí mi to (nevím proč by mělo), jen jsem si Vás zasadil do svého vidění světa…
…velmi těžce by šlo zde vedou diskuzi shrnout do vašeho vyjádření: „hlavní motivace je že C++ používají všichni ostatní“ (pro Vás to problém nebyl, proto fčul nevěřím, že si chcete udělat názor, spíše mně to přijde jako se utvrdit v: „Jediná pravda existuje, stačí jen poslouchat co říkám“…), stejně tak nevím jak se dostat k závěru: "sláva, už vidím, c++ je lék na vše a vlastně vůbec ten nejlepšejší jazyk pod sluncem".

[Bystroushaak]

Ono by nejspíš bylo vhodné analyzovat tuhle diskuzi chronologicky. Pak by vám třeba došlo že můj názor se v průběhu mění.

[__dark__]

Takže tvrdíš, že na to abych si o jazyku mohl udělat názor (a tedy zjistil jestli mi vůbec stojí za to mu věnovat čas abych ho mohl plně pochopit) musím napsat milion řádků?

Tvrdím, že bez programování se jazyk nenaučíš. Milión řádků ber orientačně, spíš jako nějakou metu (a aplikuj na jakýkoliv jazyk).

No, však ani netvrdím že ne. Proto jsem založil tohle vlákno jako dotaz s jistou žádostí o to aby mi někdo pomohl změnit názor. Kdybych chtěl pomlouvat, napíšu blog.

Bez toho, aniž bys jazyk aktivně používal, názor nezměníš.

Zatím mám pocit že je to ze stejného důvodu jako hlavní motivace která zazněla několikrát v této diskuzi - používají ho všichni ostatní. Trochu to připomíná windows, nemyslíš?

Podle mě C++ v současné době nemá konkurenci, co se některých vlastností týče. Ale chápu to tak, že pro tebe je to spíš nevýhoda.

Neměl jsem v plánu šířit bludy. Šlo mi o to že Qt zavádí novou syntaxi a nová klíčová slova, co jsem tak pochopil. Defakto tak z C++ dělá jiný jazyk. Ale možná jsem to pochopil špatně.

Ono je to pořád C++. Kdybys to bral takto, tak bys mohl tvrdit, že Gtk není C, protože používá GObject a spoustu maker. Ale sorry za zbytečnou ofenzívu;)

[Bystroushaak]

Ok.

[Ladicek]

Prosimtě, nešiř tu bludy! Qt je obyčejná knihovna pro C++

… a moc je obyčejný program, který žere text a bleje jiný text.

[__dark__]

Ten text si můžeš vyblit i ručně, ale moc je pohodlnější

[__dark__]

Jinak, čekal jsem, že se někdo chytne, a vzpomene MOC:) Sice jsem osobně proti jakékoliv formě generování zdrojového kódu, ale tyto případy, kdy se vygenerovaný kód needituje a slouží jen pro překladač, mi nevadí. Generování kódu jsem viděl i u GLib (marshall), a taky to neznamená, že už to není C. Dále tu máme DBus, a další věci, kde se něco podobného používá.

[Ladicek]

Osobně nemám problém s generováním kódu. U lidí, kteří tvrdí, že zdrojová forma je totožná s cílovou, i když prokazatelně není, no, tam už bych nějaké námitky měl. Významnou součástí Qt je samostatný dialekt C++ (což nemusí být nutně špatně) a jeho překladač, s tím nic neuděláš.

[Bystroushaak]

Já fakt nechci vypadat jako že nesnáším C++, ale napadá mě, jestli tvůrcům Qt přišlo C++ taky jako ne úplně optimální jazyk a proto z něj udělali něco lepšího? Nevíte o tom někdo něco podrobnějšího? S Qt mám nulové zkušenosti.

[__dark__]

Tvůrci potřebovali nějak implementovat signály a sloty, no a vymysleli MOC. Lze to řešit i jinak (se třeba podívej do knihovny sigc++, která se používá v gtkmm), ale implementace Qt dovoluje i introspekci, což je podle mě klíčová vlastnost, celkově to žere míň paměti, a lze poslat sygnál i asynchronně. Napojení na skriptovací jazyky je třešinkou na dortu, ačkoliv díky introspekci právě ta rychlost není úplně nejlepší (to se můžeš dočíst v blogu o Qt/Webkit), na druhou stranu, pokud používáš skriptovací jazyky, asi tě rychlost nezajímá.

Tady jen vidíš, co si schopný v C++ udělat. Pochybuju, že to změní tvůj pohled na tento jazyk, ale ty možnosti jsou nekonečné.

[Bystroushaak]

A co všechno je člověk schopný udělat ve forthu.. A ta rychlost :)

[pavlix]

na druhou stranu, pokud používáš skriptovací jazyky, asi tě rychlost nezajímá.

Ať se tu větu snažím přežvýkat jak se ji snažím přežvýkat, vždy mi z ní vycházní nesmyslná implikace (nebo prostě kec).

[__dark__]

No tak sem přihoď link na nějaký rychlý skriptovací jazyk, tos mohl udělat přece hned.

[pozortucnak]

Lua?

[__dark__]

[pavlix]

No tak sem přihoď link na nějaký rychlý skriptovací jazyk, tos mohl udělat přece hned.

Já jsem jen poukazoval na nesmyslnost toho tvrzení. S rychlostí skriptovacích jazyků to nemá nic společného.

Ale na to bys musel uvažovat trochu v širším kontextu než si jen v hlavě představit benchmark.

[__dark__]

Nechceš se ty naučit číst v širším kontextu, když to ostatním vyčítáš? Ta věta na kterou reagovals patří k té větě předtím, dokonce jsou oddělené jen čárkou. Takže ještě jednou a speciálně pro tebe: Qt aplikace se dají skriptovat pomocí introspekce, ale výkon není tak dobrý jako při použití C++ (jaké překvapení:)), takže pokud není rychlost extrémně důležitá, může to být užitečné.

Jinak nechápu v čem mé tvrzení bylo špatně. Obecně je známé, že skriptovací jazyky jsou většinou dynamicky typované a nenabízí takový výkon jako kompilované jazyky typu C++. Já v tom vidím logiku. Když se podívám na seznam skriptovacích jazyků ( http://en.wikipedia.org/wiki/List_of_programming_languages_by_category#Scripting_languages ), tak bych z těch nejpoužívanějších za výkonný označil asi jen ActionScript (ty další neznám, můžeš doplnit).

[Josef Kufner]

Nesledoval jsem to příliš podrobně, ale do QtScriptu prý portují V8. Takže tolik k nejpoužívanějšímu scriptovacímu jazyku a jeho nejvýkonějšímu interpretu.

[__dark__]

Já jsem původně vycházel z tohoto staršího zápisku:

monster-evolution-in-qt-part-1-using-qt-script

Podle mě dobré čtení, které trochu poodkrývá architekturu QtScriptu. Na V8 port se samozřejmě těším:)

[pavlix]

Nechceš se ty naučit číst v širším kontextu, když to ostatním vyčítáš?

Máš tedy asi na mysli užší kontext, ne?

Jinak nechápu v čem mé tvrzení bylo špatně. Obecně je známé, že skriptovací jazyky jsou většinou dynamicky typované a nenabízí takový výkon jako kompilované jazyky typu C++. Já v tom vidím logiku. Když se podívám na seznam skriptovacích jazyků ( http://en.wikipedia.org/wiki/List_of_programming_languages_by_category#Scripting_languages ), tak bych z těch nejpoužívanějších za výkonný označil asi jen ActionScript (ty další neznám, můžeš doplnit).

Jak říkám, ty se na to díváš jenom z pohledu benchmarků.

Ale uživatele aplikace popravdě řečeno vůbec nezajímá, jestli je na aplikaci nebo část aplikace použitý benchmarkově pomalejší jazyk, nebo ne. Na výsledné aplikaci je zajímavá její odezva, rychlost jejích operací a dejme tomu ještě spotřeba prostředků.

A použití dynamického jazyka ještě neimplikuje, že to bude pomalé a nepoužitelné. Když se ty jazyky používají správně a na správný účel, nemusí to uživatel vůbec poznat.

[__dark__]

Já myslím, že tato diskuze teoreticky nemá konce. Já tvrdím, že dynamicky typované jazyky není možné tak optimalizovat, jako staticky typované, mkrni třeba na strict režim v JS, to je čistě věc navržená pro zvýšení výkonu. Nikde netvrdím, že ten výkonnostní rozdíl je nějak propastný, ale je tam, a vždycky bude. Souhlas?

Jak říkám, ty se na to díváš jenom z pohledu benchmarků. Ale uživatele aplikace popravdě řečeno vůbec nezajímá, jestli je na aplikaci nebo část aplikace použitý benchmarkově pomalejší jazyk, nebo ne. Na výsledné aplikaci je zajímavá její odezva, rychlost jejích operací a dejme tomu ještě spotřeba prostředků.

Já vidím technologie jako celek též, toto fakt nechápu kam tím míříš. Ale na druhou stranu neznám jiný způsob, jak zjistit rychlost nějakého celku, než udělat testy jednotlivých komponent. Podle mě výkon celku je suma výkonu všech jeho komponent.

A použití dynamického jazyka ještě neimplikuje, že to bude pomalé a nepoužitelné.

Já jsem nic takového nikde nepsal.

Když se ty jazyky používají správně a na správný účel, nemusí to uživatel vůbec poznat.

Můžeš definovat "správně a na správný účel"?

[pavlix]

Kdybys psal, že dynamicky typované jazyky jsou obecně pomalejší než staticky typované, ani bych necekl. Jestli si dobře pamatuju, tak jsi ale psal, že tomu, kdo používá dynamicky typované (interpretované, nebo co jsi přesně psal) jazyky, tomu nezáleží na rychlosti.

Já stále trvám na tom, že toto tvrzení je úplný nesmysl, ať se okecává jakkoli. Další diskuze na tohle téma nemá smysl.

Podle mě výkon celku je suma výkonu všech jeho komponent.

To je podle mě jen další nesmysl, nehledě na to, že bych chtěl vidět jednotku, ve které ten výkon budeš měřit.

Můžeš definovat "správně a na správný účel"?

Doporučuju tento pojem chápat intuitivně, tedy hodnotit podle výsledku.

[____]

JavaScript přece.

[pavlix]

Jinak, čekal jsem, že se někdo chytne, a vzpomene MOC:)

Což to je v pořádku, že si ho někdo vzpomene.

Co jsem ale nečekal, je že se najde někdo jiný, kdo ho okamžitě označí za šiřitele bludů. Já nikde netvrdím, že generovat kód je špatné. Ale generovat ho, a přitom předstírat, že to nedělám, mi přijde už trošku na hlavu.

Generování kódu jsem viděl i u GLib (marshall), a taky to neznamená, že už to není C. Dále tu máme DBus, a další věci, kde se něco podobného používá.

Já nevidím důvod se v tom dál pitvat a snažit se dokázat, že Qt se používá v čistém C++.

Na případu Glib je vidět, jak se snažíš chytit se stébla trávy. Napsal jsem několik aplikací za použití Glib a žádná z nich se nemusí preprocesovat jinak než standardním céčkovým preprocesorem. Dbus jsem taky v nějaké té aplikaci použil a rovněž jsem k tomu speciální preprocesor nepoužil.

Ale to se bavím o faktech, ne o tom, jestli je to dobře nebo špatně.

[__dark__]

Já nevidím důvod se v tom dál pitvat a snažit se dokázat, že Qt se používá v čistém C++.

Qt se používá v čistém C++, paradoxně je přenositelnější než jiné C++ knihovny. Toto jsou fakta, o kterých se chceš bavit, je tak?

Na případu Glib je vidět, jak se snažíš chytit se stébla trávy. Napsal jsem několik aplikací za použití Glib a žádná z nich se nemusí preprocesovat jinak než standardním céčkovým preprocesorem. Dbus jsem taky v nějaké té aplikaci použil a rovněž jsem k tomu speciální preprocesor nepoužil.

Já jsem zase napsal nějaké věci v Qt, kde jsem nepoužil MOC, dokazuje to něco?

Ale to se bavím o faktech, ne o tom, jestli je to dobře nebo špatně.

Fakt je, že nemáš rád Qt a asi ani C++. Fakt je, že nevidíš rozdíl mezi MOC a preprocessorem. Fakt je, že bavit se ze zaslepeným člověkem nemá smysl, atd...

[pavlix]

Qt se používá v čistém C++, paradoxně je přenositelnější než jiné C++ knihovny. Toto jsou fakta, o kterých se chceš bavit, je tak?

Asi se nemá cenu o tom bavit, když máme k dispozici protichůdná fakta :).

Já jsem zase napsal nějaké věci v Qt, kde jsem nepoužil MOC, dokazuje to něco?

Ne víc než to, že umíš Qt používat nestandardním způsobem.

Fakt je, že nemáš rád Qt a asi ani C++.

To je fakt, který nijak nezastírám, a ani ho nepoužívám k přibarvování faktů.

Fakt je, že nevidíš rozdíl mezi MOC a preprocessorem.

Vztah mezi MOC a preprocesorem jsem vyčetl kdysi z nějaké dokumentace Qt a ten vztah byl podle nich inkluze.

Fakt je, že bavit se ze zaslepeným člověkem nemá smysl, atd...

Vidím, že na víc než ad hominem se nezmůžeš. Zřejmě ti uniká rozdíl mezi „bavit se s někým“ a „cíleně někoho urážet“.

Na to mi zbývá odpovědět jediné. Mě neurazíš.

[__dark__]

Asi se nemá cenu o tom bavit, když máme k dispozici protichůdná fakta :).

Fakt je, že si začínám připadat jako v sitkomu

Ne víc než to, že umíš Qt používat nestandardním způsobem

Neřekl bych. Pokud nevytváříš vlastní třídy, které dědí z QObject/zděděných z QObject, tak MOC nepotřebuješ. Třeba když děláš jen nějaké kreslení do QImage, tak tyto požadavky splňuješ.

To je fakt, který nijak nezastírám, a ani ho nepoužívám k přibarvování faktů.

Já si nejsem tak jistý.

Vztah mezi MOC a preprocesorem jsem vyčetl kdysi z nějaké dokumentace Qt a ten vztah byl podle nich inkluze.

Oni sami nazývají MOC jako Meta-Object-Compiler. Mi osobně ten Compiler sedí víc.

Vidím, že na víc než ad hominem se nezmůžeš. Zřejmě ti uniká rozdíl mezi „bavit se s někým“ a „cíleně někoho urážet“.

Sorry, asi máme hranice citlivosti někde jinde, urážení v diskuzi o C++ mě nijak nenaplňuje.

[Sten]

No, Qt sice používá MOC, ale to samé, co lze napsat v Qt, lze napsat velice podobně třeba v Boostu a bez MOC. MOC je vlastně jenom pozůstatek mizerné podpory šablon ze strany MSVC++, dost jsem se divil, když jsem zjistil, že jej v Qt 4 nechali.

[Josef Kufner]

Jak bys bez MOC udělal toto?

class Něco {
  public slots:
    void hello(QString);
  signals:
    void world(QString);
}

[Ales Hakl]

libsigc++

[Sten]

class Něco {
  public:
    void hello(QString);
    boost::signal<void(QString)> world;
};

[pavlix]

Ještě jsem neviděl programátora, který by se jazyk naučil přečtením knih. Až napíšeš v C++ milión řádků kódu, tak můžeš tento dotaz v poradně zopakovat, a věř mi, že tvoje argumentační schopnosti budou úplně jinde. Teď si ale de-fakto v pozici, kdy pomlouváš jazyk, o kterém z praktického hlediska (psals tu 1000 řádků) nevíš zhola nic

Já bych nezahazoval ani názor člověka po 1000 řádcích. Říká to o jazyku zase něco úplně jiného, než jak ho berou ostřílení C++káři.

Prosimtě, nešiř tu bludy! Qt je obyčejná knihovna pro C++

Takové mám nejradši. Píšou o bludech a ve stejné větě nepokrytě lžou, nebo alespoň šíří své další bludy.

Prostě otevři oči Já jsem tu nedávno psal do diskuze celkem záporné věci o JS, a tento víkend chci zkusit node.js

JS má hodně plusů :). Řekl bych že paradoxně možná víc než C++, v určitém smyslu (samozřejmě ne, když se je snažíš používat na to samé).

[Josef Kufner]

Docela zajímavé pak je spojení JS a C++ ... (QtScript)

[pavlix]

Docela zajímavé pak je spojení JS a C++ ... (QtScript)

Mě právě přijde daleko zajímavější spojení JS a C.

Už jenom proto, že se mi nelíbí implementace OOP v C++, a tím pádem u mě ztrácí oproti C veškeré výhody a zbývají už jen nevýhody. Subjektivní pohled, samozřejmě.

[pavlix]

A to jsem ještě zapomněl zmínit, že jsem si příliš neoblíbil Qt. Poslední grafickou aplikaci jsem psal v Clutteru a Mx, tedy blíže GTK světu. Navíc jsem vše psal v C s tím, že do budoucna na tom pravděpodobně bude pracovat někdo, komu bude bližší právě Javascript.

[__dark__]

no, tak napiš, co je tedy Qt, když ne knihovna pro C++

[pavlix]

no, tak napiš, co je tedy Qt, když ne knihovna pro C++ Váš komentář

A když ti vysvětlím, na co upozorňoval Bystroušák, přestaneš se vůči někomu chovat tak nesmyslně konfrontačně?

Qt používá upravenou syntaxi C++, která ve standardních kompilátorech bez speciálního preprocesoru nefunguje. Mám za to, že to je to, na co Bystroušák narážel.

Jinak ano, mezi lidma taky nemluvím exaktně a uklouzne mi, že Qt je knihovna pro C++. Ale tys ho označil za šiřitele bludů, přitom měl pravdu v tom, že se používá nestandardní varianta jazyka.

[__dark__]

A když ti vysvětlím, na co upozorňoval Bystroušák, přestaneš se vůči někomu chovat tak nesmyslně konfrontačně?

Nevyhýbej se odpovědi, a napiš co je Qt, když ne C++ knihovna

Qt používá upravenou syntaxi C++, která ve standardních kompilátorech bez speciálního preprocesoru nefunguje

Toto byla perla! MOC není preprocessor, ale to ty určitě moc dobře víš Mimochodem můžeš ukázat tu upravenou syntax?

Jinak ano, mezi lidma taky nemluvím exaktně a uklouzne mi, že Qt je knihovna pro C++. Ale tys ho označil za šiřitele bludů, přitom měl pravdu v tom, že se používá nestandardní varianta jazyka.

A to je právě ten problém. Ty označuješ MOC za nějakou nestandardní variantu jazyka (dokonce preprocessor), přitom to co z toho leze si můžeš klidně napsat sám - ten nástroj jen slouží pro ulehčení této práce. Označení "upravená syntax jazyka C++" je taky zcela mimo, protože takovou syntax by asi C++ překladač těžko přeložil.

[Michal Kubeček]

Ty označuješ MOC za nějakou nestandardní variantu jazyka (dokonce preprocessor), přitom to co z toho leze si můžeš klidně napsat sám - ten nástroj jen slouží pro ulehčení této práce.

To, co jste napsal, platí i o jakémkoli jiném preprocesoru - třeba i o tom standardním céčkovém. Co je tedy podle vás moc, když ne preprocesor?

[__dark__]

Co je tedy podle vás moc, když ne preprocesor?

Já osobně bych MOC označil za generátor kódu, ale v žádném případě za preprocesor.

[mich]

In computer science, a preprocessor is a program that processes its input data to produce output that is used as input to another program.

viz wiki

Kterou část moc nesplňuje?

[__dark__]

The output is said to be a preprocessed form of the input data.

[Michal Kubeček]

Takže podle vás ani cpp není preprocesor?

[mich]

Tuhle větu moc nesplňuje? Nevím proč, ale když vám teda vadí, tak na české wiki není. Pořád nechápu proč není moc preprocessor.

[__dark__]

Ne, tuhle větu jsi necitoval.

[Ladicek]

Tuhle debatu už jsem tu před pár lety s pár lidmi vedl (a možná ne jednou) a nakonec jsem kapituloval s tím, že určitě existuje definice preprocesoru, které moc nevyhovuje, zatímco cpp ano (např. moc musí rozumět C++kové syntaxi, cpp ne. Podle toho rozdělení na české wikipedii je cpp lexikální preprocesor, zatímco moc syntaktický). Lhal bych, kdybych tvrdil, že není příjemné vidět historii, kterak se opakuje

[pavlix]

Zkus jít po etymologii slova.

[Ladicek]

Nó, jako jó, v čiré obecnosti lze 99 % počítačových programů označit za překladače, protože čtou nějaký vstup, provádějí nějaké transformace a zapisují nějaký výstup. A většina z nich budou zároveň preprocesory

[pavlix]

Nó, jako jó, v čiré obecnosti lze 99 % počítačových programů označit za překladače, protože čtou nějaký vstup, provádějí nějaké transformace a zapisují nějaký výstup. A většina z nich budou zároveň preprocesory

Ale uznej, že to už je obecnost v běžném světě nepraktická.

[__dark__]

Tu větu zapomněls citovat.

Problém mám v tom, že podle tvojí definice je preprocessor i třeba takový swig, což je _podle mě_ opět nesprávné. Takže bych se nejdřív zamyslel nad tím, jak funguje MOC, a co dělá třeba C-preprocessor. Jsou to úplně rozdílné věci, které bych vzhledem k tomu, že se bavíme o C++, označil rozdílným termínem.

Shrnuj bych to tak, že MOC můžu obecně označit za počítačový program, ale toto označení je na serveru jako abclinuxu příliš obecné, takže použiju přesnější definici. Označení preprocessor by sice mohlo projít, ale jiným termínem se dá jeho účel mnohem lépe vystihnout. Pokud i nadále chceš používat preprocessor, tak používej, pro mě je tento post finále.

[iwtu]

Mistrovstvi C++ je lahky nesmierne roztahany uvod do C++. Ta kniha nestoji za nic a ani zdaleka by sa nemala volat mistrovstvi. Cela kniha by sa uplne v pohode a rozumne dala vtesnat do 200 stran.

[Ivan]

Mozna, ze ani tva otazka nema smysl. Ja na to sel obracene, vybral jsem si projekt(y) do kterych hodlam prispivat. Tim ze jsem se pridal k najake skupine(technologii) jsem se zbavil prava volby programovaciho jazyka. Dneska uz je vsechen potrebny software napsany(neba alespon rozepsany) a neni moc duvodu/sanci zacinat jako osamely vlk na zelene louce.

[Kit]

Dneska uz je vsechen potrebny software napsany(neba alespon rozepsany) a neni moc duvodu/sanci zacinat jako osamely vlk na zelene louce.

Francouzská akademie kdysi chtěla zrušit patentový úřad s odůvodněním, že už vše bylo vynalezeno.

Obden si píši programy, které přede mnou nikdo nenapsal nebo je někdo napsal pro mne nevyhovujícím způsobem.

[Bystroushaak]

Obden si píši programy, které přede mnou nikdo nenapsal nebo je někdo napsal pro mne nevyhovujícím způsobem.

Jsem na tom podobně. Sice ne obden, ale není měsíc kdy bych nějaký ten script nenapsal (je teda fakt že většina z nich má nějaký význam jen pro mě).

[Kit]

Píši zejména krátké programy, obvykle na 1-50 řádek, delší spíš výjimečně. Zato je píši častěji - dnes jsem si napsal tři. Jazyk vybírám podle typu řešené problematiky tak, aby byl co nejjednodušší. Někdy zkombinuji i 3 jazyky, abych z každého z nich využil to, co umí nejlépe. Aplikace je pak vícevrstvá.

Abych alespoň trochu zůstal u původního dotazu: C++ nepoužívám. Už pohled na cizí zdrojáky mne vždy odradil, zejména jejich délka a komplikovanost.

[__dark__]

Tak pokud si zvyklý na programy o 50 řádcích, tak je jasné, že ti nebude vyhovovat pohled na komplexní knihovny/aplikace v C++.

[Kit]

Programy mají být krátké. Třeba jen proto, aby se daly snáze rozdělit na více vláken/procesorů. Raději místo 1000 řádků napíši těch 50, které dělají to samé.

[Michal Kubeček]

Fajn, budu se těšit na váš padesátiřádkový Firefox… :-)

Ale teď vážně: jsou věci (a není jich málo), které se dají napsat na 50 řádků. Ale stejně tak jsou věci (a těch je ještě víc), které na 50 řádků nenapíšete, ani kdybyste se na hlavu postavil. Vykřikovat dogmata typu "programy mají být krátké" je krátkozraké.

Mimochodem, mohl byste trochu rozvést úvahu

Programy mají být krátké. Třeba jen proto, aby se daly snáze rozdělit na více vláken/procesorů.

Nenapadá mne, jak souvisí délka programu s tím, jestli bude moci využívat více procesorů.

[__dark__]

Na to, abys mohl psát krátké programy, potřebuješ velké knihovny

[Josef Kufner]

Nikoliv programy, ale jejich logicky už nedělitelné komponenty mají být krátké. A v tvém případě jsou to programy o jedné takové komponentě.

Další nutnou podmínkou je, aby ty komponenty měly jasně definované API, neboť je nutné jich pohodlně spojovat.

[Kit]

Děkuji za přesné vyjádření mých mlhavých myšlenek. Samozřejmě vytvářím i programy složené z více nedělitelných komponent s definovaným API tak, abych je mohl pohodlně spojovat.

[skunkOS]

Tohle není univerzální pravda. Ano, třeba ve funkcionálním paradigmatu se skutečně velmi lpí na tom, aby procedury byly krátké, ale třeba zrovna u céčka je to podle mě jedno. Pokud mám funkci, která obstaravá velkou funkcionalitu, tak mě nezajímá, jak je dlouhá. Je to promě in-out box.

[Ash]

Jedná se o funkcionalitu, kterou nebude nikdy nikdo měnit, a není v ní žádná chyba?

[Josef Kufner]

Ale tady nikdo nemluví o procedurách ani funkcích.

[pavlix]

Tohle není univerzální pravda. Ano, třeba ve funkcionálním paradigmatu se skutečně velmi lpí na tom, aby procedury byly krátké, ale třeba zrovna u céčka je to podle mě jedno. Pokud mám funkci, která obstaravá velkou funkcionalitu, tak mě nezajímá, jak je dlouhá. Je to promě in-out box.

Neúměrně dlouhé funkce i v C většinou ukazují na hodně hodně špatný návrh aplikace.

[:::]

problem jsou slozity funkce ne dlouhy. Co je to slozita funkce je tezky definovat, ale obecne bych se dival spis na pocet odsazeni nez pocet radku. Kdyz treba potrebujes sequencne provest hodne jednoduchych operaci, tak je ok to udelat v jedny funkci protoze i kdyz bude dlouha tak nebude slozita...

[pavlix]

problem jsou slozity funkce ne dlouhy. Co je to slozita funkce je tezky definovat, ale obecne bych se dival spis na pocet odsazeni nez pocet radku. Kdyz treba potrebujes sequencne provest hodne jednoduchych operaci, tak je ok to udelat v jedny funkci protoze i kdyz bude dlouha tak nebude slozita...

Proto jsem použil slovo většinou.

[Ash]

Mně to přijde takové plácání, když mám program, který funguje sekvenčně, a jsem schopen ho napsat jednoduše, mám rezignovat na procedury a napsat ho celý v main? Jistě, technicky vzato možné to je...

[Josef Kufner]

Pokud máš progam, který má vykonat 15 kroků a každý ten krok vyjde na jeden odstavec kódu (cca 10-15 řádek), tak by rozdělení do funkcí akorát nadělalo bordel. V takovém případě jsou na místě výraznější komentáře na oddělení těch kroků od sebe. A pokud nějaký z kroků začne být příliš velký, tak je teprve na místě ho odsunout (nebo jeho část) do samostatné funkce.

[Ash]

Je potřeba se obezřetně pohybovat mezi dvěma extrémy - vše v main či jedné proceduře (varianta vědec pracant), a vše v procedurách které se navzájem volají a nikdo neví co vlastně dělají, a to i když se to snaží dohledat (varianta úředník).

Nevím co jsou výraznější komentáře, doufám že ne něco jako

/* !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!*/
///////////////// INICIALIZACE ZARIZENI ///////////////
/* !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!*/

bla bla

/* !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!*/
///////////////// NAHRAVANI DAT DO ZARIZENI ///////////
/* !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!*/

bla bla

to nesnáším :) od toho lze použít proceduru, která tu inicializaci udělá, druhou která načte ta data, a správně je obě pojmenovat, a popsat v dokumentaci :)

[podlesh]

problem jsou slozity funkce ne dlouhy. Co je to slozita funkce je tezky definovat, ale obecne bych se dival spis na pocet odsazeni nez pocet radku. Kdyz treba potrebujes sequencne provest hodne jednoduchych operaci, tak je ok to udelat v jedny funkci protoze i kdyz bude dlouha tak nebude slozita...

Užitečnou metrikou je počet větvení. Což v mnoha případech odpovídá tomu počtu odsazení, nicméně odsazení se dá zbavit různými triky: break, continue, goto (huh) nebo "fortranovsky" přes speciální proměnné (to je horor jen pro silné nervy).

[JS]

No, ona ta slozitost kolikrat vyplyva hlavne z reseni chybovych situaci. Asi nejsem moc dobry programator v C, ale ja se tedy dlouhym funkcim vyhybam jen obtizne.

Staci mit funkci ktera treba zpracovava data ze site a zaroven je nejak zapisuje do souboru, a uz mate pri kazdem volani te I/O operace podminku, zda skoncila v poradku. Nakonec jeste musite mit nejakou recovery logiku, kazdou tu chybu vypisujete minimalne do logu, takze to mate 50 radku a 5 vnorenych ifu jen to hvizdne. A to jsem jeste nezminil treba zamykani, nebo jakykoli malloc je treba osetrit - to s tou delkou take umi zamavat.

Nebo jiny priklad dlouhe funkce z praxe byl stavovy automat (primitivni sledovani nejakeho procesu - ~10 stavu, na kazdem muzete mit ~4 vstupni udalosti). Ten proste nezkratite, i kdybyste se rozkrajel.

Jasne, asi by se to dalo technicky rozdelit na mensi funkce, ale proc? Tezko ta mensi funkce bude pouzitelna jeste odjinud, a na ruzne jeji chybove stavy stejne budu muset reagovat ruzne. Malokdy je to totiz to co delate tak striktne oddelene. Uz jen kvuli tomu zpracovani chyb a logovani - z ruznych mist chcete na chybu reagovat ruzne, a proto byva zabaleni do mensi funkce jen obtizne pouzitelne. Tohle se da docela dobre (no, spis snesitelne) resit v jazycich, jako je Common Lisp, ale C.. Nevim. Rad bych videl nejaky vetsi program, ktery je napsan defenzivne a pritom ma i v C kratke funkce. Nebo aspon nejakou knizku o tom, jak to v praxi delat.

[Josef Kufner]

Zrovna treba malloc je rozumne obalit nejakou funkci, ktera to slusne zabije a pak uz nekontrolovat, zda se to povedlo. (Pro obvykle pouzivani.)

Logování chyb je taky dobré mít nějak zabalené v hezké funkci, aby se to používalo skoro jak komentáře.

Tím hodně ifů odpadne a znatelně se program zjednodužší.

[JS]

No, s tim mallocem je to otazka, zda chci skutecne pri nedostatku pameti vzdy srazit cely program (jde o server). Navic, pokud treba dela malloc nejaka moje knihovna, ktera je relativne nezavisla, pak si automaticky pouzivanim toho specialniho mallocu (ktery treba zna log, ktery pouziva dana aplikace) vytvaris dalsi zavislost na cele aplikaci.

Logovani obalene mam, slo mi spis o to, ze stejne tu funkci musis volat a osetrovat chybu, a tohle se obvykle uz nikam dal zabalit neda.

[Josef Kufner]

To obalování mallocu jsem měl na mysli v aplikaci, ne knihovně. V případě serveru by to pak asi znamenalo restartovat server, tedy pozavírat co jde, chvíli počkat a udělat exec sebe sama.

[JS]

Mozna ano, ale to by znamenalo dost velky zasah do kodu, a nevim, jestli na to mam cas a chut (zejmena resit ruzne vedlejsi efekty, jako treba ze nektere datove struktury jsou na zasobniku). To asi radsi nejak osetrim kazdy malloc zvlast. Stacilo mi predelat trochu ten system logovani, a i to bylo netrivialni.

[JS]

Jeste, ja to myslel trosku jinak s tou knihovnou. Mam treba knihovnu (nemusi byt velka, jeden soubor plus header), ktera vytvari nejakou datovou strukturu, muze byt i staticky slinkovana se zbytkem. Ta samozrejme potrebuje malloc. Kdyz tenhle malloc v te knihovne obalim, budu mit zpetnou zavislost te knihovny na aplikaci (napriklad kdybych ji chtel pouzit jinde, uz spoleham na to, ze tam jinde je malloc take obaleny). Kdyz ho neobalim, budu zase muset resit situace typu nedostatek pameti (pri volani funkci te knihovny). Takze, tezko rict, co je lepsi.

Na druhou stranu, abych nebyl jen kriticky, nepovazuji to za uplne spatny napad.

[pht]

Staci mit funkci ktera treba zpracovava data ze site a zaroven je nejak zapisuje do souboru, a uz mate pri kazdem volani te I/O operace podminku, zda skoncila v poradku. Nakonec jeste musite mit nejakou recovery logiku, kazdou tu chybu vypisujete minimalne do logu, takze to mate 50 radku a 5 vnorenych ifu jen to hvizdne. A to jsem jeste nezminil treba zamykani, nebo jakykoli malloc je treba osetrit - to s tou delkou take umi zamavat.

Na to jsou přece výjimky. Konkrétně na oddělení logiky a vyrovnání se s chybami. Když je v C nemáte, tak si je tam dodělejte. Nejprimitivnější metoda je např. "if cosi goto error", další možnost je longjmp, nebo nějaká vlastní implementace. A nebo se na psaní "robustných" programů v C vykašlete rovnou.

[JS]

Diky, ale pokud si mam vybrat, jestli tam budu mit vnorene ify nebo si to zaneradim goto nebo dokonce longjmp, tak si radeji vyberu ty ify (i kdyz je pravda, pokud uz je to neunosne, goto se hodi).

Ja bych se na psani robustnich programu v C vykaslal, ale bohuzel nejsem v Matrixu a realita neni vzdycky jen moje volba.

[pht]

Nemyslím že by goto zaneřádilo kód. Viz třeba zdroják kernelu, např. net/socket.c

Ja bych se na psani robustnich programu v C vykaslal, ale bohuzel nejsem v Matrixu a realita neni vzdycky jen moje volba.

Když nemáte volbu tak to spíš zní jako byste byl v Matrixu. :)

[podlesh]

No právě, to je opět problém metaprogramování - stejně jako u těch výjimek. C sice má preprocesor, ale zrovna v tomto případě moc praktický není.

[JS]

Nerekl bych, ze je to vzdycky jen o metaprogramovani. I kdyz to treba Common Lisp hodne usnadnuje (alespon v teorii, v praxi jsem to nezkousel), stale bude obsluha chyb tvorit velkou cast kodu a jeho slozitosti.

[Bystroushaak]

Příloha:

• cpp.jpg (122568 bytů)

Aw.

[----]

Já s tebou v podstatě souhlasím. C++ je z velké části opravdu HODNĚ ŠPATNĚ udělaný jazyk, se spoustou obskurních komponent hlavně v STL, defektivním metaprogramováním, defektivní encapsulation, otřesnou prací se streamy v STL, zneužíváním operator overloadingu v STL, komplikovanými non-POD typy, vyjímkami, na které se nelze spolehnout, otřesným RTTI, nahrazováním opravdovýho garbage collection smart pointery, duplikací spousty Cčkových funkcí ...

je to hlavně tím, jak se celý jazyk vyvíjel - postupně se na něj "nalepovaly" další a další komponenty, takže výsledek je takový "kočkopes" se spoustou nelogičností a featurami, na které člověk příjde až po několikaletých zkušenostech

Zmínil jsi se o D - také jej používám, ale ještě není moc připraveno na produkční použití, nicméně designově je daleko lepší (např. vektory nahrazeny pravými poli které můžeš snadno zvětšovat a de facto tak emulovat vektor z C++ ve 40 řádcích kódu, nebo hash pole, nebo slicing apod.)

Na druhou stranu - píšu herní engine - http://www.abclinuxu.cz/blog/enlightenment/2011/6/octaforge-novy-open-source-herni-engine - rozhodoval jsem se, jestli zkusit použít Dčko, ale nakonec jsem stejně použil C++ - proč?

Protože není nutné využít v C++ všechny komponenty. De facto se dá celé C++ použít jako "trochu lepší částečně objektové C" - tzn. využívat Cčkovou standardní knihovnu, Cčkový knihovny, Cčkovou syntaxi, Cčkové funkce, Cčkovou správu paměti, ale "vylepšit" si to některými užitečnými částmi C++ - to je třeba občas operator overloading (i když se hodně zneužívá), member metody struktur, konstruktory / destruktory, občas templates (i když ty se hodně zneužívají taky) a tak se dá napsat celkem pěkný "míchaný" kód, který je validním C++, ale nikoliv tím C++, které je v učebnicích a na netu - ale C++, které si nehraje na něco, čím není (high level jazyk) a je vcelku spolehlivé (nicméně si musíš např. paměť spravovat sám!)

A momentálně je C++ celkem dobře produkčně využitelný jazyk, ale jak říkám, musí se využít "jenom něco" - to, co je užitečné a tvůj kód to zefektivňuje / vylepšuje.

http://yosefk.com/c++fqa/ Toto je celkem dobrý čtení.

Osobně jsem v podstatě Cčkař a jak jsem psal, C++ zrovna moc nemusím, a ani nemusím knihovny jako Boost (který je např. podle mě hrozně zvrstvený a nečitelný, a zpomaluje compile-time, což je problém u velkých aplikací (ne vždy se hodí používat skoro jen compile-time konstrukce!))

Velký problém s C++ je komunita kolem něj - drží se tam věci jako "proper C++", "references are objects" apod. - a když přijde někdo pro radu (na IRC třeba), tak spousta lidí místo toho, aby poradili, začne s "Use new operator here instead of malloc, make this template, use smart pointers instead of raw pointers .......") - měli by si uvědomit, že nic jako "proper C++" neexistuje a že většina dostupného C kódu je zároveň validním C++.

No, to je asi celý můj "výkřik do tmy" Asi bude dost lidí nesouhlasit, ale tohle je můj pohled na věc ..

[----]

Heh, to jsem se ale rozepsal Sorry, pokud to bude někomu připadat dlouhý

[rADOn]

RTTI? Garbage collection? C++ kompilovaný jazyk a jeho návrh tomu odpovídá. A je v tomhle ohledu naopak velmi promyšlený (minus nějaké hnidy pro kompatibilitu s ANSI C). Nedívej se na to jako na primitivní vysokoúrovňový jazyk, ale jako na velmi chytrý assembler Jestli chceš Javu, víš kde ji najdeš.

[----]

Třeba to Dčko má garbage collector a taky je to kompilovaný jazyk A C++ není ani "velmi chytrý assembler" ani "primitivní nízkoúrovňový jazyk" .. C++ je pseudo-OOP low/mid level jazyk. A za tím co píšu výše si stojím

[:::]

garbage collector v C++? Boze chran...

C++ je navrzeny tak aby se v nem dalo psat vysokourovnove a pritom bylo stejne rychly jako C. Proto v nem nejdou delat nektery veci napr z pythonu nebo smalltalku... ale zase je efektivnejsi...

btw. STL je docela dobre navrzena, jenom to chce stravit trochu casu studiem pred tim nez to kompletne zavrhnes

[----]

STL není dobře navržená, např. iostream je naprosto otřesně navržený, to samý kontejnery (vector, map, unordered_map - podívej se, v co expanduje std::map<std::string, std::string> - hlavně na kompilátorech bez pořádný podpory typedefů chuťovka )

Porovnávat python a C++ je jak porovnávat hrušky s jabkama, ale porovnávat C++ a D smysl dává. Např. stringy v D jsou efektivnější - rychlejší, a přitom jsou to klasická pole znaků, stejně jako v Cčku - akorát operace s nimi jsou high-level, třeba slicing: string a = "hello world"; string b = a[6 .. $]" b je "world"

V C++ zůstávám u clib ..

[:::]

s tim iostreamem bych castecne souhlasil, ale STL kontejnery jsou navrzeny dobre...

a ty stringy to je spis filozoficka otazka. Ja si treba myslim ze v nizkourovnovym jazyce nemaji co delat a maji byt az v knihovne. A to i presto ze prace s knihovnou bude trochu min pohodlna nez specialni syntaxe...

[----]

není žádná speciální syntaxe, prostě se s tím pracuje stejně jako s poli.

int[] array = [ 5, 10, 15, 20 ];
int[string] hashmap = [ "foo":5, "bar":10 ];
hashmap["foobar"] = 156;
char[] mutable = "foo";
string immutable = "bar";
immutable(char)[] immutable = "this is the same as string"

int[] tenfifteen = array[1..2];
array.length += 1;

string sliced = immutable[8 .. 10]; // this is "the"

char[] str = "hello C++";
str[6 .. 8] = "D"; // it's "hello D" now

etc. etc. etc...... IMO mnohem pohodlnější a navíc i efektivnější než C++ stringy.

Navíc je plně ABI kompatibilní s Cčkem a obsahuje všechny jeho typy a má kromě vlastní knihovny i přístup do Clib; má garbage collector, a s pointery se pracuje stejně jako s normálními objekty ... apod apod.... vše je na oficiálních stránkách jazyka D.

Co se týče těch kontejnerů, v podstatě už jsem to řekl - myslím, že přístup jako v D je lepší - prostě udělat je jako builtin typy - pole a hashmapy. A string prostě jako pole znaků.

Ale na tomhle se asi nedohodnem, protože je to jiný přístup k věci.

[David Watzke]

Wow, to vypadá fakt dobře, někdy se na to budu muset mrknout.

[----]

btw, "Ja si treba myslim ze v nizkourovnovym jazyce nemaji co delat" .. nemá být C++ mid-až-high level? :P

[:::]

to je prave ta vyhoda c++, ze se v tom da programovat skoro high-level, ale ve skutecnisti je to low-level

btw. uvazoval jsem ze o D neco nastuduju, ale ty kontejnery primo v jazyce me docela odrazujou...

[----]

no, ale velká část C++ komunity se mi snaží vnutit jejich smart pointery a takový kraviny, a "usage of raw pointers is discouraged" .. :P

a kontejnery v jazyce si já právě myslím že jsou dobrá věc, ale jak jsem řekl, to je věc názoru. IMO v jazyce je to lépe integrovaný a líp se s tím dělá.

[pavlix]

Ony ty kontejnery v jazyce být nemusejí, ale hodně pomáhá, když je tam k nim aspoň relativně kompletní interface.

[pavlix]

a "usage of raw pointers is discouraged" .. :P

Přemýšlel jsi někdy nad tím, proč?

[----]

a ono je nějaké lepší / kompletnější / spolehlivější řešení? smart pointery ním nejsou. To si radši budu paměť spravovat sám.

[pavlix]

Jistě, lepší interface a implementace smart pointerů se hodí, ale neříkej mi, že ti nedocvaklo, proč doporučují alespoň ty smart pointery, co jsou, místo C pointerů.

[----]

Aby si programátor nemusel paměť sám uvolňovat. Nicméně ono to až takový problém není, stačí nebýt prase a kód si správně organizovat.

[:::]

souhlasim. Nevim kdo te navadel k smart pointerum, ale pravdepodobne to byli nejaci amateri... Smart pointery se sice obcas hodi ale urcite bych je nepouzival vsude misto obycejnych pointeru...

[----]

Většina ##C++ kanálu na Freenode :P Říkají že 1) nemanipulovat přímo s pamětí (tzn. pointery, {m,c,re}alloc, free, memcpy, ...) 2) nepoužívat věci z libc. Taky říkají, že "Cčkovitý C++ není 'proper C++' a C++ se tak psát nemá", ale IMO to je taky blbost.

[rADOn]

nemanipulovat přímo s pamětí (tzn. pointery, {m,c,re}alloc, free, memcpy

Na klasické přaci s pamětí nic špatného není (když to umíš ale nedá se (spolehlivě) kombinovat se zabudovanými operátory. Tím se připravuješ o spoustu práce kterou může kompiler udělat za tebe. V konferách a kanálech se na lidi kteří si zbytečně přidělávají práci dívají celkem pochopitelně svrchu.

nepoužívat věci z libc

Stejný případ – libc je OK, ale může mít vedlejší efekty. C++ varianty jsou ošetřené. Většinou to nevadí, ale když už, stojí to za to a velice těžko se taková chyba hledá. Někdy to dělám, ale na vlastní riziko… Záleží i na překladači a platformě, je celkem pochopitelné že lidi na irc nemají čas u každé libc funkce zkoumat, jestli zrovna tvoje kombinace je košer.

Taky říkají, že "Cčkovitý C++ není 'proper C++' a C++ se tak psát nemá", ale IMO to je taky blbost.

To je normální, že každý kdo se naučí programovat si ze všeho nejdřív vypěstuje názor, že všichni ostatní jsou blbci. Že to na co jsi si zvyknul v posledních pěti letech je důležitější než zkušenosti ostatních z předchozích padesáti let. Neboj, to časem přejde. Ani se nenaděješ a budeš sekat smartpointery a alokátory raz dva

[Sten]

Což se ale může stát dost složité, když budete chtít řešit i výjimky (a není nic horšího než užitečná knihovna, která při výjimkých leakuje). Chytré pointery (ať už počítací nebo jednoduché á la boost::scoped_ptr), přesněji dodržování RAII jsou v C++ daleko vhodnější.

[----]

řešením je nepoužívat exceptions :P Osobně kompiluju jen s -fno-exceptions -fno-rtti (pokud někdy není potřeba dynamic_cast)

[pht]

Jo to je opravdu chytré řešení, ale myslím že mám lepší: nepoužívat počítač.

[----]

Nevidím žádný racionální důvod proč; Ono používat exceptions není žádná výhra.

http://yosefk.com/c++fqa/exceptions.html

a rtti je lepší se vyvarovat.

[Michal Kubeček]

Autor toho "FQA" jen názorně demonstruje, že takhle dokážete strhat naprosto cokoli, když k tomu budete přistupovat s předem pevně zakořeněným přesvědčením, že je to celé úplně špatně, budete důsledně ignorovat všechna pozitiva a nafouknete negativa (a v případě nouze si nějaká i vymyslíte).

[Sten]

Samozřejmě můžete v C++ psát C with Classes (včetně něčeho jako errno), ale výjimky i RTTI jsou velmi silné nástroje, pokud víte, jak je použít (což autor toho FAQ zřejmě netuší) Jinak standardní výjimky v C++ jsou na některé věci až příliš jednoduché, já osobně preferuji výjimky založené na Boost.Exception.

[----]

Ano, "C with classes" - jediný způsob, jakým používám C++. Pokud chci opravdový high level jazyk, použiju např. to Dčko a ne jazyk, který se k tomu nehodí.

[Sten]

Aha, takže kvůli tomu, že někdo neumí používat výjimky, je řešením celý koncept výjimek zahodit?

[----]

Nikdo nemluvil o konceptu, ale o konkrétním řešení v jazyce C++.

[Sten]

Konkrérní řešení v C++ je přesně v tendencích C++: udělat to co nejjednodušší a pokud chcete od toho něco víc, tak si to napište. Není moc složité napsat si vlastní výjimky, které uloží celý stack frame. Nebo které jenom uloží umístění. Ale každá tahle operace stojí docela dost výkonu a tak C++ tohle neřeší, je jenom vaše věc, jestli to tak chcete (a obětujete výkon) nebo ne (a obětujete snadné debugování).

[Michal Kubeček]

STL není dobře navržená, např. iostream je naprosto otřesně navržený

Jen pro pořádek: iostream není součástí STL, to je jen takové matení pojmů ze strany lidí, kteří používají zkratku STL pro celou standardní C++ knihovnu.

[----]

nojo, hnidopichu :P jasně, měl by se používat pojem stdlib, ale myslím, že každý ví, co pod "STL" myslím.

[Ash]

Přiznávám, že jsem se také mylně domníval, že tím STL myslíte STL :)

[----]

a ne, javu opravdu nechci - preferuju C.

[Bystroushaak]

Díky za názor. V podstatě jsem se rozhodl podobně - používat D a občas když to bude vhodné/nutné tak C++ ve stejném módu jako jsi psal ty (C s OOP).

[----]

No, s D já jen experimentuju, protože ještě zdaleka není připraveno na produkční využití - hlavně D2 (i když některé implementace - gdc2 - fungují už celkem dobře) .. používám hlavně C a C++.

[dejvik]

Dá se ten gdc2 někde rozumně sehnat? Třeba balíček pro Ubuntu. Chtěl jsem rozjet D2 s Tango (ne přes proprietární DMD), ale našel jsem jen nějaký napůl mrtvý repozitář gdc bez návodu, jak to rozjet.

[Bystroushaak]

Budu s tím muset zaexperimentovat, už se mě na to ptalo víc lidí, píšu si to do TODO.

BTW: DMD je proprietární jen z části (jádro). Osobně mi přijde víc fajn než gdc (co se týče vlastností), protože je mi jeho licence totálně ukradená tak dlouho, dokud mě neobtěžuje.

PS: Teď jsem nakoukl na stránky projektu, které se tváří jako že tam plná podpora je: https://bitbucket.org/goshawk/gdc/wiki/Home. Problém bude spíš s tangem, které nepoužívám, a naposledy když jsem o něm slyšel tak jsem se dočetl že D2 nepodporuje.

[dejvik]

Ta stránka projektu vypadá dobře. Už jen balíček:)

Proč vlastně řeším to Tango: myslel jsem, že std.algorithm chybí ve Phobos. Nainstaloval jsem dmd, který by měl mít Phobos a std.algorithm mu nechybí. Mám v tom trochu chaos.
Zkusil jsem ještě gdc (Ubuntu 11.04). To std.algorithm nenajde. Asi to podporuje jen D1.

Na druhou stranu Phobos narozdíl od Tango nemá veselé IO, jako v C++:

Cout("Hello")(" ")("World").newline;

Wiki: DMD — The Digital Mars D compiler is the official D compiler by Walter Bright. The compiler front-end is licensed under both the Artistic License and the GNU GPL; the source code for the front-end is distributed with the compiler binaries. The compiler back-end source code is available but not under an open source license. It implements 1.0 and 2.0 versions.

Tak to vypadá, že ti možná zdroják ukáží, když začneš své programy prodávat. Ale kdo ví, jestli Walter Bright není zlý a nedal tam backdoor:)

[Bystroushaak]

Zkusil jsem ještě gdc (Ubuntu 11.04). To std.algorithm nenajde. Asi to podporuje jen D1.

Jj, v Ubuntu jsou balíčky jen na D1. Co jsem tak četl, D2 se z toho dá udělat nakopírováním něčeho někam.

Nedávno se někde v konferenci někdo ptal kdy tam budou D2 balíky a dostalo se mu odpovědi, že poté co bude D2 stable, takže tak.

Jinak Tango má docela pěkné API pro práci s netem, to phobosu chybí. Já to vyřešil tak, že jsem si napsal vlastní modul pro práci s HTTP (uznávám, ne zrovna dokonalý) a teď mám rozepsaný HTML parser (něco podobného BeautifulSoup z pythonu). Další věc je, že phobos se stále vyvíjí, v 2.053 třeba přibyl kus API pro práci s emailovou adresou atp..