🚀 go-pugleaf

On Wednesday, January 29, 2020 at 8:26:51 PM UTC+1, heby wrote:
> On 29/01/2020 19:50, M.M. wrote:
> > Firma ma kilku pracowników którzy znają tylko C i mają doświadczenie w pisaniu
> > aplikacji w C. Przychodzi do firmy zamówienie na aplikację podobną do tych w
> > jakich mają doświadczenie i aplikacja nie jest kolosalnie duża. Mają do wyboru:
> > kurs C++ i tworzenie aplikacji w języku w którym nie mają doświadczenia albo
> > pisanie w C.
> 
> 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. Wszystko ma
swoje wady i zalety, nawet C++ ma wady względem C, a jako nadzbiór nie
powinien mieć wad. Koszt przeszkolenia jest nie do przeskoczenia. 

Dlatego ja się nie dam nabrać więcej na nowe super technologie. Programowało 
się kiedyś na kartach perforowanych, potem w kodzie binarnym, potem w asemblerach
gorszych, potem w lepszych, potem w makroaseblerach, w końcu w gorszych
językach wysokiego poziomu, w lepszych i w najlepszych... Nie zaprzeczam że
nastąpił rozwój technologii wytwarzania oprogramowania, ale po pierwsze nie
wierzę że ten rozwój nie wpadał i nie wpada w ślepe uliczki, 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?

Podobnie jest od jakiegoś czasu z językami programowania, języki rozbudowane i
dopracowane o milion procent, dają przyspieszenie procesu wytwarzania 
oprogramowania o kilka procent. A nakład środków na przeszkolenie personelu 
lub samego siebie jest tym większy, im język bardziej rozbudowany. Zmiana
technologii opłaca się dopiero na dłużą metę, do większych projektów.


> 
> > Przy okazji mam pytanie, od dawna się nie interesowałem: czy kompilator gcc i
> > jądro linuxa, x-server są nadal pisane w C?
> 
> gcc:
> 
> https://lwn.net/Articles/542457/
> 
> Kernel to problem białkowy. W zasadzie to problem jednego konkretnego 
> zbioru molekuł, ale ludzie i tak robią swoje:
> 
> https://pograph.wordpress.com/2009/04/05/porting-cpp-code-to-linux-kernel/
> 
> x-server nie wiem. Nie przypuszczam aby komukolawiek opłacało się to 
> przepisywać dla idei, to raczej kod muzealny.
> 
> >> Nikt w tym wątklu nie mówi o programowaniu pełną gębą z użyciem
> >> obiektowości.> 
> > Ale potocznie
> 
> 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 :) 
Napisałem o tym z jakim sposobami używania określenia 'programowanie w C++'
się spotkałem, dlatego żeby wiedzieć o czym rozmawiamy.

 
> >> 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?

> 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ą?




> >> I jakie przy okazji bugogenne. Gdzieś musisz mieć cast. Czy aby na pewno
> >> znasz wszystkie miejsca gdzie ten cast występuje? Wiesz już dlaczego
> >> ogólnie szablon jest lepszy niż void*? Podpowiem: bo wykrywa problem na
> >> kompilacji a nie runtime.
> > Ale zwykle nie ma rzeczy pod każdym względem lepszych. Szablon w C++ jest
> > dobry, bo kompilator pilnuje zgodności typów, bo można zrobić specjalizację,
> > można wygenerować wydajną wersję w zależności od parametrów szablonu. Mówią
> > że szablony są dobre bo się popełnia mniej błędów względem makrodefinicji.
> 
> Prawda.


> > Mnie bardzo dziwi taki sposób porównywania, dlaczego porównywać do czegoś co
> > powodowało (szczególnie u niedoświadczonych programistów) błędy wykrywalne
> > po dwóch dniach debugowania?
> 
> 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. 


> 
> > Szablony mają okropną składnię i podobno lepsza w
> > ogóle nie istnieje.
> 
> Lepsza pewnie istnieje, ale też składnia nie jest okropna.

No dobrze, ja nie lubię, ale kilku dyskutantów przed laty też mówiło że 
nie lubi.


> Serio, uważasz że:
> 
> 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. Miałem na myśli sytuacje
gdy jeden szablon jest parametryzowany kilkoma innymi szablonami i jeszcze
dziedziczy z innego szablonu. Potem gdzieś w klasie jakaś statyczna tablica,
wszystko w kilku wersjach zależne od kompilacji warunkowej... Naprawdę w
takich sytuacjach mocno tęsknię za minimalistycznym C++ albo za Javą, ale
cóż, przyznaję, że ani w Javie, ani w minimalistycznym C++ takiego efektu 
nie uzyskam. Natomiast nie przyznam że szablony stanowią elegancką i
przejrzystą składnię, sprzyjającą analizie kodu i sprzyjającą pisaniu kodu 
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*.


