Největší změny v C++0x (diskuse)

[stativ]

Jak já se na šiší podporu C++ 2011 těším. Je to mnohem lepší jazyk, než současná verze C++.

[Miloslav Ponkrác]

A přitom stále zpětně kompatibilní se současným jazykem C++.

C++ nešel cestou Pythonu či Perlu, že vše změní už jen pro ten pocit, že to překopal.

Osobně si myslím, že nejlepší cesta by v budoucnu byla sjednocení jazyků C a C++ do jednoho jazyka.

[----]

Kdyby se to stalo, to už bych fakt kompletně přešel k D.

[Miloslav Ponkrác]

To můžete i dnes.

I když si myslím, že D nakonec umře.

Ostatně, stejně se pořád zvyšuje podíl C++. U velkých projektů dříve, nebo později zjistíte, že v C už je to neudržitelné.

Osobně není jediná objektivní výhoda C vůči C++ – zatím mi nikdo takovou nedokázal vyjmenovat. Pokud mám k dispozici na dané platformě jak C tak i C++ kompilátor – není jediný důvod, proč něco psát v C.

Výhrady C programátorů, kteří se rekrutují spíše podle stylu „co vzniklo v unixu je dobré, i když je to sračka“ – postupně historicky zmizí.

Navíc C++ je jednotné. C už stihl třetí normu a připravuje čtvrtou – a žádný zázrak to stále není. Přičemž stále existují platformy, kde je k dispozici jen první verze – proto třeba vim autor píše v K&R C.

Za takových 20 let tak jako tak C stejně de facto zanikne. Oproti C nemá žádnou výhodu, vývoj v C je chybovější, pomalejší a dražší, než v C++ aniž by nabídlo cokoli jako plus. Jen mínusy. Buďto se bude výhradně používat většinově C++, nebo se C a C++ sloučí. Je to jen otázkou času, kdy skalní Céčkaři vymřou, či zestárnou.

[Michal Kubeček]

Čím více a čím agresivněji se nějakému projektu předpovídá brzký zánik, tím déle obvykle přežije. Předpovídat zánik jazyku, který se pro účely systémového programování používá už 40 let a který po tu dobu své pozice (v této oblasti) stále posiluje, je poněkud odvážné…

To, že tu někteří prezentují emocionální a argumentačně prázdné výpady proti C++, neznamená automaticky, že musíte reagovat stejným způsobem.

[Miloslav Ponkrác]

„Čím více a čím agresivněji se nějakému projektu předpovídá brzký zánik, tím déle obvykle přežije. Předpovídat zánik jazyku, který se pro účely systémového programování používá už 40 let a který po tu dobu své pozice (v této oblasti) stále posiluje, je poněkud odvážné…“

Mimochodem, já tu i na abclinuxu předpovídal růst či pád různým technologiím i firmám. Roky nazpět je to tu jako důkaz v diskusích. Zatím jsem se ani jednou nespletl a nemám za sebou jediný omyl. Pohybuji se v IT už skoro 30 let a viděl jsem leccos. Pády nadějných technologií, stejně jako růst outsiderových. A viděl jsem i ty příčiny a celý děj.

C rozhodně neposiluje.

V poslední době čím dál více projektů z C přechází alespoň částečně na C++. Před časem to udělalo třeba i gcc.

Ono de facto neexistuje C a C++, naprostá většina kompilátorů umí obojí, protože C je de facto velmi malou podmnožinou C++. Pokud dnes někdo udělá kompilátor, tak ho většinou nedělá jen pro C, ale umí skoro vždy oba jazyky.

De facto C a C++ nejsou dva jazyky, ale jen ottéž na různém stupni vývoje. De facto existuje jen jeden jazyk – C/C++.

Používání C postupně zaniká. Ten proces v minulosti nebyl, protože C++ je relativně mladé. Norma C++ přišla až v roce 1989, dalších několik let trvalo, než přišly kompilátory vyhovující normě. Následně se roky hledalo, jak efektivně implementovat v C++ výjimky – tedy natolik efektivně, aby rychlostí byl kód používající výjimky stejně rychlý jako ošetřování chyb jiným způsobem, což se nakonec podařilo. A pak byl rok někde kolem 1996 a C++ začínal startovat ve svém rozšíření. Zhruba až kolem roku 2000 si mnoho programátorů všimlo, že je to báječný jazyk pro úlohy, kde se dříve používalo C a dá se na něj rychle přejít.

