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

J.F
Guest

Thu Nov 18, 2021 4:09 pm   



On Thu, 18 Nov 2021 06:52:45 -0800 (PST), Dawid Rutkowski wrote:
Quote:
środa, 17 listopada 2021 o 20:32:15 UTC+1 heby napisał(a):
On 17/11/2021 20:14, Marek wrote:
Nie. Dałem Ci przykład dwóch programów, jeden w C drugi w C++. Który
wykona się wolniej i dlaczego?
Daj spokój, dobrze wiemy, że żaden z nich nie jest w C++.
Jeden z nich na pewno jest.

Na tym polega proble m ludzi związanych z embedded. Wydaje im się, w
swojej ignorancji, że kod C++ to biliardy klas, i eniony templejtów.

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.
Dla ustalenia uwagi w porównaniu do C, żeby nie wynajdywać koła.

Piotr kiedys wymienial.

Chocby izolacja nazw procedur w klasie - i nie musisz wymyslac
unikalnych nazw, czy martwic sie, ze gdzies w bibliotece juz jest jest
tak nazwana funkcja.

W malych uC wydawało mi się to niewielką zaletą - nad małym programem
można zapanowac. Ale jak sie uC rozbudowały.

Quote:
Ten drugi napisz porządnie w C++, pętlę zrób obiektowo i żeby
proces zajął min 2GB ram. Wink
To jest właśnie opinia niedzielnego programisty embedded o C++. Z nią
walczę.

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

Jeszcze kwestia, jak mocny musi byc procesor, żeby sie te konstrukcje
naprawde wydajnie kompilowaly.

C++ na 8051? :-)

No, ciekawe, czy by sie udalo ubrac te 3 rodzaje pamieci w klasy ...
nie, chyba nie :-)

J.

Dawid Rutkowski
Guest

Thu Nov 18, 2021 4:52 pm   



środa, 17 listopada 2021 o 20:32:15 UTC+1 heby napisał(a):
Quote:
On 17/11/2021 20:14, Marek wrote:
Nie. Dałem Ci przykład dwóch programów, jeden w C drugi w C++. Który
wykona się wolniej i dlaczego?
Daj spokój, dobrze wiemy, że żaden z nich nie jest w C++..
Jeden z nich na pewno jest.

Na tym polega proble m ludzi związanych z embedded. Wydaje im się, w
swojej ignorancji, że kod C++ to biliardy klas, i eniony templejtów.

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.
Dla ustalenia uwagi w porównaniu do C, żeby nie wynajdywać koła.

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?

Quote:
Ten drugi napisz porządnie w C++, pętlę zrób obiektowo i żeby
proces zajął min 2GB ram. Wink
To jest właśnie opinia niedzielnego programisty embedded o C++. Z nią
walczę.

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

ptoki
Guest

Thu Nov 18, 2021 5:10 pm   



środa, 17 listopada 2021 o 19:37:59 UTC-6 anti...@math.uni.wroc.pl napisał(a):
Quote:

W embedded prawo Parkinsona tez dziala, ludzie wstawiaja
Raspberry Pi z 1GB RAM i 1GHz zegarem w miejsca gdzie
lepiej by dzialal MCU z 16k flashu i zegarem kilka-kilkadziesiat
MHz.


Tak, ALE! Smile
Wyjasnienie nizej.

Quote:
Wracajac do C++ na MCU: jest sporo przykladow programikow
ktore robia proste ale pozyteczne rzeczy napisanych w C++
gdzie kod jest ponizej 3 kB. Oczywiscie w 3 kB kodu
wynikowego nie da sie wrzucic wszyskich ficzerow C++,
ale wlasnie o to chodzi: uzywasz to co jest potrzebne
a reszte pomijasz. No i sa pulapki: jak Ci przyjdzie
do glowy zlinkowac program z libstdc++ to masz ponad
100kB w plecy...


Najsmieszniejsze w tym jest to ze o ile zrobienie sobie termostatu rzeczywiscie zajmie te 3kb (lub pewnie mniej) nawet w arduino przy uzyciu gotowych bibliotek ALE
bardzo czesto tworca sobei zazyczy kontrole i monitoring zdalny. Czyli wifi, http(s), jakas autoryzacja, jakies kolejki, moze scheduler zachowan...
I program nie miesci sie w attiny.
Nie miesci sie w byle atmega bo trzeba by przynajmniej taki z ethernetem.
Mozna zrobic na esp8266 czy podobnych rozwiazaniach ale jak malina kosztuje to samo, ma ssh, ogarnia ssl, moze hostowac baze, moze miec zabbixa czy inna grafane to czemu nie uzyc?

