On 19/11/2021 09:33, Mateusz Viste wrote:
>> Ma. Ale prawde mówiąc są tak niszowe, że nie użyłem go od chyab 20
>> lat. Mimo zawodowej pracy w C++.
> No właśnie, C++. Bo w C++ masz milion konstrukcji

Nie ma ani jednej konstrukcj w C++ która była robiona z myślą o
usunięciu goto. Goto usuneliśmy wieki temu, jako idityczny koncept, w
praktycznie każdego języka. Zastapiliśmy je break, exception, None i
wieloma innymi konstrukcjami w wielu róznych językach. Być może
przespałeś. Bywa.

> wymyślone aby nie użyć goto/define. Co kto woli, ale to dalej nie jest
> postęp (w tym szczególnym kontekście).

To nigdy nie jest postęp w opini kogoś, kto go nie dostrzega. Pamietaj,
że Twoja opinia o postępie jest subiektywna i mało kompatybilna z
teoriami języków programowania. Ogólnie wszystkie języki wyższego
poziomu starają się uzyskać kod bezpeiczniejszy na etapie pisania i
kompilacji a nie na teapie runtime. Ty zatrzymałeś się w latach 70 ze
swoimi rozwiązaniami problemów, które nijak nie przystaja do tego co
osigneliśmy do dzisiaj. I spoko, ale nie chwal się tym. To żenujące.

>> 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.
> Czyli ludzkość przez dekady pisała (i pisze dalej) brzydki, śmierdzący i
> niebezpieczny kod

Tak.

>, Linus i jego koledzy to idioci

Nie. Ale są pod wpływem zaklęcia z okolic "C jest nalpeszy". Ja nawet
znam czarnoksięznika, który je rzucił. Trzymał ich twardę ręką i kilku
odeszło m.in. z podobnych powodów.

> i tylko jeden heby

Nie. Jakieś kilka milionów ludzi nie piszących w C oprogramowania w
którym chodzi o bezpieczeństwo.

Pozwól że Ci wyjaśnie: kernel Linuxa napisano w C *tylko* dlatego, że
napisano go dawno i nic innego nie było. Reszta tej historii nazywa się
inercją. Stawianie jej jako obrony dla wyboru C w nowych projektach
świadczy o niepojmowaniu podstaw programowania. Język C był *dawno* temu
sensownym wyborem. Obecnie nie jest. W zasadzie do niczego nie nadaje
się lepiej niż cokolwiek innego.

>> 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.
> Zauważ, że to zupełnie tak, jak duża część twoich odpowiedzi w tym
> wątku.

Moje odpowiedzi w tym wątku są specjalnie przerysowane, aby spuścić z
Ciebie powietrze z farfoclami goto.

>> Tak. Jeśli popełniasz błąd, to raz a nie 500 razy w każdym możliwym
>> miejscu.
> No tak, ale ty też możesz przecież się pomylić: zapomnieć wstawić
> range_check<>, albo wstawić mu nieodpowiedni typ... To znów przesuwanie
> problemu.

Jesteś jak ci miszczofie z Watykanu, którzy twierdzą że jesli
prezerwatywa nie chroni w 1 promilu przypadków to nie nalezy jej używać.

Zaskocze Cię: zdecydowana większość współczesnego embedded jest tak
skomplikowana, że od jakiś 20 lat, a obecnie bardzo intensywanie,
stosujemy metody *statystyczne* oceny jakości kodu. Na przykład przez
randomizacje unit testów. To może być szokujące dla Ciebie: w duzym
software może okazać się że nie da się usunąc wszystkich bugów, ale
można zrobić coś aby na wyjsciu było ich mniej. ta twoja pogradzana
statystyka gra obecnie pierewsze skrzypce w dużym embedded.

Oczywiście miganie diodą na goto ujdzie, ale software mające kilka
gigabajtów kodu źrodłowego (tak, dalej mowa o embedded) nie ma wyjścia,
musi być pisane używajac wszystkiego co mamy w kwestii bezpieczeństwa i
znając ograniczenia białkowe.

I teraz wyjasnij mi po co stosować dziadowskie pisanie z goto, skoro
lepsze, bezpieczniejsze techniki są stosowane w dużym sofcie i masz je
za darmo?

Zwróć uwagę, że nie padł z twojej strony ani jeden argument po co *nie*
stosować.

Ja ciągle pytam czemy nie stosujesz odkurzacza, tylko szczoteczką do
zębów zamiatasz salon. Oba narzędzie są w schowku.

>> I wszystkie ich kombinacje. To jest kilkaset asercji i czasami
>> cieżkich obliczeń, z gwarnacja buga.
> Od tego jest #define, żeby takie rzeczy elegancko sobie opakować. Znane
> od 1978 (a może i trochę wcześniej).

Od tego są szablony, aby sobie takie rzeczy opakować. Mają o wiele
więcej możliwości, są bezpieczne pod względem typów i czytelniejsze niż
milion #define. Po ch... komu uzywać #define? Bryczką też jeździsz, bo
starsza od samochodu, a więc na pewno lepsza? Co to za idiotyczny argument?

>> Twoja metoda to technika rozpryskowa, czyli wpierniczmy te asercje
>> wszędzie po kodzie, a każda inna.
> Niekoniecznie inna. Jeśli sprawdzam tylko range typu, to może być taka
> sama, wówczas opakowana w jakimś #define.

A czemu nie szablonem? Powody religijne czy reglamentacja narzędzi?

> Ale często sprawdzam granice
> różne od typu, np. zwracany int ma być -1 >= x < CHAR_MAX.