C++ dostalo do vínku začít jako extenze C. Takže C je jen dialektem maličké podmnožiny jazyka C++. Je zbytečné aby existovalo více dialektů téhož jazyka. Stejně jako mezi K&R dialektem a ANSI normou C postupně získalo vedení to druhé, pak současné C a C++ jsou jen dialekty a C++ začíná získávat pomalu vrch.

Bohatě stačí, když někdo vezme velký projekt v C a překlopí ho do C++. Takový člověk po praktické ukázce už nikdy C upřednostňovat nebude – zejména pokud se předtím trápil s pokusy udržet velký projekt v C.

„To, že tu někteří prezentují emocionální a argumentačně prázdné výpady proti C++, neznamená automaticky, že musíte reagovat stejným způsobem.“

To je pravda.

[Michal Kubeček]

Obávám se, že asi každý žijeme v jiné realitě.

[Miloslav Ponkrác]

To zcela určitě.

Jsme toho názoru, že přežije Cobol, Fortran, i další.

Stejně tak jako přežije C, ale jeho používání bude klesat v prospěch C++.

Když jsem začínal s C a dělal v něm řadu let a pak vznikl jazyk C++ a já ho vyzkoušel – už nikdy jsem v C nechtěl dělat. To se bavím o době tak 20 a více let zpátky.

Přitom jsem všechny své C moduly nemusel měnit, prostě jen je přeložit C++ kompilátorem a pokračoval v C++.

C se drží hlavně z historické perspektivy. Jsou v tom prostě nějaké projekty z minula. Ale nikdo soudný dnes nebude začínat velký projekt v C – byl by blázen a nic by nezískal.

C a C++ nejsou de facto jiné jazyky. C++ přebírá celý jazyk C jako svou součást (kromě pár drobností). Tudíž přechod je naprosto minimální problém. Zato efektivita vývoje v C++ je o řád výše.

Nevím jak Vy, ale já růst používání C nepozoruji.

Naopak pozoruji, že se vyčistily věci. C a C++ přišlo o projekty, které nepotřebovaly rychlost a tyto projekty se píší třeba v Javě, Pythonu, či řadou dalších jazyků. Ve zbylých případech si to dělí v zásadě C a C++ a tím, že projekty začínají, nebo přecházejí na C++.

Proto jsem psal, že stejně logicky splyne C a C++ v jedno. A pokud ne, C++ to postupně převálcuje. Není důvod držet dva dialekty od stejné věci.

[kralyk z abclinuxu]

Cool story, bro...

[Miloslav Ponkrác]

Taky se loučím, stejně jako končím s příspěvky do této debaty.

[pavlix]

Už zase?

[petris_]

protože C je de facto velmi malou podmnožinou C++

Toto neni pravda, pomerne dost v praxi pouzivanych konstrukci z C nen soucasti C++. Prikladem budiz variadicka makra, otevrena pole a pokrocile literaly. Navic nektere konstrukce znamenaji v obou jazycich neco jineho.

[----]

C++ je relikt z doby, kdy kompilátory byly ještě v plenkách a programátoři potřebovali něco jednoduššího než C; nicméně postupně se to zvrhlo a dnes je C++ polovičaté rádoby high level řešení s otřesnou stále se nabalující standardní knihovnou a rostoucí tendencí přesouvat funkce z jazyka do knihovny a často duplikovat existující funkční C řešení (často i horší, např. streamy). Oproti tomu D nevypadá, že by mělo kdykoliv v blízké budoucnosti umřít a jeho použití roste; oproti C++ je daleko lépe navržený. Navíc předpovídat mu smrt, když finální specifikace verze 2 ještě ani není hotová - no comment.S C++ dělám, ale jen jako "C with classes" protože jinak je ten jazyk pro mě naprosto nepoužitelný.

[kralyk z abclinuxu]

Haters gonna hate.

[Miloslav Ponkrác]

„C++ je relikt z doby, kdy kompilátory byly ještě v plenkách“

