Standard C++ ISO 2010 (diskuse)

[Josef Kufner]

10MB, 1325 stran... uff... četl to už někdo? Může někdo shrnout, co je nového?

[Fido]

Neni to jen toto?

http://en.wikipedia.org/wiki/C++0x

[Martin Doucha]

C++0x je pracovní název draftu, tohle už nejspíš bude hotová verze.

[Miloslav Ponkrác]

Je to norma, tudíž rozpitvává všechny situace a chování a tedy 1325 stran je naprosto v pořádku. Plus popis všech standardních knihoven. Její největší část je převzatá z předchozí normy, kterou jsem četl celou.

Můžete se s klidem vykašlat na všechny knížky o C++, když máte v ruce normy. Nahradí všechnu literaturu ohledně používání C++, navíc si můžete být jistí, že co je v normě je závazné.

U programovacích jazyků už léta nečtu nic jiného, než normy.

Jak vypadá špatná a krátká norma si můžete vlézt na web W3C a stáhnout si libovolnou normu. Například W3C vůbec nevadí, že vydá normu HTML a ani po mnoha letech nepopíše, jak se má syntaxe jazyka vlastně parsovat, jak má reagovatř na chyby, atd. Následně se všichni zlobí, že si to prohlížeče dělají po svém a každý jinak – právě předcházení těmto situacím je určená dobře napsaná a všeobsažná norma. Pro W3C nedostižný sen přesahující jejich schopnosti.

Norma CSS je také kouzelná. Definuje gramtiku v CSS1 a zároveň NORMATIVNÍ závazek, že se nikdy v budoucnu gramatika CSS nebude měnit. Následně vyšlo CSS2 se změněnou gramatikou a opět stejným normativním závazkem. Jak to bylo s další verzí, nechám na Vás, ale je to tak jak čekáte.

Také je kouzelnější přístup třeba k tomu, že W3C si na svůj web nasměrovalo DTD popisy XHTML, čímž pádem donutilo následkem své normy obecné XML parsery toto DTD používat a na web W3C sahat. Což je W3C nelíbilo, že programátoři dodržují W3C standardy a tak DTD na 14 dní vypnuli, aby je to odnaučili. Myslím, že je pak někdo přivedl k rozumu.

Zkrátka važte si dobré normy. A normy C/C++ jsou napsané dobře a úplně.

[Josef Kufner]

Ok, takže víme že máš rád dlouhé normy a teď zpět k otázce: Co je nového?

[Miloslav Ponkrác]

Stovky nových věcí. Převedeno do populární podoby, nedovedu si vůbec představit, jak to krátce odpověď na malém prostoru jednoho příspěvku. Běžný článek na abclinuxu by možná (i když i o tom pochybuji) na vyjmenování podstatných změn. A to vyjmenování Vám stejně houby řekne, například hesla jako „r-value výrazy“, „variadic templates“.

Nicméně nepokoušejte se vůbec o čtení dlouhých norem, protože jsme se dozvěděli, že nejste s to objevit ani odkaz od kolegy výše jako odpověď na Vaši otázku.

Obvykle neduplikuji odpověď, která s eobjevila dříve, než jsem začal psát příspěvek. A nemám důvod to dělat ani teď.

[hajma]

navíc si můžete být jistí, že co je v normě je závazné.

coz u C++ a treba gcc tak uplne neplati, protoze gcc si dela vicemene co chce a zkompiluje i veci, ktere dle normy zkomilovat vubec nema

[Miloslav Ponkrác]

Nicméně C++ standardní zdroják by měl přeložit všude.

Řada lidí říká „píši v C“, ale ve skutečnosti v C psát neumí, protože píší v gcc.

U C++ se nestandardní psaní objevuje zřídka, protože C++ je velmi bohatý jazyk a nestandardnosti prakticky nejsou třeba.

Extenze nad normu má každý jazyk, kde to norma nezakázala. Například přidat do kompilátoru Ady rozšíření proti normě znamená prohraný soudní proces a značné pokuty. Ostatně ani GNAT nevyhovuje Adě, a aby se vyhnul soudnům, tak se nejmenuje Ada.

Když si Microsoft udělal rozšíření oproti Javě, Sun ho hnal k soudu a vyhrál.

U gcc jsem neměl v C++ ani tak problém u rozšíření, ale spíše to, že STL knihovna neobsahovala celý standard a také s tím, že hlášení ohledně chyb bylo dost kryptické.

Ale budu rád, když se tu dozvím, jaké problémy dělá gcc v nesouladu s normou. Ono na druhé straně díky bohu za gcc, protože přináší C++ na tolik platforem, že je to požehnání.

[JoHnY2]

hlášení ohledně chyb bylo dost kryptické.

Podle me jeden z duvodu proc sluna cast lidi co chce zacit s C++ zbabele prchne. Ukazte javistovi nejakou vypecenejsi hlasku z GCC a uvidite co vam na to rekne. For je v tom, ze na chyby v jave vetsinou pomuze aspon strycek google. Na nektery vejmysle GCC nepomuze ani svecena .

[Miloslav Ponkrác]

To je ale chyba gcc, ne C++. Na jiných překladačích jsou chyby daleko jasnější, srozumitelnější a čitelnější.

[vencas]

Hlavně naopak donedávna (pár let) nezkompilovalo věci, které by podle normy zkompilovat mělo. Ne že by na tom ostatní překladače nebyly ještě hůře, tak to nemyslím.

Sotva kompilátory implementovali předchozí standard c++, přichází nové c++10, aby vývojáři kompilátorů zase měli co dělat a za 5 let standard postupně možná dohnali

[stativ]

