Powrót do AVR: Wybór IDE i narzędzi do programowania attiny806

Thu Nov 18, 2021 8:03 pm   

On 18.11.2021 18:45, heby wrote:

Przede wszystkim jak ktoś zaczynał w IT 40 lat temu to aktualnie raczej
zajmuje się odcinaniem kuponów od tego co osiągnął w życiu (zawodowym),
a nie kodowaniem.

Tak więc będę się upierał, że w przypadku profesjonalistów problem
zależności jakości kodu od wieku programisty jest IMHO marginalny.

Natomiast nie neguję zależności jakości kodu od wcześniej wykonywanego
zawodu ;-)

Ale przede wszystkim od doświadczenia zawodowego (przy założeniu, że
gość ma zdefiniowaną ścieżkę kariery, ma mentora, bierze udział w
szkoleniach, etc.)


?

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

Piotrek

Thu Nov 18, 2021 8:26 pm   

On 18/11/2021 19:55, Dawid Rutkowski wrote:

Tak, od ~10 lat minimum.


Ten przykałd rozwiązuje problem powszechnie występujacy w programach C w
embedded, czyli tansapcyjności flag. Przerwań, bo łatwe, ale masy innych
tez łatwo tym osiągnać.


Mechanizm RAII jest używany tam, gdzie jest przydatny. Tu jest przydatny.


Tak, dlatego eliminujemy go z C i pojawia się potrzeba użycia czegoś
lepszego. C++ jest za darmo.


Wiec wyjasnij to embedowcom, u których goto jest podstawą wzroców
programowania.


A takie "enableDisplay()" i "disableDisplay()" też?

Przyczepiłeś się użycia w przypadku 1, ale nie widzisz pozostałych N-1
przypadków, gdzie wzorzec projektowy ...scoped... jest znacznie
wygodniejszy i bezpieczniejszy niż debilizmy z goto.


To masz dodatkowy scope w połowie funkcji.

Jesli przerwania musisz wyłączyć pomiędzy scopeami funkcji, to
prawdopodobnie masz coś mocno spieprzone we flow algorytmu i niewiele tu
można pomóc, musi wystarczyć modlitwa.


scope stosuje się własnie w programach znacznie bardziej skomplikowanych
niż miganie diodą. Aby w ogóle dało się je utrzymać dalej, niż etap
migania diodą.


Mówisz o pisaniu na odpierdol? Łopanie, to oczywiscie goto i nastepny.

Poważne oprogramowanie przeszło by review, testy automatyczne, statyczną
analizę, analizę formalną, linting, akceptację SQA. Ale na odpierdol
nie, ja w ogole nie mówie o takiej kategorii oprogramowania. Być może to
miganie diodą było by w respiratorze, więc wtedy też.

Choć nawet w tym na odpierdol wolałbym RAII, niż 30 goto.


To proponuj.


Niczym istotnym. Właśnie odkryłeś że przejście na C++ jest za darmo. A
mimo to dev 60+ broni się rękami i nogami, wymyślając co chwile nowe
debilizmy do obrony epoki kamienia goto-wanego.


Nie. Nie powinno. Będzie zero. Gwarantowane. ISO 9899:201x 5.1.2.2.3


Jak sobie wyobrażasz heap na AVR? Java jest językiem, w którym cieżko
się piszę bez allokacji na heapie. Innymi słowy nie jest możliwa do
użycia na AVR w sposób pełny. Co innego C++ - w nim używania heapu nie
ma obowiązku.

Istnieją podzbiory Javy np. na karty SIM, ale nie chciałbyś w tym pisać,
to jest żenujące i przypomnia tortury.


To są podstawy C++. Nie ma nic prostszego niż RAII.


"grupa" i "review" nie mają nic wspólnego z "akademickością". Są
normalnymi narzędziami używanymi przez prawie wszystkie firmy zajmujące
się pisaniem programów, a nie dicking around.

Bywają "akademickości" gdzie o nich nie słyszano i dalej uczą Delphi,
dajac na koniec magistry.


Myślę, że przeoczyłeś jakieś ~40 lat rozwoju informatyki.

Thu Nov 18, 2021 8:35 pm   

2021-11-18 o 19:40 +0100, heby napisał:

Masz 30 miejsc wyjścia z funkcji? No, to faktycznie przykładny kod.


