Old C++ VS C++11, 14, 17

[Petr]

C++11 podle mě minimum a C++17 pro nové projekty určitě:

  - stricter expression evaluation order (C++17) - šel bych ještě dál
  - guaranteed copy elision (C++17)
  - noexcept in typedefs (C++17)
  - nested namespaces (C++17)
  - [[fallthrough]], [[maybe_unused]], etc... (C++17)
  - std::string_view (C++17)
  - relaxed constexpr (C++14)
  - enum : type (C++11)
  - constexpr (C++11)
  - move semantics / rvalue (C++11)
  - lambdas (C++11)
  - auto (C++11)
  - a mnoho dalších

Možná další ne až tak důležité věci, ale konečně:

  - Removing trigraphs (C++17)
  - Removing 'register' keyword (C++17)
  - Removing throw(...) specifications (C++17)

Z knihoven bych určitě zmínil <cmath>, <atomic>, <utility> a <type_traits>, které jsou podle mě super použitelné. Pro některé to může být i threading, ale já osobně si radši dělám vrstvu nad OS sám. Kontejnery z std nepoužívám, protože teď většinou píšu knihovny a tam je potřeba aby to neházelo výjimky nebo rovnou mělo C-API. S C++17 jsem celkově spokojený a je to určitě krok dopředu, ale asi bych byl radši, kdyby se specifikace víc zaměřovala na jazyk samotný a ne na to co je v std.

Co se týče překladače tak bych doporučil Clang a hned za ním GCC - MSVC a ICC jsou dnes už hodně pozadu. Občas o tom i něco napíšu tady, ale není moc času no

[Reklama]

[Miloslav Ponkrác]

S C++17 jsem celkově spokojený a je to určitě krok dopředu, ale asi bych byl radši, kdyby se specifikace víc zaměřovala na jazyk samotný a ne na to co je v std.

Tak toto můžu jedině podepsat. Uvítal bych, kdyby se méně řešilo STL, ale o to více samotný jazyk C++.

Co se týče překladače tak bych doporučil Clang a hned za ním GCC - MSVC a ICC jsou dnes už hodně pozadu

Je naprosto běžné, že kompilátory implementují standardy s cca dvouletým zpožděním. To je do jisté míry i znakem serióznosti kompilátoru. Chcete dělat svůj projekt a mít odladěný kompilátor. Doby, kdy si člověk hrál na alfa testera kompilátoru (u Borlandských C++ překladačů) jsem zažil kdysi dávno - a nikdy více.

Tedy osobně bych posečkal s bezhlavým používáním C++17, a projekty jedu s tím, že C++14 je jistota. A C++17 je ještě příliš příliš čerstvé, abych čekal odladěnost, podporu a spolehlivost kompilátorů.

Standard C++17 byl vydán v prosinci 2017. Očekávat, že kompilátory nebudou mít problémy - je naprostý nesmysl.

***

Co mě naprosto nevyhovovalo a nevyhovuje je situace v GCC. GCC se snaží implementovat vše, co je v draftech a diskusích standardizační komise. Tedy i to, co se může, a nejspíše také bude velmi měnit a konečná podoba ve standardu bude s vysokou pravdědpobností odlišná. Momentálně se snaží implementovat vše, co se šustne kolem budoucí revize C++2x.

Ve výsledku je to tak, MSVC implementuje mnohem lépe C++17 a ve větší šíři než GCC. Clang je na tom s implementací ještě hůře než GCC. Kdyby se raději GCC a Clang snažili korektně, seriózně a úplně implelentovat už existující standardy C++ a revize - udělaly by lépe.

https://en.cppreference.com/w/cpp/compiler_support#cpp17

Osobně jsem měl v minulosti opakovaně problém právě s GCC a C++. Jsem zvyklý využívat celý standard, a v C++ nadšeně používám skoro vše, co umí. A narážel jsem až příliš často u GCC na nesouhlad se standardem C++. Po časem mě to přestalo bavit, a GCC používám jen neochotně.

[Petr]

Já jsem myslel pozadu co se týče optimalizací, což mi přijde u C++ jako jedna z nejdůležitějších věcí. Co se týče standardu tak GCC/Clang na tom jsou velmi dobře a přijou mi hodně striktní - úroveň varování se dá navíc nastavit celkem jednoduše a každý warning má svůj název a ne nějaké hloupé číslo jak v případě MSVC.

Těžko odpovědět na zbytek, pokud nemátě něco konkrétnějšího co by se dalo demonstrovat např. přes <a href="https://godbolt.org/>Compiler Explorer[/url]. Co se týče otestovanosti tak už hodně dlouho se mi nestalo, že bych hitnul nějaký compiler bug u GCC/Clang, ale stalo se mi to ve VS2015 i VS2017 a na opravu bugu ve VS se čeká roky!