A ja mówie o przypisaniu, nie o wartosci zwracanej. Wartość zwracana
ogarniana jest m.in. w unit testach, asercjami, itp.

>> Nie. Podalem tezę "można zerowym kosztem pisać kod lepszy niż w C" bo
>> niczym się od gołego C nie różni.
> Ja rozumiem zamysł, i szanuję ideę. Miałem tylko nadzieję dowiedzieć
> się z tego wątku o jakichś rewolucyjnych wynalazkach które C++ posiada,

Dowiedziałeś się. To że jesteś za słaby z programowania aby zrozumieć
stojącą za tym abstrakcję nie jest moją winą. Jesteś typowym
assemblerowcem który nie jest w stanie ruszyć sie ze swojej strefy
komfortu, bo zakładasz że jesteś najmądrzejszy i każdy problem możesz
rozwiązać lepiej niż reszta świata uzywająca innych, "skomplikowanych"
technik. W rzeczywistości strach cie oblatuje za każdym razem kiedyu
widzisz kod, którego nie rozumiesz i pojawia się, typowa dla legacy
programmers, reakcja alergiczna i emulowanie. Widzę to bardzo często u
starszych programistów. Co gorsza sam się do nich powoli zaliczam.

> ale to co przedstawiasz to raczej luźne wariacje w tematach znanych od
> prehistorii. I nie żeby to było coś złego, fajnie że się młodzież
> dobrze bawi, to z pewnością rozwijające jest.

Pomysliłeś fanaberie z czymś co jest dostepne powszechnie od 30 lat na
rynku i na czym pracuje niezliczona ilość programistów. Prawdopodobnie
przegapiłeś te lata debugując swój gówniany kod z goto. Co zrobić, nie
każdemy dane będzie oświecenie.

> Jeśli miałbym mieć jakiś jeden zarzut do C++, to chyba właśnie tylko
> to, że namnożył miliony bytów

Namnożył wiele użytecznych narzędzi.

To dlatego, że w przeciwieństwie do wszelakich kiepskich programistów,
zebrali się ludzie widzący *abstrakcje* w kodzie i wytworzyli generyczną
obsługę tych abstrakcji. Jeśli używasz goto na codzień, to tego nie
pojmiesz, jesteś programistą w asemblerze.

I nie milion. Na razie te dwie, czyli RAII i szablony, załataiają
większośc problemów niedzielnego programisty embeede i zaawansowanego
programisty embedded, w tejsamej cenie. Poza Mateuszami, oczywiście.
Ktoś musi być kustoszem w tym skansenie.

>, przez co człowiekowi ciężko wszystko
> ogarnąć i o wszystkim pamiętać.

Tobie jest cieżko. Pracuje w C++ od 20 lat. Ani mi, ani kolegom
pracującym ze mną nie jest cieżko. Ciezko to by było, gdyby nas ktoś
zmuszał do używania, z powodów religijnych, goto, zamiast wyrażania
poprawnie swoich celów używając wysokich abstrakcji z C++.

> Ja sam ograniczam się w mojej pracy do
> C89 (no, w praktyce do gnu89), dlatego właśnie, że lubię grać w gry o
> prostych zasadach. NASM też bardzo doceniam swoją drogą.

Tak, prostactwo przede wszystkim.

Wyjasnie Ci, na czym polega róznica między prostotoą a prostactwem:

Prostota: używam RAII, bo mam, przez co kod jest którki i wiadomo co
chciałem uzyskać.

Prostactwo: używam goto bo nie potrafię inaczej i nie rozumiem abstrakcji.

>> W przypadku C vs C++ argumentacja że "C++" jest gorszy od C, wymagała
>> odpowiedzi.
> Była taka argumentacja? Jeśli tak, to przeoczyłem. W każdym razie nie
> wyszło to ode mnie. Ja czepiam się tylko konkretnych przykładów.

Czepiasz się ich prezentując workaroundy. Nie wiem jaki masz w tym cel,
ale mam wrażenie, że ośmieszanie się.

Tak, ja też jestem w stanie napisać dowolny kod na goto. Bo pisałem w
swoim zyciu bardzo dużo w asemblerze. Ale mimo to potrafie określić
dlaczego jest to zło i to to jest turing-completeness. Dla mnie to że da
się coś napisać inaczej i niebezpiecznie nie jest argumentem, tylko
zaoraniem.

>> 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...
> Ot, to. Ale z tą logiką to nie tak. Bo jeden lubi grać w Go, a inny
> woli współczesne gry planszowe z kilometrowymi regułami.

To nie jest kwestia "wolę". Masz używać narzędzie optymalnego do problemu.

Narzędziem optymalnym do problemu "transakcja w scope" jest RAII a nie goto.

Jeśli używasz goto to robisz to źle, ponieważ nie masz argumentu przeciwko.

jeśli używasz #define zamiast szabolu, to robisz to źle, bo nie masz
argumentu przeciwko.

Jedyny argument jaki pada Twojej strony jak d otej pory to "że to
Trudne". Myślełeś nad karierą rolnika? Tam jest łatwiej.

> Pewno powiesz,
> że ten pierwszy jest niepełnosprytny, że nie potrafi ogarnąć kilku
> tysięcy zasad i egzotycznych ruchów. I może masz rację, on po prostu gra
> w to, w czym idzie mu najlepiej.

Słusznie. Też uważam, że jesli ktoś potrafi sprawnie kopać rowy łopatą
to głupotą będzie wzywać koparkę, mierzeje przekopać można używają goto,
bo tak robili za pradziada.