Hi, czy 40 letni język który chce się rozwijać nie powinien dostać ponad 10 lat temu wersji C++ 2.0? Znamy takie języki jak Python i Scala, które nie są takie stare jak C++, a pomimo tego przeprojektowano je całkowicie od nowa na Python 3 i Scala 3. To samo można powiedzieć o PHP 7.
C++ dodało nowe funkcje jak #include <format> cout << std::format("\n"); to wygląda jak taki półśrodek przed #include <print> std::prinln();
Ogólnie <print> jest dostępne od C++23, ale żaden kompilator go nie obsługuje, trzeba czekać na GCC 14.
Więc gdy będzie udostępniony <print> to <format> będzie miało jeszcze sens?
Czy gdyby komisja C++ zdecydowała się na odświeżenie języka, to nowy kompilator GCC powinien porzucić C i zostać przy samym C++?
Wolę żeby powstał C++ 2.0, a nawet osobny kompilator wyłącznie do C++. Niż myśleć nad tym który język wybrać w zastępstwie czyli Circle, Carbon, CppFront, Cpp2, Rust, Zig...
https://www.reddit.com/r/cpp/comments/16e2o7a/carbon_language_successor_strategy_from_c_interop/
https://www.reddit.com/r/cpp/comments/16dvzv3/circle_may_be_the_future_of_c/
A co ma na celu takie gdybanie co byłyło gdyby? Jesteś członkiem komisji i masz wpływ?
BTW C++ 2.0 to Rust
Czy w C++ 2.0 można by korzystać z istniejącego kodu w C++?
Jeśli tak, to tym są kolejne wersje języka: C++17, 23…
Jeśli nie, to ustanowienie nowego języka przez obecny komitet C++ nie wystarczy, by nowy, niekompatybilny język się przyjął. Cześć systemów przyjmie go, część przejdzie na bardziej dopracowane i popularne w chwili wprowadzenia C++2.0 języki jak D, Rust; większość zostanie przy starych kompilatorach C++23, bo przepisywanie dużych systemów ma dużo wad, mało zalet, a jeszcze mniej chętnych do sfinansowania.
KamilAdam napisał(a):
BTW C++ 2.0 to Rust
Podoba mi się taki slogan, ale patrząc realnie to za wcześnie na myślenie, że Rust zastępuje C++.
To bardzo powolne procesy. C++ przez kilka dekad był i nie zniknie. A Rust dopiero się rozkręca.
Kolega zapewne wstawił kropkę pomiędzy cyfry w C++20.
Kolejne standardy c++ mają numer od ostatnich dwóch cyfr roku publikacji. Piewrszy standard by opublikowany 1998.
Więc kolejne standardy ISO C++ to:
- C++98
- C++03 (C++03 tr1)
- C++11
- C++14
- C++17
- C++20
Niedługo opublikowany będzie C++23 (grudzień), a w planach jest już C++26.
@coderx napisał:
Tak jak to jest w rustup, gdzie mam najnowszy kompilator i działają w nim wszystkie nowe funkcje i funkcjonalności
w ruście nie ma branżowego standardu, więc działa to odwrotnie, tzn. to co uda się wstawić do nowej wersji rusta staje się automatycznie pseudo-standardem. podobnie w wielu innych językach, w tym scali, javie, php, pythonie, itd
z c++ jest podobnie jak z javascriptem. c++, podobnie jak javascript, ma wiele wiodących implementacji i każda w innym tempie implementuje nowe standardy. analogicznie, zarówno w c++ jak i jsie istnieją niezależne komitety rozwijające język, a więc żadna organizacja zajmująca się rozwojem jakiejś konkretnej implementacji nie jest wyrocznią co do nowych wersji tych języków.
@coderx: Co da "oczyszczenie"? Pisz w nowym standardzie i już. Wymuś na teamie by pisał w nowym standardzie.
Ja nie piszę na co dzień w C++, w tym momencie przeprojektowuje taki kod na Rusta. Mam kilka plików po +94k linii bo kod obsługuje wszystkie trzy duże systemy operacyjne. Otwieram je w swoim neovim i nie mam z nimi problemów. Jeśli IDE ma problem, to zmień je.
Ponieważ C++ opiera się głównie na istniejącym kodzie i jest strasznie gówniany przez bagaż doświadczeń to masz dwa rozwiązania:
- język kompatybilny taki jak Carbon czy CppFront. Niestety nie przyciągnie to nowych devów, bo C++ jest gówniany w wielu założeniach i nikt nie będzie w tym pisał nowych projektów
- nowy język. Mamy przecież Rusta, który czerpie z C++ garściami ogarniająć kilka kluczowych bolączek C++ w dobry sposób
coderx napisał(a):
Wolę żeby powstał C++ 2.0, a nawet osobny kompilator wyłącznie do C++. Niż myśleć nad tym który język wybrać w zastępstwie czyli Circle, Carbon, CppFront, Cpp2, Rust, Zig...
Widzę, że z jednej strony chcesz mieć C++ i go nie mieć. Powiedz jak według ciebie wygląda twój idealny C++ 2.0 i dlaczego taki Carbon nie spełnia tych warunków
Sęk w tym że nie ma takiej dobrej książki, takiego kursu, tutorialu, który uczył by dobrego nowoczesnego C++. Zebrał te najlepsze najnowsze funkcje i pomijał te starocie
Ale co to są najnowsze funkcje(ten język żyje!)? Dobrej architektury, nawyków itd. to nie wytłumaczysz tutorialem albo jedną książką, to jest głębszy dłuższy proces. Programista to rzemieślnik nikt więcej. Podstawy szablonów są znane, pracy z pamięcią itd.. Jak chcesz są książki do STL które są de facto dokumentacją + ekstra tłumaczenie/przykłady? możesz kupić jest. Są różne książki poruszające pewne zaawansowane tematy i ich jest sporo więc i lektury nie brakuje. A w javie czy .net taka książka jedna jest? Nie ma. Są tytuły co mówią że jest w nowej wersji a zastepuje stare podobnie w c++.
I nie wiem co masz na myśli w kwestii staroci new, delete? Prawda jest taka że kupę softu np. takiego gatewaya to można napisać mając do dyspozycji kontenery z STL, algorytmy z STL + wątki i parę ekstra bibliotek okraszone prostymi szablonami. Żadnej ekstrawagancji, ale przemyślana architektura i trzymanie się pewnych standardów to jest to!
Podsumowując C++ jest trudny, jak pisać w nowoczesnym c++? To już rzemieślnicza robota.
A dlaczego nikt nie złamie kompatybilności? Bo jest kupa tooli i softu. Ktoś tu podał przykład pythona3, po prawdzie to inna kategoria niż c++(przypadki użycia) ale pominięto jedną rzecz ile żył!python2,
Już istnieje C++ 2.0
C, C++, (C++)++, czyli C#.
A tak na serio - moim zdaniem DUŻA fragmentacja ekosystemu (kilka kompilatorów, kilka package managerów, itd itd) jest czymś co działa na niekorzyść przeciętnego deva, który nie targetuje jakichś dzikich sprzętów. Obniża to developer experience.
Więc jeżeli by oczyścili C++ ale nadal bawili się w te swoje standardy, UB itd., i byłoby N różniących się interpretacji standardu w obiegu, to i tak prędzej czy później znów by się zrobił syf.
@slsy: Moim osobistym zdaniem język C++ 2.0 powinien wyglądać tak jak V (Vlang). Mały fajny zgrabny język programowania ogólnego przeznaczenia, który może być nawet zamiennikiem C. Z czasem i tak będą dodawane nowe funkcje, więc taki mały skromny język i tak się rozrośnie. Systemowy język powinien być mały, zwięzły, szybki, bezpieczny o czytelnej składni. Powinno być nowoczesne zarządzanie pamięcią, dodać skromnie cukier składniowy, jak te nowe minimalistyczne pętle, switch, when, pozbyć się całkowicie zbędnych średników Vlang ich nie ma. Nie potrzeba zapychać nowego języka systemowego tonami nowych funkcji i beczkami lukru składniowego. https://github.com/vlang/vls
Skoro wśród ważnych problemów C++23 wymieniasz sposób drukowania nowej linii, obecność średników i niewystarczającą nowoczesność RAII, to chyba dużo w nim nie pracowałeś. Możesz wybrać, a nawet stworzyć sobie inny język, ale po co wspominać przy nim o C++?
coderx napisał(a):
@slsy: Moim osobistym zdaniem język C++ 2.0 powinien wyglądać tak jak V (Vlang). Mały fajny zgrabny język programowania ogólnego przeznaczenia, który może być nawet zamiennikiem C. Z czasem i tak będą dodawane nowe funkcje, więc taki mały skromny język i tak się rozrośnie. Systemowy język powinien być mały, zwięzły, szybki, bezpieczny o czytelnej składni. Powinno być nowoczesne zarządzanie pamięcią, dodać skromnie cukier składniowy, jak te nowe minimalistyczne pętle, switch, when, pozbyć się całkowicie zbędnych średników Vlang ich nie ma. Nie potrzeba zapychać nowego języka systemowego tonami nowych funkcji i beczkami lukru składniowego. https://github.com/vlang/vls
Vlangowiec. To znowu ty
Właściwie w C++ jest jedno ważne pytanie: z kompatybilnością z chaotycznym rozwojem > 30 lat, czy z zerwaniem kompatybilności
Odpowiedź znany, i dlatego żadne C++ 2.0 nie powstanie
coderx napisał(a):
@slsy: Moim osobistym zdaniem język C++ 2.0 powinien wyglądać tak jak V (Vlang). Mały fajny zgrabny język programowania ogólnego przeznaczenia, który może być nawet zamiennikiem C. Z czasem i tak będą dodawane nowe funkcje, więc taki mały skromny język i tak się rozrośnie. Systemowy język powinien być mały, zwięzły, szybki, bezpieczny o czytelnej składni. Powinno być nowoczesne zarządzanie pamięcią, dodać skromnie cukier składniowy, jak te nowe minimalistyczne pętle, switch, when, pozbyć się całkowicie zbędnych średników Vlang ich nie ma. Nie potrzeba zapychać nowego
Ludzie używają C++ czy Rusta dlatego, że ma pierdyliard ficzerów. Nie da się pisać wydajnego i wysokopoziomego kodu bez zero cost abstracions. Zobacz jak wyglądają lifetimy albo asynci w Ruscie. To bardzo skomplikowane ficzery, ale bez nich jest ciężko osiągnąć to samo.
Jak chcesz prosty język z filozofią C, gdzie skomplikowane ficzery są zastąpione "spowolniaczami" w postaci runtimu to masz przecież Go. Z tego co czytam to ty wcale nie szukasz C++ 2.0 tylko C 2.0.
Co do składni to faktycznie Rust trochę ssie, ale to akurat mały problem. C++ ma masę innych bolączek i Rust dobrze je rozwiązuje
Moim zdaniem nigdy nie będzie c++2.0
C++ nigdy nie zdecyduje się na mocne zerwanie kompatybilności, nie zdecyduje się też na zerwanie z podejściem zero-overhead.
W związku z tym nigdy nie będzie prostym pięknym językiem.
Patrząc jak działa iso c++ i że do dziś nie udało się dogadać co zrobić aby dodać split string do std, to nie wierze że kiedykolwiek zobaczymy poważniejsze zmiany.
Dzisiaj największą bolączką jest to że standard idzie znacznie szybciej niż implementacja w kompilatorach.
Moim marzeniem było by żeby iso c++ zamiast skupiać się na nowych featurach podjęła decyzje i wbudowała w język manager pakietów, support dla utest, autoformatowanie (jak w go) i ulepszyła moduły w taki sposób żeby nie było potrzeby rozdzielanie headerów od implementacji do osobnych plików.
@hans_z: przecież my wiemy, że to twoje drugie konto, czyli autora tematu.
C++ jest specyficznym językiem używanym do tworzenia czegoś co jest niemożliwe jak np. potrzeba system modów dodać, ale nie mamy kodu źródłowego, możemy się zaadaptować do class, i zrobić interface, którym będziemy operować niezależnie jaki bazowy język był, po prostu C++ umożliwia korzystanie ze wszystkiego.
C++ jest do hackingu i brak safety jest tu zaletą, czasem trzeba na pointerach, których nie znamy dokładnej struktury klas, wykorzystać, używać pracować na nich, to robimy wtedy interface dla innych języków, w których się łatwiej pisze i dajemy im dostęp niskopoziomowy do systemu/aplikacji.
Trzeba wpuścić kilku 25 latków w miejsce gdzie się decyduje o C++ , na pewno rozwiążą wszystkie problemy a za pół roku będzie 2.0 , za rok 3.0
Trzeba zacząć od tego, że najlepszy język programowania nie istnieje i istnieć nie może. Wszystko zależy od rodzaju aplikacji i systemu, w którym ma ona pracować. W jednym przypadku lepszy będzie język Rust, w drugim lepszy będzie C++ w obecnej postaci, w trzecim Java i długo by wymieniać.
A jeżeli chodzi o C bez plusów, to w jakiejkolwiek wersji by nie był, on moim zdaniem nadaje się się tylko do programowania mikrokontrolerów i systemów wbudowanych. Do komputera i w przypadku programu pracującego pod jakimś OS, to zawsze lepszy jest C++.
Każdy język można rozwijać dwutorowo i tak też jest w C++.
- Rozwój składni samego języka z zachowaniem kompatybilności wstecznej.
- Coraz więcej struktur i funkcji w bibliotece standardowej, kompatybilność jest siłą rzeczy zachowana, o ile nic nie będzie usuwane.
W obu aspektach, można niektóre elementy opisywać jako "deprecated" ze wskazaniem alternatywnego i zalecanego sposobu uzyskania tego samego efektu. Element "deprecated" mógłby być utrzymywany przez dwie kolejne wersje języka, a w kolejnej nie byłoby gwarancji, że kompilator to obsłuży. Nie od dzisiaj wiadomo, że wieczne utrzymywanie wstecznej kompatybilności utrudnia rozwój oprogramowania.
Często problemem jest zarządzanie pamięcią. w Pascal, C i C++ nie ma GC i każdy obiekt na stercie należy niszczyć ręcznie, jak nie jest już potrzebny, ale w Java i C# jest GC przy braku możliwości ręcznej likwidacji obiektu. A mógłby być język, w którym jest i jedno i drugie, czyli każdy obiekt można zlikwidować ręcznie, ale może też zostać zmieciony przez GC po utracie możliwości odniesienia się do niego. Nie ma reguły, które podejście jest lepsze, w Java teoretycznie jest możliwe ręczne uruchomienie GC, ale w praktyce podobno wywołanie GC nie zawsze powoduje faktyczne uruchamianie GC..
andrzejlisek napisał(a):
Nie ma reguły, które podejście jest lepsze
IMHO reguła jest prosta :P Języki z GC (za wyjątkiem GC opartego na zliczaniu referencji) nie nadają się do pisania systemów czasu rzeczywistego i wysokowydajnych gier bo jak masz GC to masz problem "zatrzymania świata" gdzie cały program się zatrzymuje bo trzeba sprawdzić które obiekty są jeszcze używane. (BTW jak to się dzieje że Unity używa C# gdzie jednak jest problem zatrzymania świata?)
We wszystkich innych przypadkach IMHO lepsze są języki z GC bo nie trzeba myśleć o niszczeniu obiektów (Chociaż trzeba przyznać jest że C++ i Rust zrobiły niesamowity postęp żeby w większości wypadków nie trzeba jednak robić "delete"). No bo jak mamy taki zrównoleglony mikroservice w Javie (czy C#) to nawet jak się mikroserwis zatrzyma to pracuje jeszcze n innych (Byle nie zatrzymały się wszystkie na raz :D ). A nawet jak to nie jest zduplikowana aplikacja i zatrzyma się jedyna instancja na 100ms to nic się nie dzieje w większości wypadków
BTW pomysł żeby język miał opcjonalne GC jest ciekawy, ale czy komuś chciałoby się utrzymywać tak skompikowany język? I problem wszystkich bibliotek które musiałyby być w dwóch wersjach? Z jednej strony pomysł ciekawy, a z drugiej strony tyle niesamowitych kompilacji :(
BTW 2 jeszcze ciekawiej jakby to było połączenie Haskella z Rustem:
- Biznesowe rzeczy piszesz w funkcyjnym Haskellu z GC
- Niskopoziomowe rzeczy piszez z imperatywnym Ruscie bez GC
Heh, się rozmarzyłem :D
KamilAdam napisał(a):
. (BTW jak to się dzieje że Unity używa C# gdzie jednak jest problem zatrzymania świata?)
Zgaduję, że heap typowej gry jest całkiem korzystny do działania GC tj. duża część pamięci to duże tablice, których nie trzeba skanować. Z tego co czytam to nie mają nawet generacji https://docs.unity3d.com/Manual/performance-garbage-collector.html . Możliwe też, że C# ficzery dotyczące alokacji w miejscu (jak struct) sprawiają, że allocation pressure jest dużo mniejszy niż w przypadku korpo apki w Javie
We wszystkich innych przypadkach IMHO lepsze są języki z GC bo nie trzeba myśleć o niszczeniu obiektów (Chociaż trzeba przyznać jest że C++ i Rust zrobiły niesamowity postęp żeby w większości wypadków nie trzeba jednak robić "delete"). No bo jak mamy taki zrównoleglony mikroservice w Javie (czy C#) to nawet jak się mikroserwis zatrzyma to pracuje jeszcze
ninnych (Byle nie zatrzymały się wszystkie na raz :D ). A nawet jak to nie jest zduplikowana aplikacja i zatrzyma się jedyna instancja na 100ms to nic się nie dzieje w większości wypadków
Zazwyczaj aplikacja nie jest odpinana z puli load balancera jak odpala gc. A nawet gdyby to gc i tak moze sie trafic w srodku procesowania zapytynia. Jeśli zależy nam na niskim latency to może się zdarzyć, że każdy serwis w scieżce zapytań odpali gc w niekorzystny sposób. Między innymi dlatego gc w go był projektowany pod niskie latency
BTW pomysł żeby język miał opcjonalne GC jest ciekawy, ale czy komuś chciałoby się utrzymywać tak skompikowany język? I problem wszystkich bibliotek które musiałyby być w dwóch wersjach? Z jednej strony pomysł ciekawy, a z drugiej strony tyle niesamowitych kompilacji :(
W C++ masz https://chromium.googlesource.com/v8/v8/+/main/include/cppgc/README.md , zgaduję, że Rust ma coś podobnego.
A zapomniałem, że jest jeszcze cos takiego jak cpp2, rozwianego przez Herb Sutter:
Wszystko wskazuje na to że język C++ zostanie z nami jeszcze długo. W takiej robotyce dominuje nadal C/C++, Python też ale jest za wolny tam gdzie liczy się szybki czas reakcji. Jak te Japońskie walki robotów, system napisany w Pythonie nie nadąży za tym napisanym w C++.
https://blog.robotiq.com/what-is-the-best-programming-language-for-robotics
https://www.quora.com/What-is-the-future-as-a-C++-developer
Sam c++ nie, ale mógłby powstać twór, który zachowałby składnię c++ ale zostałaby z niego usunięta narośl z C i tak aby nie trzeba było się babrać dłużej w kompatybilności wstecznej.
To co jest dla mnie najważniejsze to to, aby w całym procesie zachować nadal składnię starego c++ po to, aby programiści tego języka nie musieli się niczego nowego uczyć, bo to kosztuje czas.
W innym wypadku nie ma to żadnego sensu, bo jest już Rust i jak mam coś nowego poznawać to po co mam poznawać następny twór c++podobny.
No i aby to miało sens to musiałby to być po prostu osobny twór a nie w ramach obecnej komisji standaryzacyjnej która przedłuża wszystko tylko po to, aby mieć pracę.
@Czitels: A to nie wystarczy wykasować paru plików h ? np. stdio.h
ej, zamiast tak skomleć, że mógłby powstać C++ 2.0 albo C++ XXX.XXX to jak macie wiedzę, to stwórzcie swój własny język, który będzie wszystko miał i będzie taaaaki zayebisty - a potem przekonajcie do niego cały świat - ale coś mnie się wydaje, że macie nadmuchane ego i nie dacie rady, bo wasza wiedza kończy się na umiejętności korzystania ze standardu :)
PS. Coś mnie się wydaje, że nigdy nie powstanie coś pokroju tego o czym gadacie, a to z tego względu, że nagle by 99% urządzeń przestało działać i byście się zapłakali bez dostępu do jutuba...
Sam c++ nie, ale mógłby powstać twór, który zachowałby składnię c++ ale zostałaby z niego usunięta narośl z C i tak aby nie trzeba było się babrać dłużej w kompatybilności wstecznej.
Przecież to cloue istnienia c++ kompatybilność i nic więcej.
To co jest dla mnie najważniejsze to to, aby w całym procesie zachować nadal składnię starego c++ po to, aby programiści tego języka nie musieli się niczego nowego uczyć, bo to kosztuje czas.
Przecież tu nie chodzi o składnie(może trochę ale to wynika z feauterów) a kupę UB i nie jasnych corner caseów które wynikają z tego że chciano pozwolić pewnymi konstrukcjami pozwolić na bardzo dużo. Do tego sam język jest niebezpieczny. Ergo usunięcie pewnych pomysłów zubożyło by sam c++. Generalnie przegrana sprawa patrz pkt. wyżej.
Cała ta ekwilibrystyka c++ która istnieje(kosmiczne przykłady z szablonami itd.) i tak używana jest głównie w jakiś libkach. W większości projektów 90% kodu jest po prostu prosta nie korzystająca z jakiś cudownych mechanizmów. Tyle że są czasami jak napisałem UB, znienawidzone konwersje typów itd. i człowiek jak uczy się rust to widzi że sporo załatano i z górki bardziej.
Jest kilka powodów, które sprawiają, że C++ jest jednym z najlepszych języków. Poza tym że napisane są w nim kompilatory, systemy, przeglądarki, gry 3D AAA, sterowniki systemowe, biosy, uefi sterowniki, płyt głównych i kart graficznych CUDA, oprogramowanie samochodów elektrycznych i spalinowych, oprogramowanie do sterowania samolotami osobowymi typu Boeing czy wojskowymi takimi jak F-35, F-16, SR-71. Wymienię niektóre z nich w dowolnej kolejności:
C++ nie ma właściciela. Jest to bardzo ważne, ponieważ wiele innych języków należy do korporacji, zatem ewolucja tych języków wynika z interesów ekonomicznych tej korporacji. Nie dajcie się zwieść: bycie otwartym oprogramowaniem to nie to samo, co brak właściciela.
C++ jest prawie w pełni kompatybilny z C. C jest jednym z najważniejszych języków niskiego poziomu w historii. C++ ma pełną moc programowania niskopoziomowego, jaką ma C. C++ pozwala na kompilowanie programu w C niemal bezpośrednio za pomocą kompilatora C++.
C++ to wysoki poziom abstrakcji. Będąc tak niskim poziomem jak C, C++ jest jednocześnie prawdopodobnie najpotężniejszym istniejącym obecnie językiem wysokiego poziomu abstrakcji.
C++ to programowanie wielu paradygmatów. C++ obsługuje programowanie strukturalne, programowanie obiektowe, programowanie generyczne, paradygmaty programowania funkcjonalnego i współbieżnego; integrując wszystkie te paradygmaty w sposób umożliwiający jednoczesne ich programowanie.
C++ stale ewoluuje. C++ stale się rozwija, wykorzystując najbardziej zaawansowane obecne techniki komputerowe. Dlatego C++ jest zawsze bardzo nowoczesnym nowym językiem, ale z ponad 30-letnią historią i doświadczeniem.
C++ ewoluował, zachowując niemal całkowitą zgodność z przeszłością. Od cfront, do C++98, do C++03, do C++11, do C++14, do C++17, do C++20 i do zaprogramowanego C++23; C++ ewoluował, szanując kompatybilność z przeszłością, umożliwiając programistom „rozwój” bez niszczenia istniejących programów.
C++ ma bardzo dobrą dokumentację. C++ ma w pełni darmową, najłatwiejszą w czytaniu dokumentację programistyczną online , a jednocześnie najlepsze, niewolne książki o C++
Zostało napisane.
C++ to język od wszystkich dla każdego. C++ jest stale tworzony w komitecie złożonym z najważniejszych i najinteligentniejszych naukowców na świecie, ale w którym prawie każdy może uczestniczyć, aby stworzyć formalny standard regulowany przez ISO.
C++ opiera się na zasadach filozoficznych, które określają jego ewolucję. C++ to język zaprojektowany tak, aby ewoluował w łatwy w użyciu sposób, tworząc bardzo wydajne programy, które są łatwe do odczytania, zrozumienia, napisania i utrzymania. Jedną z takich zasad jest na przykład zasada zerowych kosztów ogólnych: „Nie płacisz za to, czego nie używasz”.
C++ to bardzo potężny język. Każda z funkcji C++ zasługuje na konkretne wyjaśnienie, które wykracza daleko poza tę odpowiedź. Wspomnę tylko o kilku z nich (w dowolnej kolejności), żeby dać ci wyobrażenie: Wszystko, co język C ma plus: klasy, konstruktory, destruktory, dziedziczenie, dziedziczenie wielokrotne, dziedziczenie wirtualne, polimorfizm, ochrona dostępu, metody czysto wirtualne, funkcja przeciążanie, przeciążanie operatorów, referencje, inteligentne wskaźniki, RAII, RTTI, szablony funkcji, szablony klas, specjalizacja szablonów, argumenty szablonów wariadycznych, wątki, futures, asynchronizacje, atomy, muteksy, koncepcje, dedukcja typów, auto, wyjątki, moduły, semantyka kopiowania , przesuwaj semantykę, kompiluj obliczenia czasu, lambdy i wiele, wiele innych. Ważne jest jednak to, że zdecydowanej większości z nich nie trzeba znać, żeby tworzyć dobre programy. Jeśli chcesz, możesz się ich po prostu nauczyć i wykorzystać.
C++ jest połączeniem dwóch dużych części: rdzenia i biblioteki standardowej. Język składa się ze stosunkowo krótkiej części stanowiącej rdzeń i dużej części napisanej w samym C++, który jest biblioteką standardową. Pozwala to na łatwy rozwój języka, użytkownicy mogą zobaczyć kod biblioteki, a nawet rozszerzyć go. Wreszcie, ponieważ biblioteka standardowa jest napisana w C++, testuje to sam język. „Tworzenie języka to tworzenie biblioteki”.
C++ ma bardzo potężną społeczność użytkowników i programistów. Istnieją miliardy napisanych programów komputerowych, miliony programistów, tysiące nauczycieli, setki bezpłatnych bibliotek, setki stron internetowych z informacjami, kilka w pełni zoptymalizowanych i darmowych kompilatorów C++ oraz aktywny komitet C++, który stale rozwija język. W ten sposób C++ ma ogromny ekosystem dziedzictwa — współdzielony z C — i zawsze był wierny tej wspaniałej społeczności, zachowując kompatybilność wsteczną i wsparcie.
Wiem, że powodów spektakularnego sukcesu C++ jest więcej, ale myślę, że wspomniałem o kilku najważniejszych czynnikach. Niektóre z nich mogą wymagać dodatkowego wyjaśnienia, jednakże aby skrócić tę długą odpowiedź, wyjaśniłem je jedynie pokrótce.
C++ jest tworzony przez ludzi, więc nie jest doskonały. Ale to jest całkowicie nieistotne. Ważne jest to, że C++ stale ewoluuje w poszukiwaniu „doskonałości” , dowodzonej przez bardzo inteligentnych ludzi, którzy dążą do wzniosłych ideałów w celu poprawy życia ludzkości.
Wierzcie lub nie, ale czy wam się to podoba, czy nie, C++ jest językiem przyszłości. Moja rada: ucz się i bądź kompetentny w C++, szczególnie jeśli chcesz być profesjonalnym programistą. Inne języki są dobre, ale C++ jest koniecznością.
Język który mógł zagrozić C++ to był D, był takim poprawionym C++ z czytelną składnią, ale się nie udało.
jordan_ napisał(a):
C++ nie ma właściciela. Jest to bardzo ważne, ponieważ wiele innych języków należy do korporacji, zatem ewolucja tych języków wynika z interesów ekonomicznych tej korporacji. Nie dajcie się zwieść: bycie otwartym oprogramowaniem to nie to samo, co brak właściciela.
Przez to ABI jest zamrożone i nie można wprowadzić nowych zmian. Inne języki takie jak Go czy Rust mają dużo bardziej elastyczny model rozwoju
C++ jest prawie w pełni kompatybilny z C. C jest jednym z najważniejszych języków niskiego poziomu w historii. C++ ma pełną moc programowania niskopoziomowego, jaką ma C. C++ pozwala na kompilowanie programu w C niemal bezpośrednio za pomocą kompilatora C++.
Możesz być kompatybilny z C nie bazująć na idiotyzmach tego języka. Tak chyba robi V, równie dobrze możesz też używać C z jakiegokolwiek języka poprzez interfejs binarny. Rust ma nawet fajną bibliotekę do pisania FFI w przyjemny sposób
C++ stale ewoluuje. C++ stale się rozwija, wykorzystując najbardziej zaawansowane obecne techniki komputerowe. Dlatego C++ jest zawsze bardzo nowoczesnym nowym językiem, ale z ponad 30-letnią historią i doświadczeniem.
Ale te zmiany to głupotki. C++ dalej nie ma np. refleksji i jest chyba jedynym językiem z top 10 (no i C oczywiście), gdzie nie da się przeparsować JSONa do struktury w sposób automatyczny
C++ opiera się na zasadach filozoficznych, które określają jego ewolucję. C++ to język zaprojektowany tak, aby ewoluował w łatwy w użyciu sposób, tworząc bardzo wydajne programy, które są łatwe do odczytania, zrozumienia, napisania i utrzymania. Jedną z takich zasad jest na przykład zasada zerowych kosztów ogólnych: „Nie płacisz za to, czego nie używasz”.
Np exceptiony to cos za co płacisz choć nie używasz
C++ jest połączeniem dwóch dużych części: rdzenia i biblioteki standardowej. Język składa się ze stosunkowo krótkiej części stanowiącej rdzeń i dużej części napisanej w samym C++, który jest biblioteką standardową. Pozwala to na łatwy rozwój języka, użytkownicy mogą zobaczyć kod biblioteki, a nawet rozszerzyć go. Wreszcie, ponieważ biblioteka standardowa jest napisana w C++, testuje to sam język. „Tworzenie języka to tworzenie biblioteki”.
Biblioteka standardowa C++ jest gówniana przez naleciałości i zamrożone ABI. Co do tego, że jest napisana w C++: każdy stdlib jest napisany w tym samym języku
Inne języki takie jak Go czy Rust mają dużo bardziej elastyczny model rozwoju
Nie ma bardziej elastyczniejszego modelu rozwoju niż całkowicie otwarty standard, który każdy podmiot może sobie wziąć i zrobić z nim co zechce. C++ poleciał w kosmos i jeździł po marsie, odpala Ci gierki i wyświetla strony internetowe. Za to Go cały czas leży w swojej niszy. Nie trafiony przykład. Wiem, że trudno o nie porównywanie do innych języków, ale jak to robisz pisz konkretnie, inaczej zacznie się kolejny językowy flame war.
Ale te zmiany to głupotki. C++ dalej nie ma np. refleksji i jest chyba jedynym językiem z top 10 (no i C oczywiście), gdzie nie da się przeparsować JSONa do struktury w sposób automatyczny
To prawda, że ludzie tworzący propozycje do standardu unikają poważnych problemów, patrz wyjątki, ale nie wszystkie zmiany to głupotki. Za to automatyczne parsowanie JSONa do struktur byłby kolejną głupotką, nie trafiony przykład. Parsowanie JSONa to rozwiązany problem z pomocą 3rd party i jest wiele małych ficzerów w C++, np. structured bindings, które stawiałbym wyżej, niż automatyczne parsowanie modnego w danym czasie formatu.
Np exceptiony to cos za co płacisz choć nie używasz
I tak i nie, jak nic nie rzuci to nie płacisz, ale w ogólności się zgodzę. Tym nie mniej to jedyna taka rzecz.
Biblioteka standardowa C++ jest gówniana przez naleciałości i zamrożone ABI.
Nie cała. Są gówniane elementy, są elementy, które rozwiązują problemy, których nie masz oraz są też te obiektywnie dobre. Zbyt duże uogólnienie.
(edit)
Unikałem tego tematu przez długi czas, bo wiedziałem, że większość postów będzie mało konstruktywna. No ale skoro już napisałem posta to napiszę też na temat.
Czy język C++ potrzebuje wersji C++ 2.0?
Wersja 2.0 miałaby teoretyczną szansę się pojawić jeśli zerwiemy kajdany ABI, co się nie wydarzy bo w komitecie standaryzacyjnym zasiadają ludzie pracujący dla komercyjnych firm i nie w ich interesie będzie sabotowanie własnego oprogramowania bądź narażania pracodawcy na wydatki. Czy zerwanie ABI jest konieczne? Hmmm, zdrowy podzbiór ficzerów istnieje już teraz, jedyną solą w oku są wyjątki i to faktycznie przydałoby się wyczyścić.