tak tak, třeba export šablon podporuje asi jenom Comeau. Je ale fakt, že to se u kompilovaného jazyka dělá hodně blbě.

[Miloslav Ponkrác]

Export šablon se dělá u kompilovaného jazyka parádně.

Jediné co dře je, že kdysi byla zvyklost rozdělit proces na kompilaci a linkování, přičemž kompilátor měl být chytrej a vysypat jen stroják se symboly a linker měl být blbej spojovatel. To s C++ dost dobře nejde.

C++ musí minimálně v linekru odtraňovat mnohonásobně zduplikované instance šablon, jinak by binárka měla zbytečně obří velikost.

Díky C++ se postupně činnosti kompilátoru a linkeru spojují. Jak gcc, tak jiné kompilátory mají mnohem chytřejší linkery, než dříve. Kompilátor dává do přeloženého modulu mnohonásobně více informací, než za času Céčka a linker zase dokáže řadu optimalizací i věcí, co dříve dělal kompilátor.

Bylo načase, protože bývalá spolupráce kompilátor + linker s jasně rozdělenými rolemi vyhovovala tak assembleru, nebo Céčku, což je v podstatě jen assembler s jinou syntaxí.

Mám vyzkoušeno, že když zapnu v MSVC optimalizace na úrovni linkeru, že binárka je klidně o 20% rychlejší, než když optimalizuje jen kompilátor. Například je docela hezké pozorovat, jak linker projde všechny moduly a inlinuje funkce, které jsou ve strojáků krátké, nebo funkce, které jsou volány jen na jednom místě. Linker jako jediný dokáže provést optimalizace nad celým výsledným programem – a tady to dělá dost brutálně.

Rok od roku se vechny kompilátory méně a méně upejpají. Kompilátor dává více a více informací do přeložených modulů a linker přebírá více a více práce kompilátoru ovšem s výhodou globální pohledu na celý výsledek a tedy netušenými možnostmi nejen optimalizací.

Časem se to osmělí natolik, že šablony bude řešit linker kompletně a v tu chvíli nebude s exportem šablon problém.

[stativ]

Export šablon se dělá u kompilovaného jazyka parádně.

Kdyby to bylo tak jednoduché, tak to implementuje víc než jeden kompilátor. Času na to bylo dost dlouho.

[stativ]

Sorry, Sun Studio prý export umí také.

[Miloslav Ponkrác]

Je to jednoduché, a pokud někdo někdy bude dělat kompilátor od nuly, tak export šablon tam mít bude.

Problém je, že v dnešních kompilátorech je 20 i více let stará architektura kompilováno/linkování – jako v gcc, nebo ms kompilátorech. Na ní se jenom nalepuje, tudíž to jde pomalu ztuha.

Tyto architektury předpokládaly C model, tedy model hloupého jazyka, kde programátor myslí strojově low level a kde funkce a struktura je vrchol abstrakce, který ten jazyk dokáže.

Navíc Céčko vznikalo stejně jako Git. Jeho první verzi někdo nabastlil za pár týdnů, protože se s tím nechtěl čistě dělat. A jazyk C nebyl hlavní cíl, jen prostředek k jiným věcem. Jen rychle zbastlená věc na přenos unix kernelu na něco jiného, s Céčkem se nikdo prčit nechtěl.

Architektura Céčka zůstala zbastlená stejně jako Gitu, byť samotná věc je dobrá a funkční. A teprve vyšší jazyky začínají rozbíjet kompilační schéma Céčka, protože hrubě nedostačuje.

[McJ]

Pokud je to opravdu tak jednoduche, tak je celkem skoda, ze se rada rozhodla export sablon z noveho standardu odstanit.

[Miloslav Ponkrác]

Protože nevyhovuje starým kompilátorům, založeným na C způsobu linkování – to je celé.

Do nového kompilátoru ho dáte velmi snadno.

Koneckonců stále je export součástí C++ normy a navěky bude v této verzi standardu C++.

Je jen otázka, kdy i staré kompilátory upgradují interní struktury a formát objektových souborů natolik, že to ani pro ně nebude problém.

Právě proto trvalo starým kompilátorům cca 10 let, než vůbec obohatily linker aspoň natolik, že je schopen zařídit běžné operace se šablonami. Proto ještě mnoho let po standarud byly různé limity na šablony.

[Sten]

Je to proto, že dost kompilátorů místo extern šablon (které měli zrychlit překlad) přišla s precompiled headers a extern tak ztratilo smysl.

[Miloslav Ponkrác]

Neztratilo smysl, obojí slouží k něčemu jinému.

Skutečný důvod, proč se odstranilo extern, jak se snadno můžete dočíst i ve zprávách ze setkání komise je ten, že výrobci kompilátorů jsou velmi laxní v implementaci exportu.

C++ bylo vždy zaměřeno prakticky a v souladu s praxí. C++0x chce využít triku, že jen minimum kompilátorů může dnes říci, že plně vyhovuji normě C++ z roku 2003, protože jim chybí právě ten export. Pokud export z C++0x vyndají, pak pomohou prosazení C++0x, protože nové featury C++0x není tak těžké implementovat, a výrobci kompilátorů budou moci říci náš kompilátor plně vyhovuje normě ISO C++ 201x.

Jinak řečeno, standardizační komise dává přednost tomu, aby existovalo maximum kompilátorů C++ 100%ně v souladu s normou.

Export stále zůstává, klíčové slovo export je stále rezervované.

[Jardík]

