On 18/11/2021 21:47, Mateusz Viste wrote:
>> Wylatujesz za drzwi nie tylko z kopniakiem, ale jeszcze z wilczym
>> biletem na pracę w IT.
> Przypomnę, że pisałeś wcześniej że "w C nie da się tego zrobić". Teraz
> ci po prostu łyso. :-)

Nie, dalej twierdze że nie da się zrobic RAII w C. Można emulatowac
pojedyncze przypadki, jak Twój przykłąd. Przeciez oba są
Turing-complete, więc można napisać żałosny kod o identycznej logice jak
inny kod.

>> Wlasnie napisałeś kiepski, ale emulator RAII. I po co było bredzić o
>> goto?
> goto ma swoje niszowe zastosowania.

Ma. Ale prawde mówiąc są tak niszowe, że nie użyłem go od chyab 20 lat.
Mimo zawodowej pracy w C++.

> To, co dziś nazywa się "RAII"
> istniało przed C++ i wykorzystywało właśnie goto.

Nie. To nie ma jedno z drugim nic wspólnego. RAII to nie jest inne goto.
To w ogóle nie jest nawet obok.

Jak chcesz już analogii, to Twoje "goto" jest bliżej exceptionów z C++,
one też przerywają flow kodu.

RAII jest najbliżej konstrukcji try {} finally {}.

> Zresztą nie tylko ja
> o tym bredzę:
> https://www.kernel.org/doc/Documentation/process/cod
ing-style.rst

Podałeś przykład kodu, w którym religijnośc jest ważna, wazniejsza niż
zdrowy rozsądek. Nic dziwnego, że nie ma wyjścia i trzeba korzystać z
mechanizmów, które są śmieszne, żałosne i niebezpieczne, bo C++ nie
wolno bo nie wolno.

Ja oczywiście znam rozsądne argumenty za C w kernelu, ale znam też
głośno powtarzane, nierozsądne.

> "The goto statement comes in handy when a function exits from multiple
> locations and some common work such as cleanup has to be done. If
> there is no cleanup needed then just return directly."

No widzisz, a reszta świata ma finally. Czyli reszta świata się myli.

Kolesie od kernela nie mają wyjścia: pracują w toksycznym środowisku w
którym jednym pytaniem o coś lepszego niż C zbywa się "you're full of
shit" i podobnyumi argumentami merytorycznymi. Wiem, słyszałem
wielokrotnie. Kernel linuxa to nie jest specjalnie dobry argument w
jakiejkolwiek dyspucie o jakosci i bezpieczeństwie kodu, chyba że
potrzebujesz wyznaczyć poziom zerowy.

>> char value = cast_with_range_check< char >( intValue );
>> W kodzie produkcyjnym nic się nie zmienia, w kodzie dla unit testów
>> masz tam w środku zaawansowane sprawdzanie czy wartość mieści się w
>> zakresie typu.
> Ciekawa konstrukcja. Nie mam pewności, czy to w praktyce mogłoby być mi
> użyteczne, bo jeśli castuję większe do mniejszego to obwarowuję
> operację stosownymi asercjami.

Potraktuj to jaki uniwersalną, generyczną asercję.

> Czy w takiej sytuacji ten
> cast_with_range_check<> ma jakieś zalety? Pytam szczerze i bez przekąsu.

Tak. Jeśli popełniasz błąd, to raz a nie 500 razy w każdym możliwym miejscu.

Wyobraź sobie że musisz rozpatrzeć:
a) signed/unsigned
b) mały/duży
c) float/int
d) double/single
e) ttmath/magic_int256_t

I wszystkie ich kombinacje. To jest kilkaset asercji i czasami cieżkich
obliczeń, z gwarnacja buga.

Twoja metoda to technika rozpryskowa, czyli wpierniczmy te asercje
wszędzie po kodzie, a każda inna.

Moja technika to generalizacja i abstrakcja problemu to template,
którego nie da się użyć źle. W dodatku o jakości zapewnianej unit
testami. C++ daje mi do tego calu trywialne i wygodne narzędzie.

Oczywiscie, za chwile wyskoczy jakiś hacker z hasłem "ale ja to mogę
zrobic na #define, potrzymaj mi kota".

Tak, wszystko jest turing-complete, brainfuck, whitespace, intersil też.
Da się zrobic na #define. I w brainfucku. I ja też kiedyś robiłem na
#define. Ale już nie robie. To dziecinada.

>> Ja tu bronie jakiejś idei? Robisz gówniany kod na goto, który
>> świadczy o zerowej wiedzy z zakresu bezpieczeństwa kodu i to w imię
>> "Łojezu, nie wolno używać C++, bo przyjdzie babajaga i zje!" i to ja
>> czegoś zaciekle bronię? Żartujesz?
> Tak, bronisz. Podałeś tezę pt. "C++ najlepszy do programowania w
> embedded"

Nie. Podalem tezę "można zerowym kosztem pisać kod lepszy niż w C" bo
niczym się od gołego C nie różni.

Do programowania embedded jest najlepszy język, który najlepiej pasuje
do zagadnienai które chcesz rozwiązać.

W przypadku C vs C++ argumentacja że "C++" jest gorszy od C, wymagała
odpowiedzi. I tak doszliśmy do twojego goto, jako panaceum na problemy
3-go świata programistów z epoki kamienia łupanego.

> i uargumentowałeś ją kiepskim przykładem. Zapytałem o lepszy.
> I zaczęło się.

Wiec zauważ o czym dysputa była. Dysputa jest o tym, że C nie jest
lepszy od C++, bo C++ to C + *przydatne* rzeczy. Więc niejako na bazie
czystej logiki nawet...

>> To co, piszesz to zabezpieczneie przed podaniem złej flagi do uartu,
>> w C?
> Ja zupełnie tego nie potrzebuję.

No własnie. Innymi słowy jesteś wyznawcą podejścia hackerskiego do
programowania.

"Ja się nie mylę, po co mi to całe bezpieczeństwo".

Ja wręcz odwrotnie: "bezpieczeństwo i testowanie a potem kodowanie".

I różnica jest taka, że ja wiem jak to przenieśc do embedded.

> przykład wyższości C++ "w embedded"... Ale okazało się niestety, że to
> przykład tylko wirtualny.

Ja bym go nazwał konkretnym, ale ja pracuje zawodowo w takim języku,
więc co ja tam mogę wiedzieć.