LLVM 3.3

Akkor a DragonEgg minden bizonnyal egy hiba a mátrixban.

Es mennyire igaza van a clang-nak. Pl. en nagyon utalom, hogy pl. az stdlibc++ std::set-ben nincs emplace() fuggveny implementalva (as of gcc 4.7.3). Pedig a szabvany szerint kellene.

Mi szinte az osszes c++11 feature-t hasznaljuk. A szemelyes velemenyem az, hogy nagyon hatekony eszkozoket ad, de azt el kell ismernem, hogy az amugy is komplex c++ meg egy fokozatnyit bonyolodott. Szerintem a c++ teamek technikai vezetesenek alaposan meg kell valogatni, hogy a csapat felkeszultsege alapjan mennyire alkalmazzak az uj dolgokat.

Pl. siman el tudom kepzelni, hogy library kodban hasznaljak az rvalue referenciakat, de alkalmazaskodban mar nem.... Lemondanak a teljesitmenytobblet egy reszerol, de legalabb nem szabadulnak el doglott referenciak a kodbazisban.

Ellenben a lambdak egeszen biztosan nagyon hasznosak lesznek, sok design egyszerubbe valik, ugyanigy a variadic template-ek hasznalata is sok helyen elegansabb/olvashatobb kodot eredmenyez. Ugyanez igaz a range-based for ciklusokra.

A mi projektunkben sajat smart pointer osztalyok vannak, de a unique_ptr es shared_ptr atgondolt hasznalata helyenkent sokat segithet. Plane ugy, hogy a shared_ptr-re a szabvany eloirja a szalbiztossagot.

std::chrono: szerintem kicsit over-engineered megoldas, de barmi jobb a unix-os idokezelo fuggvenyek tulburjanzasanal
std::regex: nem hasznaljuk
std::thread&std:atomic&co: mar 10 eve is kellett volna. atlathato, hordozhato, korrekt
std::future/std::promise: nagyon jovobe mutato, szerintem jo library-ket lehet epiteni erre a koncepciora (pl. a szalhataron atdobott kivetel eleg utos gondolat), a c++14y-ra valszeg a hianyzo reszek is meglesznek

Ha a jovore nezve valamit kivanni lehetne, akkor en azt kernem a Telapotol, hogy a boost::asio-t minel hamarabb emeljek be a szabvanyba, de szerintem ez csak a 2017 kornyeki verzioban esedekes....

Így már érthető, tehát a GCC hiába támogatja a C++11 szabványt, ha a hozzá tartozó libstdc++ még nem.