Už by měli vyhodit hlavně makra. Jsou hnus. I C (C99) podporuje inline funkce a je hnus, když si napíšu třídu např. Matrix a chci tam funkci minor(size_t,size_t) pro získání "minor" matice, tak namě preprocesor začne jebat, že makro minor bere jeden argument. fakt super, vymejšlet jiný název. Dalším řešením by byl #undef, ale pak by zase zdrojáky, co includujou třídu s maticí nemohly používat to makro

[deda.jabko]

Už by měli vyhodit hlavně makra. Jsou hnus. I C (C99) podporuje inline funkce

makra jsou nahodou naprosto uzitecna vec a jsou situace, ktere neresi ani inline funkce ani templaty. vlastne, spis je skoda, ze v C maji makra jenom tak omezene schopnosti... napr. by se mi hodilo makro generujici dalsi makra (v rozumnych jazycich je to normalni)

chci tam funkci minor(size_t,size_t) pro získání "minor" matice, tak namě preprocesor začne jebat, že makro minor bere jeden argument. fakt super, vymejšlet jiný název.

to je spis problem ,,jednoho/spolecneho namespacu'' nez tech maker

[Jardík]

Má třída byla v jiném namespacu než makro minor (v globálním ze sys/stat.h či čeho). Pokud definujete makro, tak nezáleží, v jakém namespacu napíšete #define, je prostě definované v globálním namespacu a preprocesor je blbej a tak to nepozná. Pokud už chci/potřebuji definovat makro, tak mu dám alespoň nějaký solidní prefix (např. podle názvu knihovny), aby "nekradl" jména "normálním" funkcím.

[Miloslav Ponkrác]

To je bohužel dědictví C. C jazyk je velmi chudý jazyk a tak se tam nahrazuje makry leccos a často se jím simulují inline funkce.

Bohužel většina kompilátorů má společné C a C++ headery, stejně tak jako headery pro API operačního systému.

Kdyby se psaly C++ headery, bylo by to na jiné úrovni.

Jinak osobně bych byl spíše pro rozšíření možností maker v C++ zhruba na úrovni makrovacích schopností běžných assemblerů.

[kralyk z abclinuxu]

Už by měli vyhodit hlavně makra. Jsou hnus.

Jakpak bych bez maker definoval toto:

#if defined __FILE__ && __LINE__
#define ohshit(code, message) throw Err(code, message, __FILE__, __LINE__)
#else
#define ohshit(code, message) throw Err(code, message)
#endif

[Jardík]

Dobře, ale pravděpodobnost, že si někdo vybere pro funkci/proměnnou název __FILE__ je určitě několikanásobně menší, než že si vybere název "minor". Navíc je __FILE__ apod. součástí standardu (snad nekecám), takže nevidím důvod, proč by tak někdo pojmenovával funkci.

[petr_p]

Kompilační schéma C (hloupý linker) umožňuje míchat objektové soubory z různých jazyků dohromady. Pokud zrušíte linker, jak budete dělat binding mezi jazyky?

[Miloslav Ponkrác]

Nejde o rušení linkeru, ale o to aby nebyl hloupý. Což u Céčka být může, protože linker de facto u C skoro nic neřeší.

Pravdou je, že i z chytrého linkeru bude Céčko mít benefit, ale nebylo zvykem ho pro C takto dělat.

[Miloslav Ponkrác]

Změny budou menší.

Dříve měli kompilátory problémy s implementací výjimek, a trvalo mnoho let, než se přišlo na to a našel model, jak to udělat efektivně.

Navíc při první normě kompilátory musely nějak zajistit, aby předchozí programy psané nadivoko nějak fungovaly – změna se nedala udělat naráz.

Nová norma je kompatibilní se starou (až na drobnosti). Druhá věc je, že schází motivace výrobců kompilátorů proč novou normu implementovat.

Samotné změny jsou většinou syntaktické rozšíření a několik tříd v knihovně navíc. Například MS Visual C/C++ 2010 už půlku normy implementovala, a to ještě není zcela schválená. Gcc udělal to samé. Někdy se spíše ptám, jestli rychleji budeme mít kompilátory, co podporují novou C++ normu, nebo jestli rychleji bude ta norma schválená.

[Boris Dušek]

Její největší část je převzatá z předchozí normy, kterou jsem četl celou.

Chtěl bych si normu taky někdy přečíst, zkoušel jsem už začít, ale hodně se tam začalo odkazovat na nedefinované pojmy (sekce o lexikální analýze byla v pohodě, ale myslím už v sekci "Basic" začala používat pojmy definované až později). Jak se taková norma nejlépe čte? Od začátku do konce?

[kralyk z abclinuxu]

Je ta norma alespoň veršovaná?

[Miloslav Ponkrác]

Ne, ale konečná verze standardu C++ stojí 380 CHF (přes 6000 Kč) za pdf.

[Bedňa]

Kuvy normovačské, čo ešte nevypotia To asi písal Jan Jilek.

[mehturt]

pokial sa nemylim je to len final draft

[mehturt]

vid http://herbsutter.com/2010/04/02/how-anyone-can-comment-on-the-fcd/

[Miloslav Ponkrác]

Jakákoli konečná verze ISO je jen za peníze a nebude se nikde válet volně ke stažení. Cokoli si za ISO normu volně stáhnete, jsou to vždy jen drafty.

[mehturt]

presne tak, teda ta originalna spravicka je zavadzajuca

[kralyk z abclinuxu]

Jsou v tom (také) ty novinky známé jako C++0x, nebo to je něco jinýho? Kdo se v tom má vyznat...

[Miloslav Ponkrác]

Je to snaha konečně C++0x dorazit do konečné podoby a schválit jako ISO standard.

[kralyk z abclinuxu]

Aha ok díky za vysvětlení...

