Zaprojektowanie prostszego podzbioru języka C++

Zastanawiam się nad tym czy jest możliwe stworzenie takiego podzbioru C++ i bazowej części biblioteki standardowej, które byłyby prostsze w użyciu.

Co mam na myśli. W Modern C++ jest dużo tak zwanej "soli syntaktycznej" (STL, templates, stosowanie zbyt długich wyrazów itp.), w wyniku czego - kod staje się mniej czytelny, albo w ogóle trudny do zrozumienia.
Jestem natchniony prostotą takich języków jak PHP, Visual Basic, Lua, Python, i uważam że jeżeli dobrze zaprojektować klasy C++ i nie używać zbędnych "modernistycznych" cech języka - można osiągnąć takiego samego poziomu prostoty (jak w niektórych językach skryptowych), szybkiego prototypowania, i co za tym idzie - większej produktywności.

Nie jestem pierwszy, kto zauważył ten problem:

Orthodox C++
https://gist.github.com/bkaradzic/2e39896bc7d8c34e042b

Nominal C++
http://archive.md/2016.08.07-162105/https://namandixit.github.io/blog/nominal-c++/

Embedded C++
https://en.wikipedia.org/wiki/Embedded_C%2B%2B

Sane C++
http://archive.md/2016.08.07-162220/http://flohofwoe.blogspot.nl/2013/06/sane-c.html

Why Your C++ Should Be Simple
http://archive.md/2017.03.19-055108/https://hacksoflife.blogspot.nl/2017/03/why-your-c-should-be-simple.html

C++, it’s not you. It’s me.
https://web.archive.org/web/20190227061553/https://c0de517e.blogspot.com/2019/02/c-its-not-you-its-me.html

"Keep It C-mple" Alexander Radchenko Sydney C++ Meetup

A dialect of C++
https://web.archive.org/web/20200521234043/https://satish.net.in/20180302/

Uwaga! Sam język C++ bardzo mi się podoba! Nie jest to krytyka języka, ale tylko próba odnalezienia zwolenników alternatywnego (niestandardowego) sposobu użycia tego języka w praktyce.

