🚀 go-pugleaf

W dniu poniedziałek, 2 września 2019 19:59:36 UTC+2 użytkownik Wojciech Muła napisał:

> > Klasa std::initializer_list nie ma zdefiniowanego operatora indeksowania.
> > Dlaczego? Bo nikt nie wpadł na to, żeby go dodać.
> 
> std::initializer_list fajnie wygląda na slajdach, ja ostatni raz std::initializer_list
> użyłem, gdy pisałem implementację std::string. W kodzie produkcyjnym ta klasa ma
> zastosowanie zerowe i są głosy, żeby ją wywalić.

W takim razie dlaczego ją dodano?
(Nota bene, to samo słyszałem o std::vector)

> > 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)
> 
> Ojej, bo taka jest definicja domknięcia w C++... przykład kompletnie
> z międzypośladzia.

Nie. Przykład jest bardzo konkretny. Że język jest niesystematyczny, bo szanowny komitet zapomniał dodać do gramatyki regułę produkcji dla przypadku, gdy gdzieś tam się pojawia jakieś tam słowo kluczowe.
Z czego można wyciągnąć taki wniosek, że składnia C++ jest nawet zbyt skomplikowana dla osób, które się zajmują standaryzacją języka.

> > Albo wykwity w rodzaju xvalue reference.
> 
> O których w codziennej pracy nie ma potrzeby wiedzieć.

Jasne. Można znaleźć jakiś dowolny minimalny podzbiór C++ który będzie "Turing-complete" i sobie w nim programować. Ale za czym to jest argument?
Jeżeli w języku są rzeczy, które są niepotrzebne, to po co je dodawać?

> Zresztą, w tym zachwalanym C masz jakieś rvalue i lvalue.

Które bardzo łatwo wytłumaczyć.
lvalue - to, co może się znaleźć po lewej stronie operatora przypisania
rvalue - to, co musi się znaleźć po prawej stronie operatora przypisania

Albo można jeszcze powiedzieć "lokacje i wartości".

A w C++ masz kompletną sieczkę, bo ktoś kiedyś wymyślił zupełnie głupi typ o nazwie "referencja", który do siły wyrazu języka nic nie wnosi, i się nagle okazało, że nie można jako argumentów do wywołań funkcji przekazywać literałów.

> > 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
> 
> No proszę Cię, wziąłeś mega chujowy kod (który wygląda jak port z plain C)
> i oczekujesz, że w takim ścierwie ktoś stworzył dobre abstrakcje?

Nie. Ja próbowałem to napisać w C++. I nie zdołałem.
Później jak prosiłem różnych zwolenników C++, żeby podali, jeśli nawet nie implementację, to chociaż dobry projekt interfejsu dla algorytmu A* w C++, to nikt do tej pory nie podołał temu zadaniu.

Jeśli masz ochotę się z tym zmierzyć, i stworzyć dobry interfejs do algorytmu A*, to ja się z chęcią z tym zapoznam.

> > Generyczność w C również jest ułomna, ale przynajmniej dla tej ułomności można znaleźć jakieś uzasadnienie.
> 
> Mhm, a ułomności C++ nie mają źródła, siły nadprzyrodzone. :)

Mają oczywiście źródło. Ale nie mają dobrego uzasadnienia.
Język C jest często nazywany przenośnym asemblerem - i można znaleźć języki, które się do C kompilują.
Natomiast nie do końca wiadomo, jaka idea stoi za tym całym C++em. Po prostu zbiór randomowo dodawanych ficzerów. "Obiektowość". "Referencje". "Szablony". "Meta-programy w szablonach". "Automatyczne wnioskowanie o typach". "Perfect forwarding". "Koncepty".
I ja oczywiście nie mam nic przeciwko eksperymentowaniu przy projektach języków programowania. Bardziej mierzi mnie to, jak takie języki eksperymentalne nazywa się "produkcyjnie gotowymi".

> > 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.
> 
> Owszem, język jest koślawy i trzeba czasu, żeby dobrać sobie pasujący zestaw
> narzędzi. Problemem jest też to, że jego biblioteka standardowa przez długi
> czas była cholernie słaba, co spowodowało powstanie dużej liczby
> rozwiązań własnych wzajemnie niekompatybilnych.

Można też poszukać lepszego języka.
(Albo nawet pozostać przy C)