🚀 go-pugleaf

Marcin Stefaniak <matmis.WYTNIJ@gazeta.pl> napisał(a): 

> int priority();
> void processWidget(auto_ptr<Widget> pw, int priority);
> ...
>   processWidget(auto_ptr<Widget>(new Widget), priority());
> ...

autopoprawka: miało być shared_ptr<Widget>, a nie auto_ptr<Widget>. 
To znaczy, w wersji z auto_ptr nie znika ten problem z wyjątkami, natomiast
deklarowanie parametru funkcji jako shared_ptr<T> jest bardziej życiowe niż
auto_ptr<T>.

panowie Andrzeje sobie drwią, a może by tak rozwiązać tą zagadkę? Bo ja wcale
nie jestem pewien, czy to co Scott Meyers pisze jest prawdą. Ale wygląda to
prawdopodbnie.

Marcin Stefaniak

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

Marcin Stefaniak napisał(a):
> Marcin Stefaniak <matmis.WYTNIJ@gazeta.pl> napisał(a):
>
> > int priority();
> > void processWidget(auto_ptr<Widget> pw, int priority);
> > ...
> >   processWidget(auto_ptr<Widget>(new Widget), priority());
> > ...
>
> autopoprawka: miało być shared_ptr<Widget>, a nie auto_ptr<Widget>.
> To znaczy, w wersji z auto_ptr nie znika ten problem z wyjątkami, natomiast
> deklarowanie parametru funkcji jako shared_ptr<T> jest bardziej życiowe niż
> auto_ptr<T>.
>
> panowie Andrzeje sobie drwią, a może by tak rozwiązać tą zagadkę? Bo ja wcale
> nie jestem pewien, czy to co Scott Meyers pisze jest prawdą. Ale wygląda to
> prawdopodbnie.

Niestety, jest to prawda.

http://www.gotw.ca/gotw/056.htm

D.

Dnia Thu, 24 Aug 2006 18:32:41 +0000 (UTC), Marcin Stefaniak skrobie:
> Marcin Stefaniak <matmis.WYTNIJ@gazeta.pl> napisał(a): 

> > int priority();
> > void processWidget(auto_ptr<Widget> pw, int priority);
> > ...
> >   processWidget(auto_ptr<Widget>(new Widget), priority());
> > ...

> autopoprawka: miało być shared_ptr<Widget>, a nie auto_ptr<Widget>. 
> To znaczy, w wersji z auto_ptr nie znika ten problem z wyjątkami, natomiast
> deklarowanie parametru funkcji jako shared_ptr<T> jest bardziej życiowe niż
> auto_ptr<T>.

Niby dlaczego? Shared ptr jest akurat do tego, żeby zawierać się w obiekcie, a
nie jako argument funkcji.

Zresztą shared_ptr też nie powinno się używać ze względu na jego powolność.
:)

-- 
//  _    ___         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"

"Darek Kubiczek" <darek_kubiczek@wp.pl> writes:

>> > int priority();
>> > void processWidget(auto_ptr<Widget> pw, int priority);
>> > ...
>> >   processWidget(auto_ptr<Widget>(new Widget), priority());

> Niestety, jest to prawda.
>
> http://www.gotw.ca/gotw/056.htm

To jest inna sytuacja. Warunkiem koniecznym, żeby zaszedł opisany tam
problem, jest żeby istniał argument, którego obliczenie może rzucić
wyjątek, i *inny* argument, któremu wycieka pamięć, jeśli jego
obliczenie i związanie go z parametrem zostanie przerwane. Tutaj on
nie zachodzi.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

A.L. <alewando@fala2005.com> writes:

> 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.

C++ nie jest pod tym względem, nomen omen, wyjątkiem.

http://java.sun.com/j2se/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

On Sun, 27 Aug 2006 16:43:16 +0200, Marcin 'Qrczak' Kowalczyk
<qrczak@knm.org.pl> wrote:

>A.L. <alewando@fala2005.com> writes:
>
>> 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.
>
>C++ nie jest pod tym względem, nomen omen, wyjątkiem.
>
>http://java.sun.com/j2se/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html

Czy sa jakies konstrukcje w C++ ktore oficjalnie zostaly uznane za
"deprecated"?

A.L.

Marcin 'Qrczak' Kowalczyk napisał(a):
> "Darek Kubiczek" <darek_kubiczek@wp.pl> writes:
>
> >> > int priority();
> >> > void processWidget(auto_ptr<Widget> pw, int priority);
> >> > ...
> >> >   processWidget(auto_ptr<Widget>(new Widget), priority());
>
> > Niestety, jest to prawda.
> >
> > http://www.gotw.ca/gotw/056.htm
>
> To jest inna sytuacja. Warunkiem koniecznym, żeby zaszedł opisany tam
> problem, jest żeby istniał argument, którego obliczenie może rzucić
> wyjątek,