Pamiętacie jak w Facebooku zrobili nowy język HACK (https://docs.hhvm.com/hack/) - który jest podobny do PHP, ale bardziej szybki.

W VK.com - ta sama historia, zrobili szybki podzbiór, kompilowany KPHP (https://vkcom.github.io/kphp/)

Uważam, że zamiast tworzenia nowego języka lepiej byłoby usprawnić podejście do użycia C++ (C z klasami) w pewien niestandardowy sposób, który jak na razie nie jest potocznie akceptowany, ale to nie szkodzi. Najważniejsze są rezultaty. Jeżeli to pozwoli szybciej tworzyć programy, to mnie nie obchodzi co o tym mówi komitet standaryzacyjny.

W C++ też można używać garbage collector (boehm i inne) jeżeli trzeba, chociaż mi wystarczają dobrze zaprojektowane klasy z destruktorami i valgrind. Właśnie teraz robię takie klasy C++ (in-house development w swojej firmie), i powiem wam to wymaga dużego poziomu kreatywności, chociaż wiele pomysłów i konceptualnych rzeczy można adoptować z PHP i podobnych języków.

Czy w ogóle istnieje zainteresowanie tym tematem? Być może ktoś też robi takie eksperymenty albo zbiera już istniejące klasy/biblioteki, w których są zastosowane jakieś niestandardowe sztuczki, usprawniające programowanie w C++?

Pisz w C, to nie będziesz miał takich problemów :P

Pisz w C, to nie będziesz miał takich problemów :P

:) Właśnie tak robiłem, ale potem postanowiłem że w C jest za mało "cukru syntaktycznego", makra nie wystarczają, a tworzyć dodatkowy preprocessor nie ma sensu, dlatego że bazowe dodatki z C++ pozwalają zbudować o kilka razy prostszy język niż czysty C. Ale z drugiej strony, jeżeli przesadzać z tymi dodatkami (jak w Modern C++), to będzie jeszcze gorzej niż w czystym C. Mówię o znalezieniu złotego środka, takiego rozwiązania które pozwoli pisać w tym podzbiorze (C z klasami) tak samo szybko jak w PHP, Python i innych skryptowych językach.

IMHO Porzuć C++ i idź do Rusta. Nie widze przyszłości w upraszczaniu C++ skoro można iść od Rusta

@KamilAdam: zobacz to

(STL, templates, stosowanie zbyt długich wyrazów itp.), w wyniku czego - kod staje się mniej czytelny, albo w ogóle trudny do zrozumienia.

Myślę, że Rust nie pomoże.

IMHO Porzuć C++ i idź do Rusta. Nie widze przyszłości w upraszczaniu C++ skoro można iść od Rusta

Podoba mi się C/C++. Po co bym miał iść od Rusta? IMHO, Rust ma podobną przyszłość (overengineering) jak i Modern C++.

Nie widzę żadnego problemu w napisaniu kilku klasów podstawowych upraszczających programowanie w C++. Jak zauważyłem, problem jest nie w języku. C++ jest o tyle elastyczny, że pozwala osiągać cudowne rezultaty w zakresie projektowania tego podzbioru.

Ten temat jest teraz bardzo gorący. Poczytaj o cppfront albo o carbon.

Co do pytania: nie warto według mnie. C++ ma za dużo problemów takich jak dziedzictwo C, błędne decyzje projektowe z przeszłości czy zamrożone ABI. Do nowych projektów Rust jest dużo lepszym językiem

Nie jestem pierwszy, kto zauważył ten problem:

Od dekad ludzie o tym myślą i próbują zrobić lepsze C. No i zrobili C++. Ale nie wystarczyło i postanowili zrobić lepsze C++. Więc powstała Java i C#. A potem znowu nie wystarczyło i to jakiś Rust, to jakiś Golang, jakiś Zig czy nawet Carbon ostatnio.

Może więc wybrać coś z tych popularnych alternatyw do C++?

to napisz specyfikację i przykładową implementację skoro wiesz co jest problemem

Pracuję nad podstawową implementacją dla swojej firmy. Wymyślenie/projektowanie było najbardziej ciężkim etapem, ale teraz już widzę zalety takiego kierunku.

Jestem pewien, że większość ze sprytnych programistów miała by lepsze pomysły niż ja, ale i to co osiągam też wygląda całkiem nieźle.

Mam bardziej biznesowy background (niż techniczny), dlatego potrzebuję prostego narzędzia do szybkiego prototypowania, ale musi to być jednocześnie język kompilowany. No i C/C++ w ogóle mi się podoba.

slsy napisał(a):

Ten temat jest teraz bardzo gorący. Poczytaj o cppfront albo o carbon.

Co do pytania: nie warto według mnie. C++ ma za dużo problemów takich jak dziedzictwo C, błędne decyzje projektowe z przeszłości czy zamrożone ABI. Do nowych projektów Rust jest dużo lepszym językiem

Dziękuję bardzo za odpowiedź. Dobrze wiedzieć co ludzie o tym myślą. Być może się mylę i czas pokaże.

Carbon od Google jest językiem eksperymentalnym jak na razie. Taki "Kotlin" tylko dla C++.

Dla mnie kompatybilność C++ z C jest raczej zaletą niż wadą.

LukeJL napisał(a):

Nie jestem pierwszy, kto zauważył ten problem:

Od dekad ludzie o tym myślą i próbują zrobić lepsze C. No i zrobili C++. Ale nie wystarczyło i postanowili zrobić lepsze C++. Więc powstała Java i C#. A potem znowu nie wystarczyło i to jakiś Rust, to jakiś Golang, jakiś Zig czy nawet Carbon ostatnio.

Może więc wybrać coś z tych popularnych alternatyw do C++?

Panowie, wszystko mi się podoba. Dla mnie całkowicie wystarcza minimalistyczny C++. Mam po prostu takie zdanie, takie widzenie tej sytuacji.

https://godbolt.org/z/bPEzf4KWx

Dziękuję bardzo za tematyczne wideo, pójdę oglądać.

https://godbolt.org/z/bPEzf4KWx

Coś w tym stylu, ale jeszcze prościej. Naprawdę, można to zrobić na poziomie podstawowego C++. Makra też używam dla celów fundamentalnego upraszczania.

Zanim zaczniesz coś robić, zastanów się nad definicjami, jak je rozumiesz. W pierwszym wpisie nazywasz "prostym" język do którego ja bardziej uważam pasuje określenie "prymitywny" - czyli ten Python. Przemyśl wszystkie definicje. "dlatego że bazowe dodatki z C++ pozwalają zbudować o kilka razy prostszy język niż czysty C" -- tutaj zaś tracisz kontrolę nad kodem.

johnny_Be_good napisał(a):

Zanim zaczniesz coś robić, zastanów się nad definicjami, jak je rozumiesz. W pierwszym wpisie nazywasz "prostym" język do którego ja bardziej uważam pasuje określenie "prymitywny" - czyli ten Python. Przemyśl wszystkie definicje. "dlatego że bazowe dodatki z C++ pozwalają zbudować o kilka razy prostszy język niż czysty C" -- tutaj zaś tracisz kontrolę nad kodem.

Tak, chcę mieć opcję tego "prymitywizmu" (kiedy mniej kodu robi to samo) i C++ pozwala ją zrealizować wbrew potocznemu widzeniu że C++ jest "skomplikowany". Być może jest skomplikowany tylko wtedy kiedy tego wymaga synchronizacja z powszechnie zaakceptowanymi regułami jego używania (to jest niezbędne, bo standardowa biblioteka pozwala w biznesie szybko zamieniać programistów na tym samym stanowisku, to są przyczyny tej pułapki).
P.S. Oczywiście Modern C++ też muszę uczyć żeby rozumieć jak używać bibliotek napisanych w C++11 C++17 etc.

Dennis Kring napisał(a):

Tak, chcę mieć opcję tego "prymitywizmu" (kiedy mniej kodu robi to samo)

Mniej kodu robi to samo to ekspresywność języka - czyli między innymi cukier składniowy, a w przypadku C++ pomagają też templaty i STL (między innymi).
Skoro akurat powyższe Ci przeszkadza, to jednak nie tego szukasz.

Mniej kodu robi to samo to ekspresywność języka - czyli między innymi cukier składniowy, a w przypadku C++ pomagają też templaty i STL (między innymi).
Skoro akurat powyższe Ci przeszkadza, to jednak nie tego szukasz.

Tak, templaty to cukier składniowy, ale STL to już jest biblioteka. Templaty mi nie przeszkadzają, po prostu bardzo rzadko ich używam - tam gdzie to trzeba, a nie wszędzie.

A jak ktoś tu na forum wklei kod w "C with classes" to go objeżdżają że to nie jest prawdziwy C++ :)

