KDE a sdilene knihovny (Was Re: Programovani - shared libraries na Linuxu)
Pavel Kankovsky
peak na argo.troja.mff.cuni.cz
Úterý Září 11 06:13:59 CEST 2001
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."
Další informace o konferenci Linux