RTV forum PL | NewsGroups PL

AVR po latach

NOWY TEMAT

elektroda NewsGroups Forum Index - Elektronika Polska - AVR po latach

Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next

Piotrek
Guest

Thu Nov 18, 2021 8:03 pm   



On 18.11.2021 18:45, heby wrote:
Quote:
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.

Zależy. Przykro mi to stwierdzić, ale zalezy. W embedded w szczególności.

Isnieje korelacja między używaniem konstrukcji hackerskich i
niebezpiecznych, a wiekiem developera. Są to moje, subiektywne
oczywiscie, obserwacje. Ale sądząc po dyskusjach z moimi znajomymi, nie
odosobnione.

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

Quote:

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

Piotrek

heby
Guest

Thu Nov 18, 2021 8:26 pm   



On 18/11/2021 19:55, Dawid Rutkowski wrote:
Quote:
Robiłem to dziesitki razy, na tej grupie, trzeba było uważać.
To dość dawno, p.m.e. wnikliwie czytam pewnie z rok czy dwa.

Tak, od ~10 lat minimum.

Quote:
Np taki:

foo()
{
DisableInterruptsInThisScope guard;

[...]
return;
[...]
return;
[...]
return;
}
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.

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

Quote:
Mechanizm RAII stosowany po to, by "usunąć kategorię bugów", która pojawia się w wyniku kodowania, które nie jest nawet strukturalne.

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

Quote:
Wiem że BASIC ryje beret nieodwracalnie...

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

Quote:
I wiem też, że w C można pisać programy FORTRANowe.
Sztuka i nauka w tym, by tego nie robić.

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

Quote:
Zaś takie cli() na początku i sei() na końcu funkcji można sobie zrobić za pomocą __attribute__.

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.

Quote:
Tylko co, jeśli przerwania musisz włączyć w połowie funkcji?

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.

Quote:
Np. w ISR w programie bardziej skomplikowanym niż miganie diodą?

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

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

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.

Quote:
Dla ustalenia uwagi w porównaniu do C, żeby nie wynajdywać koła.
No to masz RIIA.
Słabe. Jeszcze bym chciał coś lepszego.

To proponuj.

Quote:
Drugi. Kompiluje się g++. Pierwszy też, ale drugi jest *niewątpliwie*.
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ą?

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.

Quote:
Pewnie tym, co zwróci
$ echo $_
Ciekawe co będzie w tym drugim przypadku.
Nie powinno być:
void main() {}
?

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

Quote:
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 Wink
Java była OK, za co ją uwielbiam (ciekawe czy jest gcj na AVR?)

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.

Quote:
, C++ koszmarne - ale to Twoje jest jeszcze trudniejsze.

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

Quote:
Dlatego postulatem nie jest uzywanie g++ tylko pisanie w C++.
Tak samo albo nie.
Jakoś to mocno "akademickie" - czy dobrze odbieram "grupę" i "review"?

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

Quote:
I to jeszcze akademickie młodego pokolenia, co pierwszy komputer miało z windows 95...

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

Mateusz Viste
Guest

Thu Nov 18, 2021 8:35 pm   



2021-11-18 o 19:40 +0100, heby napisał:
Quote:
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.

Quote:
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

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

Quote:
Wiec albo chcesz mieć szambo, jak proponujesz, albo automatyzację. I
tak, nie da się tego zrobic w C.

Patrz wyżej.

Quote:
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++.

Quote:
Pisałeś kiedyś coś więcej, niż hello world?

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

heby
Guest

Thu Nov 18, 2021 8:47 pm   



On 18/11/2021 20:03, Piotrek wrote:
Quote:
Isnieje korelacja między używaniem konstrukcji hackerskich i
niebezpiecznych, a wiekiem developera. Są to moje, subiektywne
oczywiscie, obserwacje. Ale sądząc po dyskusjach z moimi znajomymi,
nie odosobnione.
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.

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.

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

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

Quote:
Natomiast nie neguję zależności jakości kodu od wcześniej wykonywanego
zawodu Wink

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.

Quote:
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.
?

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

Quote:
Nie traktuj tego osobiście ale IMHO masz wypaczone pojęcie o technologii
i zakresie kształcenia (studentów informatyki) w latach 80.

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.