Templaty mi nie przeszkadzają, po prostu bardzo rzadko ich używam - tam gdzie to trzeba, a nie wszędzie.

A już w ogóle antydydaktyczne jest wciskanie template'ów w każdy przykład kodu dotyczący jakiegoś ficzera C++ (a niewymagającego użycia template'u).

W nowoczesnym C++ kod może być akurat bardziej zwięzły niż kiedyś. Możesz pokazać na przykładzie, co tak bardzo Ci przeszkadza?

Pebal napisał(a):

W nowoczesnym C++ kod może być akurat bardziej zwięzły niż kiedyś. Możesz pokazać na przykładzie, co tak bardzo Ci przeszkadza?

Tak, wiem o tym. Czytam nowe książki Stroustrup'a czasami. Nie wykluczam tego, że być może kiedyś się przydadzą niektóre z tych nowych ficzerów w przyszłości. Ale C++03 jest dla mnie w 99% wystarczający.

Jakie przykłady? No cała ta biblioteka STL jest przykładem :) Rozumiem, że to sprawa gustu i subiektywizm.

Moim zdaniem dyskusyjny jest kierunek, w jakim miałby zmierzać C++: czy zmierzać do abstrakcji, czy trzymać się bliskości sprzętu. Ponieważ powstały różne abstrakcje, które umożliwiają prostszy zapis, ale niekoniecznie wyrażają bezpośrednio intencję w języku maszynowym. Chciałem tutaj napisać na przykład o iteratorach i ich otoczeniu do przetwarzania danych, ale skoro jest przykład C++ Syntax 2, to odniosę się do niego.

