On 18/11/2021 19:19, Mateusz Viste wrote:
> 2021-11-18 o 18:38 +0100, heby napisał:
>> Zmniejszyłem je. Z wielu miejsc usunąłem.
>
> Za pomocą tego magicznego guard?

Tak. Wyeliminował wszystkie źrodła błedu "zapomniałem włączyć" teraz i w
przyszłosci, z tej funkcji.

Oczywiście można go usunąć przypadkiem. Można wiele rzeczy zrobić, to
tylko białko. Idę o zakłąd że ilosc takich przypadków będzie o rząd
wielkosci mniejsza, niż przypadków "zapomniałem gdzieś zawołać goto w 30
miejscach".

> Wmówiłeś to sobie, uprawiasz tylko
> kreatywną księgowość.

Dziwnym trafem ta "kreatywna księgowość" jest powszechnie używanym
wzorcem projektowym w całym C++, dając zaskakująco wysoki poziom
bezpieczeństwa transakcji.

Podpowiem kilka generyków: std::mutex::scoped_lock, boost::scoped_ptr,
boost::scoped_array itd.

Każdy da się napisać na goto. I wylecieć kopniakiem za drzwi, bo to nie
lata 60te.

>> Ale jest rozległy. I co teraz? Oferujesz "gapmiy się bardziej
>> wnikliwie". Ja oferuje "upewnijmy się, że to co można, da się
>> zautomatyzować".
> Ale ja przecież nie proponuję gapienia się.

Dokładnie to oferujesz. Mówisz: "ale uważaj, przed każdym wyjściem z
funkcji musisz zawołać goto". Ja tego nie mówie. Samo prawidłowo zawoła
się to, co ma się zawołać, nie muszę żyć w ciągłym strachu, mam 1
miejsce a nie 30, do popełnienia błedu.

> Objaśniam tylko, że to co
> starasz się wypromować jako "argument za C++ w embedded" wcale nie
> potrzebuje C++.

Zrobiłeś jakiś mechanizm działajacy w podobny sposob na poziomie *tego*
konkretnie przypadku. Po refaktoringu środka funkcji, ja nie muszę się
martwić i mam gwarantowane wywołanie sei(), Ty musisz się męczyć i
przeglądać kod, czy ktoś nie zapomniał zawołać goto. Innymi słowy mój
zysk to bezpieczeństwo refaktoringu tej funkcji, bezpieczeństwo jej
pisania i przejrzystośc kodu.

Wiec albo chcesz mieć szambo, jak proponujesz, albo automatyzację. I
tak, nie da się tego zrobic w C. Można tylko napisać identyczny przykład
i wymachiwać "nie ma żadnej różnicy". Ona jest, nie widzisz jej, bo nie
piszesz nic więcej niż miganie diodą i nigdy nie przyszło Ci do głowy że
ktoś będzie tą funkcję zmieniał, w czasie jej życia, 100 razy.

>> A ile płacisz?
> Czyli ta łatwość usuwania białka C++ w ramach flag wymaga założenia
> projektu i zainwestowania roboczogodzin?

Tak. Ja inwestuje raz. Kod taki (o podobnej funkcjonalnosci) napisałem
już kilka razy, komercyjnie. Za każdym razem używałem go w setkach, jak
nie tysiącach miejsc. Więc ja zapłaciłem raz, a dobrze.

Niejaki Mateusz, za każdym razem jak robi UART= płaci na nowo koszta
potencjalnych bugów, w kółko używając technik z epoki kamiennej do
podwyższania jakości kodu, czyli cichej modlitwy, że się nie pomylił.

Przykro mi, że kod nie jest za darmo. Jestem znudzony edukowaniem za
friko każdego, kto jest za wielkim ignorantem, aby zrobic to samodzielnie.

> No to ja dziękuję za taki
> postęp.

Nie pojmujesz nawet tego, że ten kod da się napisać generycznie i używać
gdzie chcesz, *zmniejszajac* koszty błedów.

Pisałeś kiedyś coś więcej, niż hello world?

> Jak ma być skomplikowanie to równie dobrze w C mogę sobie
> złożyć system do sprytnego zarządzania flagami.

To złóż i pochwal się. Ale nie zapłacę za niego z prostej przyczyny: nie
będzie mieć śladu zalet względem statycznych checków C++. Wiem to
dlatego, że widziałem ich na pęczki. Każdy gówno wart.

A najbardziej zabawne, że to dopiero początek tego, co C++ pozwala
zrobić dobrego w kodzie embedded, a Ty już nie pojmujesz gdzie zalety,
bo ci assembler przesłania.