On 2013-10-10 20:07, JDX wrote:
>> Odróżniasz idiom RAII od kodu natywnego, prawda?
> Ale o co chodzi? Co ma RAII do kodu natywnego? W każdym razie chodziło
> mi jedynie o to, że cli() i sei() to nie są funkcje standardowe C czy
> też C++.

Wyobraź sobie że napiszę ten sam example bez cli/sei. Co on niby miałby
ilustrować? Sam idiom RAII nie jest przydatny, jego konkretna
implementacja już jest.

>> 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.
> No to przecież sam pokazałeś że w C obudowujemy czytanie w cli()/sei().

Ale musisz uzyć zmiennej tymczasowej i musisz *pamiętac* o sei. kod robi
się podatny na czynnik ludzki.

> A jeśli z jakiegoś powodu w tej samej funkcji potrzebujemy przeczytać
> zasób jeszcze raz, no to jeszcze raz obudujemy operację czytania. Zdaję
> sobie sprawę, że kod się komplikuje i tym samym jest bardziej podatny na
> błędy, ale w sam raz IMO w tak, nomen omen, krytycznych przypadkach jak
> CS lepiej jest sterować ręcznie a nie zdawać się na automatykę.

Dlaczego lepiej zdawać się na czlowieka a nie na automatyke absurdalnie
automatycznej rzeczy? RAII to mechanizm który obecnie jest testowany
biliony razy na sekundę na calym swiecie na wszystkich architekturach i
działa. Dlaczego miałby tu być problematyczny? Znam tylko jeden powód:
gównanie kompilatory na gówniane architektury (PIC < 32).

>> Destruktor nie "czeka" tylko wołany jest natychmiast po return.
>> Dokładnie tak jak chcę.
> Zakładając, że pomiędzy odczytaniem z chronionego zasoby a returnem nie
> ma znaczącego (w sensie czasu wykonania) kodu.

A skąd on miałby się tam wziąść? Nawej najgorsze kompilatory C++ nie
będą robiły zadnego obiektu sc. On nie istnieje w kodzie wynikowym,
zostaje po nim tylko sei w miejscach gdzie wychodzisz z funkcji. Puffff
i cała sekcja krytyczna, klasa, konstruktor itd zamienia się w dwie
instrukcje asm. To jest wlasnie ten moment którego programiści embedded
nie czają. Tam *nie* ma obiektu ani narzutu w kodzie. Kod jest taki sam
jak z C a bywa że lepszy.

>> 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.
> W każdym razie ja w podanym przykładzie jakoś nie widzę wyższości C++
> nad C. Zyskujesz większą odporność na błędy ale płacisz za to mniej
> precyzyjną kontrolą nad CS.

Jesli potrzebujesz precyzyjniejszej kontroli nad cs to mozna taką zrobić
bez rezygnacji z RAII.

> Nie twierdzę, że C++ jest gorsze od C w
> zastosowaniach embedded. Twierdzę jedynie, że przykład jest słaby.

Bo miał być jakikolwiek. Np. często liczę na szablonach rozmiary typów
co pozwala mi kod przenieść między różnymi procesorami. Często
specjalizuję generyczną funckję za pomocą obiektu co pozwala mi kod z uC
testować na PC używając mocków. Jest sporo zastosowań. Żadne nie ma nic
wspólnego z obiektowością.

>> 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.
> No nie wiem, mi w sam raz wystarczyłaby informacja, że to jest coś co ma
> być chronione za pomocą CS. Tak, abym nie musiał snuć domysłów. :-)

Przecież właśnie w tym kodzie to doskonale widać.