On 18/05/2023 16:54, Dawid Rutkowski wrote:
>>> Niestety da się również pisać gorzej.
>> Tak, ale to już problem białkowy, a nie ograniczenia języka. Wystapuje w
>> każdym języku. No może poza perlem, tam pisanie bardzo dobrze jest
>> nieodróznialne od pisania najgorzej.
> Czyli to, że w C można pisać gorzej, to problem języka,
> a to, że w C++ można pisać gorzej, to tylko problem białka?

Nie. W obu można pisac źle. W C++ jest to tak samo łatwe jak w C. Ale
jednocześnie w C++ istnieją techniki programowania, wymuszajace pisanie
dobrze i bez absuradlnych błedów, jak z watku. Nie da się ich stosować w
C, ale można je stosować w C++. Niektóe lintery je wymuszają.

Pierwsza z brzegu z technik wspomagających jakość, za darmo: RIIA.

Innymi słowy w każdym jezyku można pisać dziadowski kod, ale niektóre
języki aktywnie mogą temu przeciwdziałać lub przynajmniej mają do tego
narzędzia zamiast pistoletu na wodę C.

>> Używasz C++ w tym jednym miejscu.
>> Reszta dnia wolnego.
> Reszta dnia na kotrolowanie tego, czy ktoś inny nie użył więcej z C++ niż
odpuszczasz.

To się nazywa review i jesli pracujesz w firmie robiącej coś wiecej niż
miganie diodami, to na pewno jakaś formę review kodu masz. I
kontrolujesz kod współpracowników, czy on jest w C czy C++ w sposób
formalny już teraz.

Masz review, prawda?

>> Czyli to problem ideologiczny. Nie możesz uwierzyć, że można pisać po
>> staremu i tam gdzie C++ się przydaje - użyć go. Musi być albo skrajna
>> prawica albo lewica. Recjonalizm zakazany.
> Sklonuj się to się uda.
> Ja zawsze chciałem mieć brata bliźniaka (niekoniecznie chciałbym mieć
> przy tym na imię Jarosław) - to bardziej realne niż 4 ręce.

Nie rozumiem po co. Pisanie w C++ oszczędza również czas. Nie musisz co
chwile wynajdywać kwadratowych kół albo emulować C++ na makrach.

Bo zdecydowana większosc kodu embedded, którą widziałem w życiu, to
emulacja C++ na makrach, generatorach kodu i fikusnych konstrukcjach.

Dawniej uważałem to za śmieszne, ale dzisiaj, po doświadczeniu zawodowym
jakie mam, uważam to za poważny problem tej branży.

"Nie, bo nie, napisze to sam".

>> Po prostu ich nie rozumiesz i to całkowicie zrozumiałe. Jak zaczniejsz
>> używać, szczególnie jeśli ktoś pokaże Ci jak, zrozumiesz, że pewne
>> konstrukcje w C są najzwyczajniej niebezpieczne i prowadzą do sytuacji
>> niewykryanych przez kompilator, jak w tym watku.
> Pewne konstrukcje w C++ są jeszcze bardziej niebezpieczne.

Które?

> I ogólnie C++ jest jeszcze bardziej niebezpieczne, bo zawiera wszystkie
niebezpieczeństwa C,
> plus jeszcze dodatkowe z C++.

Podaj przykład takiej konstrukcji w C++, która jest niebezpieczna i czai
się jak mina na biednego asemblerowca z C.

>> Pisanie we współczesnym C++ polega na wyrażaniu potrzeb w sposób
>> wysokopoziomowy. Zamaist "potrzebuję wiedziec ile to zajmuje ramu i
>> potem se podziele" piszesz "potrzebuje wiedzieć jakie to jest duże". To
>> jest bezpieczniejsze.
> Byś może rozmawiamy o zupełnie różnych C++.

To wrażenie odnoszę zawsze, kiedy gadam z embedowcami. Był tu taki jeden
kiedyś, co mówił, że jak zmieni się gcc na g++ to od razu trzeba cały
kod przepisać na obiektowy.

Fascynujący przypadek medyczny, ale chyba już tu nie pisze.

To tylko niewiedza. Ja programuję w C++ od lat ~25. Programiści embedded
słyszeli o C++ od szwagra kolegi. Nie wszyscy, ale ciągle większość
czerpie opinie z absurdalnych źródeł.

>> Do tego stopnia, że w jednym z coding standardów jakie miałem okazję
>> czytać, używanie sizeof w pętli for jest wykrywane przez linter na
>> etapie review. Ktoś widocznie miał dośc poprawiania takich bzdur.
> C++ minus to, co odwala linter, to już nie jest C++.

Brednia.

> I tu dochodzimy do kosztów wprowadzenia C++ w firmie.

Zerowe.

> Np. taki linter. I nowy coding standard.

Bzdura. Jesli tylko nie masz firmy z dykty i paździerza, to oba
narzędzia już tam masz. W C są tak samo przydatne, jak w C++.

> To koszty niezaprzeczalne. Zyski - możliwe, lecz niepewne.

Coding standard, review, lintowanie, unit testy, bazy bugów i masa
innych elementów programowania funkcjonuje w firmach od dziesięcioleci.

Idź i zapytaj, czy zyski są niepewne.

Wiele z nich szlag by trafił bez tych narzędzi. Są krytyczne, dla
dowolnego języka programowania i komplikacji projektu.

>> Nie chcesz tego. Semantyka referencji i zarządzanie pamięcią w Javie nie
>> nadaja się do mikrokontrolerów, szczególnie do zastosowań realtime, mimo
>> wielu prób wciśnięcia Javy do małych uC. Za to C++ jak najbardziej
>> pasuje, bo jest zdecydowanie bliżej sprzętu.
> Hmm, a we "współczesnym" C++ nie ma czegoś w rodzaju std::garbageCollector?

Nie.

Istnieją zewnątrzne bibliteki oferujące taki bajer.

Prawda taka, że w typowym małym embedded posiadanie heapu jest ogólnie
nierozsądne, a posiadanie GC jeszcze bardziej. A jak już go masz (heap),
to C++ oferuje RIIA a na nim możesz zabudować wyższe poziomy abstrakcji,
takie jak poole czy liczenie referencji.

C++ to narzędzie oferujace pewien zakres rozwiązań problemów, ale nie
forsuje jakiegoś konkretnego rozwiązania. Java forsuje GC, choć są
wersje bez.

Używałem GC w C++ do pewnego specyficznego zagadnienia. Mogę. Ale prawda
taka, że większośc softu w C++ stosuje raczej metody zarządzanie heapem
typu liczenie referencji albo ownership.

A w małych systemach nic nie stosuje. Bo i użycie malloc/new nie ma tam
sensu.

> Czym się różnią referencje w Javie i wskaźniki/referencje w C++?

Pominąłeś coś: *semantyka* referencji jest inna.

To oznacza, że w javie:

a = b

i w C++

a = b

oznaczają dwie kompletnie rózne rzeczy. Java przenosi uwspólniony
ownership, C/C++ kopiuje. C/C++ preferuje kopie, Java preferuje
uwspólnianie właśności.

Java robi to dlatego, że ma Garbage Collector i może.

W C++ jest kopia, bo to zgodne z semantyką C i nie ma w C++ tak naprawdę
żadnej pamięci allokowanej dynamicznie - allokacja jest dostarczana
przez zewnętrzne bibliteki, wględem samego języka. I może jej nie być,
co nie jest niczym dziwnym w embedded.

> Możliwością statycznej alokacji w C++?

W javie statyczna allokacja to po prostu statyczny obiekt. Allokowany
przy pierwszym użyciu.

Java jest znacznie mniej elastyczna.

W c++ to po prostu to samo co w C, powiększone o klasy, jak komuś potrzebne.

> To sobie w Javie stwórz i nie kasuj, będzie tam samo, a nawet lepiej,
> bo jakbyś chciał zacząć kasować to odchodzi jedno z największych bugo-bagien.

Allokacja w runtime nie jest za darmo: ryzykujesz fragmentację i w ogóle
potrzebujesz jakiegoś heapu.

