Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

[ATmega][C/C++] Programowanie obiektowe, inne kompilatory

Piotr_pp 08 Cze 2010 12:09 7414 60
  • #31 08 Cze 2010 12:09
    utak3r
    Poziom 25  

    "W pewnych przypadkach" to można wszystko i długo moglibyśmy tu rozmawiać :) Zawsze znajdzie się taka sytuacja, że możliwe będzie zastosowanie nieszablonowego podejścia - włącznie z bezobsługową obsługą ;) i zwalnianiem flagi przerwania w pętli głównej.

    Niemniej, warto pamiętać o naczelnej zasadzie, którą powinni kierować się, przypominam, początkujący: obsługa przerwania powinna być jak najkrótsza. Inaczej potem widzimy, jak niektórzy robią obsługę przerwania trwającą setki milisekund, złożone głównie z... __delay(x). Oczywiście - czasami można sobie na to pozwolić - ale nie początkujący, którzy nie widzą żadnego w tym problemu ;)

    Dodano po 2 [minuty]:

    To trochę tak, jak w sąsiednim wątku... najpierw nauczmy się używać narzędzi standardowo i poznać je dogłębnie - a dopiero potem uczmy się kombinować - a nie odwrotnie.

  • #32 08 Cze 2010 12:39
    tmf
    Moderator Mikrokontrolery Projektowanie
  • #33 08 Cze 2010 14:43
    gaskoin
    Poziom 38  

    tmf napisał:
    Zresztą jeśli ktoś jest zainteresowany to chętnie wrzucę tu swoje przykłady klas obsługujących przerwania w C++.


    a wrzuć

  • #34 08 Cze 2010 15:49
    PO.
    Poziom 20  

    mirekk36 napisał:


    tmf napisał:
    ...., podałem mu dwa przykłady prostych, jednolinijkowych makr, których wynik działania miał podać. W 100% podał błędny. Utwierdzanie kogoś takiego, że makra są super to jak danie 2 latkowi pistoletu.


    hyhyhyhy "przykłady" dobre sobie, ktoś kto nigdy nie doczytał dokładnie na temat działania preprocesora, zawsze tak samo odpowie na te twoje "przykłady" - a autor wątku właśnie zaczyna od tyłu (stąd jego odpowiedź taka a nie inna) - ale fakt , ty z kolei tłumaczysz mu od tyłu. Twoje zachowanie jest mniej więcej takie jakbyś dziecku w 2 klasie szkoły podstawowej zadał pytanie jak się liczy całki i z lubością byś się cieszył, że dziecko tego nie wie...... za to ciebie duma rozpiera.



    No nie, czuję się "pojechany" przez wszystkie strony sporu... Dużo sobie "dopowiedzieliście" do tego co pisałem i jak pisałem. Mogłoby nie chodzić o mnie normalnie... Więcej we właściwym wątku.

    Flaga ma zawsze stan 0/"nie zero" (w domyśle 1). Sprzętowa realizacja na bicie, programowa dowolnie duża pod warunkiem powyższego. Wszystko co przyjmuje więcej stanów to index, licznik itp w zależności od zastosowania i fantazji programisty ;) ale nie flaga.

    Flaga programowa w przerwaniu ma sens pod warunkiem, że jeszcze się coś w przerwaniu dzieje i flaga wskazuje że coś dodatkowo zrobiliśmy. Inaczej możemy pominąć przerwanie i sprawdzać sobie flagę sprzętową w programie. Co nie jest głupie jeśli mamy np duże obliczenia niekrytyczne czasowo.

  • #35 08 Cze 2010 16:01
    utak3r
    Poziom 25  

    PO. napisał:
    Flaga programowa w przerwaniu ma sens pod warunkiem, że jeszcze się coś w przerwaniu dzieje i flaga wskazuje że coś dodatkowo zrobiliśmy. Inaczej możemy pominąć przerwanie i sprawdzać sobie flagę sprzętową w programie. Co nie jest głupie jeśli mamy np duże obliczenia niekrytyczne czasowo.


    A widzisz, nie doczytałeś mojego wyjaśnienia, kiedy będzie to nie do przyjęcia :) Co, jeśli pętla główna zwyczajnie "nie wyłapie" zdarzenia? Bo nie zdąży?

  • #36 08 Cze 2010 16:10
    PO.
    Poziom 20  

    utak3r napisał:
    PO. napisał:
    Flaga programowa w przerwaniu ma sens pod warunkiem, że jeszcze się coś w przerwaniu dzieje i flaga wskazuje że coś dodatkowo zrobiliśmy. Inaczej możemy pominąć przerwanie i sprawdzać sobie flagę sprzętową w programie. Co nie jest głupie jeśli mamy np duże obliczenia niekrytyczne czasowo.


    A widzisz, nie doczytałeś mojego wyjaśnienia, kiedy będzie to nie do przyjęcia :) Co, jeśli pętla główna zwyczajnie "nie wyłapie" zdarzenia? Bo nie zdąży?


    Doczytałem ale uzupełniam :) . Zwracam uwagę na słówko "niekrytyczne" - i proszę go błędnie nie interpretować, pętla wyłapie. A jeśli nie wyłapie to znaczy że jednak było krytyczne i trzeba myśleć jak się programuje ;) .
    Tak samo z delayami, potrafię sobie wyobrazić sytuację kiedy ich rozsądnie i bezpiecznie użyć - ale to przypadek jeden na milion więc nie ciągnijmy tematu ;) bo jeszcze ktoś źle zrozumie, zastosuje i mu przeze mnie program poleci...

  • #37 08 Cze 2010 16:23
    tmf
    Moderator Mikrokontrolery Projektowanie

    utak3r napisał:
    PO. napisał:
    Flaga programowa w przerwaniu ma sens pod warunkiem, że jeszcze się coś w przerwaniu dzieje i flaga wskazuje że coś dodatkowo zrobiliśmy. Inaczej możemy pominąć przerwanie i sprawdzać sobie flagę sprzętową w programie. Co nie jest głupie jeśli mamy np duże obliczenia niekrytyczne czasowo.


    A widzisz, nie doczytałeś mojego wyjaśnienia, kiedy będzie to nie do przyjęcia :) Co, jeśli pętla główna zwyczajnie "nie wyłapie" zdarzenia? Bo nie zdąży?


    Oj, a ty nie doczytałeś mojego :) Jeśli to jest flaga sprzętowa (sygnalizująca zajście sytuacji wywołującej przerwanie) to pętla zawsze ten fakt wyłapie, tak samo skutecznie jakby to była flaga ustawiana w przerwaniu. A korzyść z tego taka, że a) nie tracimy miejsca na dodatkową i zbędną flagę, b) nie tracimy czasu na jej zmianę i samo wywołanie przerwania. Także PO. pisząc "Flaga programowa w przerwaniu ma sens pod warunkiem, że jeszcze się coś w przerwaniu dzieje i flaga wskazuje że coś dodatkowo zrobiliśmy. Inaczej możemy pominąć przerwanie i sprawdzać sobie flagę sprzętową w programie." ma 100% racji.

  • #38 08 Cze 2010 19:50
    utak3r
    Poziom 25  

    A jednak... takie małe zwątpienie: jeśli wystąpi przerwanie i nikt nie wyzeruje flagi, a nastąpi to dopiero po iluś tam milisekundach - utracimy ileś tam ewentualnych następnych wystąpień - które już nie nastąpią, czyż nie?

  • #39 08 Cze 2010 20:13
    PO.
    Poziom 20  

    A po co mają występować skoro flaga jest na 1 i tylko raz wszystkie obsługujemy :) ? W ogóle to nie "wystąpień" chyba :P bo ich nie obsługujemy osobną obsługą przerwania.
    To tak praktycznie, bo cały czas się rozbija o krytyczność.

    Myślałem raczej że chodzi Ci o sprawdzenie dopiero w następnym obiegu pętli, gdy po sprawdzeniu jest coś ważnego względem tego przerwania czego pętla już nie wyłapie.

    PS: gwoli formalności ;) to jak obsługujemy w głównej pętli to to już nie jest "przerwanie" bo nie przerywamy :P . Ale nie zmieniajmy nazewnictwa teraz bo się pogubimy.

  • #40 08 Cze 2010 20:31
    utak3r
    Poziom 25  

    Ok, żeby była jasność, o czym mówię:
    Robimy np. prędkościomierz, czyli inaczej mówiąc: częstotliwościomierz. Obliczanie wyniku na podstawie danych i wyświetlanie tego wyniku to sprawa drugorzędna i można to robić nawet raz na sekundę. ALE musimy mieć dokładną ilość impulsów. Impuls wyzwala przerwanie. Jeżeli nie wyzerujemy flagi najszybciej, jak się da, zgubimy impulsy i wynik będzie zafałszowany. Typowe zadanie do realizacji tego dokładnie tak, jak napisałem: w przerwaniu, wywołanym impulsem, zwiększamy licznik wystąpień, natomiast obliczenia i wyświetlanie, które zajmuje nieco czasu (sama obsługa LCD to kilka milisekund, do tego jakieś mnożenia, dzielenia itp.) wykonujemy w pętli głównej z jakimś tam opóźnieniem.

  • #41 08 Cze 2010 20:54
    Freddie Chopin
    Specjalista - Mikrokontrolery

    tmf napisał:
    A w przypadku UARTa można ładnie enkapsulować dane, np. program nic nie musi wiedzieć o buforowaniu, obsłudze itd. Wysyła coś na UART, klasa sobie to kolejkuje, w przerwaniach wysyła kolejne bajty. Aplikacja dostaje tylko potwierdzenie (jeśli chce), że cała paczka została wysłana. Zresztą jeśli ktoś jest zainteresowany to chętnie wrzucę tu swoje przykłady klas obsługujących przerwania w C++.

    Ja również byłbym zainteresowany

    4\/3!!

  • #42 08 Cze 2010 21:09
    PO.
    Poziom 20  

    utak3r napisał:
    Ok, żeby była jasność, o czym mówię:
    Robimy np. prędkościomierz, czyli inaczej mówiąc: częstotliwościomierz. Obliczanie wyniku na podstawie danych i wyświetlanie tego wyniku to sprawa drugorzędna i można to robić nawet raz na sekundę. ALE musimy mieć dokładną ilość impulsów. Impuls wyzwala przerwanie. Jeżeli nie wyzerujemy flagi najszybciej, jak się da, zgubimy impulsy i wynik będzie zafałszowany. Typowe zadanie do realizacji tego dokładnie tak, jak napisałem: w przerwaniu, wywołanym impulsem, zwiększamy licznik wystąpień, natomiast obliczenia i wyświetlanie, które zajmuje nieco czasu (sama obsługa LCD to kilka milisekund, do tego jakieś mnożenia, dzielenia itp.) wykonujemy w pętli głównej z jakimś tam opóźnieniem.


    To już jest kluczowe czasowo właśnie :) . I robisz tak jak opisałeś, z dodatkową flagą softwarową do obliczeń albo bez.
    Albo druga opcja nie licznik tylko w przerwaniu obsługa timerem czasu między przerwaniami (zapisanie stanu, zerowanie) - obliczenia też w pętli głównej oczywiście. Nie wiem tak na szybko co będzie dokładniejsze / mniej obciążające dla kodu.

  • #43 08 Cze 2010 21:15
    utak3r
    Poziom 25  

    Zależy, co rozumiesz pod pojęciem "krytyczne czasowo" ;) Ale ok, dajmy spokój.

    A co do przykładu, imho najdokładniejsze będzie coś pomiędzy - przerwanie i licznik wystąpień plus timer odmierzający np. sekundy i ustawiający flagę zakończenia pełnej sekundy. Wtedy w pętli głównej obliczenia i zerowanie flagi pełnej sekundy (w tle cały czas impulsy się zliczają).

  • #44 08 Cze 2010 21:21
    PO.
    Poziom 20  

    PO. napisał:
    A jeśli nie wyłapie to znaczy że jednak było krytyczne i trzeba myśleć jak się programuje ;) .

    Rozumiem powyższe - nic nie zastępuje myślenia.
    Dokładność i konkretne rozwiązanie zależy od zakresu nawet. Zostawmy teoretyzowanie.

  • #45 08 Cze 2010 21:53
    atom1477
    Poziom 43  

    mirekk36 napisał:
    hyhyhyhy "przykłady" dobre sobie, ktoś kto nigdy nie doczytał dokładnie na temat działania preprocesora, zawsze tak samo odpowie na te twoje "przykłady"


    No to wyobraź sobie że ja nigdy o preprocesorze nie czytałem. A chyba odpowiedziałem dobrze.

  • #46 08 Cze 2010 22:41
    mirekk36
    Poziom 42  

    atom1477 napisał:

    No to wyobraź sobie że ja nigdy o preprocesorze nie czytałem. A chyba odpowiedziałem dobrze.


    Zgadłeś? ;) to gratuluję - powinieneś grać w totolotka ;) chociaż w tym przypadku prawdopodobieństwo wygrania było o wiele większe niż w toto - bo tylko 1:2

  • #47 08 Cze 2010 22:59
    atom1477
    Poziom 43  

    Nie. Po prostu słyszałem że makro to zwykłe kopiuj/wklej.
    No więc wkleiłem zawartość „wywołania makra” do makra, wyszło że pojawiło się mnożenie pomiędzy plusami i takie tam, więc policzyłem zgodnie z kolejnością działań i wyszło.
    A co do totolotka: skąd wiesz że już nie gram? :D

  • #48 08 Cze 2010 23:02
    tmf
    Moderator Mikrokontrolery Projektowanie

    utak3r napisał:
    Ok, żeby była jasność, o czym mówię:
    Robimy np. prędkościomierz, czyli inaczej mówiąc: częstotliwościomierz. Obliczanie wyniku na podstawie danych i wyświetlanie tego wyniku to sprawa drugorzędna i można to robić nawet raz na sekundę. ALE musimy mieć dokładną ilość impulsów. Impuls wyzwala przerwanie. Jeżeli nie wyzerujemy flagi najszybciej, jak się da, zgubimy impulsy i wynik będzie zafałszowany. Typowe zadanie do realizacji tego dokładnie tak, jak napisałem: w przerwaniu, wywołanym impulsem, zwiększamy licznik wystąpień, natomiast obliczenia i wyświetlanie, które zajmuje nieco czasu (sama obsługa LCD to kilka milisekund, do tego jakieś mnożenia, dzielenia itp.) wykonujemy w pętli głównej z jakimś tam opóźnieniem.


    Ale tu znowu wracamy nieco do semantyki i naszej definicji flagi, co do której jak sądzę większość już się zgodziła. W przypadku, który opisujesz nic nam nie da, że ustawimy flagę w procedurze obsługi przerwania, jeśli w pętli głównej, na zasadzie klasycznego poolingu nie będziemy odpowiednio szybko na tą flagę reagować. W efekcie też zgubimy impulsy, tak jakbyśmy w ogóle nie korzystali z przerwań. W tym wypadku trzebaby w ogóle zrezygnować z flag, a zastosować licznik zmieniany w przerwaniu, który nam powie ile tych przerwań było od ostatniego razu, kiedy to sprawdzaliśmy. Flaga staje się niepotrzebna, bo sama zmiana stanu licznika jest informacją, że coś się stało i w programie musimy się tym zainteresować.

  • #49 08 Cze 2010 23:10
    atom1477
    Poziom 43  

    Dokładnie tak.
    Flagę sprzętową, np. w rejestrze EIFR, tak samo można kasować programowo.
    Więc stosując flagę programową nic nie zyskujemy. Tracimy za to czas na obsługę przerwania (mały, ale zawsze te kilka cykli) oraz kilka B Flasha.
    A to co napisałeś, o zwiększaniu licznika wystąpień, to już nie jest flaga. Licznik to nie flaga.

  • #50 08 Cze 2010 23:27
    mirekk36
    Poziom 42  

    atom1477 napisał:

    Flagę sprzętową, np. w rejestrze EIFR, tak samo można kasować programowo.
    Więc stosując flagę programową nic nie zyskujemy. Tracimy za to czas na obsługę przerwania (mały, ale zawsze te kilka cykli) oraz kilka B Flasha.


    No ale tłumaczenie takich rzeczy to troszkę jak tłumaczenie komuś, że 2 x 2 to równa się 4. Wątpię, żeby ktokolwiek z opowiadających tu o flagach używał np Timera tylko po to, żeby ustawić w nim flagę programową i przekazać jej wartość sprawdzać w pętli głównej - toż to normalne - że bez sensu.

    Ale jeśli już w przerwaniu Timera ogranizuję sobie np "tyknięcia systemowe" dla timerów programowych albo np w przerwaniu Timera robię obsługę multipleksowanego LED a przy okazji ustawiam jakąś flagę programową żeby np co sekundę sprawdzać stan DS18B20 to - chyba normalne i oczywiste wykorzystanie takiej flagi programowej. Nie trzeba zaraz obsługi DS'a pakować do przerwania.

  • #51 08 Cze 2010 23:28
    tmf
    Moderator Mikrokontrolery Projektowanie

    Wracając do przerwań, zgodnie z obietnicą wrzucam przykładowe definicje interfejsu klas opartych na przerwaniach. Pierwsza obsługuje timer i umożliwia wywoływanie z opóźnieniem lub cyklicznie podanej funkcji, lub wywoływanie jakiejś akcji:

    Code:

        1 #ifndef _TMFTIMER_H
        2 #define _TMFTIMER_H
        3
        4 #include <stdint.h>
        5
        6 #ifdef __AVR__
        7 #include <avr/io.h>
        8 #endif
        9
       10 #include <singleton.h>
       11 #include <TMFObjects.h>
       12
       13 #ifdef __AVR__
       14 extern "C" void TIMER0_COMP_vect(void) __attribute__ ((signal));
       15 #else
       16 extern "C" void TIMER0_COMP_vect(void);
       17 #endif
       18
       19 struct TimeMark
       20 {
       21    uint16_t Timer : 15;         //Timer event counter
       22    uint16_t Type  : 1;            //Indicates if it is single or periodic event
       23    uint16_t Period :15;         //Period for periodical events
       24 };
       25
       26 struct EventList
       27  {
       28     EventList(TMFObject *atowhom, TimeMark aInterval);
       29
       30    TMFObject *towhom;            //Object to which send timer event
       31    TimeMark Interval;            //Timer event interval
       32    EventList *Next;
       33  };
       34
       35 class EventTimer
       36 {
       37    friend void TIMER0_COMP_vect();
       38
       39    private:
       40     static EventList *FL;                  //List of functions which will be executed
       41     static volatile uint16_t Counter;         //Counts 1ms intervals
       42
       43    public:
       44     enum EventType{Single_Event=1, Periodic_Event=0};
       45
       46     EventTimer();
       47     static void *AddEvent(TMFObject *towhom, uint16_t interval, EventType type);   //Add function that will be executed every interval time




       48     static void PostProneEvent(void *TimerID, uint16_t interval);      //Postprone given event by indicated numer ob time intervals
       49     static void DelEvent(void *TimerID);                        //Delete function from seduler list
       50
       51    private:
       52     inline static void EventTimerInterrupt();
       53 };
       54
       55 typedef Singleton<EventTimer> ETimer;
       56
       57 #endif


    Dodatkowo, żeby uniknąć sytuacji, kiedy przypadkowo programista stworzy kilka instancji, co oczywiście byłoby błędem, bo timer się nie rozmnoży, klasa zabezpieczona jest singletonem.

    Drugi przykład to interfejs do ADC:
    Code:

        1 #ifndef _ADC_H
        2
        3 #include <avr/io.h>
        4 #include <Common/singleton.h>
        5 #include <Common/bitoperators.h>
        6
        7
        8 #ifndef ADC_MAX_ADCNO                  //Number of ADC on chip
        9 #define ADC_MAX_ADCNO 8
       10 #endif
       11
       12 #ifndef ADC_DEFAULT_CLOCK               //Default ADC clock [kHz]
       13 #define ADC_DEFAULT_CLOCK   100
       14 #endif
       15
       16 #ifndef ADC_INTEGRATIONNO               //How many samples should be integrated
       17 #define ADC_INTEGRATIONNO   16            //16 is maximum for 10-bit resolution
       18 #endif
       19
       20 extern "C" void SIG_ADC(void) __attribute__ ((signal));
       21
       22 class ADCHandler
       23 {
       24     friend void SIG_ADC();
       25
       26    private:
       27     static uint16_t values[ADC_MAX_ADCNO];   //Storage place for ADC values
       28     static BitArray<ADC_MAX_ADCNO> mask;   //Mask of active ADC, 1 - active, 0 - disabled
       29     volatile static uint8_t MUXStatus;      //Used internally by ADC interrupt routine
       30
       31    public:
       32     enum ADCRef {AREF=0, AVCC=_BV(REFS0), Internal=(_BV(REFS1) | _BV(REFS0))};
       33     enum Errors {ErrADC=0xFFFF};         //If GetADCValue returns ErrADC it means that something is wrong
       34     enum ADCLevels {ADC_HIGHTRESHOLD=800};   //If ADC value is above treshold we assume that appropiate ADC channel is opened
       35
       36    public:
       37     ADCHandler();
       38     ~ADCHandler();
       39
       40     void SetADCClock(uint16_t clk);            //Set ADC clock [kHz]
       41     void EnableADC(uint8_t ADCNo, bool en);      //Enable or disable specified ADC converter
       42     bool isADCEnabled(uint8_t ADCNo) {return mask[ADCNo];};   //Return ADC channel status
       43     void EnableFreeRunningMode(bool en);         //Enable or disable (false) ADC free running mode
       44     void SetRefSource(ADCRef ref);               //Set source of reference voltage
       45     uint16_t GetADCValue(uint8_t ADCNo);         //Return ADC value, 12-bit value is returned - 2LSB bits are typically not significant
       46     bool TestIfADCInputIsOpen(uint8_t ADCNo);      //Return true if nothing is connected toADC channel
       47
       48    private:
       49     inline static void ADCInterrupt();            //This routine is evoked in ADC interrupt handler. Because strange C++ names mangle
       50                                         //it's evoked in c wrapper function, so it's better to keep it as inline function
       51                                        //so we can avoid one unnecessary CALL instruction and possibly better
       52                                        //register optimalization.
       53 };
       54
       55 typedef Singleton<ADCHandler> ADClass;
       56
       57 #endif

    Analogicznie klasa jest singletonem, bo ADC w AVR jest tylko jeden. Tu dodatkowo wykorzystałem class templates - i dla singletonu i dla klasy operującej na bitach. Ilość kanałów ADC waha się w AVR od 4 do 16, więc żeby nie tracić niepotrzebnie miejsca w RAM na przechowywanie zawsze 16 bitów, mimo, że np. 8 wystarczy, stworzyłem szablon klasy realizujący dostęp do bitów o zmiennej długości - zajmuje dokładnie tyle bajtów ile trzeba i ani jednego więcej.
    Pytanie brzmi co mi z tego, że mam to w C++. Ano jak widać mamy piękną enkapsulację, dla programisty dostępny jest prosty i stały, niezależny od procesora interfejs dający dostęp do ADC. C++ daje też możliwość kontroli dostępu do danych - więc przypadkowo nie nabruździmy mieszając w wewnętrznych strukturach obiektu, bo są zabezpieczone przez private/protected. Upchnięcie tego w klasę powoduje też że w programie dostęp do zasobów odbywa się wyłącznie poprzez metody klasy EventTimer i ADCHandler, czyli przeportowanie aplikacji na inny procesor staje się łatwiejsze bo wiadomo co gdzie jest.
    Niestety ponieważ C++ dziwnie mangluje nazwy, a AVR-libc nie jest do tego dostosowane trzeba stosować wrappery w C, ale poza efektem kosmetycznym nie ma to żadnych konsekwencji - optymalizator wywala wrappera, lub jak to woli inlinuje handlera przerwania z klasy (inline static) do wrappera, dzięki czemu nie są wykonywane żadne zbędne skoki i wywołania. Hardcorowcy mogą oczywiście zdefiniować właściwy handler, tak, żeby miał zmanglowaną nazwę, ale to sztuka dla sztuki.

  • #52 09 Cze 2010 01:27
    rpal
    Poziom 27  

    kol. autorze myślę że dobrze się bawisz czytając posty od własnego tematu które sa generalnie nie na temat. Jak masz bajzel w zmiennych globalnych a chesz je jakoś ująć w kupę to bez odwoływania się do obiektów wpakuj je w jedną strukturę i będziesz je miał z grubsza pod kontrolą, w jednym zgrabnym "agregacie" :)

  • #53 09 Cze 2010 17:37
    MinisterQ
    Poziom 18  

    tmf napisał:


    Może sobie nawet cały dysk zapełnić, nie zmienia to faktu, że flaga przechowuje wartość 1 lub 0, tak lub nie. Wrzucenie tego do całego bajtu nie zmienia prostego faktu, że ilość informacji ciągle wynosi 1 bit i w związku z tym jest to flaga.


    A widziałeś kiedyś reprezentację boolean która w pamięci operacyjnej zajmuje 1 bit?
    A wedle Twojej skromnej definicji boolean może być używany jako flaga, ponieważ wedle standardu może przyjmować jedynie wartości "tak" lub "nie" (true/false).
    Więc jak to w końcu z tymi flagami jest? ;)

  • #54 09 Cze 2010 17:44
    atom1477
    Poziom 43  

    MinisterQ: sam sobie zaprzeczasz.
    Tmf przecież napisał dobrze.
    Przecież napisał że flagę która z definicji jest bitem zwykle ładuje się do całego bajtu.
    I tym bardziej Boolean może być wykorzystywany jako flaga.

  • #55 09 Cze 2010 17:47
    MinisterQ
    Poziom 18  

    atom1477 napisał:
    MinisterQ: sam sobie zaprzeczasz.
    Tmf przecież napisał dobrze.


    Odnosiłem się do postów, w których tmf twierdził że "Flaga to pole bitowe, a nie licznik, zmienna itd".
    boolean można nazwać wszystkim, włącznie z flagą, ale polem bitowym? Wedle ścisłej definicji? ;)
    Ale mniejsza o to, spory semantyczne mnie nie bawią, EOT z mojej strony.

  • #56 09 Cze 2010 18:38
    tmf
    Moderator Mikrokontrolery Projektowanie

    Jeśli cie nie bawią to po co zabierasz głos?
    A coś takiego:

    Code:

    struct flagi
    {
      uint8_t f0 : 1;
      uint8_t f1 : 1;
      uint8_t f2 : 1;
     itd
    };


    to jak nazwiesz? Nie sa to flagi będące polami bitowymi, w dodatku zajmujące w pamięci dokładnie jeden bit?

  • #57 09 Cze 2010 18:46
    MinisterQ
    Poziom 18  

    tmf napisał:
    Jeśli cie nie bawią to po co zabierasz głos?


    By Ci dać do zrozumienia że taki puryzm w odniesieniu do niektórych pojęć w zakresie informatyki jest po prostu głupi, i jednocześnie bardzo zależny od kontekstu konkretnego programu.

  • #58 09 Cze 2010 19:05
    tmf
    Moderator Mikrokontrolery Projektowanie
  • #59 09 Cze 2010 19:35
    utak3r
    Poziom 25  

    Błagam, daj już spokój z nazewnictwem, godnym wypracowań akademickich...
    Napisałeś kiedyś, że przecież w MSDNie nie ma tego czy tamtego. Wiesz dlaczego? Dlatego, co i ja Ci napisałem wówczas: bo pisząc oficjalna dokumentację, są zobowiązani pisać tak a nie inaczej. Natomiast w mowie potocznej używa się różnych określeń - nie zawsze ścisłych i nie zawsze z punktu widzenia teorii prawidłowych.
    A my tutaj, wydawać by się mogło, jesteśmy społecznością nie-akademicką... dlatego dajmy już nareszcie spokój wypowiedziom w tym stylu jak powyżej.

    Grunt, że tak naprawdę się rozumiemy - co przecież dalsze dyskusje wykazały, prawda? Nie róbmy z siebie bufonów. Normalnie aż mi się przypominają wykłady - a już zdążyłem o nich na szczęście zapomnieć po latach.

    A'propos wykładów... na zajęciach z asemblera poprosiliśmy wykładowcę, żebyśmy porozmawiali o grafice - wydawało nam się, że to naturalny temat ;) Niestety, wykładowca stwierdził, że ten temat kompletnie nie nadaje się na rozmowy o asemblerze. Więc co robiliśmy? Otwieraliśmy pliki i pisaliśmy do nich, przy użyciu int21h. Ot... to takie króciutkie streszczenie na temat wykładowców akademickich, które niestety jest prawdziwe na każdym kroku. Z malutkimi tylko wyjątkami. Tak małymi, że kiedy szedłem na uczelnię, miałem w planach zostać na uczelni i zająć się pracą naukową - cholernie szybko mi przeszło :| i teraz się cieszę, że nie popełniłem tego błędu. Co innego, gdybym studiował na MIT ;)

  • #60 09 Cze 2010 19:54
    tmf
    Moderator Mikrokontrolery Projektowanie

    Ja rozumiem, że dla niektórych ścisłe pojęcia i definicje wydają się byc nieistotnym szczegółem. Natomiast wyobraźmy sobie co by było, gdyby autorzy MSDNa też tak luźno podchodzili do definicji i flagi nazywali licznikami, wątki procesami itd. Czy taki manual byłby do czegoś przydatny? Jeśli podobnie jak ja uważasz, że nie to powiedz mi dlaczego normalnie nie mielibyśmy posługiwać się poprawnym językiem?
    Z drugiej strony wywołałeś dyskusję nie na temat, bo MinisterQ zadał mi pytanie "A widziałeś kiedyś reprezentację boolean która w pamięci operacyjnej zajmuje 1 bit? " - pokazałem mu jedną z możliwych reprezentacji w której boolean zajmuje 1 bit. Zarzucił mi, że flagi nie można nazwać polem bitowym - analogicznie, ma przykład w którym flaga jest polem bitowym... I tylko o to chodziło.

  Szukaj w 5mln produktów