Zaprojektowanie prostszego podzbioru języka C++

Dennis Kring napisał(a):

A jaki język musi być zalecany na forum w wątku poświęconemu C/C++ ?

Nie językowi C/C++, ale "ulepszonemu C/C++"

Niemozliwe jest ulepszenie C ++ ++ bez zerwania kompatybilności z C

@Dennis Kring:

Chcesz powiedzieć, że ty osobisćie nigdy:
nie przejechałeś tablicy
nie pomyliłeś wyrażenia w if (a kompoialtor nie kontrolował)
nie waliłeś w null pointer zabijając porogram (o ile system operacyjny był na tyle litościwy, gorzej jak jakiś DOS w uK nie zabijał)
(Jeszcze ciekawszy jest null z małym offsetem. Kto się przyzna?)
nie pomyliłeś parametrów printf
twoj kolega nie wywrócił sie na twoim makrze we wspólnym pliku include

Skoro tak, ciągnij w C

ZrobieDobrze napisał(a):

Dennis Kring napisał(a):

A jaki język musi być zalecany na forum w wątku poświęconemu C/C++ ?

Nie językowi C/C++, ale "ulepszonemu C/C++"

Niemozliwe jest ulepszenie C ++ ++ bez zerwania kompatybilności z C

Przepraszam, ale nie do końca rozumiem, na kiedy jest zaplanowane zerwanie kompatybilności z C ?

Dennis Kring napisał(a):

Przepraszam, ale nie do końca rozumiem, na kiedy jest zaplanowane zerwanie kompatybilności z C ?

Dlatego dla mnie to wątek "jasiowy"

ZrobieDobrze napisał(a):

@Dennis Kring:

Chcesz powiedzieć, że ty osobisćie nigdy:
nie przejechałeś tablicy
nie pomyliłeś wyrażenia w if (a kompoialtor nie kontrolował)
nie waliłeś w null pointer zabijając porogram (o ile system operacyjny był na tyle litościwy, gorzej jak jakiś DOS w uK nie zabijał)
(Jeszcze ciekawszy jest null z małym offsetem. Kto się przyzna?)
nie pomyliłeś parametrów printf

Skoro tak, ciągnij w C

No to zrób sobie C++ class który będzie śledzić by twoja tablica nie została "przejechana" albo używaj gotowych bibliotek ze strukturami danych jeżeli preferujesz tylko czysty C. Używaj narzędzi do debugowania, wykrywania wycieków pamięci. To kwestia przyzwyczajenia.

Właśnie piszę w C++ jeżeli nie zauważyłeś :)

several napisał(a):

Uważam, że zamiast tworzenia nowego języka lepiej byłoby usprawnić podejście do użycia C++
Czy w ogóle istnieje zainteresowanie tym tematem?

Korporacje się interesowały tematem przez ostatnie 25 lat i po kolei zaczynają dochodzić do wniosku, że nadszedł czas by tworzyć nowe języki w jego miejsce :) C++ to taka wielka, magiczna skrzynia w warsztacie w której znajdziesz łom, klucz nasadowy, trójkołową kosiarkę na propan butan skręcającą tylko w lewo, czterokołową kosiarkę na propan butan skręcającą tylko w prawo, młot pneumatyczny i inbusik rozmiaru 7.5mm. Jak siedziałeś w tym warsztacie jakiś czas to mając taką skrzynię jesteś w stanie wiele osiągnąć dobierając odpowiednie narzędzia z tej wielkiej, magicznej skrzyni i ustawiając je sobie samemu na stole, jednak osoba dopiero wchodząca do warsztatu z reguły będzie bardziej efektywna mając uporządkowaną ścianę narzędzi przed oczami. Narzędzi może i mniej za to wiadomo, gdzie rękę wyciągnąć jak coś potrzeba.

Zgadzam się z tym. Ale warto spróbować jeszcze raz. Bo siedziałem w tym warsztacie jakiś czas.

KamilAdam napisał(a):

Dennis Kring napisał(a):