[Petr]

Compiler Explorer (nějak mi ten odkaz předtím uletěl)

[Miloslav Ponkrác]

Já jsem myslel pozadu co se týče optimalizací, což mi přijde u C++ jako jedna z nejdůležitějších věcí. Co se týče standardu tak GCC/Clang na tom jsou velmi dobře a přijou mi hodně striktní - úroveň varování se dá navíc nastavit celkem jednoduše a každý warning má svůj název a ne nějaké hloupé číslo jak v případě MSVC.

Přitom úsměvné je, že GCC na tom velice dlouho bylo špatně s optimalizacemi, a generoval mnohem pomalejší kód než MSVC.

Složité šablony a STL kontejnery jsem i na Linuxu odlaďoval tak, že jsem si přepnul do Windows a MSVC. Na MSVC jsem to odladil, a pak se vrátil do Linuxu. Důvodem byly zmatené chybové zprávy a warningy v GCC - pokud vůbec. Když uděláte chybu v STL kontejneru, tak to jednoduše v GCC tiše sletí. V MSVC vám napíše, co jste udělal špatně. To co bych hledal za chybu v GCC tři dny, to mi MSVC napíše rovnou po prvním spuštění - takové jsou mnohaleté praktické zkušenosti se souběžným vývojem na MSVC a GCC.

Zbytečně pomlouváte MSVC, přičemž já bych si ho pro C++ vybral tisíckrát raději pro vývoj než cokoli jiného. Je to seriózní kompilátor zaměřený na seriózní vývoj. Lépe hlásí chyby, jak kompilátor, tak runtime - zejména ve složitých šablonách.







Těžko odpovědět na zbytek, pokud nemátě něco konkrétnějšího co by se dalo demonstrovat např. přes <a href="https://godbolt.org/>Compiler Explorer[/url]. Co se týče otestovanosti tak už hodně dlouho se mi nestalo, že bych hitnul nějaký compiler bug u GCC/Clang, ale stalo se mi to ve VS2015 i VS2017 a na opravu bugu ve VS se čeká roky!
[/quote]

[Reklama]

[Miloslav Ponkrác]

Těžko odpovědět na zbytek, pokud nemátě něco konkrétnějšího co by se dalo demonstrovat.

Spíše to vypadá tak, že chválíte a haníte kompilátory podle vašich sympatií a antipatíí. Přičemž realita je často naprosto opačná než tu píšete.

[Petr]

To samé se ale dá říct o vás. Vyzdvyhujete tu MSVC a přitom tu nepadl žádný konkrétní argument / příklad - kód je pro mě v tomto případě víc než slova. Já se aspoň snažím v tom blogu (když mám čas) a moje hodnocení je vždy na základě vygenerovaného kódu a né osobních preferencí.

GCC před 4.0 byl porod používat a MSVC v té době generoval mnohem lepší kód, s tím souhlasím, ale já žiju v současnosti a mám k dispozici mnohem lepší nástroje než tehdejší 10 let starý GCC. Navíc vyrostla obrovská konkurence jménem Clang, takže tu máme 2 open source překladače, které si vzájemně konkurují a profitujeme z toho všichni.

[m]

GCC před 4.0 byl porod používat a MSVC v té době generoval mnohem lepší kód, s tím souhlasím, ale já žiju v současnosti a mám k dispozici mnohem lepší nástroje než tehdejší 10 let starý GCC. Navíc vyrostla obrovská konkurence jménem Clang, takže tu máme 2 open source překladače, které si vzájemně konkurují a profitujeme z toho všichni.

j to je presne. Nynejsi GCC a LLVM Clang je nesrovnatelny s tim co bylo pred 10 lety.

A to taky zabilo veci jako MSVC:D

[y,]

MSVC bylo zabity Microsoftem kvuli jejich pristupu "nedelame prekladac pro standard C++, delame prekladac pro windows".
Zkusite si dneska MSVC 18 (kde se chlubi, ze podporuji C++11 kompletne a C++14 castecne, iirc), prelozit treba takovou aktualni verzi OpenFST (take C++11 a zadne extremni silenosti).

[Sten]

S C++17 jsem celkově spokojený a je to určitě krok dopředu, ale asi bych byl radši, kdyby se specifikace víc zaměřovala na jazyk samotný a ne na to co je v std.

C++17 se zrovna na jazyk zaměřuje hodně:

