eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaAVR po latachRe: AVR po latach
  • Data: 2021-11-18 19:55:34
    Temat: Re: AVR po latach
    Od: Dawid Rutkowski <d...@w...pl> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    czwartek, 18 listopada 2021 o 17:22:57 UTC+1 heby napisał(a):
    > 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.

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

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

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

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

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

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: