🚀 go-pugleaf

W dniu poniedziałek, 11 czerwca 2018 06:38:10 UTC+2 użytkownik szyk...@gmail.com napisał:
> > PS: ...a najlepiej porzuć zgrzybiałego staruszka z dwoma krzyżykami
> >       na karku np. na rzecz Pythona :)
> 
> Tak się jakoś składa, że:
> * ogromne możliwości C++ nie wpływają negatywnie na szybkość działania, bo jezyk jest w całości zaprojektowany przede wszystkim pod kątem szybkości.

Raczej chodziło o implementację OOP w języku tak niskopoziomowym jak C: https://www.youtube.com/watch?v=JBjjnqG0BP8
Czyli połączenie dwóch światów: niskopoziomowego C z abstrakcjonizmem znanym z Simula. 

> Więc jego wszystkie zaawansowane funkcje są uwzględniane jedynie w czasie kompilacji do kodu maszynowego (po kompilacji są jedynie funkcje i zmienne jak w Asemblerze, natomiast cały obiektowy majdan jest spłaszczany i nie istnieje w pliku exe/so/dll).

Nie do końca się zgodzę, bo struktura vtable, która jest esencją tego "całego obiektowego majdanu" tam jest i jest nie do pominięcia.

> * C++ daje w wyniku NORMALNE programy (bez konieczności łączenia programu z maszynami wirtualnymi, interpreterami, jakichś zwyrodniałych kompilacji do kodu bajtowego i innych wynalazków w stylu Jit). W C++ po prostu masz plik exe czy so/dll i po prostu to działa.

Z tą dokładnością, że ten plik exe czy so/dll działa tylko dla systemu i architektury dla której został przygotowany i nie ma technicznych możliwości poza emulacją (czyli jakieś maszyny wirtualne, interpretatory czy JIT) aby uruchomić go na czymś innym. Tej wady nie mają języki które korzystają z wspomnianych wyżej maszyn wirtualnych, interpretatorów byte-kodu czy JIT. Generalnie coś za coś. 

> * poważne biblioteki są tylko w C i C++ (i bez problemu można użyć ich obu rodzajów)

Cokolwiek masz na myśli pod pojęciem "poważne", to z wymiennością C i C++ nie jest tak różowo. Owszem, bez problemu i jakichkolwiek starań możesz użyć funkcji napisanej w C bezpośrednio w programie napisanym w C++, ale odwrotne działanie już jest mocno problematyczne.
Z tego co obserwuję podczas pracy, to biblioteki napisane w C/C++ (mające API dla tych języków) to przede wszystkim funkcjonalności niskopoziomowe, może "średnio" poziomowe. Wszelkie wysoko-poziomowe albo nie mają API dla C/C++ albo istniejące API jest zrobione "aby było i można było wpisać do CV", z wersją 0.1 beta aktualizowaną 4 lata temu. Oczywiście YMMV.

> * w C++ można pisać przenośne programy (przenośne między systemami operacyjnymi), a jednocześnie mogą dobrze zintegrowane z systemem operacyjnym na którym działają (po przez klauzule typu: #ifdef Q_OS_WIN) - jest to bezproblemowe i bez udziwnień i nie wymaga stosowania niczego innego poza Api danego systemu operacyjnego.

Przenośne w sensie kodu źródłowego do skompilowania, tak można. Warunkiem jest jednak rozwiązanie ogromnej ilości pobocznych problemów związanych z różnicą API takich systemów.

> * program w C++ z definicji powinien dużo szybciej działać niż wspomniany Python czy Java czy C#. Gdyż one właśnie są pisane w C++ na bazie jego zalet są tworzone.

W pewnym sensie masz rację, jednak w pozostałym się mocno mylisz. Java może być skompilowana do natywnego kodu. A w pewnym sensie nawet kod binarny na poziomie współczesnych procesorów jest "interpretowany" na poziomie sprzętowym. 

> * programy w C++ dają akceptowalną szybkość działania w przypadku programów narzędziowych (typu edytory grafiki czy Ide). Tego typu programy pisane wyłącznie np. w Pyhtonie działają po prostu strasznie. Podobnie jest z Java i np. Eclipse (to istnie zaćmienie umysłowe musiało być u tego kto postanowił napisać to w tym języku).

Zależy od tego jak to programista napisał i generalnie nie zależy od wybranego języka.

> * ten kto nie potrafi pisać programów w Asemblerze i C/C++ ten nie jest prawdziwym programistą. Bo bez tych języków zwyczajnie nie wie jak działa procesor (Asembler) oraz nie wie jak pisane są (a tym samym nie zna możliwości jakie dają) współczesne systemy operacyjne (C/C++).

Na obecnym etapie rozwoju informatyki pisanie w Assemblerze jest skrajnie nieefektywne nie tylko ze względu na czas poświęcony na napisanie takiej aplikacji ale także ze względu na możliwy do osiągnięcia poziom optymalizacji kodu. W tej materii kompilatory już dawno prześcignęły możliwości człowieka. Owszem pojedyncze, specjalizowane funkcje można napisać lepiej i często tak się robi. To są jednak wyjątki.

> * języki typu Python nadają się jedynie do pisania jakichś małych skryptów do automatyzacji przetwarzania tekstów. Które pisze się samemu, dla siebie i odpala się tylko u siebie i nie martwi się o czas ich działania. Do tego używam Pythona i w tym on się sprawdza...

Python, Java itp. języki już dawno dorobiły się ogromnej ilości wysoko-poziomowych bibliotek/narzędzi (o czym pisałem powyżej) przez co pisanie całych aplikacji jest w tych językach znacznie prostsze, efektywniejsze i przez to znacznie tańsze. To już od dawna nie są tylko proste skrypty.