2021-11-19 o 09:43 +0100, J.F napisał:
> w przypadku sukcesu tez mozemy chciec zwolnic zasoby, wiec raczej
>
> int err_code=0;
>
> if (!buf) {err_code=BUF_ALL; goto poleglem;}
> if (!napisz_na_port() {err_code=PORT_Write; goto poleglem;}
> if (!odbierz_z_portu() {err_code=PORT_READ; goto poleglem;}
>
> err_code=SUCCESS
>
> poleglem:
>
> if (buf) zwolnij_bufor();
> if (port) zamknij_port();
> return(err_code);

Detale zależą już od założeń konkretnego przypadku - API może
przewidywać, że po nawiązaniu komunikacji port pozostaje otwarty na
potrzeby dalszych operacji. Jeśli nie, to oczywiście masz słuszność.

> Mozna tez
> int err_code=0;
>
> if (!buf) err_code=BUF_ALL;
> if (!err_code && !napisz_na_port()) err_code=PORT_Write;
> if (!err_code && !odbierz_z_portu()) err_code=PORT_READ;
>
> err_code=SUCCESS
>
> if (buf) zwolnij_bufor();
> if (port) zamknij_port();
> return(err_code);
>
> no i niby poprawniej, tylko program niepotrzebnie sprawdza pare razy
> blad ... a co tam, szybkie procki mamy

Można. Tylko po co? Aby zmniejszyć czytelność kodu i dodać
niepotrzebnych kroków, coby za wszelką cenę uniknąć goto?

> ewentualnie
>
> int err_code=0;
> if (!buf) err_code=BUF_ALL;
> else if (!napisz_na_port()) err_code=PORT_Write;
> else if (!odbierz_z_portu()) err_code=PORT_READ;
>
> err_code=SUCCESS
>
> if (buf) zwolnij_bufor();
> if (port) zamknij_port();
> return(err_code);
>
> Superczytelne :-P

No właśnie, czytelność na tyle słaba, że zapomniałeś o końcowym "else" i
awaria gotowa. A w efekcie kompilator i tak przetłumaczy to wszystko
na kilka goto...

Mateusz

do góry

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.

do góry

On Fri, 19 Nov 2021 09:44:17 +0100, heby wrote:
> On 19/11/2021 08:57, Mateusz Viste wrote:
>> poleglem:
>>
>> if (buf) zwolnij_bufor();
>> if (port) zamknij_port();
>> return(fail);
>
> Ten fragment kodu nie jest za darmo. Innymi słowy ideologię "da się na
> goto" dostałeś w bonusie z runtime checkiem.
>
> Samo życie ideologa C.

Niby owszem, ale mozna przeciez tez tak:

void *buf = NULL;
int port = 0;

buf = alokuj_bufor();
if (!buf) goto poleglem_buf;
if (!napisz_na_port() goto poleglem_write;
if (!odbierz_z_portu() goto poleglem_read;
return(sukces);

poleglem_read:
poleglem_write:
zamknij_port();
poleglem_buf:
zwolnij_bufor();
return(fail);

Popierasz, nie popierasz?

Fakt, ze to juz bliskie czystej strukturze na if-else.

Tylko ze czasem algorytm nie ma takiejs czystej struktury.

J.

do góry

2021-11-19 o 10:18 +0100, heby napisał:
> Moje odpowiedzi w tym wątku są specjalnie przerysowane, aby spuścić z
> Ciebie powietrze z farfoclami goto.

Nie, jesteś po prostu cham i krzykacz, a zamiast merytorycznych
argumentów wolisz naubliżać zza anonimowego nicka. Nie dziwię się, bo
to częste w tej branży.

Wyciąłem z twojej wypowiedzi wszelkie chamstwo, odniosę się więc do
tego, co zostało (niewiele).

> ta twoja pogradzana statystyka gra obecnie pierewsze skrzypce w
> dużym embedded.

Nie, nie pogardzam. Sam stosuję.

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

Bo ja niczego nie bronię. Ja tylko pytam o rozwinięcie twojej tezy "C++
jest najlepsze w embedded" na konkretnych przykładach.

> I nie milion. Na razie te dwie, czyli RAII i szablony, załataiają
> większośc problemów niedzielnego programisty embeede

C++ to jednak nieco szerszy temat niż tylko RAII i szablony. Jak
rozumiem, sugerujesz używanie C++ "tak, jak by to było C, z dodatkiem
dwóch-trzech nowości bo przecież to darmo jest". Ja uważam takie
podejście ze nieodpowiedzialne, bo jeśli używam narzędzia do poważnych
zastosowań, to muszę panować nad nim w 100% aby nie dać się zaskoczyć
jakimś nieznanym zachowaniem. To trochę tak, jakbyś doradzał pilotowi
lecieć samolotem z milionem gałek, bez znajomości większości z nich
("bo te trzy tutaj po lewej załatwią większość sytuacji, a tych innych
po prostu nie dotykaj"). A potem okazuje się, że drugi pilot zna inny
zestaw gałek i tak sobie dłubią każdy w inny sposób i wpadają we własne
pułapki.

Mateusz

do góry

2021-11-19 o 10:53 +0100, J.F napisał:
> Niby owszem, ale mozna przeciez tez tak:
>
> void *buf = NULL;
> int port = 0;
>
> buf = alokuj_bufor();
> if (!buf) goto poleglem_buf;
> if (!napisz_na_port() goto poleglem_write;
> if (!odbierz_z_portu() goto poleglem_read;
> return(sukces);
>
> poleglem_read:
> poleglem_write:
> zamknij_port();
> poleglem_buf:
> zwolnij_bufor();
> return(fail);

Maszynowo niewątpliwie czyściej, ale dostrzegam potencjalny
problem w czynniku ludzkim - bo teraz programista musi wiedzieć, do
którego labela wykonać jmp.

Metoda "sprawdzam wszystko w jednym miejscu" ma tę zaletę, że jest
bardzo łatwo w użyciu i trudno o pomyłkę. Fakt, zmarnujemy na tym kilka
instrukcji JZ/JE, ale jeśli zależałoby nam na tak daleko posuniętej
oszczędności, to po prostu użylibyśmy NASM... Swoją drogą, ciekawe jak
RAII w C++ to tłumaczy. Domniemywam, że właśnie tak - bo przecież musi
pamiętać/sprawdzać co zostało zainicjalizowane, a co nie. Sprawdzi ktoś?

Mateusz

do góry

2021-11-19 o 11:07 +0100, Mateusz Viste napisał:
> Maszynowo niewątpliwie czyściej, ale dostrzegam potencjalny
> problem w czynniku ludzkim - bo teraz programista musi wiedzieć, do
> którego labela wykonać jmp.

Muszę tu uściślić, że przy bardzo małej ilości możliwości, kiedy trudno
by programista się pomylił, to podejście z paroma labelami *może* być
fajne. Kwestia wyczucia punktu równowagi.

Tutaj jest ładny przykład w ten deseń:
https://github.com/git/git/blob/master/dir.c#L3653

Swoją drogą - w kodzie git-a naliczyłem 759 wystąpień goto. Ale to
przecież poziom migania diodą, więc nic dziwnego. :-)

Mateusz

do góry

heby napisał(a):
> On 13/11/2021 09:40, Bool wrote:
> > Dodam tylko że Arduino mnie kompletnie nie interesuje.
> To jakiś pogląd religijny?


Narzędzie jak każde inne. Dobre do tego do czego zostało stworzone.
Nigdy nie korzystałem, ale ostatnio zaszła taka potrzeba.
Trza było umieścić wsad grbl do atmegi, poszło prawie gładko.
Z punktu widzenia osób które nie chcą się doktoryzować z :
- języka c, konfiguracji IDE
- obsługi programatora
- softu do projektowania pcb
- trawienia, wiercenia, zakupów każdej drobnej części osobno w celu zaświecenia diodą


... ten soft jest idealny:) Zaoszczędza dobrych kilka dni pracy.


Tak poza tym najtańsze pice są tańsze od najtańszych avr.

do góry

On 19/11/2021 10:59, Mateusz Viste wrote:
>> Moje odpowiedzi w tym wątku są specjalnie przerysowane, aby spuścić z
>> Ciebie powietrze z farfoclami goto.
> Nie, jesteś po prostu cham i krzykacz

Pełna zgoda.

, a zamiast merytorycznych
> argumentów

Których tu kilka podałem.

> wolisz naubliżać zza anonimowego nicka.

Mój nick nie zmienił się od 20 kilku lat. Trudno o coś mniej
anonimowego, wystraczy śladowa ilośc woli.

> Nie dziwię się, bo
> to częste w tej branży.

Nie spotykam się na codzień z ludzmi uważającymi że goto to coś lepszego
od RAII, więc wypacz napływ emocji. Czuję się tak samo podekscytowany,
jak ktoś kto wykopuje dinozaura.

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

Wymyslasz jak obejśc rozwiązania gotowe, robiąc takie same, tylko
znacznie gorsze. Nie uzasadniasz dlaczego (albo inaczej: uzasadnienie
jest poniżające). Bronisz więc tak naprawdę faktu, że każdy program da
się napisać w innym języku. Gubiąc po drodze wszytkie zalety jakie
istnieją z generalizacji, skupiajac się na bezsensownych przykładach i
uważając e statystyka bezpieczeństwa kodu nie ma znaczenia.

> Ja tylko pytam o rozwinięcie twojej tezy "C++
> jest najlepsze w embedded" na konkretnych przykładach.

Nie jest najlepze w embedded, nigdzie taka teza nia padła.

Ale.

Padła teaz: jesli już musisz uzywać C w embedded to nie ma ani jednego
powodu dla którego to nie powinien być C++ lub jego fragment.

> C++ to jednak nieco szerszy temat niż tylko RAII i szablony.

Nie ma obowiązku używania czegokolwiek, co nie jest optymalne do
problemu jaki rozwiązujesz.

Nie ma też obowiazku używania czegokolwiek optymalnego do problemu, ale
to już jest odpierniczanie byle jak.

> Jak
> rozumiem, sugerujesz używanie C++

W miejscach gdzie rowiązuje problemy lepiej niż żałosne goto. I w
tysiącu innych miejsc, gdzie pomaga utrzymać bezpieczeństwo.

> "tak, jak by to było C, z dodatkiem
> dwóch-trzech nowości bo przecież to darmo jest". Ja uważam takie
> podejście ze nieodpowiedzialne, bo jeśli używam narzędzia do poważnych
> zastosowań, to muszę panować nad nim w 100%

Gdybyśmy rozmawiali o technologi wymysolnej wczoraj, to bym się zgodził.
Rozmawiamy o technologi będącej na rynku do 30 lat, które najzwyczajniej
przespałeś i teraz dorabiasz głupie filozofie "jest niepewna" itd.
Chowasz swoją ignorancję za głupimi argumentami.

Uzywamy tego, co jest wygodniejsze, bezpieczniejsze, prostsze.

RAII spełnia te założenia, goto nie.

W połowie lat 90 mogło nie spełniać. Od tamtego czasu było dość wolnych
wieczorów, aby poczytać jakąś ksiązkę o C++.

> aby nie dać się zaskoczyć
> jakimś nieznanym zachowaniem.

Nie ma nieznanych zachowań w RAII na poziomie o którym dyskutujemy.
Wymyślasz problemy które nie istnieją. To czysta, pusta ideologia "nie,
bo nie".

> To trochę tak, jakbyś doradzał pilotowi
> lecieć samolotem z milionem gałek, bez znajomości większości z nich

Jesli nie wiesz do czego te gałki to faktycznie lepiej lecieć w balonie.

Chyba nie zakładasz, że komuś kto nie ma pojęcia o C++ polecam jego
używanie? Polecam *zapoznanie* się.

Na szczęscie Arduino, nie patrząc na kiepskie opinie wszelakich
Mateuszy, wproawadziło ten C++ prosto w środek hobbystycznego dziargania
embedded, dzieki czemu poglądy o goto i #define mają szansę szybko wymrzeć.

> ("bo te trzy tutaj po lewej załatwią większość sytuacji, a tych innych
> po prostu nie dotykaj"). A potem okazuje się, że drugi pilot zna inny
> zestaw gałek i tak sobie dłubią każdy w inny sposób i wpadają we własne
> pułapki.

Typowe brednie z ignorancją w tle.

Od 30 lat dłubiemy kod w C++, produkcyjnie, na szeroką skalę.

A tu się uchowali jezcze ludzie, którzy nie potrafią wyjśc z asemblera i
nawet majac nowoczesne języki programowania, muszą używać goto, no bo
jak inaczej.

Powiedz że żartujesz i to wszystko to tylko głupi trolling, bo nie
wierzę własnym oczom, że to nie jest połowa lat 90.

do góry

2021-11-19 o 17:08 +0100, heby napisał:
> > Nie, jesteś po prostu cham i krzykacz
>
> Pełna zgoda.

Reasumując, spotkał się cham z ignorantem. No to skoro ustaliliśmy
na czym stoimy, to może uda się dojść do jakichś budujących wniosków.

> Nie spotykam się na codzień z ludzmi uważającymi że goto to coś
> lepszego od RAII, więc wypacz napływ emocji.

Podałem sposób, w jaki można rozwiązać problem który ilustrowałeś
przykładem. Nie twierdzę, że to lepsze niż nowoczesne RAII. Twierdzę
natomiast, że RAII nie jest tak naprawdę żadną rewolucją i przykład
który podałeś słabo odzwierciedla jego ewentualną wartość dodaną. A tak
promowałeś C++, że naprawdę spodziewałem się jakiegoś life-changera.

> Wymyslasz jak obejśc rozwiązania gotowe, robiąc takie same, tylko
> znacznie gorsze.

Nie nie, ja niczego nie wymyślam. Ja to po prostu stosuję, bo to
codzienność w pracy programisty C. Ja rozumiem, że cię to brzydzi.
Mnie brzydzą lambdy, funkcje wirtualne i templaty.

> Gubiąc po drodze wszytkie zalety jakie istnieją z generalizacji,
> skupiajac się na bezsensownych przykładach

Przecież ja od początku pisałem, że te przykłady są bez sensu i
prosiłem o jakąś dobitniejszą demonstrację.

> Rozmawiamy o technologi będącej na rynku do 30 lat, które
> najzwyczajniej przespałeś i teraz dorabiasz głupie filozofie "jest
> niepewna" itd. Chowasz swoją ignorancję za głupimi argumentami.

Nie pisałem nic o "niepewnej technologii". Pisałem, że C++ to nie tylko
C z RAII, tylko dużo większy kombajn i zanim programista zacznie
cokolwiek w nim dłubać to musi go całego ogarnąć. Włącznie z tymi
milionami rzeczy, których sam nie będzie używał - bo nie wiadomo czy
kolega obok ich nie użyje i trzeba będzie z tym kodem potem walczyć.

> Chyba nie zakładasz, że komuś kto nie ma pojęcia o C++ polecam jego
> używanie? Polecam *zapoznanie* się.

Nawołujesz do używania "fragmentów". Dodatkowo argumentując, że "to
jest za darmo", a to bardzo myląca promocja. Zapoznać się oczywiście
warto - ze wszystkim. I żeby nie było: ja nie jestem żadnym
przeciwnikiem C++. Kilka lat temu przeczytałem książkę o nim, i
wstukałem nawet kilka hello-worldów. Po prostu nie przekonało mnie to,
by zgłębiać temat dalej.

Na zakończenie zapytam zupełnie z innej beczki, bo chodzi to za mną
cały dzień: dlaczego używasz/zachwalasz git-a, skoro jego kod to
(cytując twoje słowa) "szambo"?

Mateusz

do góry

On 19/11/2021 20:38, Mateusz Viste wrote:
> 2021-11-19 o 17:08 +0100, heby napisał:
>>> Nie, jesteś po prostu cham i krzykacz
>> Pełna zgoda.
> Reasumując, spotkał się cham z ignorantem. No to skoro ustaliliśmy
> na czym stoimy, to może uda się dojść do jakichś budujących wniosków.

Nie uda się. Ignoracja i ideologia się nie do ogarniecią argumentami
praktycznymi.

>> Nie spotykam się na codzień z ludzmi uważającymi że goto to coś
>> lepszego od RAII, więc wypacz napływ emocji.
> Podałem sposób, w jaki można rozwiązać problem który ilustrowałeś
> przykładem.

Jeśli podam taki sam w braifucku, to też uznasz, że jest "równorzędny"
bo realizuje ten sam algorytm?

Ludzie od dziesięcioleci wypruwają sobie zyły w dziedzinie
bezpieczeństwa w językach programowania, a na koniec okazuje się, że
wszystko można napisać na goto. No i można. Tylko po ch...

> Nie twierdzę, że to lepsze niż nowoczesne RAII.

Wiec jaki jest powód używania popsutych i iditycznych konstrukcji?
Ustaliłem, że zwykła, pusta ideologia "nie, bo nie". Coś przeoczyłem?
Jest coś więcej?

> Twierdzę
> natomiast, że RAII nie jest tak naprawdę żadną rewolucją

Nie jest, używamy od 30 lat.

> i przykład
> który podałeś słabo odzwierciedla jego ewentualną wartość dodaną.

Nie dostrzegasz jej. Widzisz tak napradę asembler. Nie widzisz lasu, bo
drzewa zasłaniają.

> A tak
> promowałeś C++, że naprawdę spodziewałem się jakiegoś life-changera.

Jest ich wiele, ale na razie zatrzymaliśmy się na trywialiźmie, którego
nie ogarniasz.

>> Wymyslasz jak obejśc rozwiązania gotowe, robiąc takie same, tylko
>> znacznie gorsze.
> Nie nie, ja niczego nie wymyślam.

Oczywiście że tak. Podałeś kilka przykładów: szambo z goto, emulacje
RAII na podziale funkcji na kawałki. Za oba wylatujesz z kopniakiem za
drzwi na review kodu, bo lata 80 słusznie minęły.

> Ja to po prostu stosuję, bo to
> codzienność w pracy programisty C.

Przykro mi.

> Ja rozumiem, że cię to brzydzi.

Nie, nie przechodzi review. Tu nie ma obrzydzenia, jest tylko brak ShipIt.

> Mnie brzydzą lambdy, funkcje wirtualne i templaty.

Widzę. Najzwyczajniej nie masz o nich pojęcia, to naturalny odruch
wymiotny, spotykany często u programistów embedded, na widok innowacji
ponad 8051 i Keila. Nic nowego, jesteś, że tak powiem, potwierdzeniem
obserwacji tego środowiska na przestzreni dziesięcileci moich z nim
kontaktów.

>> Gubiąc po drodze wszytkie zalety jakie istnieją z generalizacji,
>> skupiajac się na bezsensownych przykładach
> Przecież ja od początku pisałem, że te przykłady są bez sensu i
> prosiłem o jakąś dobitniejszą demonstrację.

Ale jej nie zrozumiesz, sam napisałeś że C++ nie znasz, po co więc mamy
się produkować?

>> Rozmawiamy o technologi będącej na rynku do 30 lat, które
>> najzwyczajniej przespałeś i teraz dorabiasz głupie filozofie "jest
>> niepewna" itd. Chowasz swoją ignorancję za głupimi argumentami.
> Nie pisałem nic o "niepewnej technologii".>

Napisałeś:

"nie dać się zaskoczyć jakimś nieznanym zachowaniem".

Nie wiem jak u was, ale ja czasem czytam sepcyfikację i mam niejakie
pojęcie które elementy C++ są "zaskakujące". Te, użyte w przykładzie,
nie są.

> Pisałem, że C++ to nie tylko
> C z RAII, tylko dużo większy kombajn

Ale nie musisz od razu kombajnem kosić trawnika. Wymontuj sobie z niego
to co potrzebujesz.

To jest jeden z nagłupszych i najczęsciej potwarzanych argumentów
przeciw C++: muszę używać *WSZYSTKIEGO*. No wiec nie musisz. Użyj tego,
co jest lepsze dla rozwiązania problemu.

To że goto rozwiązuje wszystkie problemy, to wiemy. Gdzieś od czasów
początku informatyki. Ale od tamtego czasu, wiemy troche więcej.

> i zanim programista zacznie
> cokolwiek w nim dłubać to musi go całego ogarnąć.

Bzdura. Piramidalna. Mozesz całe życie przeprogramować używając RAII i
nie używają templates. Możesz całe życie programować używając indeksów i
nie widzieć pointera na oczy.

Skąd ted idityzm o tym, że musisz nagle ogarniać wszystkio, jeśli chcesz
uzyć jakiegoś małego, świetnie definiowanego detalu?

Po co programiście embedded wiedza o tym jak działa std::shared_ptr w
detalach enable_shared_from_this? Po co mu wiedza jak pod maską działą
rvalue reference i co to jest std::move? On tego nie użyje, ani do
migania diodą, ani do respiratora.

> Włącznie z tymi
> milionami rzeczy, których sam nie będzie używał

To ich nie używaj.

> - bo nie wiadomo czy
> kolega obok ich nie użyje i trzeba będzie z tym kodem potem walczyć.

To zainteresuj się review kodu, coding standardem, lintowaniem itp
"duperelami" na które spora częsci programistów embedded reaguje agresją.

Gwarantuje Ci, że Twoje problemy "kolega użył", to problemy które reszta
świata miała w latach 70, od tamtego czasu mamy postęp w tym, jak się
pracuje w zespołach, narzędzia do tego i prawidłowe metodyki eliminujące
"kolega użył" bardzo skutecznie, na etapie produkcji.

>> Chyba nie zakładasz, że komuś kto nie ma pojęcia o C++ polecam jego
>> używanie? Polecam *zapoznanie* się.
> Nawołujesz do używania "fragmentów". Dodatkowo argumentując, że "to
> jest za darmo", a to bardzo myląca promocja. Zapoznać się oczywiście
> warto - ze wszystkim. I żeby nie było: ja nie jestem żadnym
> przeciwnikiem C++. Kilka lat temu przeczytałem książkę o nim, i
> wstukałem nawet kilka hello-worldów. Po prostu nie przekonało mnie to,
> by zgłębiać temat dalej.

Nie dziwie się. Nie dostrzegasz abstrakcji RAII nad gówniane goto, więc
C++ nie jest najzwyczajniej dla Ciebie. Tobie wystarczyu dowolny język,
byle blisko asemblera. Jesteś programistą typu "hacker" i C++ nie jest
dla Ciebie.

> Na zakończenie zapytam zupełnie z innej beczki, bo chodzi to za mną
> cały dzień: dlaczego używasz/zachwalasz git-a, skoro jego kod to
> (cytując twoje słowa) "szambo"?

Nigdzie i nigdy nie zachwalałem gita. Nie znajdziesz wypowiedzi na ten
temat gdziekolwiek.

Na codzień pracuje z Subversion, który jest optymalny do zagadnień jakie
mam. Git nie ma żadnej zalety, a same wady, w mojej konkretnej sytuacji.

Jedyna wypowiedź pozytywna na temat gita jaką mogłem rzucić, to co
najwyżej "jak nic nie masz, to git jest lepszy niż to zero co masz je
teraz".

do góry