https://godbolt.org/z/bPEzf4KWx

W podanym przykładzie jest procedura (tak ją określę) decorate.
Zaletą jest możliwość określenia parametru jako wejściowy i wynikowy. Natomiast można się zastanowić, jak ma w rzeczywistości być dokonywane scalenie ciągów tekstowych.
Bo może być dokonane na co najmniej dwa sposoby:

• Nie używamy abstrakcji i każdy operator dodawania przydzieli brakujący bajt pamięci, co jest nieoptymalne, ponieważ wiemy od początku, że będą potrzebne dwa dodatkowe (w tym jeden na początku).
• Język tworzy abstrakcję i kompilator alokuje na początku dwa bajty więcej, i to jeszcze w taki sposób, że nie będzie wymagane kopiowanie otaczanego ciągu tekstowego.

Według mnie lepiej by było umieścić od razu ciąg tekstowy tam, gdzie jest potrzebny wynikowy, lecz bez zakładania, że kompilator zastosuje abstrakcję, ponieważ wtedy oddalamy się od kontroli tego, co się dzieje, w kierunku języków takich jak Javascript. Jednak nie wiem, jak to zapisać prosto bez ręcznej manipulacji wskaźnikami.
Dlatego krytykuję tutaj takie użycie procedury decorate — uważam, że to nie jest to, gdzie C++ mógłby zmierzać — ale pochwalam postać nagłówka tej procedury.

Dopiszę jeszcze, że… tak, używam tutaj być może nie stosowanego przez kompilator podejścia do użycia ciągów tekstowych, takiego, które pozwala uniknąć niepotrzebnego kopiowania. W tym przykładowym programie od początku wiadomo, że będzie jeden dodatkowy znak przed ciągiem otaczanym, więc można przydzielić pamięć na ten znak, a ciąg umieścić od razu za nim. Natomiast nie zawsze to jest wiadome od początku, a wtedy wystarczy wyszukać, czy w pamięci jest wolny obszar przed tym tekstem i przydzielić z niego bez kopiowania. Taką właśnie procedurę napisałem w rozwijanym przeze mnie C+, jednak tam nie ma abstrakcji, ponieważ oparty jest o C i muszę używać wskaźników. Jednak tego typu podejście jest przyszłościowe, a nie upraszczanie bez zrozumienia w samej istocie C++.

overcq napisał(a):

Moim zdaniem dyskusyjny jest kierunek, w jakim miałby zmierzać C++: czy zmierzać do abstrakcji, czy trzymać się bliskości sprzętu.

Jeżeli trzymać się bliskości sprzętu (żeby nie oddalać się od kontroli tego, co się dzieje), to pamiętam jeszcze kiedyś był taki język C-- (https://en.wikipedia.org/wiki/C--), "portable assembly language", chyba byłby przydatny do niskopoziomowych zastosowań.

Ja tutaj mówię o wysokopoziomowym programowaniu, dla biznesu, RAD itp.

Dennis Kring napisał(a):

Dla mnie kompatybilność C++ z C jest raczej zaletą niż wadą.

W tej linii nie da się nic pozytywnego wymyśleć. Tylko dowcip mi się przypomina (trzeba mówić tzręsącym się starczym głosem) "20 lat temu staliśmy na brzegu przepaści. Jednak dzięki braterskiej pomocy Zwiazku Radzieckiego zrobiliśmy znaczący krok do przodu"

Już nie pamiętam co to jest "milladr dollar bug", ale dla mnie C jest trillion dollar bug (niech tego amerykanie nie czytają).
Język jest najzwyczajniej niebezpieczny, co oznacza również kosztowny.
Arytmetyka pointerów, tablice będące pointerami a nie rzeczywistymi tablicami, rzutowanie do bool'a, ale i syntaktyczne które NIESTETY wniósł w branże, jak nieszczęsny switch case itd...

Język C pochwały i apostolstwo - jak widzę - dostaje najczęściej od świeżaków będącymi w dziedzinie homo unius libri

ZrobieDobrze napisał(a):

Już nie pamiętam co to jest "milladr dollar bug", ale dla mnie C jest trillion dollar bug (niech tego amerykanie nie czytają).
Język jest najzwyczajniej niebezpieczny, co oznacza również kosztowny.

Bardziej kosztowny niż Java (z punktu widzenia pracodawcy). Nóż też jest niebezpieczny. Wszystko zależy od tego kto i jak go używa.

Arytmetyka pointerów, tablice będące pointerami a nie rzeczywistymi tablicami, rzutowanie do bool'a, ale i syntaktyczne które NIESTETY wniósł w branże, jak nieszczęsny switch case itd...

Pointerofobia?

Język C pochwały i apostolstwo - jak widzę - dostaje najczęściej od świeżaków będącymi w dziedzinie homo unius libri

Linus Torvalds to świeżak?

ZrobieDobrze napisał(a):

W tej linii nie da się nic pozytywnego wymyśleć. Tylko dowcip mi się przypomina

Bardziej dowcipne dla mnie jest porównanie C z Syjonizmem/Judaismem, a C++ z Chrześcijaństwem. Można powiedzieć że już jestem ochrzczony :)

