techniki pisania w języku C vs C++?

Pytanie nie jest precyzyjne ale próbuję zapytać inaczej.
W języku C nie ma klas, za to są struktury.
W języku C++ są klasy i struktury - wiem, że w C++ można pisać obiektowo i proceduralnie i teraz właściwe pytanie
Czy język C jest językiem proceduralnym? Czy w języku C można pisać stricte obiektowo?

Czy język C jest językiem proceduralnym? Czy w języku C można pisać stricte obiektowo?

Tu trzeba by się odwołać do definicji co to jest pisać stricte obiektowo. Niestety takiej definicji nie mamy, nie podali jej najwięksi zwolennicy pisania stricte obiektowo. Wiec podejrzewam że pisać stricte obiektowo nie da się w żadnym języku :P

zkubinski napisał(a):

Czy język C jest językiem proceduralnym? Czy w języku C można pisać stricte obiektowo?

W C można pisać obiektowo. W zasadzie systemy obiektowe w C to końcówka lat 80. A tu przykład jak to robić:
https://kaczus.ppa.pl/art/c_obiektowo,3.html

stricte znaczy ściśle - więc C++ jest językiem obiektowym, a że pozwala też na pisanie proceduralne to już inna sprawa

kaczus napisał(a):

zkubinski napisał(a):

Czy język C jest językiem proceduralnym? Czy w języku C można pisać stricte obiektowo?

W C można pisać obiektowo. W zasadzie systemy obiektowe w C to końcówka lat 80. A tu przykład jak to robić:
https://kaczus.ppa.pl/art/c_obiektowo,3.html

no dobra czyli wychodzi na to, że język C jest językiem proceduralnym, a żeby pisać obiektowo, to trzeba robić różne fikołki

stricte znaczy ściśle

Ale co to znaczy ściśle? Iż obiekty są ściśniete? Czym się różni programowanie obiektowe od programowania ściśle obiektowego? i programowania luźno obiektowego?

ej, no nie rób jaj, ściśle znaczy, że programujesz TYLKO obiektowo

ściśle znaczy, że programujesz TYLKO obiektowo

No to teraz zostaje tylko do ustalenia co to oznacza programować obiektowo

KamilAdam napisał(a):

ściśle znaczy, że programujesz TYLKO obiektowo

No to teraz zostaje tylko do ustalenia co to oznacza programować obiektowo

tak jak w javie ;)

zkubinski napisał(a):

kaczus napisał(a):

zkubinski napisał(a):

Czy język C jest językiem proceduralnym? Czy w języku C można pisać stricte obiektowo?

W C można pisać obiektowo. W zasadzie systemy obiektowe w C to końcówka lat 80. A tu przykład jak to robić:
https://kaczus.ppa.pl/art/c_obiektowo,3.html

no dobra czyli wychodzi na to, że język C jest językiem proceduralnym, a żeby pisać obiektowo, to trzeba robić różne fikołki

Samo użycie klasy w C++ nie oznacza, że jest pisanie obiektowo. Pisanie obiektowo, to sposób programowania, jedne języki wspierają to bardziej inne słabiej.
Języki takie jak C, C++, Pascal itp pozwalają na programowanie w większości (jeśli nie we wszystkich) paradygmatach. W jednych robi się to prościej, w innych słabiej.

ej, no weź... przestań trolować

kaczus napisał(a):

zkubinski napisał(a):

kaczus napisał(a):

zkubinski napisał(a):

Czy język C jest językiem proceduralnym? Czy w języku C można pisać stricte obiektowo?

W C można pisać obiektowo. W zasadzie systemy obiektowe w C to końcówka lat 80. A tu przykład jak to robić:
https://kaczus.ppa.pl/art/c_obiektowo,3.html

no dobra czyli wychodzi na to, że język C jest językiem proceduralnym, a żeby pisać obiektowo, to trzeba robić różne fikołki

Samo użycie klasy w C++ nie oznacza, że jest pisanie obiektowo. Pisanie obiektowo, to sposób programowania, jedne języki wspierają to bardziej inne słabiej.
Języki takie jak C, C++, Pascal itp pozwalają na programowanie w większości (jeśli nie we wszystkich) paradygmatach. W jednych robi się to prościej, w innych słabiej.

No ok ale inne języki nas nie interesują, tylko mowa jest o C i C++ ale dzięki linkowi co dałeś już dało mi się jednoznacznie ustalić, że C jest proceduralny