> > Osobiście wcale nie popełniam mniej błędów w szablonach niż
> > bez szablonów, właściwie to wielokrotne dziedziczenie z szablonów masakrycznie
> > komplikuje kod
> 
> 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. 
Ale pośrednie wielokrotnie dziedziczenie, typu X dziedziczy z Y, Y z Z, a Z 
może z kolejnych - to sytuacja częsta. 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.


> >, debugowanie takiego kodu jest trudniejsze niż zwykłego kodu.
> 
> 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? No i
szablony porównujesz to do makr i void* - czyli do czegoś najbardziej
błędogennego. Jeśli używam w pewien określony sposób szablonów, to też
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. 


> 
> > W
> > Javie (poprawcie mnie jeśli się mylę) chyba nie ma szablonów, a wskazywanie
> > typów przy kontenerach jest tylko dla kompilatora?
> 
> Java ma typy generyczne. Nie ma wprost łatwego przeniesienia na C++. 
> Głównie dlatego że typy w C++ są przeliczane na etapie kompilacji i 
> generują inne typy. To inna filozofia. Jaba zatrzymała się głównie na 
> vector< int >, C++ jest o eniony dalej, choć często eniony krzaków 
> dalej, przyznaje.
> 
> > Więc na void* też można.
> 
> To nie jest dyskucja czy można. Można uzyć popsutych korutyn. No 
> przecież jak się ma takąspecyfikację to nawet trzeba. Jak coś działa to 
> nie naprawiać. Lepse jest wrogiem dobrego. Itd itp bzdury.
> 
> Na void* nie można bo:
> a) generuje to więcej błedów runtime
> b) uniemożliwia skuteczne refaktoringi
> c) narzędzia do lintowania wybijaja sobie zęby
> d) narzędzia do statycznych analiz kodu są zagubione
> e) code review nie przejdzie

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ą.
Nigdy nie negowałem szablonów, ale też nigdy nie powiem, że brak
szablonów to strona czarna, a programowanie z szablonami to strona
biała. 


> Ale oczywisćie znam milion przykładów że można mimo to. To "można" to 
> kwesia zwykłej higieny. Można pisać na void* tak samo jak można mieszkać 
> przy wysypisku i udawać że to wiejskie zapachy.

Mam nadzieję że już jest zrozumiałe, iż nie namawiam nikogo do zrezygnowania z
szablonów, szczególnie używanych po bożemu, tylko zwracam uwagę na to, żeby
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ść.


> > Z
> > kolejnych wad szablonów, długi czas kompilacji gdy w programie jest bardzo
> > dużo szablonów.
> 
> 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ę (relatywnie) małego programiku, a
test często też trwa 30 sekund. Po prostu Ty używasz szablonów inaczej niż ja, i
odpisałeś ze swojej perspektywy. Ja jeśli sięgam po szablony to jest też
jakieś prawdopodobieństwo że chcę optymalizować kod, np. chcę wygenerować
skrojony sporawy kod na miarę konkretnego przypadku do rozwiązania.

 
> 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. 

> > 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ł?


> > 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.


> 
> > 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.

> 
> >, miałem
> > na komputerze 16MB pamięci RAM, 1GB na twardym dysku, procesor może 5tys razy
> > wolniejszy i działał tam niejeden graficzny system operacyjny, graficzne
> > środowisko programowania, a nawet program do grafiki trójwymiarowej.
> 
> 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* ?



> > Jakby to
> > było napisane w 'C++ pełną gębą', to nie wiem czy by działało nawet 5 lat
> > później - ale na pewno jakby już zaczęło działać to by działało lepiej i
> > szybciej byłoby rozwijane o nowe cechy.
> 
> 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, że każda konkretyzacja szablonu oznacza nie
tylko różny kod, ale nowy dodatkowy kod. Co nie znaczy, że nie można
używać szablonów tak, aby łatwo zrobić kilka eksperymentów i wybrać
wariant generujący najmniejszy kod. 


> No, ale wiadomo, 100x wolniejszy bo to C++. Dużo NOPów się wstawia na 
> złość tym wszystkim zaprzańcom.

Hmmmm a to zaprzańcy ;-)


Pozdrawiam