[Michal Kubeček]

Nešlo by zprávičku přeformulovat tak, aby z textu bylo patrné, že odkaz nevede na příslušný web, ale rovnou na ten (poměrně velký) PDF dokument?

[Miloslav Ponkrác]

Podle mně je to ze zprávičky jasně patrné. Standardy se nevydávají většinou jinak, než v podobě nějakého dokumentu. Těžko můžete čekat nějaké populární čtení od standardizační komise.

[Michal Kubeček]

Nejde o to, že je standard dlouhý. Jde o to, že zní-li text odkazu "open-std.org", očekávám, že link povede na příslušný web. Kdyby byl text odkazu "Nový standard C++ ISO 2010" nebo "Nový standard", pak bych očekával, že link povede na ten standard.

[Tomáš Heger (geckon)]

Doplněno.

[Jardík]

Takže už to schválili? Tak a teď už mi cvičící nemůže říct ani ťuk, když v tom napíšu semestrálku, co na tom, že jí nepřeloží dnešními kompilátory

[Jardík]

Aha, hned na začátku vidím draft, tak nic

[Miloslav Ponkrác]

nikoli, je to příprava na poslední konferenci a posledním připomínkám před standardem. pokud to nezmění

[andree]

tak to vyzera zaujimavo - sa mi zda ze sa celkom priblizi niektorymi featurami interpretovanym jazykom alla python... :) akurat mam po precitani par noviniek na wiki pocit, ze bude uz celkom problem, aby niekto vyuzil aspon polovicu toho jazyka (uz len syntaxe - o STL atd. ani nehovorim...)

[Miloslav Ponkrác]

Featurami high level jazyk, efektivitou výsledného kódu rovnou low level Céčku.

Nemám pocit, že je problém využít půlku jazyka.

Mně jen zajímá jestli někdy vznikne nějaká konkurence C++, protože žádný konkurenční jazyk stejných vlastností neexistuje. Naprosto univerzální jazyk, ve kterém by se programovalo na high level úrovni, ale lezl z toho vysoce optimalizovaný stroják. Možnost v případě potřeby mít pod kontrolou zcela vše v programu. Výsledný program má minimální nároky na systémové zdroje a je stejně rychlý jako C. A k tomu standardizovaný jazyk se zaručenou zpětnou kompatibilitou.

V zásadě v okamžiku, kdy člověk potřebuje efektivní vývoj a zároveň vymačknout z hw max. rychlost, či malou náročnost na hw zdroje, pak jiná rozumná volba jazyka, než je C++ v zásadě neexistuje.

[Radek Miček]

Mně jen zajímá jestli někdy vznikne nějaká konkurence C++, protože žádný konkurenční jazyk stejných vlastností neexistuje.

Takové ambice má jazyk D.

[Jardík]

D je mrtvý jazyk. Do dnes snad nikde není kompilátor pro x86_64 a je tedy nevhodný pro vyvíjení aplikací pro dnešní počítače. Jmenujte nějakou "normální" aplikaci, která je v D napsána.

[Radek Miček]

Jen říkám, že má takové ambice.

[Sid]

C++ ma od naprosto univerzalneho jazyka zatial daleko a to minimalne do doby kym konecne napr tento standart sa nestane realitou. Zopar problemov v sucastnosti: 1) Rozne implementacie standartnych kniznic (skuste si napisat program ktory v STL ktory ma vdaka roznym pouzitym implementaciam kontajnerov uplne ine casove chovanie) 2) Rozna implementacia C++ standardu roznymi prekladacmi (uroven vnorenia sablon napr) 3) Implementacia datovych typov (prenositelnost) 4) Nulova podpora pre pripojovanie dynamickych kniznic v C++ 5) Podpora pre Unicode (to co ma stl wstring by som nazval omylom)

Inac btw : vysoko optimalizovany kod vam lezie z kde coho, skor ide o dalsie vlastnosti jazyka ktore urcuju vyslednu efektivitu kodu. ale inac s poslednou vetou suhlas

[Miloslav Ponkrác]

Ad 1) Tento problém budete mít v každém jazyce, který má více implementací. Naprosto v každém.

Ad 2) To byl spíše problém minulosti. Dnes u jsem se s tím dlouho nesetkal, že by překladač měl nějaká omezení. Nebo jsme se tolik nerozlétnul, abych na omezení dnes narazil.

Ad 3) Souhlas, C++ nemá v principu přenositelné datové typy.

Ad 4) To určitě má.

Ad 5) Unicode podporován není vůbec, std::wstring není Unicode řetězec, ale nepřenositelné pole celočíselných hodnot.

Vysoce optimalizovaný kód trošičku horší kvality leze z kdečeho kompilovaného.

[Michal Kubeček]

Ad 5: např. u gcc je std::wstring unicode řetězec (v kódování UCS-4), podobně je tomu i u řady jiných implementací. Přenositelný být nepotřebuje, protože má-li se někam přenášet, dělá se to přes stream a při zápisu dochází ke konverzi podle zvoleného locale (a stejně tak při čtení).

[Miloslav Ponkrác]

1) wstring je pouhé pole prvků typu wchar_t – nic jiného

wchar_t může být cokoli, může to být 16ti, ne 32ti bitová integer proměnná. může být signed i unsigned.

kde jsou nějaké slušné unicode funkce?

wstring není nic, než pouhé pole celých čísel a nic jiného neumí

a konverze do 8mi bitových charsetů jsou doufám minulostí, já sám nic takového už roky nepoužívám

raději se zdržím dalších komentářů

[Michal Kubeček]

wstring je pouhé pole prvků typu wchar_t – nic jiného