Miang napisał(a):

tak jak w javie ;)

Jak? Da się zrobić NullPointerException w C++?

jarekr000000 napisał(a):

Miang napisał(a):

tak jak w javie ;)

Jak? Da się zrobić NullPointerException w C++?

z tego co widać, da się zrobić null pointer exception w C++ - ale nie jestem expertem, trzeba użyć std::invalid_argument pierwszy link z brzega

zkubinski napisał(a):

ej, no weź... przestań trolować

On nie trolluje. Jest bardzo wiele definicji różnych paradygmatów programowania, w tym i pro­gra­mo­wa­nia obiektowego. To jak ze stylami architektonicznymi — jak na coś spojrzysz okiem profesjonalisty, to widzisz, że coś jest gotyckie, renesansowe, albo barokowe; ale te style się na siebie nakładają, mają cechy wspólne, oraz różni twórcy w różnym stopniu stosują się do różnych prawideł, reguł i zasad w różnych swoich projektach.

Ja bym powiedział, że istotą paradygmatu obiektowego jest upakowywanie stanu w wydzielone i łatwo rozróżnialne obiekty, które same kontrolują swój własny stan, mają przypisaną do siebie logikę (metody) i komunikacja i zarządzanie tym stanem odbywa się głównie przez nią. W tej definicji nie ma jednak nic o dziedziczeniu czy polimorfizmie, a te rzeczy się też intuicyjnie z nim wiążą.

W każdym razie, przy tym podejściu, C++ daje programistom znacznie lepsze narzędzia do osiągnięcia tego „celu” — enkapsulacji stanu w hermetycznych obiektach wystawiających na zewnątrz abstrakcyjne interfejsy do zarządzania nimi — niż C. Ale można pisać w tym stylu i w C — na przykład GMP jest przy tym podejściu biblioteką obiektową. Trochę niewygodnie — język nie zapewnia zbyt dobrych narzędzi do nakreślenia i wymuszenia jednoznacznych granic między „obiektami” — ale jak najbardziej się da.

Podobnie jak da się programować funkcyjnie w C++, czy nawet w C — potrzeba „tylko” sporo uporu.

Ale, jak wyżej — wszystko zależy od definicji. Jak się uprzesz na inną — na przykład zaakcentujesz dziedziczenie — to okaże się, że z tą obiektowością w C to nie ma tak fajnie.

no dobra, to teraz widać jak na dłoni ile mi brakuje.

jarekr000000 napisał(a):

Miang napisał(a):

tak jak w javie ;)

Jak? Da się zrobić NullPointerException w C++?

Da się, choćby implementując klasę, która będzie sprawdzać wskaźnik przed użyciem go. Jak się bardziej postarać można też przechwycić SIGSEGV/Acess Violation i rzucić wyjątek.

Co do samego pytania, można programować obiektowo w C, GTK czy SDL są tego dobrymi przykładami. Tyle tylko, że język prawie w ogóle nie wspiera programowania obiektowego. Enkapsulację da się zrobić, ale jeśli chodzi o polimorfizm itp to już zaczynają się hacki. Moim zdaniem nie warto, lepiej wziąć C++ albo w ogóle nauczyć się Rusta – najlepiej.

ok, dzięki, to co trzeba już rozumiem, zadając to pytanie chciałem się dowiedzieć jak myśleć programując arduino... bo mam tam parę rzeczy do zrobienia

Po pierwsze, w pewnym uproszczeniu można powiedzieć, że C++ to jest nadzbiór nad C, podobnie, jak TypeScript to nadzbiór nad JavaScript. Znam tylko jedną drobną różnicę: Te same nagłówki z języka C nazywają się nieco inaczej w C++. Zamiast #include "math.h" pisze się #include <cmath>. Takich różnic może być więcej. Innymi słowy, program C jest jednocześnie poprawnym programem C++, a skrypt JavaScript jest poprawnym skryptem TypeScript, ale w drugą stronę już tak nie jest.

jarekr000000 napisał(a):

Miang napisał(a):

tak jak w javie ;)

Jak? Da się zrobić NullPointerException w C++?

