On 2013-10-10 18:23, JDX wrote:
>> Na Microchipa nie. Na *dowolny* podam do znudzenia ten sam co zawsze:
> Dowolny? To cli() i sei() to są standardowe funkcje C++ (i C)? :-D

Odróżniasz idiom RAII od kodu natywnego, prawda?

> tak
> zaimplementowanej sekcji krytycznej IMO *nie jest* lepsze.

Zdefiniuj najlepsze.

> IMO lepsza
> jest "ręczna" kontrola nad CS ponieważ tak w ogólności to chcemy jak
> najszybciej odblokować przerwania

To nie jest prawda. Czasem chcemy mieć pewność że UART_D zostanie
odczytany jeszcze w sekcji krytycznej. Efektem czego jest workaround z
temp w C. Nie ma rozwiązań załatwiających wszystkie przypadki. To jest
rozwiązujące pewna sporą grupę czestych sytuacji w przerwaniach.

> a nie czekać do momentu wyjścia z
> funkcji gdy zawołany zostanie destruktor.

Destruktor nie "czeka" tylko wołany jest natychmiast po return.
Dokładnie tak jak chcę.

> No i IMO tak zaimplementowana
> CS może prowadzić do jeszcze większych i trudniejszych do wykrycia
> ooops-ów jeśli ktoś będzie tworzycł CS na początku jakiejś dużej funkcji.

Taki idiom daje znacznie wieksze gwarancje w dobrze zrobionym kodzie. W
kodzie napisanym byle jak czyli z wielkimi funkcjami - nic nie daje
gwarancji poza modlitwą. Subiektywnie patrząc: RAII genaruje mniej
błedów niż jego ręczna emulacja i miałem w życiu na to milion przykładów.

> A tak poza tym to niezbyt rozumiem zwracanie jakiejś wartości z funkcji
> typu void.

Pomyłka.

> No i przydało by sie też jakieś info na temat tego co to jest
> UART_D - domyślam się, że jest to jakiś rejestr zmieniany
> (asynchronicznie) przez moduł UART-ów.

To jest coś chronione przez sekcję krytyczna. Nie ma znaczenia co to
jest. Probolemem wielu programistów embedded jest wlasnie to że *musza*
wiedzieć co to jest, choć wiedza taka zazwyczaj kończy się pisaniem
nieprzenośnego kodu.