priority()

> i *inny* argument, któremu wycieka pamięć, jeśli jego

new Widget

> obliczenie i związanie go z parametrem zostanie przerwane. Tutaj on
> nie zachodzi.

Zachodzi.
Przy ponizszej kolejnosci ewaluacji argumentow

1. new Widget
2. priority()
3. auto_ptr<Widget> (...)

jesli priority() rzuci wyjatek mamy wyciek.

Ostatnia linijka punktu 1 z podanego wczesniej linka jest wlasnie
rozwiazaniem zagadki.

Temat watku moze byc nieco mylacy przy rozwiazywaniu zagadki -
tu nie chodzi o sytuacje w ktorej wyjatek poleci z konstruktora Widget.

D.

"Jacek" <nobody@nospamkinga.cyf-kr.edu.pl> wrote:

> Caly podwatek to dylemat pomiedzy doskonaloscia techniczna
> (tu SvS i Ty)

!!!  C++ i doskonalosc techniczna ! :)
No nieeeee !! :)

> oraz ekonomiczna (A.L.). Mam wrazenie, ze jednak
> pieniadze zadecyduja.

Ta sie sklada ze _jednak_ prostota techniczna przeklada sie
(choc z reguly wartswa managerska srednio sobie z tego zdaje sprawe;)
na doskonalosc _praktyczna_ czyli prosto mowiac wieksza przewidywalnosc
aplikacji :) cow konsekwencji ma jednak jakis tam wplyw na ekonomicznosc...

AK 

Jacek <nobody@nospamkinga.cyf-kr.edu.pl> writes:

> 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.). 

Doskonałości to są, ale w matematyce.

> Mam wrazenie, ze jednak pieniadze zadecyduja.

W inżynierii oprogramowania pieniądze zawsze decydują.

-- 
http://www.piotr.dembiński.prv.pl

Seweryn Habdank-Wojewódzki <habdank@gmail.com> writes:

[...]

> Awantura o niższości/wyższości C++ i Javy przewijała się już wiele
> razy i nic z niej nie wynika. Te języki sa calkiem różne, chociaż
> składnie strasznie myli.  Nie ma możliwości w pełni zastąpić Javy
> C++'em, ani C++ Javą. Co więcej cały czas twórcy Javy korzystają 
> z doświadczeń twórców i koderów C++, więc nie wiem dokładnie o co
> chodzi w tej wojnie.

Zapewne chodzi o to, że docelowo Java miała zastąpić C++.

A.L. <alewando@fala2005.com> writes:

[...]

> Ja tez nei wiem. Chyba chodzi o to ze niektorzy do jezyka takiego
> czy owego zywia "uczucia wyzsze" czyli milosc. Na drobna uwage ze
> "panienka jest troszke garbata i ma lekko krzywy nos" reaguja 
> z wsciekloscia.
>
> Rzecz nie jest anegdotyczna, byla pzredmiotem badan psychiatrow
> amerykanskicg.

Ja bym się nie zdziwił, gdyby prowadzono badania nad wyższością
języków z ograniczaniem bloków kodu nawiasami klamrowymi nad językami,
w których bloki kodu są ograniczane słowami kluczowymi.  A waga takich
badań jest mniej więcej podobna, co waga badań nad optymalnym układem
klawiszy na standardowej klawiaturze komputerowej (DVORAK vs. QWERTY).

-- 
http://www.piotr.dembiński.prv.pl

'Giving people a dynamically-typed language does not mean that they write
dynamically-typed programs.'  John Aycock, 'Aggressive Type Inference'

Piotr Dembiński napisał(a):
> A.L. <alewando@fala2005.com> writes:
> 
> [...]
> 
>> Ja tez nei wiem. Chyba chodzi o to ze niektorzy do jezyka takiego
>> czy owego zywia "uczucia wyzsze" czyli milosc. Na drobna uwage ze
>> "panienka jest troszke garbata i ma lekko krzywy nos" reaguja 
>> z wsciekloscia.
>>
>> Rzecz nie jest anegdotyczna, byla pzredmiotem badan psychiatrow
>> amerykanskicg.
> 
> Ja bym się nie zdziwił, gdyby prowadzono badania nad wyższością
> języków z ograniczaniem bloków kodu nawiasami klamrowymi nad językami,
> w których bloki kodu są ograniczane słowami kluczowymi.  A waga takich
> badań jest mniej więcej podobna, co waga badań nad optymalnym układem
> klawiszy na standardowej klawiaturze komputerowej (DVORAK vs. QWERTY).
> 

no kiedyś były takie badania... jak robili Adę83... i przeszło, że bloki 
robimy begin...end :)

sg <alpha@skynet.org.pl_WITHOUT> writes:

[...]

>> Ja bym się nie zdziwił, gdyby prowadzono badania nad wyższością
>> języków z ograniczaniem bloków kodu nawiasami klamrowymi nad
>> językami, w których bloki kodu są ograniczane słowami kluczowymi.
>> A waga takich badań jest mniej więcej podobna, co waga badań nad
>> optymalnym układem klawiszy na standardowej klawiaturze
>> komputerowej (DVORAK vs. QWERTY).
>>
>
> no kiedyś były takie badania... jak robili Adę83... i przeszło, że
> bloki robimy begin...end :)

Bloki robimy 'begin ... end', a zarabiamy na zintegrowanych
środowiskach programistycznych, które te słowa kluczowe 
automatycznie wstawiają :>

-- 
http://www.piotr.dembiński.prv.pl

On Mon, 28 Aug 2006 14:45:07 +0200, "Adam Karpierz"
<karpierz@NOOOOSPAAAAMpython.pl> wrote:

>"Jacek" <nobody@nospamkinga.cyf-kr.edu.pl> wrote:
>
>> Caly podwatek to dylemat pomiedzy doskonaloscia techniczna
>> (tu SvS i Ty)
>
>!!!  C++ i doskonalosc techniczna ! :)
>No nieeeee !! :)
>
>> oraz ekonomiczna (A.L.). Mam wrazenie, ze jednak
>> pieniadze zadecyduja.
>
>Ta sie sklada ze _jednak_ prostota techniczna przeklada sie
>(choc z reguly wartswa managerska srednio sobie z tego zdaje sprawe;)
>na doskonalosc _praktyczna_ czyli prosto mowiac wieksza przewidywalnosc
>aplikacji :) cow konsekwencji ma jednak jakis tam wplyw na ekonomicznosc...
>

Zasadnicza, albowiem 75% dzialalnosci to maintenance.

Na dodatek jakos niewiele osob zdaje sobie sprawe ze jezyk w ktorym
problem mozna rozwiazac na 10 sposobow jest jakby gorszy od jezyka w
ktorym problem mozna rozwiazac tylko na 5 sposobow.

A.L.

""Piotr Dembiński"" <pdemb@gazeta.pl> wrote:

> Bloki robimy 'begin ... end', a zarabiamy na zintegrowanych
> środowiskach programistycznych, które te słowa kluczowe
> automatycznie wstawiają :>

Dlugosc 'klamr' (czy inne tego typu pier..) ma dokladnie zerowy
wplyw na 'szybkosc" programowania.
Nie, nie minimalny: dokladnie ZEROWY

AK [Algolowiec: => begin end-owiec] 

Dnia Sat, 26 Aug 2006 09:04:59 -0500, A.L. skrobie:
> On Fri, 25 Aug 2006 07:38:56 +0000 (UTC), Sektor van Skijlen
> <ethouris@guess.if.gmail.com.is.valid.or.invalid> wrote:
>  
> >Pan się lepiej zajmij doszkalaniem własnych zespołów i wyjaśnianiem im,
> >dlaczego to jest naprawdę logiczne, że ThreadDeath dziedziczy po Error.
> >Jeśli się pan zmieścisz w kosztach.

> Szkoda ze Pan tego nie rozumie. Niech Pan pogogluje troche, to moze
> Pan zrozumie.

Panie Andrzeju, jedyne "racjonalne" wyjaśnienie, które znalazłem, dlaczego
ThreadDeath dziedziczy po Error jest takie, że zbyt wiele aplikacji i
bibliotek "w ciemno" ignoruje wszystko, co pochodzi od Exception.

Jeśli pan tego nie wiesz, to pan chyba bujasz w obłokach.

Jeśli to jest dla pana racjonalny powód, to znaczy, że najprawdopodobniej
język Perl jest szczytowym osiągnięciem "software engineering".

> P.S> W mojej firmie ostatnia aplikacje w C++ wlasnie przepisuje sie
> na Jave. Byli programisci C++, teraz programisci Javy, mowie ze nei
> rozumieja za jakie grzechy musieli sie meczyc z tym syfem przez tyle
> lat. Zwlaszcza ze robili to dobrowolnie.

Niektóre konie też nie rozumieją, po co ich oczy muszą patrzeć na wszystkie
strony, zamiast tylko do przodu.

> Nawet bylo nieformalne
> party "pogrzebanie C++". Z mala trumienka i drinkami. Oraz tortem.

