> > Jest dobry:
> > + jest prawdziwy (w nim się pisze wszelkie poważne systemy - nawet oprogramowanie
do F-35 napisano w C++ rzucając wcześniej stosowaną Adę np. w F-22 i Euro Fighter
2000)
>
> Nawet jeśli tak jest, niekoniecznie czyni to go dobrym do nauki.

Ofszem jest: masz pewność, że nauczysz się czegoś co jest używane, działa i się
rozwija.

> > + jest kompatybilny (z najważniejszymi językami: Asemblerem i C, a do pozostałych
języków można w nim tworzyć rozszerzenia)
>
> Prawie każdy używany współcześnie język umożliwia wywoływanie natywnych
> funkcji

Tak są one pisane w C/C++. O tym właśnie wspominałem.

> > + produkuje bardzo szybki, natywny kod (nie wymaga żadnej wirtualnej maszyny czy
interpretera)
> > + jest dobrze rozwinięty i nadal rozwijany
> > + jest dobrze zrozumiany i jest sprawdzony
>
> Oto przykład na to, jak dobrze jest zrozumiany:
> http://flyingfrogblog.blogspot.com/2013/10/herb-sutt
ers-favorite-c-10-liner.html

Ja mam inną strategię: używam tego podzbioru języka jakiego jestem pewny. Nie gonię
jak idiota za wszystkimi nowościami. Skupiam się na działaniu moich programów i jak
coś jest bardzo przydatne to próbuję ostrożnie to wdrażać. np. for(klasa i :
kontener), albo lambdy, a zamiast konwertować sprytne wskaźniki po prostu używam
QSharedPtr - ale to i tak jest mało przydatne, bo biblioteka Qt nie opiera się na tym
tylko na surowych wskaźnikach.

> > + jest wieloplatformowy (jeśli się użyje odpowiednich bibliotek: Stl, Boost, Sdl,
OpenGl czy Qt i jeśli się umiejętnie wydziela wywołania nieprzenośnych funkcji)
>
> Tzn. jest wieloplatformowy, jeśli na każdą platformę pisze się osobny kod?

Widać, że słaby jesteś w te klocki, bo nie masz pojęcia jakie możliwości mają te
wymienione biblioteki. Ale jestem cierpliwy i miły, więc wyjaśnię: nie wszystkie
możliwe przypadki są przewidziane w bibliotece i wtedy też trzeba sobie poradzić i
C++ umożliwia wybrnięcie z tego co najmniej na 2 sposoby: #ifdef #else #endif lub
kompilacją warunkową (te drugie rozwiązanie jest dużo lepsze i ja je zalecam)

> > + jest obiektowy
>
> A dlaczego to jest dobre?

Bo to odbicie ludzkiego pojmowania świata: obiekty z określonymi funkcjami (w
moralności dostępne funkcje to stopnie swobody - im człowiek jest bardziej wolny to
ma więcej dostępnych obiektów i funkcji - czyli stopni swobody).

> > + wspiera wielodziedziczenie
>
> A dlaczego to jest dobre?
> I czy jesteś w stanie podać przykład jakiegoś problemu,
> dla którego wielodziedziczenie byłoby dobrym (albo jedynym sensownym)
> rozwiązaniem?

Ofszem! Od paru lat piszę kolejne wersje mojego edytora tekstu. Początkowo się
oparłem na własnej implementacji kolorowania składni, jednak odkryłem, że Kde
udostępnia odpowiednią bibliotekę z kolorowaniem ponad 200 języków. QPlainTextEdit ma
coś takiego jak bloki (które normalnie są pojedynczymi liniami) do bloku można
przypisać jeden obiekt dziedziczący po określonej klasie (co jest wadą tego
rozwiązania bo powinno być ich wiele). Problem w tym, że ten syntaxhighlighter z Kde
już używa tej zmiennej/obiekt. Dlatego ja chcąc zaimplementować zakładki muszę
wydziedziczyć po klasie z biblioteki Kde i po mojej klasie LineInfo. By to zadziałało
muszę do mojego edytora dodać callback który będzie tworzył te obiekty. Rozwiązanie
mam zakodowane i skompilowane, jednak problem z dynamicznie ładowanymi pluginami na
razie uniemożliwia mi uruchomienie programu. Jednak wcześniejsza wersja monolityczna
działała na tej samej zasadzie.