Kdy prosím Vás byly kompilátory v plenkách?

---

„a programátoři potřebovali něco jednoduššího než C“

Jeden programátor potřeboval něco stejně rychlé jako C, jen na vyšší úrovni. A líbil se mu koncept Simuly, ale nelíbila její pomalost. Mimochodem, za svých studií jsem se se Simulou setkal také – je to úžasný a inspirující jazyk.

---

„rostoucí tendencí přesouvat funkce z jazyka do knihovny a často duplikovat existující funkční C řešení“

Což je zcela v pořádku. Existující C řešení je provedeno low level ve formě vhodné pro neobjektový jazyk strojové úrovně.

Je třeba vybudovat knihovnu využívající možnosti jazyka C++, což C funkce nejsou.

---

„Oproti tomu D nevypadá, že by mělo kdykoliv v blízké budoucnosti umřít a jeho použití roste; oproti C++ je daleko lépe navržený.“

Jazyk D pravděpodobně bude jen krátkodobý.

Koukejte, když Stroustrup koncipoval C++, dobře věděl, že kompatibilita s C a snadný přechod z C je naprostou nutností pro jeho rozšíření. C++ proto umí využívat C moduly na úrovni zkompilovaých modulů a přistupovat k nim.

Jazyk D ovšem s C++ kompatibilní není. Aby mohl C++ nahradit, musel by mít nástroj, který by dokázal využít C++ moduly a snadno přejít. To je nutnost.

Bohužel jazyk D nemá některé featury C++ a chybí mu nástroj pro automatickou konverzi C++ modulů do D.

Z druhé strany, jazyk C++ bude existovat do té doby, dokud se nenajde vhodnější nástroj na niku, kde je králem. Jazyk D do ní příliš nezasahuje, ale spíše konkuruje vysokoúrovňovým funkcionálním jazykům, kde je D horším řešením oproti těmto jazykům.

D také zrušil objektové pojetí C++ a dědičný styl přejal z Javy a funkcionálních jazyků.

Sám jsem pečlivě studoval před lety manuál k D s tím, zda to bude lepší jazyk, než C++, ale neměl jsem ten pocit.

Základní problém je, že C++ bylo navrženo pro řešení praktických úkolů. D je prostě navrženo aby se líbilo autorovi a byl „čistým jazykem“. A podle mých zkušeností jazyky navržené jako čisté a hlavně proto to prohrávají s časem.

Něměl jsem pocit, že D řeší něco lépe, než řada existujících jazyků. Pokud budu potřebovat efektivitu a rychlost kódu, C++ poslouží lépe – kompilátory jsou optimalizovanější, než vše, co nabídne D. Featury C++ umožňují lépe optimalizovat a cílit. Když nebudu potřebovat rychlost a efektivitu kódu, pak nesáhnu ani po C++ ani po D, ale po vhodnějším vyšším jazyku.

„Navíc předpovídat mu smrt, když finální specifikace verze 2 ještě ani není hotová - no comment.“

Já mu nepředpovídám smrt, jen nezájem a zapomnění.

„S C++ dělám, ale jen jako "C with classes" protože jinak je ten jazyk pro mě naprosto nepoužitelný.“

C++ jako C s třídami neukáže ani 1% jeho efektivity. Ten jazyk umí daleko více.

[Michal Kubeček]

Co máte proti elementu blockquote?

[Miloslav Ponkrác]

Jenom to, že když použiji jakýkoli element, musím pak nabouchat milióny dalších. Například poctivě označit odstavce elementem p – tudíž použitím jednoho elementu musím oelementovat všechno. Lenost vítězí.

[pavlix]

Jenom to, že když použiji jakýkoli element, musím pak nabouchat milióny dalších. Například poctivě označit odstavce elementem p – tudíž použitím jednoho elementu musím oelementovat všechno.

Nojo, v předpovídání budoucnosti jste ještě neměl jediný omyl... ale blockquote používat neumíte a místo toho plácáte něco o odstavcích, než abyste to úplně normálně vyzkoušel a zjistil, že to co píšete, je nesmysl.

[----]

"Jazyk D ovšem s C++ kompatibilní není. Aby mohl C++ nahradit, musel by mít nástroj, který by dokázal využít C++ moduly a snadno přejít. To je nutnost. "