• vnořené namespacy
• inicializátory v if a while
• if constexpr
• structured binding (auto [a, b] = funkce();)
• dedukce parametrů šablon z konstruktorů
• opravené auto u univerzální inicializace

Pár velkých zvažovaných věcí vypadlo (koncepty, reflexe), ale to kvůli tomu, že potřebují víc času, vývoj pro C++17 se u nich hodně posunul.

Je naprosto běžné, že kompilátory implementují standardy s cca dvouletým zpožděním.

Možná ten microsoftí, ten má dodnes problémy s C++14 Clang až na pár drobností C++17 podporuje. Velmi dobře podporoval C++17 už před oficiálním vydáním toho standardu, dokonce tak dobře, že jsme ho začali používat už v loňském březnu. Žádné problémy jsme u oficiálně podporovaných vlastností nepozorovali.

[hawran diskuse]

...

To s tou reflexí mne mne uhodilo do mých starých oků, určitě si to pak můžu dohledat (na isocpp už jsem se nedíval fakt hodně dlooooouho), ale teď by mi stačil rychlý nástřel: navrhuje/plánuje/... se reflexe v c++?

[Rado2]

Možná ten microsoftí, ten má dodnes problémy s C++14

Tak to je niekolko rokov stary dokument pre stare VS 2015 Ak ta to zaujima, novsi si najdes, inak VS sa dost casto aktualizuje a stale nieco zo standardu pribuda, ale nesladujem to, nepouzivam najnovsie veci.
Toto porovnanie ani nie je pre mna az tak dolezite, ak cielim na win, pouzijem MSVC, ak na Mac tak clang v Xcode (i ked to IDE je cisty masochizmus). Na linux som v poslednej dobe viac-menej pokusne pouzival z win Visual Studio IDE s jeho remote kompilaciou na linuxe - myslim gcc. Vsetko na jednom cross-platform projekte. Uz si nepamatam co to bolo, ale nejaku feature c++ som pouzil v MSVC a musel som ju dat prec, lebo nesla na gcc a tiez sa mi stalo ze nejaky kod gcc doslednejsie kontroloval podla standardu a co povodne slo na MSVC som musel upravit. To su ale drobnosti.

[Sten]

To s tou reflexí mne mne uhodilo do mých starých oků, určitě si to pak můžu dohledat (na isocpp už jsem se nedíval fakt hodně dlooooouho), ale teď by mi stačil rychlý nástřel: navrhuje/plánuje/... se reflexe v c++?

Plánuje se, compile-time reflexe byla jako možnost plánovaná už pro C++17, tak snad v C++20 bude, i když pořád tam je vedena jen jako „possibly“. Run-time reflexe je spíš na wishlistu, nějaké návrhy jsou (třeba operator $), ale konkrétní revize standardu, kam by to chtěli dát, zatím nepadla.

[Rado2]

Este k povodnej otazke - roky som pouzival stare C++ - ale hlavne s MFC, std skoro vobec. Potom som presiel na C# a teraz trochu C++11/14/17. Co sa tyka jazyka (ale aj std), robi sa s tym samozrejme lepsie a to ani nepouzivam a nepoznam vsetky vylepsienia.
Stale som fanusik C++, ale bohuzial robi sa s tym stale horsie ako v C#, hlavne koli std kde nie je ani poriadna podpora pre stringy. Taktiez iteratory sa krkolomne pouzivaju, mozno sa to zlepsi prichodom ranges. V dnesnej dobe je dost hadicap ze std nema vstavanu podporu pre unicode stringy, aj ked chapem ze by to znacne zvacsilo kniznicu, ale aj jednoduche operacie ako rozdelenie stringu na slova so zadanym oddelovacom a pod. treba zlozito riesit vlastnymi utility funkciami, alebo pouzivanim BOOST. Zakladna kniznica musi byt spravena tak, aby nad stringami clovek nepotreboval ziadne vlastne utility a externe kniznice.
Mimochodom BOOST je velky moloch. Chcel som pred par rokmi pouzit len stringove kniznice, ale ten ich tool, ktory ma z boostu vysekat len vybrane veci mi generoval neskompilovatelny vycuc z boostu (a to som sa s tym pol dna hral a postupne pridaval veci, co mu chybali), musel som ho nakoniec pouzit cely 
No a naposledy som zabil snad niekolko dni aby som zistil, ako cross-platformovo sformatovat sumu v narodnom formate s vlastnym symbolom pre menu. Takze ja by som povedal ze by sa bolo treba zamerat na riesenie praktickych problemov.

[Petr]

S tím zaměřením na jazyk samotný myslím hlavně to, že C++ Committee se zabývá blbostma typu "2D graphics library", které nemají v samotném C++ co dělat.