On 2012-05-02 14:52, Andrzej Ekiert wrote:
>> Ja rozumiem to jako podejście w stylu boost::mpl.
> Ładne. Ale szczerze mówiąc to nie bardzo widzę, jaki problem to
> rozwiązuje w przypadku programowania naszego 8-bitowca z 1kB kodu.

Powiedzmy - dopasowanie typu [char|short] licznika w czasie kompilacji.
Policzenie jaki typ nalezy wybrać dla zbioru flag. Policzenie stalej w
czasie kompilacji. Kompilacja warunkowa bez #define. Itd.

> Sprytne i fajnie pokazuje, jak działa destruktor. Ale ja bym po prostu
> napisał:
> cli();
> ... kod krytyczny
> sei();

teraz:

cli()
....
return
...
goto
...
break
...
sei();

I już po tobie. A po mnie nie.

> Lepiej widać w jednym miejscu co się dzieje, bez szukania definicji
> klasy CriticalSection, bez zastanawiania się gdzie jej obiekt wychodzi z
> zasięgu

Nie zastanawiasz sie. Na pewno wszystkie miejsca działają poprawnie. na
tym polega sztuczka. Możesz oderwać się od assemblera i skupić na
algorytmie. nadmierne przejmowanie się szczegółami uniemozliwia pisanie
czytelnego kodu.

>, no i bez ryzyka, że osoba, która nie jest autorem kodu nie
> zauważy, że wsród paru zmiennych lokalnych jest jakiś dziwny pozornie
> nieużywany obiekt.

Jesli "pozornie nieuzywan obiekt" nazywa się SekcjaKrytyczna i on tego
nie zauważy, to pozostawienie w tym miejscu makra, sei, cli nic nie
pomoże - przecież pozornie jest nieużywane. Trudno, nie mówimy tutaj o
programistach basica oddelegowanych do poprawiania C++.

> Ja tam wolę widzieć przebieg programu, a nie musieć ciągle pamiętać, że
> między ostatnią instrukcją funkcji, a '}' uruchomi się jeszcze seria
> niewidzialnych funkcji.

A więc dobrze podejrzewałem - jesteś assemblerowcem. Musisz wiedzieć co
sie dzieje bo nie ufasz kompilatorom. Ja natomiast odwrotnie. Znajduje
zdcecydowanie wiecej bugów we własnym kodzie niż w wygenerowanym przez
kompilator.

> Zresztą, akurat w mojej praktyce programowania
> małych uC potrzeba nietrywialnej destrukcji "obiektu" zachodzi bardzo
> rzadko.

Mam to za darmo. Używam. PICowcy mogą tylko obejśc się smakiem albo
ciągnąć tasiemcowe wywody dlaczego im to nie potrzebne.

>> Moje marzenie to PIC w sensie peryferiów i AVR w sensie rdzenia. Ale
>> sie nie doczekalem bo przyszły ARMy i pozamiatały.
> Architektura 16-bit Microchipa (PIC24, dsPIC33) to właśnie coś takiego.

Co takiego? Ślepą uliczkę sprzętowego stosu? Brak wsparcia poza żalosnym
kompilatorem producenta? Nawt MC sie puknął w czolo i zakopał to cudo
głęboko pod ziemią żeby już nie straszyło. Tylko że ARM jest już za tani
i za dobry.

> Bardzo elegancko zaprojektowana, przyjemnie się z tym pracuje - moim
> zdaniem dużo ładniejsza niż MIPS, którego użyli w PIC32, oraz niż ARM.

Dla mnie nie ma różnicy. Nie pisuje w assemblerze dla niepoznaki nazwanym C.

>> No chyba, że architektura PICów nie da się wmontować w backed gcc.
> gcc zostało przeniesione na architektury 16 i 32 bit. Jeśli chodzi o te
> 32 bit (rdzeń MIPS) to spodziewam się, że prędzej czy później kompilator
> C++ się pojawi.

Jasne. http://www.microchip.com/forums/m544964.aspx

> Do 16-bit też pewnie mogliby to w miarę tanio zrobić -
> mi zupełnie jednak na tym nie zależy.

Słusznie. Nie ma targetu.