To wynika ze znaczącej różnicy między C++ a Java w kwestii wskaźników i obiektów. W przypadku C++ wskaźnik na obiekt może być "przypadkowy" i próba odwołania się do niego może spowodować nieprzewidziany skutek. Natomiast w Java, wskaźnik albo jest pusty (null), albo wskazuje na poprawny obiekt. W Java, przypisanie wskaźnika do przypadkowych danych ani na obiekt niekompatybilnego typu nie jest możliwe, ale w C++ jest to możliwe i to programista musi kontrolować. Co więcej, zniszczenie obiektu nie "zeruje" wskaźnika, należy dokonać tego ręcznie. Jeszcze jedna różnica, to w Java, C# cz innych językach, wskaźnik jest tylko logicznym wskaźnikiem, a w C++ wskaźnik jest liczbą, której wartość da się zmienić w ciemno bez gwarancji, że po zmianie będzie poprawny wskaźnik (albo na obiekt, albo pusty).

W języku C da się pisać obiektowo, ale inaczej i trudniej niż w Java i C++. Nie ma klas i obiektów, ale są struktury i wskaźniki. Odpowiednikiem obiektu może być struktura (pakiet samych pól), a metody są globalne, ale każda z metod przyjmuje strukturę jako jeden z parametrów. Przykład pierwszy z brzegu https://cpp0x.pl/dokumentacja/standard-C/fopen/446 nie ma obiektu reprezentującego plik, ale jest struktura reprezentująca plik, przekazywana do każdej funkcji pracującej na niej. Ten kod można też uruchomić jako kod C++, ale C++ oprócz tego ma swoje klasy do tych samych rzeczy. Jednak koncepcyjnie to będzie to samo, bo plik jest obiektem mającym i dane (nazwa, powiązanie z faktycznym plikiem, aktualna pozycja wskaźnika zawartości), i zestaw możliwych działań (odczyt danych, zapis danych, przemieszczanie wskaźnika w pliku). Odpowiednikiem kilku obiektów fstream z C++ jest kilka zmiennych typu FILE z C.

zadając z pozoru błahe pytanie ileż to można się dowiedzieć :)

andrzejlisek napisał(a):

W języku C da się pisać obiektowo, ale inaczej i trudniej niż w Java i C++. Nie ma klas i obiektów, ale są struktury i wskaźniki. Odpowiednikiem obiektu może być struktura (pakiet samych pól), a metody są globalne,

Nie do końca globalne, może być lokalna
Nie jest też prawdą, ze wszystko oznacza to samo. W C static ogranicza widoczność tylko do pliku w którym zostało użyte. Różnic jest więcej, więc C++ początkowo był nadzbiorem C (sasc np kompilator c++ miał stworzony w ten sposób, że zamieniał kod C++ na C a potem kompilował kod C), potem drogi się rozeszły i C++ korzysta z pewnych bibliotek C na zasadzie importu.

andrzejlisek napisał(a):

Po pierwsze, w pewnym uproszczeniu można powiedzieć, że C++ to jest nadzbiór nad C, podobnie, jak TypeScript to nadzbiór nad JavaScript. Znam tylko jedną drobną różnicę: Te same nagłówki z języka C nazywają się nieco inaczej w C++. Zamiast #include "math.h" pisze się #include <cmath>. Takich różnic może być więcej. Innymi słowy, program C jest jednocześnie poprawnym programem C++, a skrypt JavaScript jest poprawnym skryptem TypeScript, ale w drugą stronę już tak nie jest.

Jest to zbyt duże uproszczenie, takie do poziomu wręcz kompletnej nieprawdy. Najbardziej istotną rzeczą, odróżniających C od C++, jest (moim zdaniem) brak VLA w tym drugim. A pełniejszą listę napisałem kiedyś tutaj: https://4programmers.net/Forum/C_i_C++/286055-funkcja_bioraca_po_jednym_znaku_ze_stringa?p=1341953#id1341953

Tak więc nie, nie tylko nie każdy program w C jest poprawnym programem w C++ (po co najwyżej drobnych poprawkach nazw plików nagłówkowych), ale nawet bardzo łatwo o taki, który nie będzie, z przyczyn semantycznych, i zmiana którego będzie wymagała nietrywialnych poprawek.

andrzejlisek napisał(a):

To wynika ze znaczącej różnicy między C++ a Java w kwestii wskaźników i obiektów. W przypadku C++ wskaźnik na obiekt może być "przypadkowy" i próba odwołania się do niego może spowodować nieprzewidziany skutek.

Jesteś pewny? Czy może raczej odwołanie się do przypadkowego wskaźnika w C++ jest niezdefiniowane - więc w zasadzie oznacza, że kod nie jest w C++?