není vůbec potřeba konvertovat existující projekty, ale zajistit ABI kompatibilitu, což D má.

"Bohužel jazyk D nemá některé featury C++"

které?

"D také zrušil objektové pojetí C++ a dědičný styl přejal z Javy a funkcionálních jazyků."

to je naprosto v pořádku a správný krok.

"Základní problém je, že C++ bylo navrženo pro řešení praktických úkolů."

od kdy? Právě D je navrženo k praktickému použití, oproti C++, a proto netrpí některými mouchami C++ (píšu pro ábíčko seriál o D, vše bude popsáno)

"Něměl jsem pocit, že D řeší něco lépe, než řada existujících jazyků."

rozhodně lépe než C++, což je jeho cílem.

"C++ jako C s třídami neukáže ani 1% jeho efektivity."

možná ještě metaprogramming a operator overloading se občas hodí, ale stdlib, encapsulation, exceptions a spousta věcí z nové 0x specifikace je naprosto otřesných.

[Miloslav Ponkrác]

„není vůbec potřeba konvertovat existující projekty, ale zajistit ABI kompatibilitu, což D má.“

Nemá. Musíte jí tvrdě naprogramovat – bavíme se o kompatibilitě s C++.

---

„to je naprosto v pořádku a správný krok“

Pak ale je lépe použít přímo tu Javu, ze které to bylo opsáno. Nebo funcionální jazyk s mixins, jako třeba Ruby.

---

„od kdy? Právě D je navrženo k praktickému použití, oproti C++, a proto netrpí některými mouchami C++“

Při čtení dokumentace D jsem získal pocit, že na praxi se zapomnělo. Že jazyk D je navržen jako soubor nesplněných přání autora kompilátoru. Nicméně je to další jazyk v řadě, kde předností byla teoretická čistota před praktičností. Autor se tím ani nijak zvlášť netají. A na jazyce je to znát.

---

„rozhodně lépe než C++, což je jeho cílem“

Nemám ten pocit. Ačkoli dokážu měnit jazyky jako ponožky, po seznámení se s D jsem velmi rád zůstal u C++ a D dále nerealizoval.

Nicméně bavíme se teď na úrovni subjektivních pocitů.

---

„možná ještě metaprogramming a operator overloading se občas hodí, ale stdlib, encapsulation, exceptions a spousta věcí z nové 0x specifikace je naprosto otřesných“

Pokud nesnášíte C++, pak vám prostě ten jazyk bude otřesný. Více to nemá smysl rozebírat.

[----]

vezměme v potaz třeba tohle: http://ideone.com/sdPBZ Tento malý test dokazuje, že encapsulation v C++ je defektivní, protože to lze naprosto snadno obejít (díky tomu, že class v C++ je stále obyčejná struktura ve které lze použít offset)

nebo iostream - co je lepší?

std::cout << foo << " bah " << meh << " blah " << std::endl;

které je naprosto nepoužitelné při i18n/l10n, je delší a vypadá hnusně

nebo

printf("%i bah %f blah\n", foo, meh);

který je naprosto bez problému?

Argument "type safety" jsou kecy, buď je kód správně nebo blbě a to, že si někdo neumí správně ověřit parametry není můj problém.

V porovnání s D:

co je lepší?

string a = "hello world";

string b = a.substr(0, 5); // hello

nebo

char[] a = "hello world".dup;

char[] b = a[0 .. 5]; // hello

co je lepší?

std::map<string, int> mymap;

mymap.insert(std::pair<string, int>("foo", 5));

nebo

int[string] harr;

harr["foo"] = 5;

?

takhle by se dalo pokračovat do nekonečna..

[Michal Kubeček]

U prvního příkladu jste taktně zamlčel, že zatímco C++ streamy a operátor << můžete rozšířit na libovolnou třídu, u printf() to nejde (o dalších lahůdkách jako např. automatické překódování škoda ztrácet řeč). U druhého příkladu mi ten rozdíl nepřipadá tak velký, aby to byl nějak relevantní argument. Třetí příklad je podvod, protože i v C++ můžete napsat mymap["foo"] = 5.

[----]

