On Thu, 18 Nov 2021 20:35:36 +0100, Mateusz Viste wrote:
> 2021-11-18 o 19:40 +0100, heby napisał:
>> 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.
>
> Masz 30 miejsc wyjścia z funkcji? No, to faktycznie przykładny kod.

Jak mam obsluge bledow w funkcji, to sie zaczynaja wyjscia mnozyc.
Bo bledow moze byc mnostwo - np brak portu, brak prawa dostepu do
portu, brak odpowiedzi w zalozonym czasie, niezrozumiala odpowiedz,
zgloszony bład przez urzadzenie na porcie, błędna wartosc.

Moim sztandarowym przykladem jest raczej przeszukanie dwuwymiarowej
tablicy.

To IMO jakos tak bylo, ze jak poczatkujacy pisze w Basicu czy
Fortranie, to wkrotce pisze kod pelny "dzikich" goto.

Wirth to chyba zauwazyl, wymyslil jezyk strukturalny,
ale czasem naprawde przykro patrzec, jakie cuda wyprawiali programisci
w Pascalu, aby nie użyć zadnego goto.
Ktore w jezyku było, ale przeciez nie wypada ...


J.

do góry

On 18/11/2021 20:35, Mateusz Viste wrote:
>> 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.
> Masz 30 miejsc wyjścia z funkcji? No, to faktycznie przykładny kod.

Prawidłowe założenie brzmi: masz N wyjśc z funkcji. Zakładanie że "N
jest małe i sobie jakoś poradzimy" jest absurdalnie niebezpiecznie.

>> 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.
> #define return goto gameover

Wylatujesz za drzwi nie tylko z kopniakiem, ale jeszcze z wilczym
biletem na pracę w IT.

> albo
> static void func_internal() {
> [...]
> }
> void func() {
> _disable();
> func_internal();
> _enable();
> }

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

> Wskazuję tylko, że innowacja którą przedstawiasz jest bardzo dyskusyjna.

To nie jest innowacja, tylko codzienność pracy programisty C++.

> I nie jest to z mojej strony krytyka C++ (którego znam słabo)

Widzę.

>, tylko
> podanego przykładu.

Podany przykład jest uproszczony na potrzeby usenetu. Jeśli nie widzisz
abstrakcyjnie zastosowania RAII, ale widzisz przykład włączenia przerwań
jako jedyne zastosowanie, to nic nie poradzę.

> Zapytałem o jakiś poważniejszy przykład, ale
> wolałeś się obrazić.

Ja się nie obrażam, mnie w ogóle ciezko obrazić.

Poważniejszy przykład mogę podrzucić jeśli chcesz, ale czy aby na pewno
pojmiesz o co chodzi? Sprawdźmy jakiś trywialny:

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.

>> Wiec albo chcesz mieć szambo, jak proponujesz, albo automatyzację. I
>> tak, nie da się tego zrobic w C.
> Patrz wyżej.

Wyżej napisałes emulację RAII. I napisałeś ja w zasadzie tylko po to aby
nie użyć C++, ale użyć RAII. Troche żałosne.

Mam kolegę, głeboko wierzącego w wyższosć C nas wszystkim, w którego
kodzie napotkałem prawie kompletną emulację obiektowości, wliczając
tablice wirtualne, na C i z kupą bugów. Zapytany o to po ch... to pisać
od zera, skoro to samo ma w C++, obraził się.

Napisałeś kiepski emualtor RAII tylko po to aby nie używać RAII. Widzę
podobieństwa między tymi sytuacjami.

>> 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.
> No fajnie, ale to też nie ma nic wspólnego z C++.

Kod sprawdzający statycznie flagi przekazywane do rejestrów sprzetowych?
Ma bardzo dużo.

>> Pisałeś kiedyś coś więcej, niż hello world?
> Już któryś raz zamiast pokazać kod stosujesz argumenty ad personam.

Kodu Ci nie pokaże, bo został sprzedany i nie jest moją własnościa.
Musiałbym napisac go ponownie ale mi się najzwyczajneij nie chce,
ponieważ nigdy go nie użyjesz. A udowanianie oczywistości nie jest tego
warte.

