On 2012-05-03 22:39, Jerry1111 wrote:
> No wlasnie ukryte jest wg mnie ciezej zdebugowac.

Po co debugować coś co na pewno działa? To troche jak argument klepaczy
w C: Wole nie używać std::vector bo cięzko debugować. A ja się pytam, po
co do cholery debugować *pewny* i *działajcy* kod? Bo może sie tam
trafić bug w kompilatorze? Wszędzie się może trafić. To nie powód do
braku zaufania do kompilatora i pisania wszystkiego w asm licząc na
własną nieomylność.

> > Wyłacza zawsze przed } kończącym dany blok lub natychmiast po
> > opuszczeniu bloku inną metoda. W czym problem z tym "za późno" ? Możesz
> > podać przykład?
> Jesli chce rozlaczyc logicznie wlaczanie i wylaczanie przerwan.

To wtedy wpadasz w podobne bagno co rozłączne wlaczanie i wylaczanie
mutexa. Po co chcesz to robić rozłacznie? Masz aż tak daleko jedno od
drugiego? Może design jest mizerny skoro sekcja krytyczna ciągnie sie
przez wiele funkcji i bloków?

> Ja nie mowie ze nie dziala. Ja mowie ze mnie by ograniczalo (za przyklad
> biore kod do ostatnio robionego urzadzenia, gdzie wlaczanie przerwan
> jest zupelnie gdzie indziej niz ich wylaczanie). Zupelnie gdzie indziej
> == inny plik.

Dlaczego tak to jest zrobione? Istnieje jakiś argument? Z chęcia go
poznam. Pytam, bo ostatnio widziałem kilka kawałków kodu na PC w których
nie dało się zrobić boost::scoped_lock. I nie wynikało to z przemyślenia
bądź rozsądnej potrzeby. Po prostu tak "sie napisało". Mogło sie napisać
inaczej, ale programista nie wiedział.

Mała uwaga: zawsze możesz zrobić coś na kształt move_lock jeśli
*naprawdę* musisz gdzie indziej uwolnić przerwania. Masz dwa w jednym:
nie jesteś ograniczony w scope i masz pewność że ktoś to gdzieś uwolni.