ono stačí si pro svou třídu napsat metodu, která vyplivne výstup pro printf .. a zůstane i funkční i18n

[:::]

vezměme v potaz třeba tohle: http://ideone.com/sdPBZ Tento malý test dokazuje, že encapsulation v C++ je defektivní, protože to lze naprosto snadno obejít (díky tomu, že class v C++ je stále obyčejná struktura ve které lze použít offset)

tohle je ukazka naprosto pokrivenyho mysleni. Encapsulation by melo chranit proti chybam a spatnymu pouziti, ne proti lidem. To ze kdyz se nekdo bude umyslne snazit to porusit tak se mu to povede je spis vyhoda...

[kralyk z abclinuxu]

+1

[----]

to je skoro stejně zvrhlá myšlenka jako type safety.

[andree]

vtipny ten priklad... to autor cakal ze dostane segfault, ci co? alebo ze kompiler zrandomizuje pamat a/alebo rozhadze objekt cez cely heap?

celkom by som sa pobavil, keby nastavil tu class na static, a kompilator mu vypisal 5, 10, 15... ako dlho by sa chytal za hlavu, co sa deje.. :)

[----]

no comment .. "kdyby" a předpovídání - klasický argument C++ fanboys.

[kralyk z abclinuxu]

Až na to, že předřečník má naprosto pravdu.
Opravdu mi není jasný, čemu se divíš na tom, že na classes funguje offset.

[----]

ale já se tomu přece nedivím Class je přece furt jenom struct.

[andree]

tak to si objavil ameriku, gratulace! .-)

[dejvik]

píšu pro ábíčko seriál o D, vše bude popsáno

Skvělé! Už se těším:) Doufám, že to bude spíše o D2.

[----]

ano, je o D2 D1 se už vůbec nezabývám.. a samozřejmě s knihovnou Phobos.

[Aminux]

Neni to ta dálnice. Jinak syntax c++ mi příde jako docela humáč. Jen můj osobní dojem.

[----]

ona je humáč .. není to jen osobní dojem.

[kralyk z abclinuxu]

Že tě baví D ti neberu (mně se ten jazyk taky celkom zamlouvá), ale musíš tu furt trollovat C++? Tak když se ti to nelíbí tak to nepoužívej a nelez sem.

[----]

to jsi mě asi trochu nepochopil Já C++ netrolluju, já kritizuju jeho mouchy, sám C++ používám pro svůj projekt a ono se dá použít, ale jen jako "C with classes" .. ony ty "špatné" části jsou většinou jen volitelné, takže se dají "nepoužít" a C++ může být decentním jazykem..

[kralyk z abclinuxu]

No, tak jsem kouknul na github na octaforge, no a to je dost neuvěřitelné Teda takhle, nechápej mě špatně, ten projekt celkem obdivuju, asi bych to neuměl napsat nebo se k tomu minimálně nedokopal, ale teda ten kód, to je docela humus To už by asi bylo lepší to čistý C.

A mimochodem co takhle boost, proti tomu taky něco máš, předpokládám...?

[----]

většina kódu není moje :) resp. moje není src/engine, src/fpsgame, src/intensity a postupně ty části přepisuju. Btw, po odstranění Boostu se 2x zkrátila kompilační doba a po odstranění Boost.Python dvakrát narostly FPS (díky odstranění Python actionqueue)

[kralyk z abclinuxu]

Jo aha, tak já koukal do src/engine...
No tak že boost zpomaluje kompilaci a python fps, to je celkem jasné

[----]

mimochodem, i když se ti Cube 2 kód může zdát trochu takový zabordelený bez nějaký struktury, tak je oproti tomu velice efektivní a malý - je menší než většina ostatních enginů bez nějakých funkčních omezení.

[----]

jojo, uznávám že některý části Cube 2 jsou dost humus, jako třeba některý makra: https://github.com/quaker66/OF-Engine/blob/master/src/engine/octaedit.cpp#L1141

[kralyk z abclinuxu]

Ale tak což o to, konkrétní podrobnosti v kódu jsem nezkoumal, spíš ta celková struktura kódu. C++ to rozhodně není, a ani "C with classes". Spíš "C with namespaces and constructors" A proč máš takovýho kódu v hlavičkovejch souborech? Přijde mi, že tam prakticky nerozlišuješ mezi .h a .cpp.