> To
> świadczy zarówno o tobie, jak i o idei którą tak zaciekle bronisz.

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?

To co, piszesz to zabezpieczneie przed podaniem złej flagi do uartu, w C?

do góry

Piotrek <p...@p...na.berdyczow.info> wrote:
> On 18.11.2021 18:45, heby wrote:
> > On 18/11/2021 18:41, Piotrek wrote:
> >> Nie to, ?ebym si? obruszy? o 60+ ...
> >> Ale przecie? styl projektowania/programowania nie zale?y od wieku autora.
<snip>
> >> Tylko raczej od tego czy go?? trafi? do zawodu w wyniku ostatniej
> >> ?apanki przeprowadzonej w ?rodowisku piekarzy, czy te? w bardziej
> >> cywilizowany spos?b.
> >
> > Problem ?e ten "bardziej cywilizowany spos?b", 40 lat temu, to by?o goto
> > w BASICu. I z tym k?opot najwi?kszy.
>
> ?
>
> Nie traktuj tego osobi?cie ale IMHO masz wypaczone poj?cie o technologii
> i zakresie kszta?cenia (student?w informatyki) w latach 80.
>
> Inn? spraw? jest to czy rzeczeni studenci mogli wykorzysta? nabyt?
> wiedz? w pracy zawodowej.
>
> Ale regresu typu Simula/Smalltalk/C++ -> BASIC raczej bym si? nie
> spodziewa?.

Elektronika na PWr 1982: programowanie to byl Fortran 66, czesc
grup Pascal. W tym czasie PWr kupila sporo ZX81, tam faktycznie
byl Basic. Mikroprocesory to byl 8080 (bylo tez o Z80), programowanie
w asemblerze. Na RIAD-ach byl tez PL/I i Algol. Byl tez Prolog,
ale chyba tylko dla malej grupki wybrancow. 2-3 lata pozniej
na komputerki domowe byl Pascal, C, Forth, Logo (Basic tez...).
Sporo bylo pisane w asemblerze.

Inna sprawa ze w 1982 dostep do komputerow byl ograniczony i
sporo studentow tego nie lapalo. Ale jak ktos zalapal i
glebiej wchodzil w programowanie to dosc szybko zostawial
Basic i Fortran za soba.

--
Waldek Hebisch

do góry

On 18.11.2021 18:38, heby wrote:

> Branża języków programowania dyskutuje własnie o tym, kiedy mowa o
> językach programowania. Szkoda, mogli by rozmawiać o dupach.
>

Ale po co ci jakieś dupy - toż to białko ;)

--
Mirek.

do góry

2021-11-18 o 21:02 +0100, heby napisał:
> 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. :-)

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

goto ma swoje niszowe zastosowania. To, co dziś nazywa się "RAII"
istniało przed C++ i wykorzystywało właśnie goto. Zresztą nie tylko ja
o tym bredzę:
https://www.kernel.org/doc/Documentation/process/cod
ing-style.rst

"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."

> Poważniejszy przykład mogę podrzucić jeśli chcesz, ale czy aby na
> pewno pojmiesz o co chodzi? Sprawdźmy jakiś trywialny:
>
> 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. Czy w takiej sytuacji ten
cast_with_range_check<> ma jakieś zalety? Pytam szczerze i bez przekąsu.

> 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" i uargumentowałeś ją kiepskim przykładem. Zapytałem o lepszy.
I zaczęło się.

> To co, piszesz to zabezpieczneie przed podaniem złej flagi do uartu,
> w C?

Ja zupełnie tego nie potrzebuję. To ty podałeś te flagi jako kolejny
przykład wyższości C++ "w embedded"... Ale okazało się niestety, że to
przykład tylko wirtualny.


Mateusz

do góry

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ć.

do góry

