KDE spece.

[Marcin Dalecki]

Jacek Konieczny wrote:
> 
> 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).

Gdy stosujesz wyjątki to właśnie domyślnie tak mniej więcej sprawdzasz 
tak mniej więcej wszystko co robisz. Wież mi to nie taki sobie
przypadek,
że a.out-y z włączonymi excetions są nieco większe :-).

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

Piszesz tylko trochę więcej, ale domyślnie za twoimi plecami kompilator
czuje się zobowiązny bardzo bardzo sporo za ciebie zrobić...

> > 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"?

Ale excepations są w tej sytuacji, którą opisujesz zupełnym  katowaniem
trupa. 
W zwykłym C to by sobie tak wyglądało:


xmalloc()
{
	...
	if (cholera nie da się) {
		longjump(jump_buf, 1);
	} 
	...

	dorba dobra już Ci masz
}


main()
{

	while(główna wstęga) {

		if (!setjump(&jump_buf)) {
			Dobra lecimy z normalnym programem
		} else {
			O cholera wystąpił wyjątek zabrakło nam nieco
			pamięci, no dorba zobaczymy co się da zdziałć.

		}
	}
}

Ani nie mniej czytelne, a nie ładuje w niekontrolownay sposób kodu do 
programu.

Problem wspomagania mechanizmów exceptions nie jest w pierwszej
kolejnosci problemem języka programowania jako takiego, lecz raczej
problemem znajomości tego co się ma do dyspozycji... A niestety 
takie wmontowane konstrukty jak w C, czy javie po prostu stwarzają
*iluzję* że to jest niby banał i prowadzą bardzo często do bardzo
niechluje, bez namysłu napisanych programów, które potrzebują nie
wiadomo
ile resourceów systemu.

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

???? Ja jak do tej pory zawsze sobie myślałem że pod DOS-em to
jako takiego zażądzania pamięci to raczej wcale nie było. Pod Linux-em
byłoby to raczej *zbędne*.

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

A jak tam sobie zażyczysz :-).

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

Nie - C++ w wersji 1.0 uważałem za jak najbardziej sensowny.
Zwłaszcza w kontekscie pisania GUI. Tylko mi się stanowczo nie podoba
to co *ostatnio* zaczęto na chama dodawać. Pomuśl o jakimś bajerze 
a C++ już go ma. Owszem teoretycznie można
by się osobiście ograniczyć do tego co się uważa za sensowne, ale tak
jak w danym przykłądzie w nietrywialnych projektach pisanych przez wielu
ludzi
okazuje się to być po prostu iluzją...

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

A brak kompatybilijności kompilatorów wynika ze stanwoczo przeładowanego
języka, płynnego pseudo standradu i wielkich tródności jakich 
przysparza *poprawna* implementacja pewnych
aspektów jego specyfikacji w systemach operacyjnych rozpowszechninych na
tej
planecie. Nie wiem czy wiesz, ale np. to że EGCS poprawnie
rozwiązuje overloaded operators to po częsci moja tobota.... (Tylko że
ja
nic dla FSF nie podpiszę i wolę czasami nie świecić oczami w ChangeLog
:-)

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

Oj niewszystkie niewszystkie... :-). No i pewne rzeczy to bym oczywiście
też i z Javy wyrzucił na pysk. (W pierwszej kolejności GC - można
dowieść
teoretycznie że to się nie da zimplementować porządnie.)

> Zobacz ile programów tutaj kożysta z tych bajerów.

Zobacz ile jest faktycznie dobrych programów...
Zobacz jak często walą się programy pod NT...

> Pozdrowienia,

narazie...

--Marcin