C++ 14 - Wasze Opinie

JVM robi niemal wszystkie optymalizacje jakie robi gcc na poziomie O2 i dokłada trochę własnych, co jest wystarczające dla nawet bardzo wymagających wydajnościowo projektów. Jak Java jeszcze dostanie niebawem value classes to będzie pozamiatane.

Takie coś już istnieje. Nazywa się C# i CLR. :P

CLR ma wprawdzie value types (mocno ograniczone i wcale nie takie szybkie; mogę się założyć, że JVM będzie mieć lepsze), ale nie umie robić paru innych rzeczy, które umie robić JVM, przez co w moim odczuciu i tak nadal JVM jest szybszy na serwerze. Np. JVM ma znacznie lepsze zarządzanie pamięcią (pauseless GC, offheap allocation) i obsługę dużych stert (> 128 GB), co jest bardzo istotne w aplikacjach serwerowych. No i CLR chodzi tylko na jednej niszowej platformie - Windows. Mono się nie nadaje na produkcję. Stąd na razie CLR widzę głównie do jakiś okienek (typu "system" PKW) i prostych webappek a nie poważnych aplikacji serwerowych o skali takiej jak ma Google albo eBay. Jak CLR będzie oficjalnie wspierany na wszelkiej maści Uniksach, Macach oraz urządzeniach mobilnych co JVM, to będzie można sobie porównywać, a na razie IMHO nie ma startu do Javy. Ale odeszliśmy trochę od tematu... Tak czy inaczej, na Windows to C# jest preferowanym sposobem programowania większości aplikacji, nie C++, mimo zaklinania rzeczywistości przez Herba Suttera (tj. cały C++ renaissance, który się nie wydarzył). 

Co do bibliotek - w takim razie wyjaśnijcie mi, dlaczego do C++ nie ma tylu dobrych bibliotek jak są w Javie i C#? Biblioteka standardowa dopiero od niedawna zaczyna wychodzić na ludzi (C++14), choć jeszcze długa droga. Dlaczego producenci wypuszczają je na licencjach typu GPL zamiast np. Apache / MIT jak to się dzieje dla Javy/C#? Przecież i tak na nich nie zarabiają. Dlaczego biblioteki nie trzymają żadnego wspólnego stylu, tylko każdy wymyśla sobie własny styl API - jeden zrobi coś super mocno na szablonach, inny zrobi OOP, jeszcze ktoś inny będzie używał surowych wskaźników z C, a inny smart pointerów, a jeszcze inny oleje STL i wprowadzi własne kontenery i klasy stringów (jak Qt albo dawniej Borland), jeden będzie używał kodów błędów, inny wyjątków itp.? Nikt tak naprawdę nie wie jak się w C++ *powinno* kodować i tu jest problem.

CLR ma wprawdzie value types (mocno ograniczone i wcale nie takie szybkie; mogę się założyć, że JVM będzie mieć lepsze), ale nie umie robić paru innych rzeczy, które umie robić JVM

Ależ ja o tym wiem, dlatego na końcu mojego posta było takie dziwne ":P", którego celem jest sygnalizowanie, że żartuję.

Nikt tak naprawdę nie wie jak się w C++ *powinno* kodować

Przecież dużo osób doskonale wie, jak powinno się w C++ kodować: wcale. Garstką świrów nie radzę się zbytnio przejmować, im i tak nic nie pomoże.

Co do bibliotek - w takim razie wyjaśnijcie mi, dlaczego do C++ nie ma tylu dobrych bibliotek jak są w Javie i C#? Biblioteka standardowa dopiero od niedawna zaczyna wychodzić na ludzi (C++14), choć jeszcze długa droga. Dlaczego producenci wypuszczają je na licencjach typu GPL zamiast np. Apache / MIT jak to się dzieje dla Javy/C#? Przecież i tak na nich nie zarabiają. Dlaczego biblioteki nie trzymają żadnego wspólnego stylu, tylko każdy wymyśla sobie własny styl API - jeden zrobi coś super mocno na szablonach, inny zrobi OOP, jeszcze ktoś inny będzie używał surowych wskaźników z C, a inny smart pointerów, a jeszcze inny oleje STL i wprowadzi własne kontenery i klasy stringów (jak Qt albo dawniej Borland), jeden będzie używał kodów błędów, inny wyjątków itp.? Nikt tak naprawdę nie wie jak się w C++ *powinno* kodować i tu jest problem.

Standard C++14 ani kolejna wersja nie zrewolucjonizuje języka C++, bo w zasadzie nazwałbym te zmiany mało istotnymi z punktu widzenia szybkości wytwarzania aplikacji.

Co do GPL-a: jak już ktoś wypuścił trochę sensownego gruzu na GPL, a ktoś inny chciał wykorzystać ten sensowny gruz i stworzyć kolejne narzędzie to również był zmuszony do tworzenia kodu na licencji GPL. Tym samym licencja wirusogenna w postaci GPL-a zatoczyła zbyt duży krąg, bo byli 'idioci', którzy propagowali kult kodowania open source z naciskiem na GPL. Java czy też C# powstały znacznie później i można było zapewnić fundamenty już u samych podstaw jak i rozsądne licencje by spopularyzować wspomniane języki programowania.

Kodować w C++ możesz tak jak w Javie czy też w C# i tutaj akurat wymyślanie teorii, że 'nie wiadomo' jak kodować w C++ jest błędne.

Co do powstających własnych kontenerów STL i wprowadzania własnych implementacji:
- STL swego czasu posiadał wolne implementacje, więc powstawały jego alternatywy
- STL nadal nie spełnia założeń wydajnościowych w niektórych aspektach, więc pisze się wówczas własne kontenery (patrz: np. std::deque oraz std::list są mega-wolne). std::list jest wolne bo ma niepraktyczne podejście do zarządzania pamięcią i każda alokacja elementu wymaga odwołania się do zasobów systemowych, co generuje ogromny narzut czasowy. Przykład:
http://cpp0x.pl/forum/temat/​?id=4004

Szybkość wykonania operacji na własnym kontenerze listy (0.025 sek) była 14-krotnie szybsza w porównaniu do std::list własnego kontenera list (0.350 sek). Jest powód do optymalizowania? Jest. Fundamenty po prostu w przypadku większości kontenerów danych są złe, stąd ten 'wielki' sukces Javy czy też C#. Z języka C++ można wycisnąć znacznie więcej jeżeli się wie jak podejść do tematu. To jest kolejna wyrwa w języku C++, która powinna być załatana na poziomie standardu C++ po to, aby nikogo nie kusiło do pisania własnych kontenerów, bo STL jest wolny.