KDE spece.

Martin Dalecki dalecki w cs.net.pl
Śro, 26 Maj 1999, 00:03:47 CEST


Marcin 'Qrczak' Kowalczyk wrote:
> 
> Mon, 24 May 1999 20:19:53 +0200 (CEST), Tomasz Kłoczko <kloczek w rudy.mif.pg.gda.pl> pisze:
> 
> > On Sun, 23 May 1999, Jacek Konieczny wrote:
> > [..]
> > > No to ja proponuje odchudzić np. glibca usuwając np. wielowątkowość.
> > > Jeśli ktoś użył w swojej aplikacji wyjątki, widać miał ku temu powody.
> > > Gdyby wszyscy mieli się trzymać przestarzałych schematów, całe KDE
> > > byłoby napisane w C i problem bbyłby z głowy tylko, czy wtedy KDE by
> > > wogóle powstało.
> 
> O, a ten list do mnie nie doszedł. Pewnie przez kłopoty z moim kontem
> na MIMUWie...
> 
> Ale mimo małego doświadczenia w tych sprawach, zgadzam się z nim.
> Kiedyś chciałem w tym guście odpisać.

A ja się nie zgadzam. Gdyby C++ był porządnym językiem oprogramowania
to by takich bzdur jak:

1. Wyjątki (- boczne wyjście z zagnieżdżenia funkcji. Nie dość jednego.
To by było zbyt czytelne. Wszyscy pragną mieć minimum dwa stosy w każdym
programie.
Choć nawet małe dziecko wie, że topologicznie liniową ograniczoną pamięć
najlepiej
wykożystać dwoma i tyklo dwoma stosami dokladnie tak jak Bóg przykazał:
heap i stack.)

2. Templates (- ultymatywna odpowiedź na pytanie: "Jak generować
najwięcej
zbędnego kodu jak najmniejszą ilością udezeń w klawiaturę. Tylko istotne
dla dyletantów nie potrafiących pisać generatorów kodu.)

3. RTTI (- to mój "ulubieniec". Coś zupełnie zbędnego a w razie "pilnej
potrzeby" łatwe jak pryszcz do zemulowania normalnym kodem. Tylko źe
wtedy bardzo
nasz dyletant zniecheca się do tego widząc jak bardzo mu to pluje
zbędnym kodem...)

4. polymorphism (uwielbiam przeładowane nazwy operatorów, obcy kod w C++
dzięki 
nim staje się czytelny jak "Biblia" lub "Kapitał" Marxa - każdy wyczyta 
dokłdanie co chce)

> > Hmm .. jeżeli włączenie wyjątków powoduje, że kod wszystkiego jest o
> > 20-30% większy, a całość przez to wolniejsza (w zwiazku z więskzym
> > kodem o wiele jest większe prawdopodobieństwo, że cache będzie
> > przeładowywany) to ja dziękuję za takie wyjątki. Zrozumiełbym kilk
> > procent (4-5) ale nie 20-30.
> 
> Cóż, bez wyjątków to się podobno w ogóle nie kompiluje, więc w tym
> przypadku nie bardzo jest jak rozważać "co by było gdyby"...

I w ten właśnie sposób wpadamy w standardową pułapkę dużych projektów w
C++.
Prędzej czy później powoli ukradkiem ktoś zacznie stosować niekoszerne 
konstrukty tego języka, których potem niesposób się już więcej pozbyć.

> > Zauważ, że użycie wątków prawie zawsze przysiesza program i usprawnia jego
> > konstruowanie. Czy to samo możesz w tym wypadku powiedzeć o wyjątkach ?
> > I druga sprawa .. usprawnienie pisanai programu .. być może ale jakim
> > kosztem ?

Też duże nie. Poczytaj sobie: Brooks: The Mythical Man Month. Tam jest
pięknie opisane jak wygląda ewolucja projektów miękkich spraw,
stosujacych
wyjątki... Były już na tej planecie takie systemy operacyjne, które
serio próbowały się w wyjątkowość bawić. Ach to musi być piękne, gdy
każda funkcja może sobie gdzieś tam wyskakiwać poza właściwym biegiem
programu w kontekscie threadów a tu człowiek i tak poci się
nad swojimi semaforami, a w jadrze to thready tak czy siak
raczej chleb powszedni...

