Nie spodziewalem sie ze ponizszy kod sie kompiluje, a on nawet uruchamia sie i zwraca oczekiwane wyniki:
member (function) name == member( function const) name - wiadomo ze dla kompilatora to nie problem ale dla czlowieka juz tak
https://godbolt.org/z/d5Pn8q831
0
1
Z tego co zauważyłem, to społeczność jest podzielona w tym temacie. Komitet ISO brnie coraz bardziej w szablony, dostarczone ficzery bywają przydatne, ale składnia jest coraz bardziej wykręcona. Dostaliśmy to już w postaci std::chrono i zapewne dostaniemy powtórkę z rozrywki w postaci obsługi sieci.
W skutek powyższego powstają różne odłamy w społeczności i powstają ruchy jak chociażby Orthodox C++. Są też środowiska, które odrzucają niemal wszystko co oferuje nowoczesny C++ i piszą jak w C99 a z C++ biorą tylko przeładowanie funkcji. Takie podejście stosuje np. Casey Muratori, twórca handmade hero https://handmadehero.org/ i ma sporo naśladowców. Inni piszą niemal w czystym C, ale kompilują kompilatorem do C++ bo ten oferuje bogatsze utility niż komplator C. Są jeszcze inni, którzy używają wszystkiego co się da z języka, ale nie używają biblioteki standardowej.
Tak na prawdę sam musisz zdecydować z którymi ficzerami czujesz się komfortowo, a które są dla Ciebie całkowicie zbędne i tylko generują brzydki zapach. Są ficzery w C++ które są obiektywnie dobre a których brakuje w C i nie mam tu na myśli bogatszej biblioteki. Pytanie tylko czy dla Ciebie te ficzery są warte by używać bardziej zawiłego języka, czy jednak lepiej jest pozostać w dużo lepiej zdefiniowanym C.
EDIT
Jeśli chodzi o przyszłość składni C++ to nie ma co się oszukiwać, społeczność sterująca rozwojem języka dąży do boostologi. Te kilkanaście tysięcy pozostałych, zawodowych programistów C++ będzie albo operowała na podzakresie języka w zależności od domeny, albo będziemy mieli wszędzie kod jak w CGAL https://doc.cgal.org/latest/Mesh_3/Mesh_3_2mesh_implicit_sphere_variable_size_8cpp-example.html
0
@several:
Nie zdawalem sobie sprawy ze w C++ (i wsrod programistow C++) jest tyle roznorodnosci. Z jednej strony to fajnie, bo jest wiekszy wybor mozliwosci, ale mozna sie na tym tez przekrecic. Nie jestem konserwatysta, aby trzymac sie tylko C czy C z klasami - raczej stopniowo w miare poznawania jezyka (w moim tempie) przyswajam nowe feature C++ - w koncu wprowadzili je ludzie, ktorzy wiedzieli co robia.
2
składnia jest coraz bardziej wykręcona
Jeszcze niedawno bym się z tym nie zgodził, ale jak zobaczyłem implementację coroutines, to zaczynam wątpić czy rzeczywiście zmiany idą w dobrym kierunku.
0
@teofrast:
w koncu wprowadzili je ludzie, ktorzy wiedzieli co robia.
No ja nie wiem czy ludzie, którzy wprowadzili auto_ptr, wyjątki i OOP w C++ wiedzieli co robią. Sam fakt jawnego istnienia pojęcia UB w standardzie nie świadczy o nich dobrze. W tej chwili faktycznie większość ludzi udzielających się w komitecie ma mocniejsze zaplecze praktyczne niż akademickie, ale większość z nich jest chyba bardziej zainteresowana dorzucaniem ficzerów z innych języków do biblioteki niż naprawianiem wieloletnich problemów.
@TomaszLiMoon
C++ potrafił mi prostować zwoje jeszcze przed C++11, wystarczy spojrzeć na niektóre techniki z książki Alexandrescu - Modern C++ Design.
2
several napisał(a):
@teofrast:
Sam fakt jawnego istnienia pojęcia UB w standardzie nie świadczy o nich dobrze.
- Pojęcie UB pochodzi z
Ci zostało "odziedziczone" - Większość kojarzy UB z błędami, ale celem było zrobić autorom kompilatorów dobrze. Nie nakładać na nich restrykcji, które miałyby negatywny wpływ na szybkość kodu. Przykład pozytywnego wpływu UB: dzięki niemu mamy np address sanitizer.
- UB umożliwia też robienie rożnych optymalizacji. Czasami to się się mści np Time Travel.
Żeby było jasne, większość UB też mnie wkurza, ale nie jest to samo zło.
Przynajmniej niektóre UB zostają zdefiniowane, np C++17 wyrażenie a[++i] = i; przestało być UB.
1
@several: powiedziałbym, że metaprogramowanie przed C++11 prostowało zwoje o wiele lepiej niż to nowoczesne ;)
BTW, czytałem ostatnio na stacku dyskusję kilku gości z komisji standaryzacyjnej i tam padło np., że Bjarne nie chciał wprowadzać dynamic exception specification do języka, ale kilka firm go naciskało (finansowo także), albo że auto miał gotowe jeszcze w czasach CFront, ale biznes chciał kompatybilności z C.
Zakładając, że to prawda - pomysły jakieś były, krawaciarze się dołożyli i wyszła zimna d...a ;) BTW, sporo UB to zaszłości z C. Ciekawe ile z nich to wynik w/w nacisków ;)
@teofrast
Czego się używa? Zależy. Ja w obecnej pracy sporo piszę templatkologii, lubię te tematy, podoba mi się to i lubię w tym dłubać a do tego mam pole do dłubania w tym z racji tego jak codbase wygląda ;P. Nie każdemu musi to pasować i to jest ok. Ale dobrze z podstawowych ficzerów, także szablonowych, być w stanie skorzystać, a takimi np. stało się perfect forwarding czy variadic templates i fold expressions.
I generalnie warto umieć pisać kod w miarę idiomatyczny, korzystać z STLa itd. Generalnie - znać bibliotekę standardową, albo chociaż jej dokumentację.
Duży problem C++ to programiści C, których przymuszono do pisania w tym języku i którzy de facto go nie znają, ale menedżment myślał że to to samo. I potem dostajesz jakieś potworki w kodzie, do tego ci starzy kształcą młodych i kręci się to niczym g... w przerębli. Pal sześć jeszcze jak to jest konsekwentne "C z referencjami i overloadingiem"., ale w momencie jak dochodzą biblioteki zewnętrzne, obsługa wyjątków itd. raczej nie da się od faktycznego C++ uciec.
2
@alagner @MarekR22 dzięki Panowie za kontekts, ale UB mogłoby być wprowadzone nawet i przez samą pra matkę całego IT i nie zmieni to faktu, że obecność UB w standardzie dowodzi słabości standardu.
UB umożliwia też robienie rożnych optymalizacji.
Ja jednak wolę spójny język, który nie przeszkadza robić programiście optymalizacji samemu, jeśli jest taka potrzeba. Nie pierwszy raz czytam to zdanie i mam z nim problem, bo tak jak rozumiem jego obiektywność tak zawsze się obawiam, że jak młody programista to przeczyta to jeszcze będzie gotów pomyśleć, że UB to coś pozytywnego a nie zło konieczne wynikające ze sposobu standaryzacji wykorzystywane jako legalną furtknę przez kompilatory do dorzucania haków do Twojego programu.
6
obecność UB w standardzie dowodzi słabości standardu
UB w standardzie wynika z filozofii języka C++, którego jedną z głównych zasad jest zero-overhead. IMO eliminacja UB z danego języka(*) musi powodować pogorszenie jego wydajności. Prostym przykładem jest tutaj tablica i przekroczenie jej rozmiaru. Gdyby w C++ zaimplementować mechanizm sprawdzający czy indeks tablicy jest poza zakresem, to czas dostęp do jej wartości stałby się wolniejszy.
(*) jeżeli jest to w ogóle możliwe
0
UB w standardzie wynika z filozofii języka C++, którego jedną z głównych zasad jest zero-overhead.
Standard jest bardzo niekonsekwentny jeśli chodzi o przestrzeganie tej zasady. Przykładowo płacisz za wyjątki mimo, że ich nie używasz i standard nic z tym nie robi, ale z drugiej strony serwuje nam UB w imię "zero-overhead". Bardzo brzydko.
Prostym przykładem jest tutaj tablica i przekroczenie jej rozmiaru. Gdyby w C++ zaimplementować mechanizm sprawdzający czy indeks tablicy jest poza zakresem, to czas dostęp do jej wartości stałby się wolniejszy.
Są dwie klasy UB - jednoznacznie negatywne czyli to co właśnie przytoczyłeś, oraz takie, na których po czasie programiści zaczynają polegać. Tych pierwszych powinno być jak najmniej, programiści powinni o nich wiedzieć i je omijać, ale czasem ciężko od nich uciec, a tych drugich nie powinno być w ogóle. Niestety tych drugich jest więcej niż Ci się wydaje, jak się puści taki UB Sanitazer na jakimś nietrywialnym systemie to można się nieźle zdziwić https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html
(*) jeżeli jest to w ogóle możliwe
Jest to możliwe gdy Twoim standardem jest referencyjna implementacja. Jeśli mówimy o standardzie na bazie dokumentu, to realistycznie na sprawę patrząc, jakieś UB zawsze się pojawią. I dopóki są to takie oczywistości jak przekroczenie zakresu tablicy to może bym się nie czepiał, ale w przypadku C/C++ sprawa jest niestety dużo poważniejsza.
0
O, znalazłem ci: "About a third of projects banned RTTI in whole or in part": dontembedd
A to o wyłączaniu masowym exceptionów ("about a half"): muszeboinaczej embeduje
0
@Wyjątek: to w końcu banują czy wyłączają? To dwie bardzo różne rzeczy. Banowanie RTTI jest powszechne, ale ogranicza się to najczęściej do nie używania RTTI we własnym kodzie, mało kto sonduje pod tym kątem third party.
A jeśli chodzi o wyjątki to też tam masz użyte słowo "ban" a nie "turn off" i troche naciągasz wyniki to połowa projektów pozwala używać wedle uznania, a 25% pozwala używać w wybranych fragmentach kodu, a 22% banuje wyjątki w całości. Do tego patrząc na wymienione przyczyny/skutki takiego bana (używanie dialektu C++, używanie EASTL itp.) na pewno nie rozpowiadałbym, że środowisko masowo banuje wyjątki, bo takie narzędzia w masowym użytku nie są.