Bo jesteście całym światem i nadajecie ton produkcji oprogramowania?

Ja właśnie przechodzę do firmy, w której pisze się wyłącznie w Javie. I co z
tego? Dotychczas pracowałem w firmie, w której od dłuższego czasu pisało się
niemal wyłącznie w C. Co to dla mnie za różnica?

-- 
//  _    ___         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"

"A.L." <alewando@fala2005.com> wrote in message

>>Ta sie sklada ze _jednak_ prostota techniczna przeklada sie
>>(choc z reguly wartswa managerska srednio sobie z tego zdaje sprawe;)
>>na doskonalosc _praktyczna_ czyli prosto mowiac wieksza przewidywalnosc
>>aplikacji :) cow konsekwencji ma jednak jakis tam wplyw na 
>>ekonomicznosc...
>>
>
> Zasadnicza, albowiem 75% dzialalnosci to maintenance.

Dokladnie.

> Na dodatek jakos niewiele osob zdaje sobie sprawe ze jezyk w ktorym
> problem mozna rozwiazac na 10 sposobow jest jakby gorszy od jezyka w
> ktorym problem mozna rozwiazac tylko na 5 sposobow.

Nic dodac, nic ujac.
Na 'stare lata' marze o jezyku w ktorym dana rzecz mozna by
rozwiazac na jeden/dwa sposoby :)

Szkoda po prostu komorek na pamietanie tych wszytskich sposobow

AK 

Dnia Sun, 27 Aug 2006 11:51:39 +0000 (UTC), Jacek skrobie:
> 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 ;)

Tyle że CP/M już dzisiaj nikt nie używa, a Windowsa NT (nie wspominając o
Symbianie) jak najbardziej.

Nie wspominając również o aplikacjach krytycznych wydajnościowo. Jak w takim
czymś zobaczę kiedyś Javę, to przejdę na Islam.

> Caly podwatek to dylemat pomiedzy doskonaloscia techniczna
> (tu SvS i Ty) oraz ekonomiczna (A.L.). Mam wrazenie, ze jednak
> pieniadze zadecyduja.

Java a doskonałość ekonomiczna? Buhahahahahahahahahahahahaha :)

Z ową "doskonałością Javy" jest mniej więcej tak, jak z doskonałością
wszystkich "ekstremalnych" metod programowania, SCRUM-ów i tym podobnych. Bo
Java jest właśnie takim językiem ekstremalnym.

-- 
//  _    ___         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"

Dnia Mon, 28 Aug 2006 21:56:35 -0500, A.L. skrobie:
> On Mon, 28 Aug 2006 14:45:07 +0200, "Adam Karpierz"
> <karpierz@NOOOOSPAAAAMpython.pl> wrote:

> >"Jacek" <nobody@nospamkinga.cyf-kr.edu.pl> wrote:
> >
> >> Caly podwatek to dylemat pomiedzy doskonaloscia techniczna
> >> (tu SvS i Ty)
> >
> >!!!  C++ i doskonalosc techniczna ! :)
> >No nieeeee !! :)
> >
> >> oraz ekonomiczna (A.L.). Mam wrazenie, ze jednak
> >> pieniadze zadecyduja.
> >
> >Ta sie sklada ze _jednak_ prostota techniczna przeklada sie
> >(choc z reguly wartswa managerska srednio sobie z tego zdaje sprawe;)
> >na doskonalosc _praktyczna_ czyli prosto mowiac wieksza przewidywalnosc
> >aplikacji :) cow konsekwencji ma jednak jakis tam wplyw na ekonomicznosc...
> >

> Zasadnicza, albowiem 75% dzialalnosci to maintenance.

> Na dodatek jakos niewiele osob zdaje sobie sprawe ze jezyk w ktorym
> problem mozna rozwiazac na 10 sposobow jest jakby gorszy od jezyka w
> ktorym problem mozna rozwiazac tylko na 5 sposobow.

Nie mówimy o rozwiązywaniu na 10 vs 5 sposobów, tylko na rozwiązywaniu go na 3
vs 1 sposobów.

Nie pokazuj człowiekowi dwóch rzeczy, bo to go czyni nieszczęśliwym. Pokaż mu
jedną, a będzie zadowolony.

-- 
//  _    ___         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"

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"

Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid> wrote:
 
> Taaa... super wyśmienicie, mamy super bezpieczne wyjątki w Javie. Dzięki temu
> wszystkie wyjątki muszą być jawnie specyfikowane.

RuntimeException i pochodne nie musza byc.

-- 
Mikolaj Rydzewski       <miki@ceti.pl>       http://ceti.pl/~miki/
                     PGP KeyID: 8b12ab02