Teoretycznie można by napisać mały rdzeń systemu w podzbiorze C++ bez wyjątków, a więc też bez obiektowości (wyjątki w C++ powstały po to żeby można było poinformowac że utworzenie obiektu się nie udało). A reszte systemu można by już napisac w Normalnym C++ z wyjątkami i obiektami. Mimo to Linus nie zdecydował się na to rozwiązanie

Teoretycznie można by było zrobić rdzeń nawet używając C z klasami. Prawdopodobnie problemem było to, że kod był generowany niezbyt optymalnie. A potem już "tradycja" i personalna alergia. Linus po prostu nie chciał bloatware with templates. To jest jego sposób zabezpieczyć się przed tym zagrożeniem :)

No ale większość z nas nie pisze systemów operacyjnych. A używanie C do pisania dużych systemów biznesowych to często szaleństwo i nic więcej

Do pisania dużych systemów biznesowych jest przydatny OOP.

jarek nie nazwał template "cukrem składniowym", ty sobie to ekstrapolowałeś.To jest potężne i niestety trudne narzędzie, którym można zrobić niesamowite rzeczy, które normalnie wymagały by dziergania.

Zgadzam się z tym. Ale warto spróbować jeszcze raz. Bo siedziałem w tym warsztacie jakiś czas.

Jakbyś siedział to byś wiedział, że nie warto.

Z tego bogatego i chaotycznego zestawu narzędzi wybierzesz te, które pasują do Twojego obecnego workflow, dla kogoś innego ten podzbiór może wyglądać zupełnie inaczej. Wcześniejsze podejścia (Sane/Orthodox C++ itp) również są obarczone taką samą inklinacją oraz mają silne skrzywienie produkcyjne. STL nie pasuje bo implementacja na jedną z platform, którą targetuje jest o kant? No dobrze, to wtedy używam czegoś swojego. Tym nie mniej standardowy STL jest wciąż super przydatny do prototypowania jak również podręcznej narzędziówki. C++03 pokrywa Twoje potrzeby? No fantastycznie, ale dla mnie era przed c++11 to jak era kamienia łupanego.

Jedyne co jesteś w stanie osiągnąć, to zrewidować szeroki zakres narzędzi, by finalnie zostać z czymś skrojonym pod swoje potrzeby. Z tymże potrzeby innego programisty mogą być zupełnie inne.

several napisał(a):

Z tego bogatego i chaotycznego zestawu narzędzi wybierzesz te, które pasują do Twojego obecnego workflow, dla kogoś innego ten podzbiór może wyglądać zupełnie inaczej. Wcześniejsze podejścia (Sane/Orthodox C++ itp) również są obarczone taką samą inklinacją oraz mają silne skrzywienie produkcyjne. STL nie pasuje bo implementacja na jedną z platform, którą targetuje jest o kant? No dobrze, to wtedy używam czegoś swojego. Tym nie mniej standardowy STL jest wciąż super przydatny do prototypowania jak również podręcznej narzędziówki. C++03 pokrywa Twoje potrzeby? No fantastycznie, ale dla mnie era przed c++11 to jak era kamienia łupanego.
Jedyne co jesteś w stanie osiągnąć, to zrewidować szeroki zakres narzędzi, by finalnie zostać z czymś skrojonym pod swoje potrzeby. Z tymże potrzeby innego programisty mogą być zupełnie inne.

Mogę używać i STL jeżeli to będzie wymagane. Jednak te skrojone pod swoje potrzeby narzędzia są o wiele ciekawsze (bardziej funkcjonalne) i prostsze.

Dziękuję za odpowiedź. Naprawdę ta dyskusja była SUPER przydatna dla mnie.

no można można, ale po co?

tworzysz nową tech i chcesz ją skojarzyć z CPP? przecież to samobójstwo :D

C

C++03

C++11, C++14, C++17, C++20, C++23

Jeszcze jedna próba - język Mojo:

https://www.modular.com/mojo

Mojo combines the usability of Python with the performance of C.

Być może będzie przydatny dla AI. Ale uważam, że nie ma sensu tworzyć nowe języki na każdy problem. C++ jest wystarczająco dobry. Tylko trzeba zrobić jeszcze jedną alternatywną standardową bibliotekę dla programistów biznesowych. I podczas projektowania lepiej zwrócić uwagę na usability of PHP, a nie Python.