zkubinski napisał(a):

ej, no weź... przestań trolować

Nie sądzę że autor troluje.

Jak najbardziej da się programować obiektowo bez używania klas. Ja powiedziałbym, że w programowaniu obiektowym chodzi po prostu o to żeby "schować" (inaczej zaenkapsulować) jakieś dane lub stan w obiekcie, i pozwolić je odczytywać lub sterować z zewnątrz (za pomocą metod lub pól).

Dookoła programowania obiektowego jest wiele utartych "schematów", typu:

• parametry konstruktora się przypisuje do pól
• pola muszą mieć settery i gettery
• obiekty można robić tylko z klas
• pola nie powinny być publiczne

Ale to są bardziej po prostu stosowane praktyki w jakichś kręgach. Nie ma zasady która mówi że argument konstruktora trzeba wsadzić do pola, nie ma zasady która mówi że nie może być pól publicznych, nie zasad o stterach i gettera. Polimorfizm i dziedziczenie (czyli coś co się określa jako "pilary oop"), też moim zdaniem nie są jakoś szczególnie konieczne. Głównie chodzi o "chowanie czegoś w obiekcie" oraz "wystawianie kontroli nad tym przez interfejs obiektu" (i tutaj nie mam na myśli javowego interfejsu, tylko interfejs obiektu: czyli jego metody i jego pola).

I owszem, można dodać polimorfizm, w językach które to wspierają: albo poprzez duck typing, albo jeśli język wymaga typów znanych w compiletimie to przez metody abstrakcyjne; ale nie powiedziałbym czy to jest konieczne. Polimorfizm można też osiągnąć samymi funkcjami, jak callbacki w JS.

Napisałem w zasadzie prawie to samo co @Althorion:

Althorion napisał(a):

Ja bym powiedział, że istotą paradygmatu obiektowego jest upakowywanie stanu w wydzielone i łatwo rozróżnialne obiekty, które same kontrolują swój własny stan, mają przypisaną do siebie logikę (metody) i komunikacja i zarządzanie tym stanem odbywa się głównie przez nią. W tej definicji nie ma jednak nic o dziedziczeniu czy polimorfizmie, a te rzeczy się też intuicyjnie z nim wiążą.

W każdym razie, przy tym podejściu, C++ daje programistom znacznie lepsze narzędzia do osiągnięcia tego „celu” — enkapsulacji stanu w hermetycznych obiektach wystawiających na zewnątrz abstrakcyjne interfejsy do zarządzania nimi — niż C. Ale można pisać w tym stylu i w C — na przykład GMP jest przy tym podejściu biblioteką obiektową. Trochę niewygodnie — język nie zapewnia zbyt dobrych narzędzi do nakreślenia i wymuszenia jednoznacznych granic między „obiektami” — ale jak najbardziej się da.

Dodałbym tylko, że obiekt nie koniecznie musi mieć jakiś stan, a jeśli ma to ten stan nie koniecznie musi być zmienny, oraz nie koniecznie obiekt musi mieć jakąś logikę.

Przyczepiłbym się tylko do tej enkapsulacij. Niektórzy przez "enkapsulacje" rozumieją to, że pole ma być private. Niby nie jest to do końca niepoprawne, ale idealnie powinno chodzić o to że użytkownik obiektu, nawet nie powinien wiedzieć że takie pole istnieje. Ale niestety w wielu językach, jak spróbujemy użyć pola prywatnego, to dostajemy komunikat "Sorry, cannot use this field because it's private". I to w moim odczuciu trochę łamie enkapsulacje, bo nie powinniśmy wiedzieć o tym polu. Kompilator powinien się zachować tak jakby tego pola nie było. To by była prawdziwa enkapsulacja (schowanie pola przed całym światem).

W C masz deklaracje .h, a implementacje w .c, i jak importujesz .h, to dostajesz tylko i wyłącznie interfejs (bez implementacji). Powiedziałbym, że to jest bardzo dobre enkapsulacja. Nie idzie po prostu żywcem dostać do czegokolwiek co nie jest w .h. W C++ ta enkapsulacja jest trochę gorsza, bo teraz importując .h widzimy pola prywatne w klasie, więc ja powiedziałbym że enkapsulacja w C++ jest mniejsza. Rozwiązaniem na to byłoby np nie umieszczanie pól prywatnych w deklaracji klasy .h (tylko nie wiem jak miałoby to działać, bo chyba kompilator musi znać te pola, żeby obliczyć rozmiar jaki trzeba zaalokować na obiekt?).

