[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Reducing the number of conflicts in libraries
From:       Harri Porten <porten () trolltech ! com>
Date:       2001-09-22 14:59:19
[Download RAW message or body]

On Fri, 21 Sep 2001, Lubos Lunak wrote:

> > Has been done for the upcoming Beta 6. Any other striking places ?
> > I just hope that the tradeoffs memory vs. speed are always justified.
> 
>  Hmm, I don't see any such changes in today's rsync. As for the memory vs. 

Takes a while to sync.

> speed, if you use the put_vtable_only_here() hack, that's just one more 
> vtable entry and no speed loss.

But isn't every new vtable entry bad per se ? I don't want Waldo knocking
at my door afterwards ;)

>  Non-inline template methods should be only instantiated when needed, but 
> this still can lead to duplicates. Separating the non-inline methods from the 
> template class definition would usually result in link errors, forcing the 
> developer to use explicit instantiation. So there would have to be some 
> #ifdef controlling whether to separate or not.

OK. That answers my question.

>  I was just asking if people think it would be worth it. I think I'll try to 
> compile qt and part of kdelibs with -fno-implicit-templates and only explicit 
> instantiation, so I can tell how this affects libraries sizes. Adding this 
> explicit template instantiation to Qt can wait. Maybe it won't be worth the 
> trouble at all, or it could be used only in some rather simple cases.

Coolo was experimented with that IIRC. At the same time bero played with
-repo. I once tried it with STL code and gave up cause it unveiled errors
(in the template code) that normally don't show up.

Harri.

[prev in list] [next in list] [prev in thread] [next in thread]