🚀 go-pugleaf

On 29/01/2020 22:48, M.M. wrote:
>> A jak im pewnego dnia podmienisz gcc na g++ to co się stanie? A jak
>> pewnego dnia dorzucisz im do kodu class scoped_interrupt_disable to co
>> się stanie? Wybuchnie im? Odmówią pracy bo niekoszerne? Do spowiedzi pójdą?
> Nie wiem co się stanie. Prosiłeś o przykład, więc podałem.

Ten przykład nie tłumaczy problemów w C++ tylko w białku.

> Wszystko ma
> swoje wady i zalety, nawet C++ ma wady względem C

W sensie że jest bardziej restrykcyjny? Słyszałme kiedyś że to wada. Do 
dzisiaj nie wiem dlaczego.

>, a jako nadzbiór nie
> powinien mieć wad. Koszt przeszkolenia jest nie do przeskoczenia.

Napisałem Ci że nic nie musisz szkolić poza "chłopaki, od dzisiaj w 
każdym przerwaniu na arma na początku ma stać scoped_interrupt_disable 
sid(); i h...". A jak któryś podskoczy to w łeb. Koniec szkolenia. Po 
roku nie dadzą sobie tego siła odebrać.

> nastąpił rozwój technologii wytwarzania oprogramowania, ale po pierwsze nie
> wierzę że ten rozwój nie wpadał i nie wpada w ślepe uliczki

Kiedyś ludzie uważali BCPL za spełenienie marzeń. Sam się kompiluje, 
można zrobić bootstrap na dziwnym systemie, architektura wręcz zdjęta z 
tablicy uczelni, *uproszczona* składnia.

I wiesz co, trafiłem kiedyś przez zupełny przypadek na kolesia który nie 
dość że pisał jeszcze koło 2000 roku w tym cudzie to jeszcze przez 
nastepne 10 lat miał do niego straszny sentyment.

Widzisz, to co piszesz to białko.

Mam takie a takie doświadczenia, widziałem to i tamto, wnioskuje z tego 
to i owo.

A na koniec okazuje się że programy w C++ nie dość że są czytelniejsze 
od tych w C, to często są szybsze, łatwiejsze w analizie i refaktoringu.

Tylko że białko. Białko wie lepiej, szczególnie jak się na czymś nie zna.

No więc dowiedziałem się że C to gówno. BCPL był lepszy.

Białko ...

>, a po drugie,
> jest takie prawo w ekonomii którego nazwy już nie pamiętam, ale mówi ono o
> tym, że od pewnego momentu trzeba niewspółmiernie dużo pracy włożyć w
> udoskonalanie, aby uzyskać minimalnie lepsze efekty. Jak myślisz, ile pracy
> trzeba włożyć, żeby przyspieszyć trabanta rozpędzający, a ile, aby
> przyspieszyć najszybszy samochód na świecie i tym samym pobić rekord prędkości?

To teraz z tej analogi zrób casta na konkret.

To jaki język jest tym najszybszy na świecie?

Rust chyba obecnie jest na karuzeli terndów?

I co to ma w ogóle do dyskusji o tym że zmiana z gcc na g++ dodaje od 
razu za darmo masę możliwosci które w C wymagają pisania kwadratowych kół?

>> Czyli mówisz o czymś innym niż ja. Spieraj się więc z kimś innym.
> Spokojnie, ja jeszcze nie jestem pewny o co się spieramy :)

Podobno o wyższość C++ nad C i odwrotnie.

Tylko że ja się o to nie spieram. Ja tylko protestuje przeciwko 
bredzeniu o tym że zmiana z gcc na g++ jest niemozliwa, bezsensowna i 
korutyny nie muszą mieć stosu a programiści muszą się szkolić z używania 
prymitywnego RAII.

> Napisałem o tym z jakim sposobami używania określenia 'programowanie w C++'

