🚀 go-pugleaf

W dniu piątek, 16 sierpnia 2019 15:04:18 UTC+2 użytkownik Queequeg napisał:

> > Od C++ wolę się trzymać z daleka.
> 
> Dlaczego?

Bo z mojego doświadczenia tworzy więcej problemów, niż rozwiązuje.
Ma tak skomplikowaną składnię, że sami twórcy sobie z nią nie radzą, a mechanizmy abstrakcji są w nim tak skopane, że nie da się w nim tworzyć generycznych rozwiązań.

Żeby nie być gołosłownym, oto przykłady:

W definicji szablonu zapis

s.foo<T>();

może w pewnych okolicznościach spowodować błąd składni, bo symbol "<" zostanie zinterpretowany jako znak mniejszości, i trzeba pisać

s.template foo<T>();

https://en.cppreference.com/w/cpp/language/dependent_name#The_template_disambiguator_for_dependent_names

Klasa std::initializer_list nie ma zdefiniowanego operatora indeksowania. Dlaczego? Bo nikt nie wpadł na to, żeby go dodać.

Inny przykład, z prezentacji Scotta Meyersa na DConfie w 2014 roku
https://www.youtube.com/watch?v=KAWA1DuvCnQ&feature=youtu.be
(fragment między 16:40 a 22:00)

Albo wykwity w rodzaju xvalue reference.

Co do generycznych rozwiązań, napisałem kiedyś na Quorze taką odpowiedź:
https://www.quora.com/What-are-some-examples-of-bad-code/answer/Panicz-Godek

Co prawda tylko przypadkowo dotyczyła C++a, ale początkowo próbowałem stworzyć dobre rozwiązanie w C++. Ostatecznie się poddałem, właśnie ze względu na to, że nie było dla mnie oczywiste, w jaki sposób zaprojektować w C++ generyczny interfejs do algorytmu A*.

(Dla kontrastu, w Haskellu i Schemie było to całkiem oczywiste).

Zadałem do tej pory kilku C++owym fanbojom wyzwanie, żeby spróbowali dostarczyć generyczne rozwiązanie w C++, i do tej pory nikt mu nie podołał.

Generyczność w C również jest ułomna, ale przynajmniej dla tej ułomności można znaleźć jakieś uzasadnienie.

Natomiast pracując w C++ zawsze miałem wrażenie, jakbym - oprócz zmagania się z problemem - musiał dodatkowo ładować energię w zmaganie się z językiem.