There are three kinds of people: men, women, and unix.

On Tue, 29 Aug 2006 11:52:43 +0000 (UTC), Sektor van Skijlen
<ethouris@guess.if.gmail.com.is.valid.or.invalid> wrote:
 
>
>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ę.

Owszem. Programowanie wielowatkowe w C++ rozwiazno znacznie
zgrabniej.

A.L.

On Tue, 29 Aug 2006 11:52:43 +0000 (UTC), Sektor van Skijlen
<ethouris@guess.if.gmail.com.is.valid.or.invalid> wrote:
 e.
>
>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.
 
Polecam jakis kurs Javy, wie Pan, jakis prosty, elementarny, taki
"Teach yourself Java in 14 days nie przerywajac snu". Wtedy by sie
Pan dowiedzial ze sa dwa rodzaje wyjatkow w Javie, takie ktore
trzeba explicite przechwytywac i takie ktorych nie tzreba. Te ktore
dziedzicza od RuntimeException sa wlasnie "przezroczyste".

A jak juz Pan ten kurs skonczy, to wtedy prosze sie wymadrzac co
Java ma a czego nei ma.

A.L.

Dnia Sun, 27 Aug 2006 10:09:28 -0500, A.L. skrobie:
> On Sun, 27 Aug 2006 16:43:16 +0200, Marcin 'Qrczak' Kowalczyk
> <qrczak@knm.org.pl> wrote:

> >A.L. <alewando@fala2005.com> writes:
> >
> >> 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.
> >
> >C++ nie jest pod tym względem, nomen omen, wyjątkiem.
> >
> >http://java.sun.com/j2se/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html

> Czy sa jakies konstrukcje w C++ ktore oficjalnie zostaly uznane za
> "deprecated"?

Tak.

 - konwersja napisu w cudzysłowiu na typ char* przy inicjalizacji
 - użycie operatora ++ na zmiennej typu bool (powoduje powstanie wartości
   true; operator -- z kolei nie jest dozwolony)
 - użycie modyfikatora static w tym znaczeniu, co w języku C
 - deklaracje dostępu ("prywatyzacja" i "upublicznianie" elementów z klas
   bazowych)
 - używanie plików nagłówkowych z biblioteki C (np. <stdio.h>).
 - klasa strstream i jej pochodne

Co ciekawe, nie wspomniano o "obleśnym rzutowaniu" - jest ono zatem deprecated
tylk nieoficjalnie.

Dla wszystkich tych właściwości są zaproponowane alternatywy:

 - używanie dla napisu w cudzysłowiu const char* (a najlepiej w ogóle string)
 - dla typu bool używanie konstrukcji "= true"
 - używanie anonimowych przestrzeni nazw
 - deklaracje using
 - używanie plików nagłówkowych przeznaczonych dla C++ (np. <cstdio>)
 - klasa stringstream i jej pochodne

Zamiast obleśnego rzutowania zaś należy stosować odpowiednie do sytuacji
operatory konwersji.

Żadna z opisanych właściwości nie powoduje błędnego działania aplikacji;
właściwości te są jedynie niezalecane z uwagi na to, że mogą wylecieć w
następnym standardzie. Część z nich jest związana ze zgodnością z językiem C i
jest to tylko niechętny ukłon w stronę tych, którzy nie chcą ślęczeć godzinami
nad dostosowaniem swojej aplikacji do C++. Inne (w szczególności deklaracje
dostępu i strstream) to podobnie, kwestia zgodności z ARM C++.

-- 
//  _    ___         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"

Dnia Tue, 29 Aug 2006 12:13:51 +0200, Adam Karpierz skrobie:
> ""Piotr Dembiński"" <pdemb@gazeta.pl> wrote:

> > Bloki robimy 'begin ... end', a zarabiamy na zintegrowanych
> > ?rodowiskach programistycznych, które te słowa kluczowe
> > automatycznie wstawiaj? :>

> Dlugosc 'klamr' (czy inne tego typu pier..) ma dokladnie zerowy
> wplyw na 'szybkosc" programowania.
> Nie, nie minimalny: dokladnie ZEROWY

Oczywiście masz rację. Ma to wpływ jedynie na czytelność kodu.


-- 
//  _    ___         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"

Dnia Tue, 29 Aug 2006 07:18:18 -0500, A.L. skrobie:
> On Tue, 29 Aug 2006 11:52:43 +0000 (UTC), Sektor van Skijlen
> <ethouris@guess.if.gmail.com.is.valid.or.invalid> wrote:
>  
> >
> >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ę.

> Owszem. Programowanie wielowatkowe w C++ rozwiazno znacznie
> zgrabniej.