Wieć programowanie w C++ to programowanie z dowolnym ficzerem dostępnym 
w g++ a niedostepnym w gcc. Na przykłd z użyciem RAII, które to jest 
swoją drogą krytycznie potrzebne w embedded i jednoczesnie skandalicznie 
olewane przez embedded. Bo kwadratowe koła łatwiej się produkuje niż 
kupuje okrągłe.

>>>> W ogóle nie ma tutaj obiektowości poza użyciem jej w celu
>>>> obsługi *ewentualnych* szablonów, bo tak to się robi w C++.
>>> Nie rozumiem.
>> Użycie składni obiektowej (struct/class) nie oznacza że używa się
>> obiektowości.
> Dlaczego?

Bo obiektowośc wymaga *OBIEKTÓW* a nie klas.

>> Składnia ta bowiem przydaje się w szablonach, jest wręcz
>> podstawą pisania z użyciem generycznych typów w C++. Nie mających nic
>> wspólnego z programowaniem obiektowym.
> Chyba nadal nie rozumiem. A jakie wnioski z tego płyną?

Że traits< int >::max to nie jest programowanie obiektowe, natomiast to 
jest programowanie w C++.

I tego faktu nie zmienia to że gdzieś w nagłówku jest [...] class traits 
[...].

"class" mogło by się nazywać "type" i być może tą prostą sztuczką ludzie 
przestali by bredzić że używanie klas w C++ to pisanie obiektowe.

>> Mam buga który ukrywał się w void* przed ponad 10 lat. Przed oczami
>> doświadczonych programistów. Jedyny powód że udało się go znaleźć to
>> *przypadek*.
> A ja zapewne mam niejeden taki błąd w szablonach.

Nie, znalezienie bładu w szablonach który ujawnia się w runtime jest 
naprawdę wyższą szkoła jazdy. Zrobienie błedu w void* który ujawnia się 
w runtime to trywializm.

Szablony powodują że błedy w runtime stają się sporadyczne. Przenoszone 
są na kompilacje.

Wiadomo, nie każdy potrafi czytać komunikaty błędów. Ale naprawdę od 
kilkudziesiąciu lat jest coraz lepiej z jakością błedów. Proponuje 
zobaczyć co wyświetla clang w przypadku błedów kompilacji. Jest bardzo, 
bardzo dobrze.

>> traits< int >::max
>> to jakaś okropna składnia? Nie czerpiesz aby przypadkiem wiedzy o
>> szablonach z jakiś grup anonimowych pisaczy w c?
> Racja, takie proste przypadki są bardzo przejrzyste.

I w tym momencie zamieniasz gcc na g++. Znalazłeś jeden powód aby użyć 
C++ to go używasz, jest za darmo.

> Miałem na myśli sytuacje
> gdy jeden szablon jest parametryzowany kilkoma innymi szablonami

Poniżej promila z promila zastosowań szablonów wymaga takich wygibasów.

Dam przykład: boost::spirit.

To jest bardzo skomplikowana bibliteka na bardzo pokręcoanych szblonach.

Ale dla user końcowego jest wręcz bajecznie prosta.

Te szablony w szablonach to taka Baba Jaga dla niegrzecznych 
programistów C. Straszy się nią i jak widać skutecznie.

> takich sytuacjach mocno tęsknię za minimalistycznym C++ albo za Javą

Prawie cały boost to ukrycie skomplikowanych szablonów za bajecznie 
prostymi interfejsami.

Pewnie, możesz zobaczyć boost::mpl czy fusion i pokazać mi przykłady 
gdzie jest cieżko.

Ale oni naprawdę się napracowali aby to całe mpl było *bajecznie* proste 
po stronie usera mimo komplikacji w środku.

Najwyczajniej, powtarzasz mity. C++ moze byc skomplikowany. Ale boost 
pokazał że ta komplikacja nie musi przeciekać do usera.

> pozbawionego błędów. Tak się mówi że szablony stanowią antidotum na błędy, bo
> porównuje się je zwykle do najbardziej błędogennych konstrukcji języka, jak
> wlaśnie do makr, albo do rzutowania na void*.

