Tentokrát jen krátce. Nedávno byl schválen nový standard C++11 (dříve provizorně označovaný C++0×), který kromě rozšíření syntaxe přidává užitečné třídy do standardní knihovny STL. Bohužel ne ve všech překladačích můžete využít vše, co nový standard nabízí.
Clang (frontend pro LLVM) ve své nejnovější verzi nemá lambda výrazy. Místo nich má „bloky“ (proprietární uzávěry), které se ovšem kromě syntaxe drobně liší od normy i sémantikou. Nevýhodou je, že tyto uzávěry nejsou typu std::function<…>, takže zatímco v GCC nebo Visual Studiu klidně napíšete např. std::thread t([](){ /* kód vlákna */ }), uzávěr takto přímo použít nelze. Řešení je jednoduché, můžete si napsat třídu, do které uzávěr zabalíte a přetížíte operátor (), takže nakonec dostanete objekt typu std::function<…>. Přesto se ale jedná o zbytečnou komplikaci.
Naopak Visual Studio (ani ve verzi 2011, tedy preview pro WinRT) nepodporuje rychlou enumeraci ve for cyklu. Tedy vlastně podporuje, jen ne podle standardu. V GCC nebo clangu můžete použít for (auto& element : vector), Visual Studio podporuje jedině for each (auto& element in vector) (což Microsoft zavedl už dříve v C++/CLI pro enumeraci kolekcí v .NET).
Píšete-li kód, který má fungovat ve více překladačích, lze oba uvedené problémy řešit jednoduše makry, jen to trochu znepřehlední kód. Podpora nových věcí v STL je naopak velmi dobrá (byť ne kompletní) jak v clangu, tak ve Visual Studiu.
NB: Úsměvná poznámka na okraj, na for each a obecně na všechna klíčová slova obsahující mezeru má Microsoft patent :-)
Podle mého názoru Range-based for-loop je pěknej hack.
Ona práce s iterátory begin() a end() je obecne velky opruz, protoze iteratory v jednom kuse musi vyhodnocovat funkci end() a operátor porovnávání. Při předávání rozsahů musím dodat tři proměnné. Kontejner, začátek a konec.
Já jsem šel cestou spíš javovského iterování typu hasItems() a next() a je to podle mě lepsi, nicmene for na tomhle nevyuziju. Jo maximalne to mohu psat takto:
for (auto x = c.getIterator();x.hasItems();) {auto a = x.getNext();...}
[5] Iterátory nemusí pořád vyhodnocovat metodu end, stačí si iterátor na konec na začátku uložit. To je mimochodem doporučené (vyhodnocení end() pro std::list je docela pomalé) a tak to i dělá implementace toho range-based for cyklu:
for (auto it = c.begin(), end = c.end(); it != end; ++it) { ... }
Také není pravda, že v C++11 musí kontejnery implementovat metody begin a end, aby fungovaly v range-based for cyklu. Ten totiž používá funkce std::begin a std::end. Stačí je tedy pro váš kontejner (a vaše iterátory) přetížit.
Dobry den,
rad by som poznamenal, ze C++11 je dost hlupy standard. Programatori sa uz dnes ucia C++03 10 rokov a stale nic nevedia... Kym sa ludia naucia C++11, pride aj tretia svetova vojna a potom nam uz nebude treba pocitace. Preco proste konecne neprejdete na Javu? Nerobte zo seba panov programatorov, co sa hraju ze ovladaju C++ a su skilla a masta a leet haka. Nebojte sa Javy.
Dalej by som rad uviedol svoje skusenosti. Udrite ma tym najlepsim, co mate. Bol som kapitanom futbaloveho timu. Nebudte cudzinci. Ste vsetko zle na svete.
Dakujem za pozornost.
Nemyslim, ze by C++11 byl hloupy standard, spis se mi nelibi, ze se C++ stava stale komplikovanejsim a je otazkou, do jake miry se budou novinky vyuzivat. Spis mam pochyby, zda tlaceni novych konstrukci do jazyka ma smysl. Uprimne: vyuzivame vsechny vymozenosti aktualniho standadu sveho kompilatoru?
U nas prechod z VS6 na VS2008 zpusobil dost problemu, takze se radsi drzime pri zemi. A proc neprejdeme na Javu? O nekterych vecech nerozhoduji sam, ale sefstvo nebo zakaznici. Ted musim delat v C# i kdyz nejsem z toho nadsen.
IMHO otazka nestoji v jakem jazyku, ale v jakem prostredi delame.
[8] Tipni jointa.
@11 No například lambda výrazy jsou hodně užitečné (kvůli expresivitě). Rvalues také (kvůli efektivitě). Komplikovanost C++ je často kritizována (právem), ale nikdo nikoho nenutí využívat vše, co C++ nabízí. Osobně mě potěšilo hlavně rozšíření STL (např. std::thread, std::chrono apod.), protože teď bude stejný kód pro všechny platformy.
Autor se zabývá vývojem kompilátorů a knihoven pro objektově-orientované programovací jazyky.
Přečteno 35 404×
Přečteno 24 418×
Přečteno 23 161×
Přečteno 19 655×
Přečteno 16 905×