To podstawowy powód średniego nadawania się Javy do embedded, nawet po
wycięciu jej z Garbage Collectora, semantyka języka jest mocno
niewygodna do obsługi ciasnej pamięci a bezustannie ją preferuje.

>>> Jak piszesz samemu to możesz sobie dyscyplinę typu: "używam TYLKO tego, tego i
tego z C++" narzucić.
>> Tak. To się nazywa coding standard, review, lint. Nie masz takiego
>> zestawu w firmie?
> Ja sam sobie sterem, żeglarzem, okrętem.

Przecięz przed chwilą mówiłeś, że powodem nieużywania C++ jest to, że
kolega może coś napisać i bedzie dramat.

Skoro jesteś sam, to te argumenty przestaja mieć sens.

> Ale jeszcze raz - czy coding standard, review, lint są za darmo?

Tak.

> Może są, daj namiar na jakiś opensource czy GNU.

Coding standard (jest ich wiele):
https://google.github.io/styleguide/cppguide.html

Review (jest ich wiele, są komercyjne):
https://www.reviewboard.org/

Linter (darmowych jest mało):
https://clang.llvm.org/extra/clang-tidy/

>>> Ale w zespole zaraz zaczną odwalać bzdury, "bo w C++ tak można".
>> Nie. Od tego jest code review + coding standard. Choć przyznaje, że to
>> pytanie/opinia czasem się pojawi, szczególnie jak zakaz idityczny. Na
>> przykład "nie wolno używać C++ bo go nie rozumiem".
> I dobrze, w pełni się z tobą zgadzam - narzędzi trzeba umieć używać.
> Ale to kosztuje.

Nie. Nic nie kosztuje. Ta wiedza ma wręcz ujemny koszt. Zyskujesz więcej
niż tracisz.

>> debilizmem. Ale czasem wrzaśnie na etapie kompilacji o jakimś fuckupie,
>> gdzie C przełknie bez popijania. I jak wstawisz w to zdanie "Java"
>> zamiast "C++" to dalej będzie prawda.
> Kompilacji? Raczej lintowania.

Kompilacji i lintowania. Oba wykrywają inne przestrzenie problemów.

> I mając do wyboru C oraz C++ jako nadzbiór C - wybiorę jednak C,
> mniejszy stopień komplikacji łatwiej badać.

To nie jest prawda od bardzo, bardzo dawna.

Typowy kod w C to asembler o sładni klamrowej, gdzie jest pełno void*,
intów i ch... wie co jeszcze.

W C++ masz więcej wysokopoziomowych typów i statyczne typowanie.

To dla lintera jest znaczące ułatwienie analizy składni.

> No a jak będzie nowe pokolenie to już nie będą musieli sięmieścić w pojedynczych kB
RAM.

Jak masz kB RAM to C++ jak znalazł. Dzięki kilku sztuczkom można sobie
prześlicznie i bezpiecznie pisać kod w ciasnym RAM.

To, że wspomniałeś tutaj małą ilośc RAMu oznacza, że komplenie nie
rozumiesz czym jest C++.

On niczego nie zmienia w ilosci RAMu ani kodu wynikowego, w większości
swoich fajnych funkcji. Prawie całe dobro płynące z C++ to tylko
metajęzyk, generujący bezpieczniejszy, a czasami lepszy kod wynikowy.

> Trzeba im tylko jako spadek zostawić dobry OS, inaczej rakiety zaczną spadać.

Jak Ci, co pisali w asemblerze, w "bezpiecznym" Ada i spowodowali spadek
Ariane 5?

Fuckup wszędzie jest możliwy.

> Może to i się do pokoju światowego przyczyni, takie kacapy nie będą miały dostępu
> do odpowiednio mocnych uC - takie z laktatorów nie wystarczą...

Popełniasz własnie ten bład, co prawie kązdy embedowiec - nie masz
pojęcia jak działa C++ ,więc zakłądasz, że wymaga ogromnych ilosci RAMu,
bo tam są obiekty a to prawie jak Java.

Nie wymaga. Generuje ten sam kod co C. ALe pozwala ten kod napisać
bezpieczniej, czytelniej, testowalniej. I zje tyle ramu, na ile styknie
IQ programisty.