🚀 go-pugleaf

On Tuesday, January 28, 2020 at 11:30:09 PM UTC+1, Mateusz Viste wrote:
> 2020-01-28 o 22:37 +0100, heby napisał:
> > Czyli jednak religia. Coś z okolic "C++ zajmuje dużo" i jakiś inny
> > tego typu krap którego pełno na necie.
> 
> C++ to mocno skomplikowana kobyła, która ulega regularnym zmianom... nie
> każdemu to odpowiada.  #muremzamaćkiem  :)
> 
> > Masz prawo do zdania odmiennego od reszty świata.
> 
> Nie *całej* reszty świata, bo jest nas co najmniej dwóch. A jak by
> dobrze poszukać, to myślę że i trzeciego by się dało znaleźć.
> 
> > Lutownicą też się da wbijać gwoździe w papę, dziadek tak robił.
> 
> Być może szybciej wbijać lutownicą którą się ma w ręku, niż młotkiem
> który leży pod drabiną? Tak tylko gdybam.

No właśnie, są pewne okoliczności w których lepiej użyć C, albo użycie C++
niewiele wniesie, i są to nie aż tak dziwne okoliczności jak 'akurat w
ręku trzymam lutownicę' - o czym na dole.

 
> > Bo przerwania, bywa, przychodzą za szybko. Szczególnie jak się w nich 
> > robi zbędną algorytmikę. Bywa że przychodzą *za* szybko.
> 
> Nie wiem jak to wygląda w ARMie, ale w x86 int handlery są
> domyślnie nieprzerywalne. ARM ma inaczej?
> 
> > W niczym. Przy bardzo dużej uwadze, wyszarpaniu sobie żył i głebokiej 
> > modlitwie masz szansę napisać cały program na side effectach przez 
> > zmienne globalne i może nawet cudem zadziała. W końcu jakoś te
> > programy w BASICu na 8-bit pisali.
> 
> Obsługa przerwań w BASICu? Nie przypominam sobie. W ASM lub jakimś
> Turbo C ze wstawkami to i owszem, zabawa przednia. Teraz już takich
> fajnych rzeczy się nie robi, inna moda, inne komputery, no i ludzie
> jacyś tacy mniej cierpliwi...


Przytoczmy kilka faktów:
1) Chyba każdemu odpowiada pisanie takich samych programów krótszym czasie?
Pisząc takich samych mam na myśli tak samo wydajnych, tak samo zdebugowanych, 
tak samo przetestowanych, tak samo funkcjonalnych. 

2) W C++ mamy praktycznie to samo co w C, plus wiele dodatkowych rzeczy. Więc
jakby nawet się uprzeć, to w C++ można programować tak jak w C jeśliby te 
dodatkowe cechy nic nie wnosiły. Ściśle, sam ten fakt powoduje, że C++ nie
może być gorszy od C w sensie z punktu pierwszego - o czym już ktoś wspominał
że C++ kompiluje C. Ale potocznie zazwyczaj ma się na myśli programowanie w C++
pełną gębą.

3) C++ znacznie szybciej się rozwija niż C i jest ogromny. Jeśli chcemy
programować w C++, to w czasie gdy uczymy się nowych fitcherów tegoż języka,
byśmy mogli sporo kodu naklepać w prostym i małym języku C. Ostatnio np.
googlałem jak Lambdę przekazać jako parametr template, nigdy wcześniej
tego nie robiłem. W C bym dane rzutował na void* i użył wskaźnika na
funkcję - banalne. 

4) Gdy się naprawdę PORZĄDNIE projektuje i implementuje ( i może optymalizuje )
kod w C++, szczególnie w celu re-używania, to nakład czasu w przypadku użycia
C++ jest większy, ponieważ mamy do wyboru znacznie więcej elementów. W C mamy
do wyboru wskaźnik na funkcję, makro i copy-paste-modify. W C++ mamy ponadto
funkcję wirtualną, wskaźnik na funkcję składową, lambdę jako argument metody 
lub szablonu, no i mamy jeszcze do wyboru szablony, a może zwykłym 
dziedziczeniem problem by się dało załatwić bez metod wirtualnych. 
Gdy te możliwości przemnożymy przez wygodny interfejs do reużywania, to 
ogarnięcie małego problemu robi się lekkim wyzwaniem. 

5) Biblioteki - używanie gotowych i dobrych bibliotek w C++ jest znaaaacznie
szybsze, znaaaacznie łatwiejsze, a jeśli używanie bibliotek ma dawać wydajny
kod, to dzięki szablonom w C++ można mieć łatwiejszy w utrzymaniu i lepiej
zdebugowany kod. Ale pisanie kodu to nie tylko 'używanie biblioteki', ale też
zrozumienie problemu który biblioteka realizuje, zapoznanie się z dokumentacją,
przeczytanie jakiś przykładów, bo nawet w C++ nie można optymalnie używać
bibliotek jeśli używa się intuicyjnie. Przecież tragedii żadnej nie było 
gdy się pisało w C w WinAPI, w OpenGL, albo gdy pod DOS się robiło własne
GUI z menu i okienkami - i potem się tego reużywało.


Pozdrawiam