[Bystroushaak]

píšu pro ábíčko seriál o D, vše bude popsáno

Wow, super :)

[jas]

A preto napr. toto ide v c++0x stale skompilovat, ze?

int main(){ auto int x = 5; return x; }

Videli ste vobec tie zmeny v pythone? Zmeny su aspon navonok relativne male a aspon velka cast z nich svoj vyznam urcite ma.

Navyse s trochou snahy sa da pisat kod pre obe verzie pythonu.

[pavlix]

C++ nešel cestou Pythonu či Perlu, že vše změní už jen pro ten pocit, že to překopal.

Python naštěstí tou cestou šel, měl hodně restů, které nešly v 2.x verzi opravit.

Osobně si myslím, že nejlepší cesta by v budoucnu byla sjednocení jazyků C a C++ do jednoho jazyka.

Apage satanas. Naštěstí nám ale céčko zůstane :).

[Josef Kufner]

Hmm... ta syntaxe je pěkně ošklivá. Trošku mi to připomíná hovniválovu kuličku.

[----]

ale vždyť to je C++ .. furt se na to nabalují nový věci i když to, co leží pod tím, stojí za h*vno, a kvůli tomu i ty nabalovaný věci jsou udělaný hnusně/polovičatě..

[Šangala]

Furt jen nevím jak si poradit s nullptr, když konečně existuje a nemusí se myslet na možné problémy spojené s NULL, protože je až v GCC 4.6 (používám 4.4), tak jak si to nachystat, udělat si vlastní NULL jako #define MyNULL NULL a v budoucnu to pak jen přehodit #define MyNULL nullptr a třeba si podivit co se stane .

[Miloslav Ponkrác]

#undef NULL #define NULL nullptr

Ale i ve starém C++ šlo udělat

template<T> T* null_ptr() { return reinterpet_cast<T*>(0); }

což se používá trochu hůře, ale je to navíc i typově bezpečné.

[Šangala]

#undef NULL #define NULL nullptr - to mi přijde docela silné, raději bych nullptr viděl jen tam kde se s tím počítalo.
template<T*> T* null_ptr() { return reinterpet_cast<T*>(0); }, to už je dál než jsem ochoten zajít .

[zeno]

Take nepodarene lambda expressions som este nevidel.

[Miloslav Ponkrác]

Mě na tom nepřijde nic nepodařeného.

Možná by bylo dobré si uvědomit, co je C++. Je to jazyk, jehož přední úlohou je zajistit rychlost + efektivitu výsledné binárky a rozsah možností programátora srovnatelné (tedy co nejvíce blízké) s přímým psaním ve strojovém kódu. Za současné vysoké efektivity psaní kódu a high level jazyka.

Druhá věc je, že C++ – stejně jako všechny stálice v programovacích jazycích – nesleví ani čárku ve zpětné kompatibilitě s předchozí verzí. Pokud by se měla porušit zpětná kompatibilita – bylo by třeba pro to velmi vážného důvodu a vysvětlení a toto porušení by muselo vynést tak obrovský benefit, aby vůbec prošlo, že je to na hranici nemožnosti.

Nakonec stejně většina vyšších jazyků je implementována pomocí C/C++, kde C je spíše historický sekundand z doby, kdy C++ nemělo standard. Stejně tak všechny virtuální mašiny pro běh virtuálního kódu se také skoro bez výjimky implementují v C++.

Když nějaký vyšší jazyk nestačí svými možnostmi – ať už rychlostně, nebo proto, že v daném vyšším jazyce není vůbec možné danou funkcionalitu implementovat – zase se to napíše v C/C++. Většina vyšších jazyků stejně z 99% není nic jiného, než kompilovaný kód C/C++ a kolem toho něco málo lepidla z kódu vyššího jazyka – asi maximálně je to vidět u Pythonu.

[Josef Kufner]

To však nemění nic na tom, že ten zápis je děsně ošklivej.

[Miloslav Ponkrác]

Jako subjektivní vnímání pro Vás. Když už nemůžete proti tomu nic věcného říci, začnete si pomáhat dojmy.