Dennis Kring napisał(a):

ZrobieDobrze napisał(a):

Już nie pamiętam co to jest "milladr dollar bug", ale dla mnie C jest trillion dollar bug (niech tego amerykanie nie czytają).
Język jest najzwyczajniej niebezpieczny, co oznacza również kosztowny.

Bardziej kosztowny niż Java (z punktu widzenia pracodawcy). Nóż też jest niebezpieczny. Wszystko zależy od tego kto i jak go używa.

Arytmetyka pointerów, tablice będące pointerami a nie rzeczywistymi tablicami, rzutowanie do bool'a, ale i syntaktyczne które NIESTETY wniósł w branże, jak nieszczęsny switch case itd...

Pointerofobia?

Język C pochwały i apostolstwo - jak widzę - dostaje najczęściej od świeżaków będącymi w dziedzinie homo unius libri

Linus Torvalds to świeżak?

Z Linusem nie miałem przyjemnosci rozmawiać (a podobno to rzadko jest przyjemnoscią), podobnie jak z Kletem ani Klemensem (jak jesteś ochrzczony, powieneś znać)

A 99% spotkanych PRZEZE MNIE w przestrzeni elektronciznej i w realu apostołów C następnego dnia zadaje banalne a podstawowe pytania. Pewne rzeczy A ZWŁASZCZA GADANIE są łatwe dopóki sobie paluchów nie poraniłeś. I łatwo zalecac jeden jezyk, jak to jest 100% które się zna.

Dennis Kring napisał(a):

Język C pochwały i apostolstwo - jak widzę - dostaje najczęściej od świeżaków będącymi w dziedzinie homo unius libri

Linus Torvalds to świeżak?

Zawsze jest wyciągany Linux w kontekście C. Ale pisanie systemów operacyjnych to bardzo specyficzny przypadek. I to faktycznie do niedawna nie było lepszego języka do pisania systemów operacyjnych. Wynika to z tego prostego problemu że rzucanie wyjątków wymaga wsparcia systemu operacyjnego (podobno). 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

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

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.

@KamilAdam:

+1

Za Kerrigana i Richiego (circa about 1970) nie było tak, ze NIE BYŁO lepszych języków (w tym do systemów) - tylko chodziło o taki kompilator, który niskim kosztem da sie portować na nowe architektury.
Stąd ten ogromny prymitywizm języka.

Przyjęcie każdej wartości jako mającej sens bool - to była optymalizacja jednego, dwóch rozkazów maszyznowych, która to optymalziacja już od 1980 kompilatorom nie robiła żadnego problemu.

Za to płacimy do dziś.

A 99% spotkanych PRZEZE MNIE w przestrzeni elektronciznej i w realu apostołów C następnego dnia zadaje banalne a podstawowe pytania. Pewne rzeczy A ZWŁASZCZA GADANIE są łatwe dopóki sobie paluchów nie poraniłeś.

Ok. Ciekawe doświadczenie.

I łatwo zalecac jeden jezyk, jak to jest 100% które się zna.

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