On Friday, September 6, 2019 at 10:33:01 AM UTC+2, Mateusz Viste wrote:
> On Fri, 06 Sep 2019 01:12:39 -0700, M.M. wrote:
> > A uzasadnienia i tak i tak nie będzie.
>
> AK to mistrz krytyki, ale na tym jego talent zdaje się kończyć... nie
> widziałem by kiedykolwiek sam cokolwiek mądrego napisał. Niemniej (a
> raczej tym bardziej) jestem pod wrażeniem cierpliwości którą kolega
> wykazuje.

Rozmowa, a przynajmniej któryś post, wydała się bardzo ciekawa i, nawet
nie byłem cierpliwy, tylko zwyczajnie chciałem się dowiedzieć jaka
jest (najlepiej kompletna) lista argumentów za tym, że C++ nie nadaje
się do tworzenia niezawodnych systemów. I, rzecz jasna, jaka jest
alternatywa dla C++, bo jak C++ ma wady, a nie ma nic wyraźnie lepszego,
to żadne argumenty mnie nie przekonają.

Warto zobaczyć ile błędów było w różnych kompilatorach w różnych językach.
Do C/C++ jest dużo niezależnych kompilatorów, można więc łatwo zrobić
testy krzyżowe - to już jest mocny argument za użyciem C++. Ja często
bym wolał coś w okolicach języka D, ale D nie ma takiego wsparcia jak C++,
więc używam C++.

Potem koszty, ciekawe ile kosztuje dobry programista w niszowym-dedykowanym
języku? Może dwóch programistów w C++ napisze bezpieczniejszy kod, niż
jeden (za te same pieniądze) w niszowym-dedykowanym języku?

Potem mnogość bibliotek. Do C++ jest całkiem sporo, często biblioteki są
pisane natywnie w C/C++, a dopiero później robi się port do innych języków.
Robienie portu to dodatkowa okazja do popełnienia błędów, więc bezpieczniej
jest w natywnej. A jeśli do dedykowanego języka nie ma bibliotek, to ciekawe
ile błędów narobią, albo ile czasu stracą na tworzenie/portowanie swojej biblioteki?
Może w tym czasie poprawili by właściwy kod aplikacji w C++?

Kolejna sprawa, napisałem w C/C++ sporo, w tym też kilka pewnych aplikacji.
Defakto były to malutkie aplikacje, ale wcale nie były trywialne obliczeniowo.
Z powodu agresywnej optymalizacji są zaprzeczeniem bezpiecznego stylu
programowania. Mimo to, działają do dziś, od wielu lat nie miałem zgłoszenia
błędu. Jeśli aplikacja nie musi być super zoptymalizowana (mowa o optymalizacji
na jeden procesor, bo w zamian za to, aplikację nadal można optymalizować na
klastry i/albo GPU) to można w C++ stworzyć aplikację składającą się np. w 98% z
czytelnego i bezpiecznego kodu. Pozostałe 2% nie jest kulą u nogi, lecz pomaga
utrzymać jeszcze większy porządek w tych 98%, stanowi dobrze wydzielone
procedury wielokrotnie użyte (a więc dobrze przetestowane) w kodzie.


Co tu by jeszcze dorzucić na korzyść C/C++... Może to, że jeśli aplikację
jednak trzeba trochę zopytmalizować na jeden procesor, to do C/C++ są
bardzo dobre optymalizatory. Więc w takich przypadkach w C++ można sobie
napisać czytelnie, a martwi się optymalizator. W innych językach które
nie mają takiego wsparcia może trzeba jakieś haki czasami w kodzie robić,
żeby procesor/ram nadążył.

Oczywiście C++ ma wady, ale te wady wynikają ani z języka, ani z narzędzi,
ani z bibliotek, lecz z ogromnej swobody programowania jaką daje język
C++. Jeśli, szczególnie mniej doświadczony, programista dostanie wiele
swobody, to niewykluczone że użyje jej przeciwko bezpieczeństwu systemu.
W C++ np. nie ma obowiązku inicjowania zmiennych przy deklaracji, a domyślnie
są inicjowane tylko w określonych sytuacjach. Jeśli ktoś w krytycznych
systemach zbagatelizuje ten problem, uzna np. że jego kod jest na tyle
dobry, że nie będzie odczytów przed inicjacją, to cóż... można przenieść
rozmowę na grunt czy to wina programisty, czy języka, narzędzi i bibliotek.
Moim zdaniem to wina programisty, a kompilatory w C++ dają sporo ostrzeżeń
przy ryzykownych konstrukcjach.

Nie chce mi się dalej ciągnąć, bo autor nie powiedział co jest takiego
złego w C++.

Pozdrawiam