2021-11-18 o 20:56 +0100, J.F napisał:
> Jak mam obsluge bledow w funkcji, to sie zaczynaja wyjscia mnozyc.
> Bo bledow moze byc mnostwo - np brak portu, brak prawa dostepu do
> portu, brak odpowiedzi w zalozonym czasie, niezrozumiala odpowiedz,
> zgloszony bład przez urzadzenie na porcie, błędna wartosc.

W tym wypadku też mnogość wyjść może być problemem, bo szybko wychodzą
tego typu rzeczy:

if (!alokuj_bufor()) return(fail);

if (!otworz_port()) {
zwolnij_bufor();
return(fail);
}

if (!napisz_na_port()) {
zwolnij_bufor();
zamknij_port();
return(fail);
}

if (!odbierz_z_portu()) {
zwolnij_bufor();
zamknij_port();
return(fail);
}


i prędzej czy później o czymś zapomnisz. Tzn. może nie ty, ale ja
na pewno. Zamiast tego można w ten sposób:

void *buf = NULL;
int port = 0;

buf = alokuj_bufor();
if (!buf) goto poleglem;

if (!napisz_na_port() goto poleglem;

if (!odbierz_z_portu() goto poleglem;

return(sukces);

poleglem:

if (buf) zwolnij_bufor();
if (port) zamknij_port();
return(fail);


albo, jeśli kto naprawdę uczulony na goto, to całość ubrać w jakąś
niby-pętlę która wykonuje się raz, a wychodzić z niej breakiem... Ale
to już kombinowanie na siłę, aby tylko nie zhańbić się goto przed
pryszczatą młodzieżą.

Mateusz

do góry

2021-11-18 o 22:06 +0100, heby napisał:
> 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 które zostały
wymyślone aby nie użyć goto/define. Co kto woli, ale to dalej nie jest
postęp (w tym szczególnym kontekście).

> 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, Linus i jego koledzy to idioci i tylko jeden heby z
internetu osiągnął zrozumienie świata i dzielnie niesie światło
pogańskim narodom. Może tak faktycznie jest.

> 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.

> 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.

> 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).

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

> 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,
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.

Jeśli miałbym mieć jakiś jeden zarzut do C++, to chyba właśnie tylko
to, że namnożył miliony bytów, przez co człowiekowi ciężko wszystko
ogarnąć i o wszystkim pamiętać. 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ą.

> 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.

> 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. 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.


Mateusz

do góry

On Fri, 19 Nov 2021 08:57:19 +0100, Mateusz Viste wrote:
> 2021-11-18 o 20:56 +0100, J.F napisał:
>> Jak mam obsluge bledow w funkcji, to sie zaczynaja wyjscia mnozyc.
>> Bo bledow moze byc mnostwo - np brak portu, brak prawa dostepu do
>> portu, brak odpowiedzi w zalozonym czasie, niezrozumiala odpowiedz,
>> zgloszony bład przez urzadzenie na porcie, błędna wartosc.
>
> W tym wypadku też mnogość wyjść może być problemem, bo szybko wychodzą
> tego typu rzeczy:
[...]
> i prędzej czy później o czymś zapomnisz. Tzn. może nie ty, ale ja
> na pewno. Zamiast tego można w ten sposób:
>
> void *buf = NULL;
> int port = 0;
>
> buf = alokuj_bufor();
> if (!buf) goto poleglem;
>
> if (!napisz_na_port() goto poleglem;
>
> if (!odbierz_z_portu() goto poleglem;
>
> return(sukces);
>
> poleglem:
>
> if (buf) zwolnij_bufor();
> if (port) zamknij_port();
> return(fail);

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);

> albo, jeśli kto naprawdę uczulony na goto, to całość ubrać w jakąś
> niby-pętlę która wykonuje się raz, a wychodzić z niej breakiem...
> Ale
> to już kombinowanie na siłę, aby tylko nie zhańbić się goto przed
> pryszczatą młodzieżą.

Jak krokow wiecej to moze byc nieglupie - przygotowac taki
mini program do wykonania.

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


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

Gorzej, jak sie drzewko decyzyjne komplikuje ...

J.

do góry

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.

do góry