Możliwe, ale dzięki temu komitet standaryzacyjny nie skompromitował się żadną
chujowizną.
:)

-- 
//  _    ___         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"

Dnia Tue, 29 Aug 2006 07:39:59 -0500, A.L. skrobie:
> On Tue, 29 Aug 2006 11:52:43 +0000 (UTC), Sektor van Skijlen
> <ethouris@guess.if.gmail.com.is.valid.or.invalid> wrote:
>  e.
> >
> >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.
>  
> Polecam jakis kurs Javy, wie Pan, jakis prosty, elementarny, taki
> "Teach yourself Java in 14 days nie przerywajac snu". Wtedy by sie
> Pan dowiedzial ze sa dwa rodzaje wyjatkow w Javie, takie ktore
> trzeba explicite przechwytywac i takie ktorych nie tzreba. Te ktore
> dziedzicza od RuntimeException sa wlasnie "przezroczyste".

No dobra, drobna pomyłka - pochodne Error i RuntimeException.

Zabawny pan jesteś - najpierw pan się śmiejesz z C++, że ma wiele trudnych
rzeczy (które nb. ma również Java), a następnie się okazuje, że do Javy też
trzeba zrobić doktorat z hierarchii klas standardowych.


-- 
//  _    ___         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"

"A.L." <alewando@fala2005.com> wrote in message

> Owszem. Programowanie wielowatkowe w C++ rozwiazno
> znacznie zgrabniej.

ROTFL :)

AK

"Sektor van Skijlen" <ethouris@guess.if.gmail.com.is.valid.or.invalid> 
wrote:

>> Nie, nie minimalny: dokladnie ZEROWY
>
> Oczywiście masz rację. Ma to wpływ jedynie na czytelność kodu.

Ano ma
Dosc mam syfu typu:

if ( baaaaaaaaaaaaardzo dluuuuuuuuuuuugi waruneeeeeeeeeeeeeeeeeeeeeeek ) {
  cos tam1
  cos tam2
}

Wole normalnie jak w Algolu czy Simuli

if baaaaaaaaaaaaardzo dluuuuuuuuuuuugi waruneeeeeeeeeeeeeeeeeeeeeeek then
   begin
   cos tam1
   cos tam2
   end

Ew. wole jeszcze inaczej:

 if baaaaaaaaaaaaardzo dluuuuuuuuuuuugi waruneeeeeeeeeeeeeeeeeeeeeeek :
     cos tam1
     cos tam2

AK 

Dnia Tue, 29 Aug 2006 15:30:38 +0200, Adam Karpierz skrobie:
> "Sektor van Skijlen" <ethouris@guess.if.gmail.com.is.valid.or.invalid> 
> wrote:
> >
> >> > Drudzy w kolejnosci sa programisci zakochujacy sie
> >> > w swoich jezykach.
> >
> >> > Trzeci  - posiadacze broni.
> >
> >> Boze ! Dziekujemy Ci ze jednak Sektor jest tylko zakochanym
> >> programista :))
> >
> > Adam, ciebie to chyba muszę kiedy? stukn?ć.

> No to probuj Wasc.
> Warze 105kg i mierze 1.93m, a Ty ? ;)

Warzysz to chyba piwo.

W mierzysz zdecydowanie za nisko :)

> > Najlepiej kuflem od piwa.

> Widziels takie stateczki w butelce ? Fajne prawda ?
> Sektor w kuflu piwa.. Hm.. tez moze byc fajne !
> (chociaz ci bedzie ciut duszno).

Ostatnio któryś numer PSD opisywał "jak nabić skrzata w butelkę".

Chyba się zainteresuję fotoszopem.

-- 
//  _    ___         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"

Dnia Tue, 29 Aug 2006 15:43:41 +0200, Adam Karpierz skrobie:
> "Sektor van Skijlen" <ethouris@guess.if.gmail.com.is.valid.or.invalid> 
> wrote:

> >> Nie, nie minimalny: dokladnie ZEROWY
> >
> > Oczywi?cie masz rację. Ma to wpływ jedynie na czytelno?ć kodu.

> Ano ma
> Dosc mam syfu typu:

> if ( baaaaaaaaaaaaardzo dluuuuuuuuuuuugi waruneeeeeeeeeeeeeeeeeeeeeeek ) {
>   cos tam1
>   cos tam2
> }

> Wole normalnie jak w Algolu czy Simuli

> if baaaaaaaaaaaaardzo dluuuuuuuuuuuugi waruneeeeeeeeeeeeeeeeeeeeeeek then
>    begin
>    cos tam1
>    cos tam2
>    end

Taaa... to to już jest szczyt czytelności.