Riddle napisał(a):

zkubinski napisał(a):

Jak najbardziej da się programować obiektowo bez używania klas. Ja powiedziałbym, że w programowaniu obiektowym chodzi po prostu o to żeby "schować" (inaczej zaenkapsulować) jakieś dane lub stan w obiekcie, i pozwolić je odczytywać lub sterować z zewnątrz (za pomocą metod lub pól).

ja uważam że nie zawsze musi chodzić o schowanie, ale przede wszystkim o zgrupowanie

Dookoła programowania obiektowego jest wiele utartych "schematów", typu:

• parametry konstruktora się przypisuje do pól
• pola muszą mieć settery i gettery
• obiekty można robić tylko z klas
• pola nie powinny być publiczne

Ale to są bardziej po prostu stosowane praktyki w jakichś kręgach. Nie ma zasady która mówi że argument konstruktora trzeba wsadzić do pola, nie ma zasady która mówi że nie może być pól publicznych, nie zasad o stterach i gettera. Polimorfizm i dziedziczenie (czyli coś co się określa jako "pilary oop"), też moim zdaniem nie są jakoś szczególnie konieczne. Głównie chodzi o "chowanie czegoś w obiekcie" oraz "wystawianie kontroli nad tym przez interfejs obiektu" (i tutaj nie mam na myśli javowego interfejsu, tylko interfejs obiektu: czyli jego metody i jego pola).

naprawdę ktoś uważa że argumenty konstruktora muszą być wsadzone do pola? naprawdę?
no bo wiarę w settery i gettery to już widziałam na żywo, i ten dogmat ze pola nie mogą być publiczne
no niestety tak wyglądają efekty jak ktoś się uczy programować patrząc co mu kolega pokazał i nie czyta książek a ni dokumentacji
praktyka która miała być może nawet sens w danym projekcie urasta do ogólnoprogramistycznego dogmaru

Miang napisał(a):

Riddle napisał(a):

zkubinski napisał(a):

Jak najbardziej da się programować obiektowo bez używania klas. Ja powiedziałbym, że w programowaniu obiektowym chodzi po prostu o to żeby "schować" (inaczej zaenkapsulować) jakieś dane lub stan w obiekcie, i pozwolić je odczytywać lub sterować z zewnątrz (za pomocą metod lub pól).

ja uważam że nie zawsze musi chodzić o schowanie, ale przede wszystkim o zgrupowanie

No tak, coś w tym jest. Lepsze, np z uwagi na SRP.

Ale zauważ, że robienie obiektu tylko po to żeby coś pogrupować, miałoby sens tylko wtedy, jakby ta grupa była "czymś więcej" niż samymi częściami. Jak np można powiedzieć "vector" to jest coś więcej niż jego współrzędne, albo user to coś więcej niż login i hasło. To by miało zasadność gdyby to było po coś, mieć odpowiednią nazwę, i to że akurat takie atrybuty są jego częścią musiałoby wynikać z logiki i użycia w kodzie, a nie z widzimisię (jeśli jakieś dwa atrybuty są często używane razem, warto je połączyć). Wiele razy widziałem jak ludzie wkładają atrybuty w obiekty, nie dlatego że tak wynika z kodu że one są używane razem, tylko dlatego że tak "lepiej wygląda".

Jeśli coś ma być grupowane dla samego grupowania (bez enkapsulacji i abstrakcj), to praktycznie masz strukturę, a nie obiekt.

zkubinski napisał(a):

Pytanie nie jest precyzyjne ale próbuję zapytać inaczej.
W języku C nie ma klas, za to są struktury.
W języku C++ są klasy i struktury - wiem, że w C++ można pisać obiektowo i proceduralnie i teraz właściwe pytanie
Czy język C jest językiem proceduralnym? Czy w języku C można pisać stricte obiektowo?

A kto Ci zabroni tworzyć struktury ze wskaźnikami do funkcji? A to jest właśnie klasa (jeśli tam dodasz zabezpieczenia - czyli ify)

johnny_Be_good napisał(a):

zkubinski napisał(a):