> Robiłem ostatnio rozeznanie w temacie, i trafiłem na książkę
> "Object Oriented Programming. An evolutionary approach", gdzie
> jako przykład podano, że języki z wielodziedziczeniem pozwalają
> reprezentować "zabawkową ciężarówkę" jednocześnie jako rodzaj
> zabawki, jak i rodzaj ciężarówki.
> Firmy logistyczne będą zachwycone.

Generalnie wielodziedziczenie umożliwia rzeczy nie możliwe do osiągnięcia w inny
sposób. Tak jak u mnie gdzie musiałem rozszerzyć istniejącą klasę by móc użyć
pojedynczej zmiennej w QPlainTextEdit - głowiłem się nad innym rozwiązaniem ale brak
pełnego dostępu do wnętrza tej klasy uniemożliwia inne podejście.

> > + ma możliwość przeładowania operatorów
>
> A dlaczego to jest dobre?

Np. by móc porównywać złożone typy. Albo by napisać zoptymalizowany menadżer pamięci
w aplikacji jednowątkowej (trochę to trąci myszką w dzisiejszych czasach...).

> > + ma wsparcie dla metaprogramowania (szablony)
>
> C również ma "wsparcie dla metaprogramowania" (preprocesor).
> Są języki, które mają naprawdę o wiele lepsze wsparcie dla
> metaprogramowania (Lisp, OCaml, Haskell)

Możliwe, tylko, że te języki nie istnieją dla pracodawców, ani nawet dla uczelni.

> > + wspiera wyjątki (jako sposób obsługi błędów)
>
> A dlaczego to jest dobre?

Bardziej naturalne podejście i duuużo bardziej niezawodne. Choć w aplikacjach
zdarzeniowych i wielowątkowych robi się upierdliwe, ale i tak jest to lepsze niż
sprawdzanie wartości zwracanej.

> > + wspiera wiele stylów programowania i wiele paradygmatów programowania
>
> Podobnie jak wiele innych języków.

Wiele, ale są też takie które dopuszczają wolność, ale nie w tak szerokim zakresie (w
połączeniu z innymi cechami).

> > + darmowy
>
> Podobnie jak wiele innych języków.

Tu chodziło mi raczej o podkreślenie, że nie generuje dodatkowych kosztów - wystarczą
chęci i samozaparcie.

> > + ma bardzo dobre BIBLIOTEKI DO WSZYSTKIEGO na liberalnych licencjach
>
> Podobnie jak wiele innych języków.

ŻADEN INNY JĘZYK NIE MA TYLE BIBLIOTEK (bo włączyć do repertuaru można biblioteki w
Asemblerze i C a w drugą stronę już słabo).

> > + jest przyjazny dla ucznia (można go poznawać stopniowo - w miarę potrzeb)
>
> A znasz jakiś język, którego nie można poznawać stopniowo?

Nie szukałem... Tą zaletę pamiętam z Symfonii C++ Jerzego Grębosza (chyba miał na
myśli to, że efekty szybko się pojawiają przy jego nauce).

> > + jest wiele podręczników (z Opus Magnum Jerzego Grębosza na czele)
>
> Nie czytałem, to się nie wypowiem.
> Ale "Język C++" Stroustrupa to w moim odczuciu naprawdę kiepska książka.

To bardziej wyrocznia w sprawach nie oczywistych i mało znanych. Jerzy Grębosz pisze
dużo bardziej zrozumiale (może to kwestia tego, że nie wymagało to tłumacza?!?).

> Zresztą nawet Scott Meyers, autor książek z serii "Effective C++",
> już sobie odpuścił.
> https://www.youtube.com/watch?v=KAWA1DuvCnQ&feature=
youtu.be

Nie mam czasu godzinę się męczyć wsłuchując się w monolog po angielsku... I w
zasadzie nie obchodzi mnie to, że woli pisać w D niż w C++. Ja wiem, że D jest do d*
i to nie dlatego, że ma braki składniowe tylko wsparcie jest marginalne (debuger,
środowisko programistyczne i społecznościowe, brak biblioteki graficznej, muzycznej,
profilera) - takimi językami można się podniecać w szkole średniej, ale (najpóźniej)
na studiach powinno przyjść otrzeźwienie - liczą się szczegóły dzięki którym można w
pełni osiągnąć cel a nie co chwila z czegoś rezygnować, bo się nie da... Podobna
uwaga tyczy się wynalazków typu Raspberry - np. teraz nie można skompilować Qt 5.12
na Amd64 kroskompilując na Arm32 bo Raspberry nie zaktualizowało kros kompilatora od
4 lat...