KDE spece.

[Jacek Konieczny]

On Wed, May 26, 1999 at 12:03:47AM +0200, Martin Dalecki wrote:
> > i nie jest jasne, co powinien wtedy robić np. operator new zamiast
> > rzucenia wyjątku przy niepowodzeniu w alokacji pamięci.
> 
> Wiesz miałbym na to taki prosty pomysł: Moźe zwrócić NULL (o przepraszam
> C++, a więc (void *) 0)?
I po to są wyjątki. Nie musisz sprawdzać wyniku każdego wywołania
operatora new (to może być setki razy w najróżniejszych miejscach
programu). 
Tylko w jednym miejscu, który jest najbliżej zarządzania pamięcią robisz
obsługę wyjątku - reszta cię nie interesuje.
Zamiast sprawdzać warunek przy każdej allokacji pamięci i wyrzucać jakiś
paniczny komunikat - piszesz w jednym miejscu trochę więcej kodu - który
to obsłuży w bardziej przyjazny sposób.

> Co niepomyślane nie? A powiedz mi prosze ile
> razy ci się zdażyło aby program który pisałeś faktycznie się troszczył,
> czy malloc sie udał i ponadto jaką to niby piękną strategię przyjąć,
> gdy malloc nie wypalił.

Napisałem kiedyś, na pracę dyplomową w technikum, edytor dla
programistów. (Tu odrobina wyjaśnienia - żyłem wtedy DOSem, bo Linuxa
praktycznie nie znałem) GUI podobne do TVision - ale w 100% własne.
Była możliwość otworzenia dowolnej ilości plików, iluś okien dialogowych
itp.
Programik zaraz po starcie allokował odrobinę pamięci "na wszelki
wypadek" i miał przeładowany operator new (ten w Borland C++ sam z
siebie wyjątków nie rzucał).
Gdy tylko w którymkolwiek miejscu programu zabrakło pamięci wyjątek
rzucony przez new zostął łapany gdzieś w głównej pętli programu,
"uwolniona" została "pamieć rezerwowa" i wyświetlone zostało stosowne
okienko.
Oczywiści użytkownik mógł teraz spokojnie zapisać wszystkie pliki i
grzecznie zakończyć pracę.

Czy to nie jest odrobinę bardziej eleganckie niż "Core dumped"?

Co prawda pod Linuksem to by nie było możliwe (ze względu na inne
zarządzanie pamięcią).

> Chciałbym wiedzieć bo gdy uda mu się zachować
> funkcję
> prz takiej rozrzutności, to mam takie pytanie: po cholerę byłaby mu ta
> pamięć?
 


> Program ten działałby mniej więcej tak jak ktoś kto się spłaszcza sam, 
> aby móc pływać w wodzie po kostki. W większości wypadków to co zwykle
> robi 
> xmalloc jest tak czy siak jedynym wyjściem:
> 
> pointer = malloc(10020020);
> if (!pointer) {
> 	fprintf(stderr, "Sorry I'm going to die anyway, but I'm kindly
> informing you
> 	that you should increase your's swap partition.");
> }
> 
> lub jeśli kto woli to samo w xmalloc.
Kiedy ten warunek sprawdzasz? Przy starcie? Przy każdej allokacji
pamięci? Czy co pół minuty?
W pierwszym przypadku dane szybko się zdeaktualizują.
W drugim masz problem opisany wyżej.
A trzeci też ślicznie nie wygląda.

> Nie wiem czy wyjątki są faktycznie lekarstwem na tego rodzaju
> problemy...
> Nie wiem jak ludzie byli w stanie pisać do tej pory najróźniejsze
> programy
> bez tych wszystkich nowych bajerów z C++ przez długie lata...
Nie lubisz C++ pisz w C. Niektórzy wybrali jednak ten język.
Często właśnie dzięki funkcjom które oferuje.

To że nie jest to często wykożystywane wynika tylko z braku
kompatybilności większości kompilatorów.

Ale przyjżyj się Javie - tu część tych wyklętych przez ciebie dodatki od
początku są w standardzie, a standard pilnowany jest przez jedną firmę.
Zobacz ile programów tutaj kożysta z tych bajerów.

Pozdrowienia,
       Jacek
-- 
+---------+--------------------------------------------------------+
!      ,  !            Jacek Konieczny, Gliwice, Poland            !      
! Jajcus  !   email: jajcus w zeus.polsl.gliwice.pl, jacek w kde.org   !
!         ! ICQ# 7149127                           WWW: none (yet) !
+---------+--------------------------------------powered-by-Linux--+