Pytanie nie jest precyzyjne ale próbuję zapytać inaczej.
W języku C nie ma klas, za to są struktury.
W języku C++ są klasy i struktury - wiem, że w C++ można pisać obiektowo i proceduralnie i teraz właściwe pytanie
Czy język C jest językiem proceduralnym? Czy w języku C można pisać stricte obiektowo?

A kto Ci zabroni tworzyć struktury ze wskaźnikami do funkcji? A to jest właśnie klasa (jeśli tam dodasz zabezpieczenia - czyli ify)

Po pierwsze jeśli już, to to byłaby instancja (swoją drogą, to jest jeden z problemów, że ludzie mylą paradygmat obiektowy ze "strukturą z funkcjami". Struktury z funkcjami były daaawno przed OOP. Problem z nimi był taki że one operowały na publicznych danych, przez co inny kod mógł w nich "mieszać", więc było to mniej utrzymywalne).

A po drugie, nadal nie byłby to paradygmat obiektowy, jeśli nie możnaby zaenkapsulować danych w tym. Wyjściem byłoby zrobić domknięcie z funkcji tworzącej (która stałaby się de-facto "konstruktorem" tej struktury), mające w sobie "schowane" jakieś wartości zainicjalizowane przez funkcję tworzącą.

Riddle napisał(a):

johnny_Be_good napisał(a):

zkubinski napisał(a):

Pytanie nie jest precyzyjne ale próbuję zapytać inaczej.
W języku C nie ma klas, za to są struktury.
W języku C++ są klasy i struktury - wiem, że w C++ można pisać obiektowo i proceduralnie i teraz właściwe pytanie
Czy język C jest językiem proceduralnym? Czy w języku C można pisać stricte obiektowo?

A kto Ci zabroni tworzyć struktury ze wskaźnikami do funkcji? A to jest właśnie klasa (jeśli tam dodasz zabezpieczenia - czyli ify)

Po pierwsze jeśli już, to to byłaby instancja. A po drugie, nadal nie byłby to paradygmat obiektowy, jeśli nie możnaby zaenkapsulować danych w tym. Wyjściem byłoby zrobić domknięcie z funkcji, mające w sobie "schowane" jakieś wartości.

W C Zmienna ma w sobie wartość dostępną za pomocą & (adres) - to jest ta "schowana" jakieś wartość.
Nie widzę najmniejszego problemu żeby to rozbudować.
Python mi wygląda na robionego na javascript - wszystko zobiektowane ponoć. Jak by odpowiednio użyć js'a to wychodzi python. I chyba to jest brakujące ogniowo na które zkubiński jeszcze nie trafił.

zkubinski napisał(a):

Czy język C jest językiem proceduralnym?

Każdy używany język jest procedularny tj. każdy język ma funkcje implementujące ideę podprogramów. Wobec tego jak ktoś używa tego pojęcia to nie wiesz co dana osoba miała na myśli. Często używa się określenia język proceduralny jako język nie OOP ewentualnie jako ekwiwalent język imperatywny. Ten termin ma więcej sensu, bo mamy też inne podobne kategorie jak np. język funkcyjny

Co do paradygmatów to w C jest większa różnorodność, bo sam język za bardzo nie narzuca gotowych rozwiązań. Najczęściej wygląda to tak, że większość kodu to luźno powiązane funkcje i struktury, mocno powiązane "obiekty" pojawiają się w zależności od potrzeby a nie domyślnie, bo jest to po prostu bardziej upierdliwe i wymaga więcej kodu

W C++ jest bardziej dziko, bo dużo lat mineło a mody w tym języku programowania są kapryśne:

• C++ ala czyste C z małymi wspomagaczami wynikającymi od widzimisię programisty. Taki paradygmat jest często uczony na studiach
• taki klasyczny uber OOP C++ sprzed 30 lat, gdzie wszystko jest wirtualne, protected i wielokrotne dziedziczenie, generalnie straszna kupa. Nikt już tak nie pisze
• C++ ala C, który stara się brać to co najlepsze z C++. Przykład https://fuchsia.dev/fuchsia-src/development/languages/c-cpp/cxx
• C++ ztemplatowany, gdzie używamy dużo metaprogramowania. Dość popularne w niektórych kręgach. Przykład to duża część biblioteki boost
• modern C++, jest mnóstwo artykułów na ten temat i niestety każdy ma opinię które ficzery są modern a które nie
• C++ pod wysoką wydajność. Duże użycie lambd, templatów, 3rd party bibliotek, taka bardziej ludzka wersja C++ ztemplatowanego