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

List:       kde-core-devel
Subject:    Re: KCModule question
From:       Simon Hausmann <hausmann () kde ! org>
Date:       2002-01-22 15:31:40
[Download RAW message or body]

On Tue, Jan 22, 2002 at 04:14:26PM +0100, Daniel Molkentin wrote:
> On Tuesday 22 January 2002 16:04, Simon Hausmann wrote:
> >On Tue, Jan 22, 2002 at 04:00:00PM +0100, Daniel Molkentin wrote:
> >> function anyway. I am just wondering if we should still move the init
> >> stuff to an own  application before 3.0 so we can use KGF everywhere and
> >> to get it (hopefully) a bit faster.
> >
> >What do you mean with moving init stuff to an own application?
> >
> 
> Well, I wasn't very precise: I meant splitting all modules where kcmodules 
> have an init functions. That way, the libloader doesn't need to load the 
> other stuff (mostly, the _init part is like 10% of the library size) and we 
> can use KGenericFactory to call the init functions.

Ahh, I see. Hm, I see no problem with having something like this:

K_EXPORT_COMPONENT_FACTORY( init_libfoo, KGenericFactory<MyModule>( "mymodulename" ) )

K_EXPORT_COMPONENT_FACTORY( kcminit_libfoo, KGenericFactory<...

The only change necessary would be a simple extension of KLibrary to
make the entry point symbol configurable at run-time, when querying
the factory object.

But I'm not sure if it's worth it to use a factory to instantiate an
object just to call one function and be done. I mean, there's no
state involved or anything like that. All that's needed is to call
one simple argument-less function. And given the fact that we have
only a couple of those kcminit modules I don't think the little
extern "C" void init_foo() { ... } really hurts here. It's not that
everyone and his grandmother are going to write kcminit modules,
where a 1000% beautiful API without any little Cism is necessary ;-)

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