> Ew. wole jeszcze inaczej:

>  if baaaaaaaaaaaaardzo dluuuuuuuuuuuugi waruneeeeeeeeeeeeeeeeeeeeeeek :
>      cos tam1
>      cos tam2

A to szczególnie - zwłaszcza przy długich blokach skakanie na jego początek.



-- 
//  _    ___         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"

"Sektor van Skijlen" <ethouris@guess.if.gmail.com.is.valid.or.invalid> 
wrote:

>> Wole normalnie jak w Algolu czy Simuli
>
>> if baaaaaaaaaaaaardzo dluuuuuuuuuuuugi waruneeeeeeeeeeeeeeeeeeeeeeek then
>>    begin
>>    cos tam1
>>    cos tam2
>>    end
>
> Taaa... to to już jest szczyt czytelności.

Dokladnie !.
Wlasnie ta konstrukcja jest najczytelneijsza a wszystkich jakie spotkalem
w j.programowania.

Uzywalem jej tak:

if baaaaaaaaaaaaardzo dluuuuuuuuuuuugi waruneeeeeeeeeeeeeeeeeeeeeeek then
begin
  cos tam1
  cos tam2
end

AK

Adam Karpierz napisał(a):
> "Sektor van Skijlen" <ethouris@guess.if.gmail.com.is.valid.or.invalid> 
> wrote:
> 
>>> Wole normalnie jak w Algolu czy Simuli
>>> if baaaaaaaaaaaaardzo dluuuuuuuuuuuugi waruneeeeeeeeeeeeeeeeeeeeeeek then
>>>    begin
>>>    cos tam1
>>>    cos tam2
>>>    end
>> Taaa... to to już jest szczyt czytelności.
> 
> Dokladnie !.
> Wlasnie ta konstrukcja jest najczytelneijsza a wszystkich jakie spotkalem
> w j.programowania.
> 
> Uzywalem jej tak:
> 
> if baaaaaaaaaaaaardzo dluuuuuuuuuuuugi waruneeeeeeeeeeeeeeeeeeeeeeek then
> begin
>   cos tam1
>   cos tam2
> end
> 
> AK
> 
> 

bo to nie jest czytelne?

------------------------------------------------------------
if ( baaaaaaaaaaaaardzo dluuuuuuuuuuuugi waruneeeeeeeeeeeeeeeeeeeeeeek )
{
	cos tam1
	cos tam2
}
------------------------------------------------------------
if (
	baaaaaaaaaaaaardzo dluuuuuuuuuuuugi
	waruneeeeeeeeeeeeeeeeeeeeeeek
    )
{
	cos tam1
	cos tam2
}
------------------------------------------------------------


Tak tylko się czepiam, ale coś na rzeczy musi być skoro przy pracy nad 
Adą doszli do wniosku, że begin..end jest lepsze

Michal Przybylek napisał(a):
> "sg" <alpha@skynet.org.pl_WITHOUT> wrote:
> 
>> Tak tylko się czepiam, ale coś na rzeczy musi być
>>  skoro przy pracy nad Adą doszli do wniosku, że
>> begin..end jest lepsze
> 
> Dokladnie o tym mowili w design principles. Glownym zalozeniem jezyka bylo
> aby "programy byly maksymalnie czytelne, nawet kosztem energetycznosci
> pisania kodu". Dlatego tez Ada ma tak wiele innych ficzerow skladniowych.
> 
> 
> mp
> 

najbardziej mi się podobało jak stwierdzili, że wszystkie ówczesne 
języki programowania nie nadają się do robienia aplikacji krytycznych 
(łącznie z C) :)
Ale z drugiej strony Ada przegrywa jeśli chodzi o użyteczność... brakuje 
bibliotek w tym również bibliotek do GUI.

"sg" <alpha@skynet.org.pl_WITHOUT> wrote:

> Tak tylko się czepiam, ale coś na rzeczy musi być
>  skoro przy pracy nad Adą doszli do wniosku, że
> begin..end jest lepsze

Dokladnie o tym mowili w design principles. Glownym zalozeniem jezyka bylo
aby "programy byly maksymalnie czytelne, nawet kosztem energetycznosci
pisania kodu". Dlatego tez Ada ma tak wiele innych ficzerow skladniowych.


mp

Witam

Adam Karpierz wrote:

> "Sektor van Skijlen" <ethouris@guess.if.gmail.com.is.valid.or.invalid>
> wrote:
> 
>>> Wole normalnie jak w Algolu czy Simuli
>>
>>> if baaaaaaaaaaaaardzo dluuuuuuuuuuuugi waruneeeeeeeeeeeeeeeeeeeeeeek
>>> then
>>>    begin
>>>    cos tam1
>>>    cos tam2
>>>    end
>>
>> Taaa... to to już jest szczyt czytelności.
> 
> Dokladnie !.
> Wlasnie ta konstrukcja jest najczytelneijsza a wszystkich jakie spotkalem
> w j.programowania.
> 
> Uzywalem jej tak:
> 
> if baaaaaaaaaaaaardzo dluuuuuuuuuuuugi waruneeeeeeeeeeeeeeeeeeeeeeek then
> begin
>   cos tam1
>   cos tam2
> end

W czasopiśmie Overload ostatnio napisany został piękny artykuł dla ludzi,
którym zależy na tego typu wyglądzie:

#define begin {
#define end }
#define then

i cała masa różnych #define aby pisać w C jak w Pascalu czy innych językach.

kłopt pozostaje że po if trzeba pisać nawiasy :-).

Pozdrawiam.

Dnia Sun, 03 Sep 2006 14:08:13 +0200, Seweryn Habdank-Wojewódzki skrobie:
> Witam

> Adam Karpierz wrote:

> > "Sektor van Skijlen" <ethouris@guess.if.gmail.com.is.valid.or.invalid>
> > wrote:
> > 
> >>> Wole normalnie jak w Algolu czy Simuli
> >>
> >>> if baaaaaaaaaaaaardzo dluuuuuuuuuuuugi waruneeeeeeeeeeeeeeeeeeeeeeek
> >>> then
> >>>    begin
> >>>    cos tam1
> >>>    cos tam2
> >>>    end
> >>
> >> Taaa... to to ju? jest szczyt czytelno?ci.
> > 
> > Dokladnie !.
> > Wlasnie ta konstrukcja jest najczytelneijsza a wszystkich jakie spotkalem
> > w j.programowania.
> > 
> > Uzywalem jej tak:
> > 
> > if baaaaaaaaaaaaardzo dluuuuuuuuuuuugi waruneeeeeeeeeeeeeeeeeeeeeeek then
> > begin
> >   cos tam1
> >   cos tam2
> > end

> W czasopiśmie Overload ostatnio napisany został piękny artykuł dla ludzi,
> którym zależy na tego typu wyglądzie:

> #define begin {
> #define end }
> #define then

> i cała masa różnych #define aby pisać w C jak w Pascalu czy innych językach.

> kłopt pozostaje że po if trzeba pisać nawiasy :-).

#define If if (
#define Then )



-- 
//  _    ___         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"

"Seweryn Habdank-Wojewódzki" <habdank@gmail.com> wrote:

>> Uzywalem jej tak:
>>
>> if baaaaaaaaaaaaardzo dluuuuuuuuuuuugi waruneeeeeeeeeeeeeeeeeeeeeeek then
>> begin
>>   cos tam1
>>   cos tam2
>> end
>
> W czasopismie Overload ostatnio napisany zostal piekny artykul dla ludzi,
> którym zalezy na tego typu wygladzie:
>
> #define begin {
> #define end }
> #define then
>
> i cala masa róznych #define aby pisac w C jak w Pascalu czy innych 
> jezykach.
>
> klopt pozostaje ze po if trzeba pisac nawiasy :-).

Jestes o krok od osmieszenia sie.
Moze nie takiego jak Sektor ale..  :)

AK

Witam

Adam Karpierz wrote:

>> W czasopismie Overload ostatnio napisany zostal piekny artykul dla ludzi,
>> którym zalezy na tego typu wygladzie:
>>
>> #define begin {
>> #define end }
>> #define then
>>
>> i cala masa róznych #define aby pisac w C jak w Pascalu czy innych
>> jezykach.
>>
>> klopt pozostaje ze po if trzeba pisac nawiasy :-).
> 
> Jestes o krok od osmieszenia sie.
> Moze nie takiego jak Sektor ale..  :)

Nie rozumiem. Nie jestem estetą i nie musze zawsze tak samo pisać, więc moja
propozycja raczej była żartem. Inaczej pisze się skrypty w shellu inaczej w
Pythonie, inaczej w C++ czy Javie. Nie przeszkadza mi to, bo wzory
matematyczne pisze się w Latex i jest też inaczej. A, że rozmowa spadła na
poziom czy lepiej "{" czy "begin", więc napisałem jak to rozwiązać.

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
`\/\/'

"Seweryn Habdank-Wojewódzki" <habdank@gmail.com> wrote:

> Nie rozumiem. Nie jestem esteta i nie musze zawsze tak samo
> pisac, wiec moja propozycja raczej byla zartem.

A to co innego :)
Zwracam honor.

PS: po prostu na widok #define trace humor :)

AK