Smieszne jest to ze z punktu widzenia hobbysty to dobry kierunek. Z punktu widzenia gigantow tez!

I dlatego ludki chca i C++ i arduino i maline bo kosztuje podobnie, a pozwala na wiecej.

A ludzie tacy jak w tym watku, broniacy minimalizmu (lub atakujacy rozrzutnosc) czy jeszcze inaczej motywowani to w praktyce mniejszosc.
Maja slusznosc w pewnych aspektach ale ogolny trend od dawna byl taki ze minimalizm nie poplaca.

Sprawdza sie czasem (minecraft, notepad++, esp8266) ale ogolnie preferencja jest aby miec wiecej za te same pieniadze. Fakt ze to powoduje pewne problemy (zawodnosc, wiecej wektorow ataku itp) jednak nie zmienia tego trendu mimo ze to calkiem wazne aspekty.

heby
Guest

Thu Nov 18, 2021 5:22 pm   



On 18/11/2021 15:52, Dawid Rutkowski wrote:
Quote:
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ć.

Np taki:

foo()
{
DisableInterruptsInThisScope guard;

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

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

No to masz RIIA.

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

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

heby
Guest

Thu Nov 18, 2021 5:27 pm   



On 18/11/2021 17:22, heby wrote:
Quote:
No to masz RIIA.

Tfu, RAII.

Mateusz Viste
Guest

Thu Nov 18, 2021 5:32 pm   



2021-11-18 o 17:22 +0100, heby napisał:
Quote:
Np taki:

foo()
{
DisableInterruptsInThisScope guard;

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

Spodziewałem się jakiejś faktycznej wartości dodanej, a tu zawód. :)

To co podałeś to przecież nic innego jak to:

foo() {
_disable();
[...]
goto gameover;
[...]
goto gameover;
[...]
goto gameover;

gameover:
_enable();
}


Mateusz

heby
Guest

Thu Nov 18, 2021 5:47 pm   



On 18/11/2021 17:32, Mateusz Viste wrote:
Quote:
To co podałeś to przecież nic innego jak to:

foo() {
_disable();
[...]
goto gameover;
[...]
goto gameover;
[...]
goto gameover;

gameover:
_enable();
}

No i właśnie nie rozumiałeś, więc C++ nie dla Ciebie.

Celem tego kodu była eliminacja BIAŁKA z procesu tworzenia się bugów.

W twoim przypadku, białko zostało i niczym się to nie rózni od ręcznego
pisania sei(); return;.

W moim nie da się wyjśc ze scope funkcji bez właczenia przerwań. Jedna
kategoria bugów została właśnie usunięta: "zapomniałem załączyć przerwania".

Mateusz Viste
Guest

Thu Nov 18, 2021 6:01 pm   



2021-11-18 o 17:47 +0100, heby napisał:
Quote:
Celem tego kodu była eliminacja BIAŁKA z procesu tworzenia się bugów.

Cel szczytny, ale taki jakby mało realistyczny. A raczej: realistyczny,
ale kiedy zostanie osiągnięty, to już dawno nie będziemy potrzebni.

Quote:
W moim nie da się wyjśc ze scope funkcji bez właczenia przerwań.
Jedna kategoria bugów została właśnie usunięta: "zapomniałem załączyć
przerwania".

W konkursie wystartowała natomiast kategoria nowa: "zapomniałem ustawić
scope guard na włączenie przerwań".

No i teraz można się spierać o styl, jakieś prawdopodobieństwa,
zwyczaje itd, ale liczyłem że podasz po prostu inny przykład, który
wykazałby wyższość tych plus-plusów w sposób bezdyskusyjny.

Mateusz

heby
Guest

Thu Nov 18, 2021 6:12 pm   



On 18/11/2021 18:01, Mateusz Viste wrote:
Quote:
Celem tego kodu była eliminacja BIAŁKA z procesu tworzenia się bugów.
Cel szczytny, ale taki jakby mało realistyczny. A raczej: realistyczny,
ale kiedy zostanie osiągnięty, to już dawno nie będziemy potrzebni.

Dostałeś wlaśnie metodę eliminacji białka z procesu tworzenia się błedu
w kodzie. Kazde takie miejsce przyczynia się do mniejszej ilości bugów.

Programowanie w językach wyższego poziomu własnie na tym polega: na
zmniejszeniu ilosci potencjalnych miejsc z pomyłką.

Quote:
W moim nie da się wyjśc ze scope funkcji bez właczenia przerwań.
Jedna kategoria bugów została właśnie usunięta: "zapomniałem załączyć
przerwania".
W konkursie wystartowała natomiast kategoria nowa: "zapomniałem ustawić
scope guard na włączenie przerwań".

Co wydarzy się 3x rzadziej, niż w twom ręcznie wydziarganym kodzie.

Quote:
No i teraz można się spierać o styl

Nie pojmujesz że to nie jest styl. To zwiększanie bezpieczeństwa kodu.
Są miejsca, gdzie takie gówno oparte o goto wyleciało by z hukiem na
review razem z autorem tego szamba. Choć zdaje sobie też sprawę, że w
grupach 60+ to może być coding standard.

, jakieś prawdopodobieństwa,
Quote:
zwyczaje itd, ale liczyłem że podasz po prostu inny przykład, który
wykazałby wyższość tych plus-plusów w sposób bezdyskusyjny.

Ten przewyższa, tylko nie pojmujesz, najwidoczniej w projektach miganai
diodą nie ma problemu i stąd ten problem z rozumieniem tej wyższości.

To jeszcze jeden:

UART0CTL = 1<<UART0_DOUBLE | 1<<UART0_REVERSE | 1<<UART1_FAST;

Ten kod ma buga. Nie do znalezienia oczami natychmiast. Użyto złej
flagi, od innego uarta. W czasach ludzi robiących #define UART0_FOO 7 to
jest poważny problem.

Mogę ten kod napisać sprytnie. Tak sprytnie, że użycie złej flagi będzie
niemożliwe na złym porcie. I w dodatku bez zmiany składni, którą widzisz
na górze, wyłącznie używając C++, wrapując enumeratory, przeciążając
operatory i na zawsze zapominając o błędnych flagach. I bez śladu
obciążenia w kodzie wynikowym, asm będzie zawierał tą samą instrukcję.

Tak, to też da się zastąpić uwaznym gapieniem się w kod, wiec doskonale
zdaje sobie sprawę, że nie będziesz pojmować po co to komu. Bo przeciez
wszystko da się napisać w asm, jak się jest uważnym hackerem.

Mateusz Viste
Guest

Thu Nov 18, 2021 6:28 pm   



2021-11-18 o 18:12 +0100, heby napisał:
Quote:
Dostałeś wlaśnie metodę eliminacji białka z procesu tworzenia się
błedu w kodzie.

Nie, nie dostałem. Smile
Ty tego białka nie wyeliminowałeś, tylko je przesunąłeś w inne miejsce.

Quote:
W konkursie wystartowała natomiast kategoria nowa: "zapomniałem
ustawić scope guard na włączenie przerwań".

Co wydarzy się 3x rzadziej, niż w twom ręcznie wydziarganym kodzie.

Ech, czyli jednak dyskutowanie o prawdopodobieństwach. Szkoda.

Quote:
Nie pojmujesz że to nie jest styl. To zwiększanie bezpieczeństwa
kodu. Są miejsca, gdzie takie gówno oparte o goto wyleciało by z
hukiem na review razem z autorem tego szamba.

Bo ty tak mówisz?

Quote:
Ten przewyższa, tylko nie pojmujesz, najwidoczniej w projektach
miganai diodą nie ma problemu i stąd ten problem z rozumieniem tej
wyższości.

Czy to miganie diodą, czy sterowanie promem kosmicznym, w obu
przypadkach scope nie powinien być tak rozległy, że autor przestaje nad
nim panować.

Quote:
To jeszcze jeden:

UART0CTL = 1<<UART0_DOUBLE | 1<<UART0_REVERSE | 1<<UART1_FAST;

Ten kod ma buga. Nie do znalezienia oczami natychmiast. Użyto złej
flagi, od innego uarta. W czasach ludzi robiących #define UART0_FOO 7
to jest poważny problem.

Mogę ten kod napisać sprytnie.

O, czyli może jednak będzie konstruktywnie. No to dajesz.

Mateusz

heby
Guest

Thu Nov 18, 2021 6:38 pm   



On 18/11/2021 18:28, Mateusz Viste wrote:
Quote:
Dostałeś wlaśnie metodę eliminacji białka z procesu tworzenia się
błedu w kodzie.
Nie, nie dostałem. Smile
Ty tego białka nie wyeliminowałeś, tylko je przesunąłeś w inne miejsce.

Zmniejszyłem je. Z wielu miejsc usunąłem. Na tym polega proces
eliminacji białka.

Quote:
W konkursie wystartowała natomiast kategoria nowa: "zapomniałem
ustawić scope guard na włączenie przerwań".
Co wydarzy się 3x rzadziej, niż w twom ręcznie wydziarganym kodzie.
Ech, czyli jednak dyskutowanie o prawdopodobieństwach. Szkoda.

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

Quote:
Nie pojmujesz że to nie jest styl. To zwiększanie bezpieczeństwa
kodu. Są miejsca, gdzie takie gówno oparte o goto wyleciało by z
hukiem na review razem z autorem tego szamba.
Bo ty tak mówisz?

Tak, z mojej grupy byś wyleciał, dodatkowo z solidym kopniakiem za
niepojmowanie podstaw bezpieczeństwa.

Quote:
Ten przewyższa, tylko nie pojmujesz, najwidoczniej w projektach
miganai diodą nie ma problemu i stąd ten problem z rozumieniem tej
wyższości.
Czy to miganie diodą, czy sterowanie promem kosmicznym, w obu
przypadkach scope nie powinien być tak rozległy, że autor przestaje nad
nim panować.

Ale jest rozległy. I co teraz? Oferujesz "gapmiy się bardziej
wnikliwie". Ja oferuje "upewnijmy się, że to co można, da się
zautomatyzować".

Quote:
To jeszcze jeden:
UART0CTL = 1<<UART0_DOUBLE | 1<<UART0_REVERSE | 1<<UART1_FAST;
Ten kod ma buga. Nie do znalezienia oczami natychmiast. Użyto złej
flagi, od innego uarta. W czasach ludzi robiących #define UART0_FOO 7
to jest poważny problem.
Mogę ten kod napisać sprytnie.
O, czyli może jednak będzie konstruktywnie.

Już było, tylko jesteś niepełnosprytny.

Quote:
No to dajesz.

A ile płacisz?

Piotrek
Guest

Thu Nov 18, 2021 6:41 pm   



On 18.11.2021 18:12, heby wrote:
Quote:
[...]
Są miejsca, gdzie takie gówno oparte o goto wyleciało by z hukiem na
review razem z autorem tego szamba. Choć zdaje sobie też sprawę, że w
grupach 60+ to może być coding standard.


Nie to, żebym się obruszył o 60+ ...

Ale przecież styl projektowania/programowania nie zależy od wieku
autora. Tylko raczej od tego czy gość trafił do zawodu w wyniku
ostatniej łapanki przeprowadzonej w środowisku piekarzy, czy też w
bardziej cywilizowany sposób.

Piotrek

heby
Guest

Thu Nov 18, 2021 6:45 pm   



On 18/11/2021 18:41, Piotrek wrote:
Quote:
Są miejsca, gdzie takie gówno oparte o goto wyleciało by z hukiem na
review razem z autorem tego szamba. Choć zdaje sobie też sprawę, że w
grupach 60+ to może być coding standard.
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.

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.

Mateusz Viste
Guest

Thu Nov 18, 2021 7:19 pm   



2021-11-18 o 18:38 +0100, heby napisał:
Quote:
Zmniejszyłem je. Z wielu miejsc usunąłem.

Za pomocą tego magicznego guard? Wmówiłeś to sobie, uprawiasz tylko
kreatywną księgowość.

Quote:
Ale jest rozległy. I co teraz? Oferujesz "gapmiy się bardziej
wnikliwie". Ja oferuje "upewnijmy się, że to co można, da się
zautomatyzować".

Ale ja przecież nie proponuję gapienia się. Objaśniam tylko, że to co
starasz się wypromować jako "argument za C++ w embedded" wcale nie
potrzebuje C++.

Quote:
No to dajesz.

A ile płacisz?

Czyli ta łatwość usuwania białka C++ w ramach flag wymaga założenia
projektu i zainwestowania roboczogodzin? No to ja dziękuję za taki
postęp. Jak ma być skomplikowanie to równie dobrze w C mogę sobie
złożyć system do sprytnego zarządzania flagami.

Mateusz

heby
Guest

Thu Nov 18, 2021 7:40 pm   



On 18/11/2021 19:19, Mateusz Viste wrote:
Quote:
2021-11-18 o 18:38 +0100, heby napisał:
Zmniejszyłem je. Z wielu miejsc usunąłem.

Za pomocą tego magicznego guard?

Tak. Wyeliminował wszystkie źrodła błedu "zapomniałem włączyć" teraz i w
przyszłosci, z tej funkcji.

Oczywiście można go usunąć przypadkiem. Można wiele rzeczy zrobić, to
tylko białko. Idę o zakłąd że ilosc takich przypadków będzie o rząd
wielkosci mniejsza, niż przypadków "zapomniałem gdzieś zawołać goto w 30
miejscach".

Quote:
Wmówiłeś to sobie, uprawiasz tylko
kreatywną księgowość.

Dziwnym trafem ta "kreatywna księgowość" jest powszechnie używanym
wzorcem projektowym w całym C++, dając zaskakująco wysoki poziom
bezpieczeństwa transakcji.

Podpowiem kilka generyków: std::mutex::scoped_lock, boost::scoped_ptr,
boost::scoped_array itd.

Każdy da się napisać na goto. I wylecieć kopniakiem za drzwi, bo to nie
lata 60te.

Quote:
Ale jest rozległy. I co teraz? Oferujesz "gapmiy się bardziej
wnikliwie". Ja oferuje "upewnijmy się, że to co można, da się
zautomatyzować".
Ale ja przecież nie proponuję gapienia się.

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.

Quote:
Objaśniam tylko, że to co
starasz się wypromować jako "argument za C++ w embedded" wcale nie
potrzebuje C++.

Zrobiłeś jakiś mechanizm działajacy w podobny sposob na poziomie *tego*
konkretnie przypadku. Po refaktoringu środka funkcji, ja nie 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. Innymi słowy mój
zysk to bezpieczeństwo refaktoringu tej funkcji, bezpieczeństwo jej
pisania i przejrzystośc kodu.

Wiec albo chcesz mieć szambo, jak proponujesz, albo automatyzację. I
tak, nie da się tego zrobic w C. Można tylko napisać identyczny przykład
i wymachiwać "nie ma żadnej różnicy". Ona jest, nie widzisz jej, bo nie
piszesz nic więcej niż miganie diodą i nigdy nie przyszło Ci do głowy że
ktoś będzie tą funkcję zmieniał, w czasie jej życia, 100 razy.

Quote:
A ile płacisz?
Czyli ta łatwość usuwania białka C++ w ramach flag wymaga założenia
projektu i zainwestowania roboczogodzin?

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.

Niejaki Mateusz, za każdym razem jak robi UART= płaci na nowo koszta
potencjalnych bugów, w kółko używając technik z epoki kamiennej do
podwyższania jakości kodu, czyli cichej modlitwy, że się nie pomylił.

Przykro mi, że kod nie jest za darmo. Jestem znudzony edukowaniem za
friko każdego, kto jest za wielkim ignorantem, aby zrobic to samodzielnie.

Quote:
No to ja dziękuję za taki
postęp.

Nie pojmujesz nawet tego, że ten kod da się napisać generycznie i używać
gdzie chcesz, *zmniejszajac* koszty błedów.

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

Quote:
Jak ma być skomplikowanie to równie dobrze w C mogę sobie
złożyć system do sprytnego zarządzania flagami.

To złóż i pochwal się. Ale nie zapłacę za niego z prostej przyczyny: nie
będzie mieć śladu zalet względem statycznych checków C++. Wiem to
dlatego, że widziałem ich na pęczki. Każdy gówno wart.

A najbardziej zabawne, że to dopiero początek tego, co C++ pozwala
zrobić dobrego w kodzie embedded, a Ty już nie pojmujesz gdzie zalety,
bo ci assembler przesłania.

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