C++ - Dlaczego uważam go za najgorszy język programowania po 2 godzinach analizy?

Sun Dec 07, 2025 12:07 pm   

Oczywiście, że C++:

https://www.youtube.com/watch?v=7fGB-hjc2Gc

Ja myślałem, że da się problemy wskazać w max 15 min i pozamiatane
ale żeby przedstawić wszystkie nonsensy i głupoty tego języka
potrzebne jest 2h literalnego wymieniania to się nie spodziewałem...

--
Marek

Sun Dec 07, 2025 1:39 pm   

W dniu 7.12.2025 o 11:07, Marek pisze:

Oczywiście, że w śród innego guana jest to najlepszy j. prog.


Nikt nie każe ci używać nonsensownych rozw. Ten j. jest b. elastyczny.
np.: w tym j. nie ma nawet wspólnej kl. bazowej dla wszystkich typów (a
tak jest np. w j. skryptowym Java).

Ja osobiście w ramach postulowanej przeze mnie izolacji proj. przezwałem
typy wbudowane z j. C i C++, oraz przezwałem używane kl. z bibl. Qt
własnymi typami (w j. pol.) (więcej na ten temat w całkowicie darmowym
dok. PDF dostępnym na mojej s. WWW:

<https://energokod.gda.pl/monografie/Arch.%20Prog.%20Nieuprzywilejowanych.pdf>

) i stworzyłem sobie 2 bibl.: jedną z podst. kl. i z podst. alg.
potrzebnymi do prog. programów konsolowych, a drugą uzupełnioną o
kontrolki graf. Obie te bibl. oparłem o Qt. I zapewniam wszystkich daje
się normalnie prog. po polsku w j. C++.

Dodatkowo podam, że od 2005r. (rozp. proj. F-35), przemysł zbrojeniowy w
SZAP/USONA powszechnie przechodzi z prog. w j. ADA na C++. Wygląda na
to, że cała nagonka na j. C++ ma na celu ogłupienie cywilnych prog. C++
i utajnienie kol. wer. tego b. udanego j. prog. (zrobienie z niego
"czarnego proj."). Tak jak to miało miejsce w przypadku następców sys.
op. Plan 9 oraz popularnych w latach 1980 i 1990 dżojstkików
(zastąpionych w cywilu pedalskimi padami). Oba te rozw. (i
prawdopodobnie wiele innych) zostały zawłaszczone przez przemysł
zbrojeniowy w SZAP/USONA. Ten temat podjąłem w "Odp. Na Apel Twórcy j.
C++ Bjarne Stroustrup", dostępnym całkowicie za darmo z mojej s. WWW:

<https://energokod.gda.pl/monografie/Odp.%20Na%20Apel%20Tw%C3%B3rcy%20j.%20C++%20Bjarne%20Stroustrup.pdf>

--
Jacek Marcin Jaworski, Pruszcz Gd., woj. Pomorskie, Polska, EU;
tel.: +48-609-170-742, najlepiej w godz.: 5:15-5:55 lub 17:15-17:55;
<jmj@energokod.gda.pl>, gpg: 4A541AA7A6E872318B85D7F6A651CC39244B0BFA;
Domowa s. WWW: <https://energokod.gda.pl>;
Mailowa Samoobrona: <https://emailselfdefense.fsf.org/pl>.

Sun Dec 07, 2025 2:20 pm   

W dniu 7.12.2025 o 12:39, Jacek Marcin Jaworski pisze:

Tak elastyczny, że ciężko zrozumieć co ktoś inny nagrzmocił. Gdyby to
służyło do jednorazowej komunikacji z komputerem to ok, ale języki
programowania służą do wyrażania kodu zrozumiałego dla wszystkich.

Sun Dec 07, 2025 2:36 pm   

On 7.12.2025 11:07, Marek wrote:

to zwykłe pierdolenie. Odpuściłem sobie, gdy koleś porównał w jakimś
aspekcie C++ z JavaScript. Odnoszę wrażenie, że to filmik adresowany
do jakichś web programatorów, a nie poważnych system programmersów.

Sun Dec 07, 2025 4:00 pm   

On 07/12/2025 11:07, Marek wrote:

Tak, to są wszystko nonsensy i głupoty języka, który wymaga
niskopoziomowego sterowania.

Obejrzałem kilka przykłądów z filmu. Koleś, który ten film robił, nigdy
nie pisał oprogramowania niskopoziomowego lub dużej skali:

1) Pretensje że C++ ma ficery takie jak inne jęzki (ukryty self w
metodzie obiektu).
2) Nie rozumienie po co jest using namespace, więc wylanie tam szamba
rozwiązuje problem.
3) C++ się zmienia i to straszne. Nikt nie wie w jakiej wersji pisze.
Szczególnie jak jest Autorem.
4) Nie umiem pisać duzych projektów w C++ więc nikt nie umie.
5) Język jest blisko sprzetu i ma inne rozmiary inta. Straszne,
wszystkie CPU powinny mieć najlepiej 32 bity i finito, reszta na stryczek.
6) Nie rozumiem unix IO więc nikt nie rozumie.
7) Patrzcie, jak łatwo można porównać gówno javastriptowe z szablonową
bibliteką C++! Ależ to javascriptowe gówno jest lepsze jak Twój cały
świat to stringi!
Niewiarygodne, że niskopoziomowe języki jak C++ nie pilnują
samodzielnie Twoich pointerów w kontenerach! Co za skandal.
9) optional nie potrafi trzymać referencji. O jak szkoda.
10) W C++ nie ma GUI! Na szczęscie takie GUI istnieje w Pythonie na
przykład, który (tylko niech nikt się o tym nie dowie) korzysta m.in. z
Qt w C++. Poza tym to skandal, że język do pisania nieskopiomowego nie
ma widgetów. Co za żałosny brak funkcjonalności jak się pisze soft do
sterownika przemysłowego od hamulców.
11) Errory są nieczytelne, bo autor filmu jest idiotą, więc są nieczytelne.
12) Dzięki templates możemy mieć specjalizowane funkcje, ale one
powiększają binaria! To skandal. Pownni nie powiekszać. Magicznie najlepiej.
13) Templaty tylko w nagłówkach, bo autor filmu to idiota i nie słyszał
jak to się robi w cpp.
14) Metaprogramowanie złe, bo jedynye przykłady jakie miał idiota, to te
których nie pojmował.
15) C++ jest winny tego, że IDE sobie nie radzą!
16) C++ jest winny, że nie ma refleksji. Nie to co zabawkowe gówna, jak
Javascript, w których refleksja zaoszczędza tyyyyle czasu programisty
(kosztem CPU, ale kto by to liczył). Zaryzykuję, że każdy projekt, który
używa refleksji w miejscu poprawnych design patterns to gówno takie samo
jak javascript.
17) C++ nie zapewnia inicjacji zmiennych, bezsensownie allokując czas
CPU. Skandal. Potrzebujemy tu jakiejś dyrektywy UE, aby nie wykluczać
niepełnosprawnych umysłowo programistów.
1 C++ domyślnie kopiuje. Skandal. Nie to, co C# który nie wiadomo co
robi i zależy to od widzimisię typu, jak python, gdzie kompia lub
referencja zależą od semantyki uzycia, albo jak js który nie wiadomo co
robi, bo to i tak bez znaczenia dla klepacza frontendu następnego sklepu.
19) Autor ma awersję do explicit, które jest chyba w każdym coding
standardzie
20) Zachowanie C++ zależy od architektury CPU na której pracuje.
Skandal. Przeciez dokładnie o to chodziło, więc po co tak zrobili?
Niepojęte.
21) "Nie rozumiem co to są korutyny, ale async w gównie JS jest
zajebisty, choć dalej nie wiem jak działa."
22) Każdy powinien mieć obligatoryjnie garbage collector, nawet jeśli
pisze na 4004, najlepiej w osobnym wątku i najlepiej typu
stop-the-world. To się świetnie sprawdza w nawigacji samolotem.
23) Linus go nie lubi. Szach-mat debile od C++! Rusta też nie lubi, ale
nie wnikajmy.
24) Exceptiony zwiększają program! Co prawda 30 lat temu, ale zawsze!
25) Nie da się pisać testów w jeden sposób. Zamiast tego jest ta
cholerna wolność.
26) Żeby pisać testy, trzeba projekto podzielić na moduły. No to jest
już przegięcie. Autor namęczyć się pisząc 10 milionów lini kodu
monolitycznego .exe i nagle ktoś pyta jak odpalić unittesty? Co za
bezczelny gówniarz, zero szacunku dla seniorów.
27) Destruktory wołają się tam, gdzie się wołać powinny. Skandal.
2 Najlepszy jest Rust, bo można wszystko zrobić tylko na jeden sposób.
One man, one vision. No i po cichu można w nim pisać niebezpieczny kod,
więc jak by co...

Podsumowując:

Autor to idiota, który nigdy niw widział śladu zastosowania C++ poza
jakimiś graficznymi duperelami. Jego niepojmowanie, że GC jest
bezużyteczne w połowie projektów C++ świaczy o bardzo nikłym pojmowaniu
niszy, w której C++ siedzi. Promowanie Rusta jeszcze bardziej mnie
przekunuje, że koleś nie wie co mówi. Ludzie wybierają C++ do pisania
własnie w sposób *niebezpieczny* aby wydoić z implementacji każdy cykl
CPU, a nie pieprzyć się z "automatcznym zwalnianiem pamięci,
automatycznym inicjowaniem śmieci i GUI". To nie ten język.