wchar_t může být cokoli, může to být 16ti, ne 32ti bitová integer proměnná. může být signed i unsigned.

To je sice pravda, ale není to v rozporu s tím, co jsem napsal.

a konverze do 8mi bitových charsetů jsou doufám minulostí, já sám nic takového už roky nepoužívám

Já jsem snad o něčem takovém mluvil?

raději se zdržím dalších komentářů

Pokud je vám zatěžko přečíst si příspěvek, na který reagujete, bude lepší, když se zdržíte.

[petr_p]

wchar_t (budu-li se držet C99), je implementačně závislý. Standard pouze požaduje, aby obsáhl všechny znaky, které daný systém v době překladu umí.

Například přeložíte-li program na systému, jehož standardní knihovna umí jen osmibitové locales, tak výsledný program může mít typ wchar_t široký osm bitů. Doinstalujete-li si podporu pro UTF-8 locales, a přeložíte-li program znovu, bude wchar_t (ve stavu dnešního Unicode) mít 32 bitů. Spustíte-li si první program na novém systému v UTF-8 locale, čtecí rutiny při převodu multibyte do wide charachter selžou, protože nedokážou reprezentovat tak široké znaky.

[Michal Kubeček]

Ani tohle pořád není v rozporu s tím, co jsem napsal, prostě jen mluvíte o něčem úplně jiném než já…

[Michal Kubeček]

Protože to asi nebylo dost srozumitelné, zkusím ještě jednou převyprávět svůj původní příspěvek. Za prvé: nelze kategoricky tvrdit, že std::wstring není unicode řetězece, protože jím nejen být může, ale často také je. (Jestli jsou nebo nejsou k dispozici specifické unicode funkce, tu nehraje roli.) Za druhé: ano, interní reprezentace std::wstring není obecně přenositelná, ale to není problém, protože u tohoto typu se nepředpokládá, že by se v nativní podobě přenášel mezi platformami nebo i jen mezi různými procesy, a standardní mechanismy pro přenos překlad zajistí. Že nebudou fungovat u zmršených implementací, jejichž wchar_t nemá dostatečný rozsah, to je celkem logické, ale je to chyba těch implementací, ne návrhu.

[Miloslav Ponkrác]

wstring samozřejmě pro uložení unicode sloužit může, ale to je z hlediska práce s unicode stringy dosti slabá funkcionalita

nehledě na implementační závislosti typu wchar_t

jestli se Vám tohle zdá jako úžasná věc, mně nikoli

dále na wstringem nefungují základní unicode akce, napřeklad dekompozice stringu, správné porovnávání dvou unicode stringů (wstring porovnává pouze binárně kódu, což dále potvrzuje co píšu, že wstring není unicode string, ale pouhé pole celých čísel), prostě nic.

[Jardík]

C99 nemá z C++ (2003) nic společného, snad jen společného "předka".

[Jardík]

Nesouhlasím s tvrzením:

u gcc je std::wstring unicode řetězec (v kódování UCS-4)

U mě v GCC je wchar_t 2B, tudíž UCS-4 z toho jen blbě vyždímete. A pokud použiju prefixu L"", nastrká tam UCS-2 "řetězec". Platí, co řekl pan Ponkrác.

wchar_t může být cokoli, může to být 16ti, ne 32ti bitová integer proměnná. může být signed i unsigned.

[David Šmíd]

Tak to máš místo gcc nějakou 16bitovou šmejďárnu, mně tenhle program vrátí 4:

#include < string >
#include < iostream >

int main()
{
        std::cout << sizeof(wchar_t) << std::endl;
}

 

---

[Jardík]

jó, jenže já používám verzi pro Windows, kde je wchar_t 2B. Utřen?

[Jardík]

Unicode podporován snad být má v C++0x, je tam char16_t a char32_t. Říká se tam něco jako že když použijete prefix u"" či U"", výsledek bude UCS-2 či UCS-4 "řetězec" a pokud to použijete jako jediný znak, tj. u'' musíte dávat bacha, aby se nejednalo o znak tvořený dvěma char16_t, nebo tak něco.

[Sinuhet]

ad 3) #include <cstdint>?

[Jardík]

U tohodle si např. MSVC neškrtne, ale dobře mu tak

[Sid]

Ad 2) Mate pravdu, bohuzial nie kazda platforma ma najnovsie gcc :). Embedded zariadenia maju casto gcc vo verziach o dost dozadu.

Ad 4) To urcite nema - poznate nejaky postup akym sposobom korektne implementovat to, ze mate napr dynamicku kniznicu a chcete spajat a volat C++ triedy medzi kniznicami a vasou hlavnou aplikaciou? A tiez korektne sirit vynimky. A ZAROVEN, ze nie ste obmedzeny na uplne rovnaky prekladac a uplne rovnake nastavanie parametrov pri preklade.

[Miloslav Ponkrác]

Ad 2) Na řadě platforem dodnes není ANSI C. Musíte používat K&R C bez prototypů funkcí, apod. To, že jsou některé platformy sto let za opicemi, to bohužel.

Ad 4) Pokud přeložíte knihovny stejnou verzí kompilátoru se stejnými volbami, tak toto všechno můžete.

To je už osud jazyků vysokých úrovní, že těžko nadefinujete binární kompatibilitu mezi různými překladači různých binárních kusů kódu. A pokud to uděláte, tak pouze za cenu, že prudce snížíte efektivitu výsledného programu. Dynamické knihovny byly vymyšleny pouze pro C – exportují jen symbol jako adresu a stroják + nějaké informace o sekcích a relokacích, nic více. Pro úspěšné spojení výšších jazyků, potřebujete další informace.