Stanowią warstwę chroniącą przed pewną klasą problemów. Akurat tych 
upierdliwych, bo w runtime.

Stanowią jeszcze wiell innych rzeczy, ale void* nie jest alternatywą dla 
szablnów. Za void* nie ma żadnych sensownych argumentów.

>> Całe szczęscie wielokrotne dziedzidzenie szablonów występuje głównie w
>> bajkach i ksiązeczkach dla niegrzecznych programistów c.
> Wielokrotnie w sensie że jedna klasa (szablon) dziedziczy z bezpośrednio z
> kilku to owszem rzadko spotykana konstrukcja i niekoniecznie zalecana.

Myśle że 90% konstrukcji z boosta jest trywialna.

> Ale pośrednie wielokrotnie dziedziczenie, typu X dziedziczy z Y, Y z Z, a Z
> może z kolejnych - to sytuacja częsta.

Prawie nie spotykana w kodzie usera. Używa się jej w booscie czy stl, 
ale mechanizmy widoczne jako API są strywialziowane.

> Gdy każde jeszcze ma jakieś parametry i
> typy - to naprawdę zazwyczaj dostawałem oczopląsu gdy analizowałem swój własny
> kod po krótkim czasie. Myślę że każdy programista uznałby za łatwiejszy w
> analizie kod np. Javy.

Więc masz kiepskie doświadczenia wynikające z kiespkiego doboru przykładów.

>> Robie to codziennie od kilkudziesięciu lat i cieżko mi się zgodzić.
> Może zwykle używasz szablonów po bożemu, a nie do optymalizacji kodu?

Używam C++. W tym szablonów. Szablony są od dziesiątek lat coraz lepiej 
wspierane przez kompialtory (komunikaty błedów) i debuggery (pokazywanie 
zawartości). Nijak nie wiem czemu foo<int> miało by być bardzie 
skomplikowane do debugu. Jedyna przeszkoda to czasem dłuższe nazwy 
typów. Tylko że tam się zagląda raz na rok.

Znowu deminizujesz. Debug kodu z szblonami wyglada tsak samo jak w C. No 
może przesadzam: w C używając void* jesteś w d... od razu.

> nie mam z nimi problemów. Ale gdy np. cały algorytm genetyczny parametryzuję
> kilkoma klasami, to nawet nie mam wsparcia ze strony edytora, bo
> edytor nie wie jakie metody będą miał parametry.

Masz zły edytor.

> To wszystko prawda, choć z review to zależy gdzie :-) Nie chciałem
> absolutnie powiedzieć, że macie olać szablony i wrócić do void*.
> Chciałem powiedzieć, że jeśli sobie radzono bez szablonów i system
> operacyjny z GUI działał na 16MB RAM i pentium I 160MHz - to nie
> ulegajmy złudzeniu, że te szablony aż tak niesłychanie dużo wnoszą.

Znowu to samo.

Mam młotek, ale lepiej wbijać gwoździe lutownicą.

Mam szablony, ale przecież void* to tylko kilka wad z którymi da sie żyć.

Ja rozumiem jeszcze jak by za używanie szblonów trzeba było płacić.

Ale są za friko.

To PO CO ich nie uzywać?

> nie traktować szablonów jako czegoś dzięki czemu technologia wytwarzania
> oprogramowania przyspieszyła o kiladziesiąt procent, bo bez szablonów była
> już całkiem szybkim samochodem, który trudo przyspieszać w nieskończoność.

Szablony rozwiazują dobrze kreśloną klasę problemów z jakością kodu.

W C nie ma nic co mogło by to zastapić poza modlitwą.

>> Jesteś nastepnym developerem w tej dyskusji z Atari 65XE jako ciągłą
>> integracją?
> Nie, po prostu czasami mam w kodzie nasrana pełno szablonów, jeden szablon
> jest parametryzowany innymi, te inne też są parametryzowane jeszcze innymi, a
> niektóre są w kilku wersjach. Jeśli zmieniam warunki kompilacji warunkowej to
> muszę czekać 30 sekund na pełną rekompilację