[Josef Kufner]

Já proti tomu neřekl nic než to, že je ta syntaxe děsně ošklivá. Jinak lambda samotná se mi líbí a považuju ji za jednu z nejužitečnějších konstrukcí vůbec. Ale tahle v C++ je ošklivá.

[:::]

sam ses osklivej...

[----]

ale on má pravdu.

[:::]

ne nema

[----]

ale jo, má

[belisarivs]

Ja myslim, ze vsichni maji pravdu. Teda krome me. Takze zapomente, ze jsem neco rekl.

[grubber]

Domnívám se, že v této diskuzi publikuje největší množství subjektivních dojmů plných rádobyvěcné onanie nad svým oblíbeným jazykem někdo zcela jiný.

[mnn]

Neviem si pomôcť, ale čo sa týka lambda expressions, tak syntakticky je na tom lepšie C# 3.0, napriek tomu, že je od MS...

[Freeman]

Rozumím tomu opravdu dobře, že v C++0x budu muset přizpůsobit názvy metod třídy abych ji mohl pohodlně iterovat? Tedy, budou to muset být begin() a end()?

To je přece hrozné, že konstrukt jazyka foreach vyžaduje určité konkrétní pojmenování metody. Od toho jsou přece klíčová slova, ne? Sice to funguje se STL, ale kupodivu existují lidi, co STL nepoužívají. A nepoužívají ani STL konvenci pro pojmenování.

Přijde mi to stejně ujeté jako by virtuální metody musely začínat písmenem v.

[kralyk z abclinuxu]

Rozumím tomu opravdu dobře, že v C++0x budu muset přizpůsobit názvy metod třídy abych ji mohl pohodlně iterovat? Tedy, budou to muset být begin() a end()?

Ne, neřekl bych, teda doufám.

Jinak ale +1 k STL, imho koule na noze C++.

[----]

stdlib/STL je jedním z hlavních problémů jazyka C++.

[solca]

Protoze?

[----]

pomalý kontejnery, streamy horší než v Cčku, pomalý stringy, nesourodý exceptions, debugování horší než v Cčku..

[kralyk z abclinuxu]

Tu pomalost kontejnerů a stringů máš nějak podloženou, nebo to je subjektivní?

Jinak s exceptions souhlasim a dodám, že jako hlavní problém stdlib/STL vidím nekompletnost / málo featur. A taky poněkud těžkopádné použití.

[----]

Porovnával jsem vector/hashtable ze sauerbratenu s vector/unordered_map z stdlib a vyšly asi o 10% pomalejší, porovnával jsem char* a std::string a std::string a std::string byl asi 2x-3x pomalejší (pouze v některých operacích, jindy se v podstatě rovnají) .. testovací kód už nemám, ale nemyslím si, že by byl problém jej znovu napsat.

[Michal Kubeček]

To, že jedna konkrétní implementace má pomalé některé algoritmy, je chyba standardní C++ knihovny?

[----]

to je pravda, i když GNU implementace je jedna z nejrozšířenějších

[Luboš Doležel (Doli)]

begin() a end() jsou docela dobře zavedené názvy. A osobně mi to připadá lepší, než komplikovat jazyk dalšími klíčovými slovy.

[Erbureth]

Ale vůbec, pro procházení přes for_each() stačí, když třída přetěžuje operátor ++; metody begin() ani end() se tam vůbec nevolají, počátek a konec zadáváte jako parametry.

[Boris Dušek]

On podle mě nemluvil o funkci std::for_each z hlavičky algorithm, ale o v C++0x novém klíčovém slově foreach.

[Erbureth]

Mea culpa, v článku se o tom nepíše...

(Každopádně upřesnění by se hodilo, zvlášť, když to klíčové slovo není foreach, ale for s jinou syntaxí [1])

[Jirka P.]

Ne. Stačí, když poskytneš volné funkce begin(x) a end(x). Chtělo by to trochu číst ten draft.

Jinak to není v programovacích jazycích nic nového ani divného, a že to někteří považují za "hrozné" je tak nějak jejich problém. Prostě nepoužívám danou konvenci => nemohu použít danou konstrukci. Rozhodně lepší, než zavádět jakákoli nová klíčová slova.