🚀 go-pugleaf

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

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

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

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

> Szablony mają okropną składnię i podobno lepsza w
> ogóle nie istnieje.

Lepsza pewnie istnieje, ale też składnia nie jest okropna.

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?

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

>, debugowanie takiego kodu jest trudniejsze niż zwykłego kodu.

Robie to codziennie od kilkudziesięciu lat i cieżko mi się zgodzić.

> 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

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.

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

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?

> Kolejna wada, trzeba udostępnić kod źródłowy gdy się
> udostępnia bibliotekę napisaną w postaci szablonów.

Brednia.

> Następna wada, kompilatory
> czasami wskazują błąd daleko od jego wystąpienia.

Brednia w 99% wypadków.

> Podsumowując, kiedyś szablonów używano rzadko albo w ogóle nie używano

Podobnie jak z papierem toaletowym.

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

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

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