#define return goto gameover

albo

#define return TUTAJ_UZYWAMY_GOTO

albo

static void func_internal() {
[...]
}

void func() {
_disable();
func_internal();
_enable();
}

Ale znowu - ja nie mam zamiaru wykłócać się z usenetowym krzykaczem.
Wskazuję tylko, że innowacja którą przedstawiasz jest bardzo dyskusyjna.
I nie jest to z mojej strony krytyka C++ (którego znam słabo), tylko
podanego przykładu. Zapytałem o jakiś poważniejszy przykład, ale
wolałeś się obrazić.


Patrz wyżej.


No fajnie, ale to też nie ma nic wspólnego z C++.


Już któryś raz zamiast pokazać kod stosujesz argumenty ad personam. To
świadczy zarówno o tobie, jak i o idei którą tak zaciekle bronisz.

Mateusz

Thu Nov 18, 2021 8:47 pm   

On 18/11/2021 20:03, Piotrek wrote:

W moim otoczeniu programistów 60+ jest mało, ale istnieją. W embedded
jest ich znacznie wiecej, choć to statystyka subiektywna, ale jak mówie,
sporo znajomych z mojego otoczenia ma podobne.


Korelacja jest miedzy wiekiem, a nie "od 60+". Przeciętny 50-latek
będzie znacznie bardziej skłonny do używania void* niż 40-latek. A
30-latek znowu, bedzie znał np. C# i nie zdziwi go lambda w C++.


Taka występuje oczywiście. Dam Ci jeszcze inny przykład: wśród
programistów z Ukrainy zauważyłem korelacje w preferowanych wzorcach
projektowych. Skłaniających się w okolice antywzorca "golden hammer". I
to nie zależy od miejsca, skad pochodzą, z tej Ukrainy. Tak jak by
problem istniał gdzieś w samym centrum nauczania.

To trochę jak kiedyś Bielecki, mający wpływ na nauczanie (kiepskie)
programowania w PL.


Starsi programiści potrafią rozwiązać każdy problem używając outdated
konstrukcji w języku.

Wyjśc ze scope? Goto! (zamiast poprawnej struktury)
Zawołać pointer? C-style (zamiast std::function/lambda)
Zwrócić dwie zmienne? Przez argumenty!
Polimorfizm? void* i enum cast rozwiązuje wszystkie problemy.

Widać wyraźną alergicznośc na konstrukcje bezpieczniejsze, ponieważ
"lepsze jest wrogiem dobrego" jak mawiają ludzie starający sie ukryć
swoją ignorancję.


Czy w latach 80 uczono C++ z RAII? Nie. Nie uczy się go, tak na
marginesie, do dzisiaj. Lata od 90 pod 2020 mam zarówno ogarnięte od
strony ucznia/studenta jak i wykładowcy. Natomiast tak, uczono na
uczelniach kiepskich jezyków programowania i zalewano betonem kiepskie
nawyki. O ile człowiek młody, to jest też elastyczny. Znów starszy, z
uwagi na biologie, przyjmuje postawę w opozycji do nowości. To
naturnalne, stwierdzam bardziej fakt, niż narzekam.


Zwyczajowo nie, programowanie uC w latach 80/90 w wiekszości odbywało
się w asm i sporadycznie w idiotycznych dialektach C. Po 20 latach
pisania na 8051 trudno się dziwić, że jak ktoś mówi o RAII to pojawia
się natychmiastowa reakcja alergiczna. Mnie to nie dziwi ani torchę i
nie zamierzam tego zmieniać. Ten problem rozwiąże biologia.


Języki dąża do bycia coraz to bardziej dziadowskimi, ale ciągle
uzytecznymi. JavaScript, jako najgorsze guano obecnie używane, jest nie
dosc że bardo popularny, to również bardzo wysoko płatny.

Całość tego procesu wynika z faktu, że nie ma na rynku zawodowych
programistów. Są jedynie Ci z łapanki, którzy nie pojmą RAII w C++, ale
pojmą jak zrobić obrazek z licznikiem w Node.js.

Ja tego nie zamierzam zmieniać, ale dziadostwo w moim otoczeniu
uprzątam, jesli tylko mam okazję. Jeszcze mi się chce.

Thu Nov 18, 2021 8:55 pm   