Quote:
Inną sprawą jest to czy rzeczeni studenci mogli wykorzystać nabytą
wiedzę w pracy zawodowej.

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.

Quote:
Ale regresu typu Simula/Smalltalk/C++ -> BASIC raczej bym się nie
spodziewał.

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.

Dawid Rutkowski
Guest

Thu Nov 18, 2021 8:55 pm   



czwartek, 18 listopada 2021 o 17:22:57 UTC+1 heby napisał(a):
Quote:
On 18/11/2021 15:52, Dawid Rutkowski wrote:
Tymczasem to bardzo dużo małych, drobnych detali które czynią ten język
*bardzo* przydatnym w embedded, bez narzutu wydajności.
Napisz choć kilka przykładów.
Robiłem to dziesitki razy, na tej grupie, trzeba było uważać.

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

Quote:
Np taki:

foo()
{
DisableInterruptsInThisScope guard;

[...]
return;
[...]
return;
[...]
return;
}

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.

Quote:
Dla ustalenia uwagi w porównaniu do C, żeby nie wynajdywać koła.
No to masz RIIA.

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

Quote:
Przykład zły,
bo oba kody skracają się do tej samej abstrakcji wspólnej dla obu
języków.
To dalej oznacza, że jeden z nich na pewno jest w C++.
Który? I dlaczego?
Drugi. Kompiluje się g++. Pierwszy też, ale drugi jest *niewątpliwie*.

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 Wink
Java była OK, za co ją uwielbiam (ciekawe czy jest gcj na AVR?), C++ koszmarne - ale to Twoje jest jeszcze trudniejsze.

Quote:
Ale ale ... zmartwię Cię. Niektóre porządnie napisane przykłady z
*klasami* kompilują się do wydajnijszego kodu, niż goła pętla w C... to
dlatego że C++ zawiera więcej konstrukcji pozwalajacej wyrazić cel, a
nie tylko metodę jego osiągnięcia, wiążac kompilatorowi ręce.
No to którym kompilatorem "lepiej" się skompiluje program napisany w C - kompilatorem C czy C++?
Oba skompilują tak samo.

Dlatego postulatem nie jest uzywanie g++ tylko pisanie w C++.

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

J.F
Guest

Thu Nov 18, 2021 8:56 pm   



On Thu, 18 Nov 2021 20:35:36 +0100, Mateusz Viste wrote:
Quote:
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.

heby
Guest

Thu Nov 18, 2021 9:02 pm   



On 18/11/2021 20:35, Mateusz Viste wrote:
Quote:
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.

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

Quote:
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?

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

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

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

Widzę.

Quote:
, 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ę.

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

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

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

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

Quote:
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?

Mirek
Guest

Thu Nov 18, 2021 9:43 pm   



On 18.11.2021 18:38, heby wrote:

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

Mateusz Viste
Guest

Thu Nov 18, 2021 9:47 pm   



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

Quote:
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/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."

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

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

Quote:
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

heby
Guest

Thu Nov 18, 2021 10:06 pm   



On 18/11/2021 21:47, Mateusz Viste wrote:
Quote:
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. Smile

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.

Quote:
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++.

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

Quote:

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.

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

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

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

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

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

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

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

Guest

Thu Nov 18, 2021 10:25 pm   



Piotrek <piotrek_at_pisz.na.berdyczow.info> wrote:
Quote:
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

Mateusz Viste
Guest

Fri Nov 19, 2021 8:57 am   



2021-11-18 o 20:56 +0100, J.F napisał:
Quote:
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

Mateusz Viste
Guest

Fri Nov 19, 2021 9:33 am   



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

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

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

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

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

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

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

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

Quote:
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

J.F
Guest

Fri Nov 19, 2021 9:43 am   



On Fri, 19 Nov 2021 08:57:19 +0100, Mateusz Viste wrote:
Quote:
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);

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

heby
Guest

Fri Nov 19, 2021 9:44 am   



On 19/11/2021 08:57, Mateusz Viste wrote:
Quote:
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.

Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next

elektroda NewsGroups Forum Index - Elektronika Polska - AVR po latach

NOWY TEMAT

Regulamin - Zasady uzytkowania Polityka prywatnosci Kontakt RTV map News map