W dniu sobota, 29 grudnia 2018 14:24:18 UTC+1 użytkownik s...@g...com napisał:
> > > 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.

Nie o to chodzi.
Pytanie brzmi, czy ucząc się C++ dobrze się nauczysz podstawowych koncepcji.

> > > + 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.

Są pisane w dowolnym języku, który jest kompatybilny z systemem
uruchomieniowym. Raczej w C niż w C++, bo C++ ma swój "name mangling",
który komplikuje dużo rzeczy.

> > > + 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.

Ja też. Tym językiem jest język C.
Stroustrup zresztą sam kiedyś stwierdził:

"Within C++, there is a much smaller
and cleaner language struggling to get out."

> 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.

Jeżeli idzie o SDL i OpenGL, to używam na co dzień.
Nawet zrobiłem framework, który udostępnia mi te interfejsy
do interpretera Scheme'u: http://puszcza.gnu.org.ua/software/slayer/

I nie, nie na każdej platformie. Na embedach niestety nie działa.
STL i Boost? Mam lepsze zajęcia. Qt? Może ma sens w niektórych
zastosowaniach.

> 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).

Jak to kiedyś powiedział mój kolega,
"nikt, kto kroi chleb, nie myśli, że wysyła wiadomość do noża,
nakazującą mu krojenie chleba, albo do chleba, nakazującą
mu się pokroić".
W każdym razie ja nie znam nikogo takiego. Jak chcę przesunąć kamień,
to przesuwam kamień, a nie mówię do kamienia: kamień.przesuń(się).
O tym zresztą też pisałem:
https://www.quora.com/Why-is-OO-programming-consider
ed-bad-by-some-people/answer/Panicz-Godek

> > > + 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.

Brzmi to dla mnie jak "wielodziedziczenie jest dobre, bo rozwiązuje niektóre
problemy, które wprowadza mechanizm dziedziczenia".

> > 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.

A dlaczego bez przeładowania operatorów miałbyś nie móc porównywać
złożonych typów?

> Albo by napisać zoptymalizowany menadżer pamięci w aplikacji jednowątkowej (trochę
to trąci myszką w dzisiejszych czasach...).

W różnych okolicznościach pisanie menadżera pamięci może mieć sens.
Tyle że do tego żadne przeładowania operatorów nie są potrzebne.

> > > + 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.

Kurde, szkoda że nikt mi o tym nie powiedział, jak pisałem
pracę magisterską.

> > > + 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.

Warto zapoznać się z tą prezentacją:
https://fsharpforfunandprofit.com/rop/

> > > + 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).

Co to znaczy: "wolność, ale nie w tak szerokim zakresie"?

> > > + 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.

Podobnie jak w przypadku wielu innych języków.

> > > + 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).

"biblioteki w asemblerze i C" można włączyć do każdego języka, który
ma jakąś implementację FFI.
Dużo języków ma dużo bibliotek. Na przykład Python (który dodatkowo
ma FFI). Albo Java.

> > > + 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++.

Prezentacja dotyczy w całości języka C++. D jest może wspomniany
gdzieś na końcu, i to bardziej kokieteryjnie.