czwartek, 18 listopada 2021 o 17:22:57 UTC+1 heby napisał(a):

To dość dawno, p.m.e. wnikliwie czytam pewnie z rok czy dwa.


Hmm, podałeś piękny przykład socjalizmu - ustroju dzielnie i skutecznie (chyba jednak nie) zwalczającego problemy, które nie występują w kapitaliźmie.
Mechanizm RAII stosowany po to, by "usunąć kategorię bugów", która pojawia się w wyniku kodowania, które nie jest nawet strukturalne.
Wiem że BASIC ryje beret nieodwracalnie...
I wiem też, że w C można pisać programy FORTRANowe.
Sztuka i nauka w tym, by tego nie robić.

Zaś takie cli() na początku i sei() na końcu funkcji można sobie zrobić za pomocą __attribute__.
Tylko co, jeśli przerwania musisz włączyć w połowie funkcji?
Np. w ISR w programie bardziej skomplikowanym niż miganie diodą?
Pewnie dałoby się to zrobić lepiej - ale urządzenie musi iść na obiekt jutro, bo za pół roku to takie oprogramowanie zrobi też Hindus, a może i Chińczyk.


Słabe. Jeszcze bym chciał coś lepszego.


To może odwrotnie - czy drugi nie skompiluje się gcc?
Przecież nie było tam nawet:
for(int i = 0 ; i < 100 ; ++i )
Czym one się w ogóle różnią?
Pewnie tym, co zwróci
$ echo $_
Ciekawe co będzie w tym drugim przypadku.
Nie powinno być:
void main() {}
?

Rozwiązywałe kiedyś test 50 pytań z Javy i C++ u takiej jednej fajnej "rekruterki" (rozpraszała, podobnie jak taka jedna fajna z zakładu metod matematycznych informatyki na egzaminie z prawdopodobieństwa
Java była OK, za co ją uwielbiam (ciekawe czy jest gcj na AVR?), C++ koszmarne - ale to Twoje jest jeszcze trudniejsze.


Tak samo albo nie.
Jakoś to mocno "akademickie" - czy dobrze odbieram "grupę" i "review"?
I to jeszcze akademickie młodego pokolenia, co pierwszy komputer miało z windows 95...

Thu Nov 18, 2021 8:56 pm   

On Thu, 18 Nov 2021 20:35:36 +0100, Mateusz Viste wrote:

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.

Thu Nov 18, 2021 9:02 pm   

On 18/11/2021 20:35, Mateusz Viste wrote:

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.


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


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


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


Widzę.


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


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.


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.


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


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.


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?

Thu Nov 18, 2021 9:43 pm   

On 18.11.2021 18:38, heby wrote:


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

--
Mirek.

Thu Nov 18, 2021 9:47 pm   

2021-11-18 o 21:02 +0100, heby napisał:

Przypomnę, że pisałeś wcześniej że "w C nie da się tego zrobić". Teraz
ci po prostu łyso. :-)


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


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.


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


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

Thu Nov 18, 2021 10:06 pm   

On 18/11/2021 21:47, Mateusz Viste wrote:

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.


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


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


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.


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.


Potraktuj to jaki uniwersalną, generyczną asercję.


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.


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.


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


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.


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

Thu Nov 18, 2021 10:25 pm   

Piotrek <piotrek@pisz.na.berdyczow.info> wrote:

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

Fri Nov 19, 2021 8:57 am   

2021-11-18 o 20:56 +0100, J.F napisał:

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

Fri Nov 19, 2021 9:33 am   

2021-11-18 o 22:06 +0100, heby napisał:

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


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.


Zauważ, że to zupełnie tak, jak duża część twoich odpowiedzi w tym
wątku.


No tak, ale ty też możesz przecież się pomylić: zapomnieć wstawić
range_check<>, albo wstawić mu nieodpowiedni typ... To znów przesuwanie
problemu.


Od tego jest #define, żeby takie rzeczy elegancko sobie opakować. Znane
od 1978 (a może i trochę wcześniej).


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.


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


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.


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

Fri Nov 19, 2021 9:43 am   

On Fri, 19 Nov 2021 08:57:19 +0100, Mateusz Viste wrote:

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


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.

Fri Nov 19, 2021 9:44 am   

On 19/11/2021 08:57, Mateusz Viste wrote:

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.