Standardowy Strach Na Wróble, tylko tym razem mocno rozdmuchany. Autor
stara się wyeksmitować C++ z zagadnień, w kórych go się nie używa, lub
gdzie jego użycie jest śladowe i często bezsensowne.

Sun Dec 07, 2025 5:42 pm   

W dniu 7.12.2025 o 15:00, heby pisze:

Mógłbyś rozwinąć temat lub podać jakiś link do odpowiedniego art.?


TPO: Szacun za to, że chciało ci się oglądać do końca te hype stworzone
na zamówienie tajnej policji. Ja osobiście nie oglądam YT (ani podobnych
s. WWW z filmami) - powody podałem w rap.:

<https://energokod.gda.pl/raporty-totaliztyczne/17.%20Patroni%20Kontra%20Bankierzy.pdf>

--
Jacek Marcin Jaworski, Pruszcz Gd., woj. Pomorskie, Polska, EU;
tel.: +48-609-170-742, najlepiej w godz.: 5:15-5:55 lub 17:15-17:55;
<jmj@energokod.gda.pl>, gpg: 4A541AA7A6E872318B85D7F6A651CC39244B0BFA;
Domowa s. WWW: <https://energokod.gda.pl>;
Mailowa Samoobrona: <https://emailselfdefense.fsf.org/pl>.

Sun Dec 07, 2025 5:55 pm   

On 07/12/2025 16:42, Jacek Marcin Jaworski wrote:

https://dice-research.org/news/2022-03-18_cpp_explicit_template_instantiation/

https://learn.microsoft.com/en-us/cpp/cpp/explicit-instantiation?view=msvc-170

https://arne-mertz.de/2019/02/extern-template-reduce-compile-times/

Sun Dec 07, 2025 6:14 pm   

W dniu 7.12.2025 o 16:55, heby pisze:

Chwytam idę: extern z konkretyzacją szablonu, czyli sztuczka rodem z C
zastosowana w C++. Teraz mam kol. pyt.:
Czy twoje doświadczenie wskazuje na to, że ta sztuczka jest używalna w
praktyce?
Pytam z czystej ciekawości, bo mi ta sztuczka wydaje się b. upierdliwa.

--
Jacek Marcin Jaworski, Pruszcz Gd., woj. Pomorskie, Polska, EU;
tel.: +48-609-170-742, najlepiej w godz.: 5:15-5:55 lub 17:15-17:55;
<jmj@energokod.gda.pl>, gpg: 4A541AA7A6E872318B85D7F6A651CC39244B0BFA;
Domowa s. WWW: <https://energokod.gda.pl>;
Mailowa Samoobrona: <https://emailselfdefense.fsf.org/pl>.

Sun Dec 07, 2025 6:32 pm   

On 07/12/2025 17:14, Jacek Marcin Jaworski wrote:

Tak. Przy czym z małym twistem: jest niezwykle mało programistów C++
majacych o niej pojęcie. Wiec tak, ale to nie oznacza, że wszędzie jest
tego pełno. Kto używa, ten używa jako normalnego narzędzia.


separować hpp od cpp. Razem z koncepcją ipp (inkludowalne pliki z
implementacją, używane w boost) pozwala calkowicie usunąć niedogodności
instancjonowania templates, o których bredzi autor filmu. Używam tego
intensywanie zarówno w dużych aplikacjach jak i w miniaturowym kodzie na
AVR.

Sun Dec 07, 2025 6:46 pm   

W dniu 7.12.2025 o 17:32, heby pisze:

Dzięki za wyjaśnienia. Jednak widzę, że podane przez Ciebie linki nie
prowadzą do art. które opisują tą sprawę wyczerpująco, bo wspominasz o
ipp, który one nie omawiają. Ta ostatnia sprawa jest pobieżnie opisywana
na stackoverflow i w archiwum listy dyskusyjnej bibl. boost. Dlatego mi
się wydaje, że opis tego rozw. był by dobrym tematem na osobny art.
Jednak puki co bez przykładowego, DZIAŁAJĄCEGO kodu ta sztuczka dla mnie
pozostaje to jedynie ciekawostką.

--
Jacek Marcin Jaworski, Pruszcz Gd., woj. Pomorskie, Polska, EU;
tel.: +48-609-170-742, najlepiej w godz.: 5:15-5:55 lub 17:15-17:55;
<jmj@energokod.gda.pl>, gpg: 4A541AA7A6E872318B85D7F6A651CC39244B0BFA;
Domowa s. WWW: <https://energokod.gda.pl>;
Mailowa Samoobrona: <https://emailselfdefense.fsf.org/pl>.