> Często bywa tak, że używanie konstrukcji wyższego poziomu abstrakcji
> powoduje, że otrzymany kod nie będzie tak optymalny jak mógłby być,
> gdyby rzeźbić ręcznie niżej. Coś za coś.

Ach rozumiem: chłamski, powolny, nieczytelny, pisany na kolanie bez
porządnej koncepcji kod za wyjątki...

> Akurat wyjątki są IMHO przykładem czegoś odwrotnego. gcc jest
> zoptymalizowany pod kątem szybkiego działania programu w sytuacjach,
> w których wyjątki nie są rzucane. Kosztem wolniejszej operacji
> rzucenia wyjątku oraz, jak widać, kosztem objętości programu (jakieś
> statyczne tablice przy każdej funkcji mogącej rzucić wyjątek - a więc
> m.in. wołającej taką która może).
> 
> Wyjątki trudno w ogólnym przypadku zasymulować w języku, który ich
> nie ma. Zwłaszcza w taki sposób, żeby nie spowalniało to działania
> programu rzucającego mało wyjątków - chyba w C/C++ trzeba by dodawać
> jawne zwracanie jakiegoś statusu jako wynik funkcji i jawne jego
> sprawdzanie po wywołaniu funkcji, właściwy wynik funkcji przekazując
> bokiem. Bardzo możliwe, że program napisany bez użycia wyjątków
> chodziłby wolniej, abstrahując nawet od wygody jego pisania.

Wiesz... poczytaj sobie man setjump i man longjump. Bo tak to się jak
do tej pory robiło. Jeśli wolisz czytać kod to proszę bardzo zerknij
do xdvi, tam tego typu konstrukcje są stosowane do "asynchronicznego"
analizowania stron w przód.

> Wyjątki są nieodłączną cechą C++. AFAIK oficjalnie nie ma żadnego "C++
> bez wyjątków". To dodatkowy bonus gcc, że w ogóle pozwala je wyłączyć,

Oficjalnie to nie ma *żadnego* C++ w ogóle. Bo standard ISO i ANSI
wymaga
zanim przyjmie coś jako standard aby istniała przynajmniej jedna
prawdziwa implementacja. Jak do tej pory żaden z kompilatorów nie
implementuje tego co ogólnie uchodzi za standard C++ w pełni. Chyba egcs
jest w międzyczasie najbardziej zbliożony ale to inna historia.

Tych wszystkich badziewi które wymieniałem powyżej nie było w pierwotnym
C++. To był po prostu jeszcze C z dodaniem klas mniej więcej w stylu
Java.
Czyli tak mniej więcej to co jest faktycznie przydatne w pisaniu GUI.

Potem niestety Bjorn Stroustroup zaczął się albo nudzić, albo
musiał w jakiś sposób uzasadnić swoją funkcję i płacę, 
jako designer jezyka oprogramowania i zaczęto dodawać do C++ bez końca.
Proszę zwrócić uwagę na taki prosty fakcik, źe im nowsza opcja C++ tym
dłuźsze słowa terminalne języka z nią powiązane. Według mnie jest to
niezbitnym dowodem, że tych funkcji żaden praktyk nie wprowadzał.
Tak jak z resztą sądzę, źe jednym z *głównych* powodów ogromnego sukcesu
C jest bardzo zwięzła (aczkolwiek jednoznaczna!) składnia.
Oczywiście dzięki temu wszystkiemu C++ stał się chyba jednym  z
najbardziej barokowych.
(No istnieje silna konkurencja ze srtony perl-a, który podobnie co
wersja
to nowe w gruncie rzeczy zbędne dopinki...)

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

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

--Marcin



Więcej informacji o liście dyskusyjnej pld-devel-pl