🚀 go-pugleaf

Dnia Sun, 27 Aug 2006 09:31:37 -0500, A.L. skrobie:
> On Sun, 27 Aug 2006 11:51:39 +0000 (UTC), Jacek
> <nobody@nospamkinga.cyf-kr.edu.pl> wrote:

> >Piotr Dembiński <pdemb@gazeta.pl> napisal:
> >> A taki Windows NT jest w całości napisany w C++.
> >
> >Wybacz, ale to slaby argument. CP/M byl pisany w asemblerze,
> >ale to nie powod, by ciagle w nim pisac ;)
> >
> >Caly podwatek to dylemat pomiedzy doskonaloscia techniczna
> >(tu SvS i Ty) oraz ekonomiczna (A.L.). Mam wrazenie, ze jednak
> >pieniadze zadecyduja.

> Doskonalosc techniczna" oddaje najlepiej nastepujacy cytat,
> potwierdzajacy to co od dawna wiadomo, a mianowicie ze C++ powstaje
> "metoda alchemiczna": Wkladamy troche g... do sloika i potrzasamy.
> Potem patrzymy co wyszlo. Jak rowneiz to ze tworcy jezyka nie sa w
> stanie zrozumeic co robia. Widac jest za trudny dla nich.

> Cytat:

> ""Hmm," you might wonder, "then why does this exception safety
> loophole exist at all? Why doesn't the standard just prevent the
> problem by requiring compilers to Do The Right Thing when it comes
> to cleanup?"

> The basic answer is that it wasn't noticed, and even now that it has
> been noticed it might not be desirable to fix it. The C++ standard
> allows the compiler some latitude with the order of evaluation of
> expressions because this allows the compiler to perform
> optimizations that might not otherwise be possible. To permit this,
> the expression evaluation rules are specified in a way that is not
> exception-safe, and so if you want to write exception-safe code you
> need to know about, and avoid, these cases. (See below for how best
> to do this.)

> Remember that C++ exception safety in general has not been well
> understood until fairly recently (namely the summer of 1997, just
> months before the standard was completed). Even so, the committee
> managed to add exception safety guarantees to the standard library,
> albeit necessarily at the eleventh hour in the last two meetings
> before the standard was cast in stone; many of the guarantees were
> added literally days before the concrete set. The problem with
> new-expressions has now been noticed, but for the reasons above the
> committee will have to decide whether the hole should be "fixed" or
> whether it should continue to be allowed in the name of compiler
> optimization flexibility..."

> Ja dziekuje. Ja postoje.

Taaa... super wyśmienicie, mamy super bezpieczne wyjątki w Javie. Dzięki temu
wszystkie wyjątki muszą być jawnie specyfikowane.

Jeśli teraz mamy nową wersję biblioteki i ktoś wymyślił nowe wyjątki, to
musimy dostosować do tego naszą aplikację lub bibliotekę, jeśli chcemy te
wyjątki przepuszczać. Bo super wybitni jajogłowi twórcy Javy wymyślili, jak
zrobić bezpieczne wyjątki, ale nie wymyślili, jak zrobić, żeby można było w
drodze wyjątku zrobić przezroczyste wyjątki. Tak samo, przez callback również
żadnego wyjątku (poza Error i pochodnymi) się nie przeciśnie.

Ludzie od C++ zdawali sobie sprawę, że chociaż bezpieczne wyjątki mogłyby
przyczynić się zarówno do bezpieczniejszego oprogramowania, jak i do lepszych
optymalizacji (w tym wykrywania sytuacji "unexpected" na etapie kompilacji),
to jednak do tego należałoby opracować również wiele koncepcji ocierających
się o generyzm względem typów specyfikowanych wyjątków (np. jak napisać takie
for_each, żeby wypuszczało wszystkie takie wyjątki, jakie wypuszcza funkcja
podana jako callback). Dlatego darowano sobie całą sprawę, bo C++ nie był
jeszcze na to gotowy.

Ludzie od Javy stwierdzili, że Java jest na to gotowa i wprowadzili. Efekt
jest taki, że jeśli chcemy mieć bibliotekę, która jest odporna na zmiany w
bibliotekach zależnych, w tym w kwestii zgłaszanych wyjątków, musi
przechwytywać wszystko, co się rusza.

Koleny efekt jest taki, że ThreadDeath jest pochodną Error, mimo że
najbardziej naturalnym przodkiem dla tej klasy byłby Exception (lub któraś
jego pochodna). Niestety zbyt wiele bibliotek przechwytuje "w ciemno" wszelkie
pochodne Exception...

Najśmieszniejsze w tym wszystkim jednak nie jest samo to, ale fakt, że w C++
w większości przynajmniej bibliotek do każdego elementu, który w razie błędu
rzuca wyjątkiem, da się znaleźć alternatywę, która nie rzuca wyjątkiem, tylko
zgłasza problem przez wartość zwracaną. W Javie natomiast, nadomiar tego
złego, co powyżej, zgłoszono idealistyczne wymaganie, że wyjątki są jedyną
metodą zgłaszania błędnych sytuacji.

Problem exception safety w C++ jest wybujały. Przynajmniej jeśli chodzi o
bibliotekę standardową, błędy zgłoszone przez wyjątki zwykle kwalifikują
program do natychmiastowego zakończenia, a efektem "exception unsafety" są
wycieki pamięci. Co mnie obchodzą wycieki pamięci, które następują na 5 sekund
przed zakończeniem programu? W Javie dokładnie te same "wycieki" trwają
znacznie dłużej.

Przy okazji proponuję również poczytać o tym, dlaczego nie należy stosować
Thread.stop i Thread.suspend. Wobec takich "faktów", ja również chętnie
postoję.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"