Řada standardů se o vyšší úroveň dynamických knihoven úspěšně pokusila, můžete jí využít. Dokáže dokonce spojit i třídy psané v různých programovacích jazycích. Například CORBA, ve Windows je to COM a DCOM.

Pokud chcete spojovat binárně knihovny na vyšší úrovni, než je stroják, nepožívejte dynamické knihovny, které jsou jen hloupým osymbolovaným strojákem, ale vyšší prostředky, které jsou schopné zajistit sdílení na inteligentnější vyšší úrovni.

[Sid]

Hm... CORBA, COM a DCOM??? to myslite vazne? to je asi podobne "riesenie" ako kedy niekto chcel zapisat pid v unixe na disk a poradil by ste mu Oracle :)). no fasa.

DCOM/COM - neprenositelne CORBA - prenositelne, pre vacsinu projektov "oversized" - pokial viem tento postup s CORBOU pouziva GNOME ale myslim, ze ho opustaju.

Navyse kedze obidva pouzivaju IDL tak potom C++ je v podstate okresane a musite sa riadit tym co vam IDL prekladac vygeneruje

[Miloslav Ponkrác]

Prostě se musíte smířit s tím, že klasické .so, nebo .dll přenositelné mezi kompilátory nejsou. Nejsou dokonce přenositelné ani v rámci C, což obecně lidi neví. Každý rok se směju několika lidem, kteří věří v přenositelnost dynamických knihoven mezi různými kompilátory C a hledají chybu.

Klasická dynamická knihovna neřeší nic, jen název symbolu a přiřazení adresy + relokaci strojáku.

Dynamická knihovna neřeší soulad binárního volání a volací konvence mezi volajícím a volaným. Ani nic jiného. I pokud chcete v C slušně použít dynamickou knihovnu mezi kompilátory, musíte se omezit, byť v rámci to omezení je malé.

Prostě máte na výběr – buť použijete dynamickou knihovnu a vše zkopilujete stejně. A nebo chcete něco víc, a pak použijete projekty, které umí zajistit kompatibilitu na vyšší úrovni.

Ani programovací jazyk C, ani programovací jazyk C++, ani další jazyky neumějí 100%ně přenášet a volat dynamické knihovny zkompilované jinou verzí kompilátoru, protože žádný z jazyků nemá binárně přesně definované API pro dynamické knihovny. Je iluzí si myslet, že nějaký vyšší jazyk nebude mít nikdy problémy při volání dyn. knihoven, pokud se rozjedete naplno. Každý jazyk bude bezproblémový jen při zkompilování všeho stejným kompilátorem.

Právě proto si mnoho jazyků vytváří svou vlastní náhradu dynamických knihoven, která je chytřejší a schopnější, než to co poskytuje operační systém. Java si udělala své .class a .jar, Python své .pyc a .pyo. A právě proto Windows zavedlo svoje COM, aby mohlo operovat na chytřejší úrovni API, než hloupé C rozhraní. Ostatně každý operační systém nějakou formu zavedl.

Zkrátka klasické dynamické objekty jsou konceptem, který je dělán pro operační systém, nikoli pro programovací jazyky a uspokojení jejich potřeb. Není v nich žádný mechanismus, který by umožňoval přenositelnost na jiné kompilátory. Ten si musí vytvořit jazyk sám.

[mnn]

Tak trochu si rýpnem

Čo takto Mono a .NET?

[Jardík]

Možná MS .NET, ale ten v mono je samej leak.

[Miloslav Ponkrác]

V .NETu je .dll obohaceno a další sekce a obsahuje obrovskou spoustu detailních informací o kódu, tzv. metainformace.

Důvod, proč se jmenuje .dll je ten, aby starší Windows po souboru bafly jako po dynamické knihovně a natáhly potřebné věci, protože obsahuje nějaké symboly, které neudělají nic jiného, než že zavedou .NET framework a zbytek už si řídí on.

Ze stejného důvodu také ve Windows máte .exe programy, protože v DOSu se zavede DOSovská část a sdělí Vám, že jde o Windows program.

[mnn]

Áno, ja viem, že Class Library nie je klasická DLL knižnica.

Mne šlo skôr o to, či je možné mixovať skompilované s Mono kompilerom a .NET kompilerom.

[kralyk z abclinuxu]

To ale není rovnoprávné porovnání s C++, protože .NET vytvořila, zastupuje a standardizuje jedna firma - MS. Veškeré ostatní implementace se musí přizpůsobovat chování .NET od MS. To je jako kdyby se všichni výrobci kompilátorů C++ museli přizpůsobovat gcc (například), ale tak to není. C++ je obecný otevřený standard nezastoupený jednou firmou, čili implemetace vytvářejí různí lidé/společnosti nezávisle na sobě.

[Jardík]

