KDE a sdilene knihovny (Was Re: Programovani - shared libraries na Linuxu)

[Pavel Kankovsky]

On Sun, 9 Sep 2001, Lubos Lunak wrote:

> > Ovsem GNOME ji pouziva porad (AFAIK) a do 128 MB se v pohode vejde.
>  Ovsem GNOME nedostava od gcc/ld premii pres 0,5MB pameti na proces.

Nebudu zapirat. Je to cele spiknuti GCC, binutils a GNOME proti KDE. ;)

> > Aaaa...asi jsme uhodili hrebicek na hlavicku. C++, your second name is
> > bloat. Cele je to totiz *vrozeny* defekt C++.
> 
>  Nechtel bych se takhle umet trefovat hrebickum na hlavicku. Mel bych z 
> toho moc casto zavazany palec.

Proc asi moje veta zacinala "aaa..."?! :) Nyni vazne...

> Doporucuji k precteni Stroustrupovo 'Design and Evolution of C++', C++
> je navrzeno tak, ze muze byt stejne efektivni jak rychlostne tak
> pametove jako C [...]

Kontrolni otazka: uvazoval pan Stroustrup v kontextu dynamickeho
linkovani? Asi ne, co?

>  No jasne, ze ja na to neprisel hned, za vsechno muze jazyk. Kdyz se 
> podivame treba na tohle ( zestrucneny realny priklad, B je QCString ) :
> 
> class A
>     {
>     public:
>         virtual ~A();
>     };
> class B
>     : public A
>     {
>     public:
>         void f();
>     };
> 
>  Naprosto regulerni C++ kod. B samozrejme potrebuje vtable, protoze kvuli 
> dedeni z A ma virtualni destruktor implicitne generovany prekladacem. Jenze 
> gcc v B nikde zadnou non-inline virtualni metodu nenajde, vedle ktere by 
> emitoval tu vtable a nenapadne ho nic lepsiho nez emitovat vtable kdykoliv 
> je treba. Pritom mi trvalo asi tak 10 sekund vymyslet, ze vtable se da v 
> pohode emitovat jen v modulu implementujicim B::f() .

Tot otazka. Modul implementujici vyhradne nevirtualni metody nemusi byt
v principu v konecnem dusledku k programu vubec prilinkovan (a ani nemusi
byt nikdy prelozen, pripadne nemusi vubec existovat ani ve zdrojove
forme). Nevirtualni metoda ma totiz status plne srovnatelny s obycejnou
deklaraci funkce: dokud ji nekdo nepouziva, tak nikomu nevadi, ze neni
ve skutecnosti nikde definovana. Uznavam, ze je to ponekud pochybny
argument...

Pak je samozrejme otazka, zda-li naznacovane explicitni definice
destruktoru (a konstruktoru) situaci nezlepsi. (*) Ono je ostatne
lepsi, kdyz se moc nezneuziva implicitnich konstruktoru a destruktoru.

(*) Uplne vyresit to podle vyskytu specifickych definic metod v zasade
nelze, protoze rozdeleni metod do vice kompilacnich jednotek dle autorovy
libosti je povoleny obrat -- ktery se navic obcas i docela hodi.

--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."