Sun Dec 07, 2025 7:00 pm   

On 07/12/2025 17:46, Jacek Marcin Jaworski wrote:

ipp nie są tylko do templates, ale do innych zastosowań. Możesz je
traktować jako alternatywę dla explicit instantiation ale również do
modularyzacji kodu dużych klas.

https://jmmv.dev/2013/12/header-files-c-ipp-files.html

Hardkorzy od C używali czasem, w powiązaniu z makrami, do emulacji C++,
z przyczyn religijnych (i do dzisiaj używają, to już kult).



Tu masz jakiś mikro dla explicit instantiation:

https://gist.github.com/jdtournier/2afaeac3b94bf2fe1dc9160d4a61356c

Tu masz jakąs biblitekę korzystającą z explicit instantiation:

https://github.com/hliberacki/cpp-member-accessor

Co do ipp, to oczywiście boost.

Sun Dec 07, 2025 7:14 pm   

On 07/12/2025 13:20, io wrote:

A nie do optymalnego rozwiązania problemu? Czyli zarówno czytelności,
prędkości, objętości, dostepności dev, przenośności itd itp? Tylko do
wyrażania kodu zrozumiałego dla wszystkich?

Sun Dec 07, 2025 7:31 pm   

W dniu 7.12.2025 o 13:20, io pisze:


Skoro czegoś nie rozumiesz, to nie jest to wina języka. To twoja wina :]


--
Pixel
Albo PiS albo Polska

Sun Dec 07, 2025 7:48 pm   

On Sun, 7 Dec 2025 15:00:52 +0100, heby <heby@poczta.onet.pl> wrote:


Ależ zarzut jest raczej taki, że zmienia się tak bardzo, że to
powoduje zamęt. Przynajmniej u zwykłych praktyków bo przecież nie u
omnipotentów wszystkowiedzących jak Seba.



Akurat w filmie kilka razy autor podkreśla, to że właśnie ma
doświadczenie z dużymi projektami i jego punkt widzenia wynika z tego
doświadczenia. Gdy się przyjrzy dobrze apologetom C++ to się okazuje,
że ich doświadczenie to najczęściej Hello World!.



Dość komiczna argumentacja, czyli nie ma guja w C++ bo jest przecież
w pythonie, który korzysta z qt który z kolei korzysta z (podobno)
przestarzałego C++...
Już pomijając awersję do pythona, że z mojego punktu widzenia jako
zwykłego usera jakiekolwiek narzędzie, które było pilnie do
uruchomienia na szybko a na nieszczęście zostało napisane w pythonie
(po jaki *uj?) to nie działało. Albo python za stary, albo brak jakiś
modułów a pip install module nie działa bo to coś tam koliduje z
systemowym pakietowaniem.
Za każdym razem jak widzę coś w pythonie to mnie krew zalewa bo już
wiem za na 99% nie zadziała bo zgodnie z aktualną modą każdy nowy
program w pythonie będzie wymagał zawsze jakieś egzotycznej
biblioteki/modułu której akurat się nie mam. Widać python działa wg
zasady że jak chcesz się napić piwa to musisz kupić cały browar.
Kiedyś znajomy podzielił się podobną opinią mówiąc "dziwni ci
programiści pythona, bo żaden niczego sam nie umie napisać by
działało "standalone" tylko muszą korzystać z innych (modułów) co
jest irytujące.".
Ja wiem na pierwszy rzut ucha można machnąć rękami, że ktoś nie
rozumie idei biblioteki. Co do zasady - tak. Ale z pkt. widzenia
użytkownika to on nie potrzebuje pythona, użytkownik potrzebuje
spełnienia tzw. paradygmatu exe: potrzebuje narzędzia *działającego*
as is a dokładniej to nawet nie potrzebuje narzędzia tylko ważny jest
efekt (jak widać teoria Levitt'a, że user potrzebuje efektu a nie
narzędzia nie ogranicza się tylko do marketingu). Jak idę do sklepu
kupując auto to chcę auto kompletne, jeżdżące. A nie, że sprzedawcą
mówi, że u nas są tylko budy, silnik musi pan ściągnąć z... Koła
z...

--
Marek

Sun Dec 07, 2025 7:53 pm   

On Sun, 7 Dec 2025 17:32:24 +0100, heby <heby@poczta.onet.pl> wrote:

Zadziwiające, że ten argument zawsze pada bezrefleksyjnie.
Po co zatem narzędzie, który ogarnia tylko niewielki ułamek
użytkowników a ogromna większość tylko psuje nim większość co zrobi
dyskwalifikuje narzędzie a nie userów.

--
Marek