Ano, míchat toto lze (ale pokud použijete mono specific knihovny, tak pak je musíte mít i ve windows (stačí zkopírovat). Problém může nastat u .NET knihoven jako např. Gtk-sharp, které volají funkce z céčkových knihoven a pak je problém s velikostí pointerů a různých dalších typů.

[Sid]

mam pocit, ze pletiete dokopy rozne veci. Miesat dokopy COM a class je porovnavat hrusky s jablkami.

Mechanizmus ktory by umoznoval prenos zase nie je az tak moc zlozity a bolo by to presne definovanie ako sa ma C++ program prelozit (tj. ako pouzivat VTABLE,ako uklada argumenty pri volani,...) Akurat ze to by asi norma C++ nemala 1000 stran.

Inac toto je jeden z dovodov preco jazyku ako Python,C++,C# su tiez uspesne. Koncepcia jazyka ktory sa neda lahko rozsirovat je napriek tomu ze jazyk sam o sebe ponuka vela trosku kulhajuca na jednu nohu.

[Miloslav Ponkrác]

Jasan, COM a class spolu fakt vůbec nesouvisí. Néééééé, vůbec néééé. Ani trochu.

Mechanismus, který by umožňoval přenos na úrovni strojáku by byl kontraproduktivní, protože by zabránil kompilátoru možnost udělat to optimálněji. Rok od roku se nachází lepší a lepší schémata jak do strojáku převést a zoptimalizovat C++ konstrukce. Jako nápověda: Vyhledejte si plačky z počátků C++, jak jsou výjimky pomalé, neefektivní a zabírají mnoho paměti. Kdybyste v jakémkoli bodě na úrovni strojáku zabetonovat něco jako API, tak byste zabetonoval neefektivní kód.

Proto standard přenosu lze definovat pouze na vyšší úrovni, než je stroják. A třeba ten Python, nebo C# to tak dělají.

Ukládání argumentů při volání hodně ovlivňuje efektivitu, víc, než se zdá. VTABLE také může obsahovat leccos. A znovu říkám, tuto standardizaci nikdo neprovedl ani na úrovni jazyka C, natož C++.

Koncepce Pythonu je geniální zase v tom, že nedává možnost své zkompilované části (asi tak ekvivalent dynamických knihoven) mít přenositelné mezi verzemi kompilátoru, ale dokonce ani zdroják (viz nekompatibilita mezi verzí 2 a 3).

Jinak já souhlasím, že by to chtělo vyšší level – ale to nastane až tehdy, až s prominutím se přestane všechno Céčkoizovat. Protože zatm je vývoj aplikací, včetně formátu .so knihoven, včetně API knihoven tvrdě přizpůsoben hranici C. Taková dynamická knihovna vyšší levelu by měla mít mnoho metainformací – teyd informací ze zdrojáku. V zásadě vyšší level by nepotřeboval hlavičkový soubor, protože všechny informace z něj a ještě mnohem víc by ten vyšší level měl v metainformacích.

[JoHnY2]

C++ je superjazyk. Nejakym zpusobem umi vpodstate vsechno co od nej muzes kdy chtit. Zdaleka ne vsechno musi pouzivat. Napriklad ja pouzivam C++ jen jako jazyk pro programovani s Qt4 a syntaxe je skoro az Javovsky prosta.

[Miloslav Ponkrác]

Jakmile lidi pochopí, že nemusí používat vše naráz, tak bude ráj. Konečně zmizí přiblbé komentáře očesaných jazyků, jejichž hlavním argumentem je, že nedokážou nepoužívat celý jazyk.

[alblaho]

Tahle idea má tu podstatnou slabinu, že každý programátor si vybere jinou podmnožinu jazyka. A každý programátor je ve styku s cizím kódem, že.

Proto je tak úspěšná Java. Ta lze nastudovat celý za dvě odpoledne

[Miloslav Ponkrác]

Co je na tom za slabinu? To, že si vyberu podmnožinu kódu neznamená, že nemůžu rozumnět i tomu, co jsem si nevybral.

Java je úspěšná proto, že do jejího protlačení dal Sun mnoho miliard dolarů a mnoho reklamy, a to vše dělal obrovskou řádku let. To je hlavní důvod úspěšnosti Javy.

Celkově vzato, C++ je velmi úspěšný jazyk (například Java by bez C++ neexistovala, celá JVM je jen C++ kód) a C++ se na rozdíl od Javy prosadil funkcionalitou a žádná firma do prosazení C++ nemusela nacpat tolik peněz, jako Sun do Javy.

Já jsem si třeba nevybral Javu, protože jí sice lze nastudovat za dvě odpoledne, ale pro mně je spíše klíčové, jak mi ten jazyk bude pomáhat, až ho nastuduji. Podle Vašeho uvažování bych na Windows psal programy v notepadu, protože ho pochopím rychle přesto mnoho programátorů píše třeba ve vimu. Proč? Protože jednoduchost není nutně vždy priorita. Stejně tak třeba jako muž nepůjdete balit a neoženíte se s bezdomovkyní na nádraží co pije čúčo, i když Vám zabere nejkratší čas jí sbalit. Kromě času na naučení jsou tu i kvalitativní požadavky na věci co používáme.

[Sid]

Nemyslim, ze prave syntax jazyka rozhoduje uplne o uspesnosti. Skor by som povedal, ze kvalita jeho kniznic. To ze nieco mozete zapisat o tri riadky kratsie je sice pekne ale nie vzdy najdolezitejsie.

Inac ohladom porozumenia - skuste sa pozriet napr. na niektore "speciality" v booste. Obcas sa tam zorientovat je cisto detektivna praca. Zrovna sablony v C++ mi pridu ako typ vyvoja "pridame tam vsetko co by sa niekomu mohlo hodit niekedy". Plus vystup z prekladaca pri chybe je co sa tyka sablon naozaj obcas krypticky.

Ak si myslite, ze uspech Javy su miliardy od Sunu tak to mi pride usmevne. Preco myslite, ze sa Microsof vydal cestou Netu a nie C++?

C++ je skvely jazyk ale nie vsade o myslim ze Java (Python,C##,...) su presne zamerane na tie oblasti.

[Miloslav Ponkrác]

To co rozhoduje o úspěšnosti je matematická funkce o tisícovce proměnných.

Kdyby měla o úspěšnosti jazyka rozhodovat pouze kvalita knihoven, tak C++ už dávno neexistuje, protože jeho knihovny jsou strašné.

Boost je exhibicionismus, a nikdo nemusí programovat tak jako v boostu.

Šablony jsou způsob, jak do staticky typovaného jazyka přidat prvky dynamického jazyka. Nějakou obdobu šablon má dnes většina kompilovaných jazyků. Za to, že gcc dává dokonale kryptické výstupy při chybách, zatímco jiné kompilátory nikoli, za to já nemůžu. Kdysi, když jsem používal gcc, tak i bez používání šablon nemělo gcc problém ukázat, že je chyba o 20 řádků jinde, než byla.

Myslím si, že úspěch Javy je především podložen miliardovými podporami Sunu a že bez nich by Java dnes nebyla. Mohl bych být prostořeký, a napsat, že v enterprise sféře se uchytí vše, co je podpořeno balíkem peněz. Je tam dodnes například COBOL (a pokud umíte COBOL, je to sakra dobře placená práace) – a ten se tam jistě nedrží kvalitou.

Microsoft se nevydal cestou .NETu a ne C++. Máte zmatek v tom, že nechápete, že .NET není jazyk, ale runtime, na které běží stovky nejrůznějších jazyků. Kdybyste to od Microsoftu chtěl slyšet celé, tak Microsoft říká, že jeho směr je podpora .NETu a nejefektiuvnější a nejrychlejší jazyk pro .NET je C++. Ale tak daleko jste to nedočetl.

Skoro se mi chce říci, že nikdo, ani žádná jiná firma nepodporuje a neudělal pro podporu C++ tak moc, jako Microsoft (hned po AT&T).

Jinak souhlas, C++ ani zdaleka není efektivní nasadit všude. C++ má své specifické vlastnosti, které jiný jazyk nemá (efektivitu výsledného kódu, efektivitu a rychlost vývoje, high level konstrukce, multiparadigmovost, nenáročnost výsledného kódu na zdroje systému, či platformy). Pokud dané vlastnosti nejsou klíčové, pak může být nasazení jiného jazyka daleko přínosnější.

[alblaho]

Když si vyberete podmnožinu, tak stejně nic neušetříte, protože pro efektivní práci musíte stejně znát i to, co používají ostatní vývojáři. Tudíž musíte ten jazyk znát skoro celý.

Ano, můžete psát v podmnožině a rozumět všemu. A když dostanete cizí kód, tak si jen řeknete: sice tomu rozumím, ale upravit to nemůžu, protože to používá věci mimo mou oblíbenou podmnožinu.

To je stejné uvažování, jako že C++ reference nemůže obsahovat null, protože je to ve standardu .

[vencas]

Všechno bohužel ne: třeba vůbec nemá introspekci (a to ani compile-time, když nepočítám pár šablonových divočin co lze udělat s boost::mpl), kterou pak řeší frameworky v rozvinutější podobě každý po svém pomocí nechutných maker.

[Jardík]

K čemu introspekci? Aby se pak metody volaly stylem call_func("Typ::fce") a bylo to tak debilně pomalý jako v GTK, kde jsou ke všemu použity řetězce? (signály, properties,...)

[vencas]

Třeba na serializaci do XML? Na signály a interoperabilitu s jazyky jako python? Někteří třeba používají co ty nepotřebuješ, no.

[Miloslav Ponkrác]

C++ je staticky typovaný jazyk. Dynamicky typované jazyky fungují jinak. Už to co dává C++ přirozeně je ve statických jazycích těžký nadstandard.

Druhá věc je, že typový systém se týká modulu, ne programu – tudíž možnosti operací s typy jsou záměrně drženy níže.

Nejrozumější řešení na speciální věci je napsat preprocesor, který vygeneruje příslušné kódy. Takový preprocesor vygeneruje kvalitnější a efektivnější kód na obě strany, protože pracuje s informacemi, které by samotný jazyk nedostal a může datové struktury i další plně podřídit efektivitě.

Ostatně preprocesory na různé oblasti použití existují, například flex je velmi známý, stejně tak swig pro generování wrapperů apod. Je to výrazně rozumnější cesta.

Podívejte se do Javy, takový Eclipse vygeneruje 2/3 kódu za programátora – což je do značné míry dané tím, že Java je tak blbý a očesaný jazyk, že bez generátorů by byl programátor docela nevýkonný.

[vencas]

Introspekce podle mě nijak nesouvisí s tím, jestli je jazyk staticky typovaný nebo ne.

Reagoval jsem na to, že c++ umí vše, co od něj kdo může chtít. Prostě neumí. Jestli je to historicky nadstandard je celkem jedno.

[Miloslav Ponkrác]

Ale samozřejmě, že na světě se ještě nezrodila věc, která by 100%ně uměla všechno, co by od ní kdo kdy mohl chtít.

[Sten]

Serializaci řeší C++ IMHO líp pomocí Boost Serialize a interoperabilitu pomocí Boost Python. Prostě si nadefinujete, co chcete exportovat, a ten jazyk to hloupě neexportuje vše, takže můžete pohlídat, že třeba buffery se do serializovaných dat nedostanou.

[vencas]

Akorát s tím je dost práce, že (obojí už používám, vím o čem mluvím).

Představoval bych si, že budu moci pomocí introspekce při startu programu projít data a podle nějaké konvence (třeba že jméno nebude začínat m_ apod) určit, co serializovat a co ukazovat do Pythonu. A to by ten jazyk umožňovat mohl.

[andree]

yep, spolu s Qt je to velmi fajn jazyk aj na gui a podobne veci.. som este zvedavy, kam sa to teraz posunie napr. s lambda funkciami - tie pouzivam celkom rad v pythone spolu s qt :)