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

[Lubos Lunak]

Pavel Kankovsky wrote:

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

 Tak, a ted jste se proflakli :). Ja myslel, ze to je jen chybka v gcc a 
ono je to tedy takhle.

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

 Tezko rict, ja se ho neptal. Me spis trapi, ze vyvojari gcc a binutils asi 
neuvazovali v kontextu dynamickeho linkovani.

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

 Souhlasim, ze je to pochybny argument. Tak pochybny, ze v celem KDE (a ze 
je to peknych par radek kodu) nejspis neni misto, kde by se to stalo, takze 
mit na to aspon prepinac, nikomu by to asi nevadilo.

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

 Tak jako tak ... kdo je tu prihlaseny na mailing listu gcc nebo binutils, 
muze si pocist. Kdo ne, asi se to zitra dozvi na dot.kde.org . Ja se totiz 
dal na spisovatelovani :) , celou situaci jsem dost dukladne analyzoval a 
mam na podporu svych tvrzeni dost slusne podklady. Nejvetsi sranda bude, 
jestli v tom lidi od gcc a binutils nenajdou zadnou vaznou chybu a takovy 
neznalek jako ja to bude ucit machry :).

 Lubos Lunak
-- 
 l.lunak na email.cz ; l.lunak na kde.org
 http://dforce.sh.cvut.cz/~seli