Przyznam że "pełna rekompilacja" to zjawisko niepotykane przy prawidłowo 
opisanym projekcie.

Jesteś pewien że masz wszystko dobrze że masz potrzebę pełnej rekompilacji?

>> Pracuje na *zaje...e* ogromnej bazie kodu w C++. Kompilacja najdłuższego
>> i najbardziej popieprzonego pliku (zawiera głównie boost::spirit)
>> napisanego z palca trwa coś pod 3 sek. Uwierz mi, to jest makabrycznie
>> dużo zaawansowanego C++ i *tylko* 3 sekundy. Czy już umarłeś z nudów?
> Ja przed chwilą dodałem do kompilacji -DOPCJA_X i czekałem na pełną
> kompilację z 30 sekund na dwóch rdzeniach. Jak jeszcze jest pomiędzy
> kompilacją -fprofile-generate i -fprofile-use to czekam 2 minuty aby
> zrobić 30 sekundowy test.

Czyli to nie jest noramlna praca w programowanie. To wyjątek, kiedy 
robisz redefinicję.

Masz kiepski przypadek, przypuszczalnie jest on na tyle specyficzny że 
nie powinien być uważany za reprezentacyjny.

>>> Kolejna wada, trzeba udostępnić kod źródłowy gdy się
>>> udostępnia bibliotekę napisaną w postaci szablonów.
>> Brednia.
> To chętnie się dowiem dlaczego, myślałem że szablony to nagłówki niezbędne
> do wygenerowania konkretnej wersji kodu, jak to udostępnić w wersji
> binarnej bez źródeł?

usenet to za mało aby to opisać bo zależy od sytuacji.

Kod nie musi akceptować *dowonych* szablonów na przykład. I biblioteka 
udostępnia impelemntcje dla tych kilku przypadków.

Mniej wiecej to to samo co biblioteka w C. Masz funckje przyjmującą inty 
i floaty. To samo w C++, możesz podać szablon z intem i floatem.

To jeden z przykładów że *NIE* musisz *zawsze* udostępniać kodu 
szablonowego.

>>> Następna wada, kompilatory
>>> czasami wskazują błąd daleko od jego wystąpienia.
>> Brednia w 99% wypadków.
> U mnie w około 30% przypadków jest to prawda.

Użyj clanga.

>>> Podsumowując, kiedyś szablonów używano rzadko albo w ogóle nie używano
>> Podobnie jak z papierem toaletowym.
> Tylko że papier toaletowy nie ma nic wspólnego z programowaniem, a (nie)używanie
> szablonów ma sporo.

Z faktu że ktoś kiedyś robił kupę bez papieru nie wynika że papier jest 
zbędny obecnie.

Najzwyczajniej kiedyś go nie było.

Podobnie jak kiedyś nie było C++.

>> Na patrz, a ja miałem Amigę z 2MB pamięci chip i na tej konfiguracji
>> poganiałem SaSC w trybie C++ pisząc obiektowe programy GUIowe. Może to
>> czary?
> Może czary, a może to (w jakimś stopniu) dzięki void* ?

Nie, C++ z szablonami. SaSC miał translator z C++ na generowany C.

Stawiam wniosek: obecnie rozpasanie programów nie ma *NIC* wspoónego z 
wyborem języka C czy C++. Ma związek jedynie z kiepskimi programistami, 
przyrostem danych i rozbudową OSów.

>> A po chwili się budzisz i okazuje się że ten sam program kompilowalny w
>> C i C++ generuje dokładnie taki sam kod asemblerowy.
> Przecież to jest oczywiste

Nie jest. Dla znacznej częsci wyznawców C, bazujących na opiniach z 
facebooka świat wygląda tak że "C++ dużo zajmuje". Ta taka kolejna 
teoria spiskowa obok antyszczepionkowców i niejedzących.

>, że każda konkretyzacja szablonu oznacza nie
> tylko różny kod, ale nowy dodatkowy kod.

Nie. Tak. Zależy.