Re: [boost] Any interest in static plugins?

Subject: Re: [boost] Any interest in static plugins?
From: Dave van Soest (dsoest_at_[hidden])
Date: 2009-12-04 17:20:36

Hi Christian,

> Sure, you can come up with and practically use toy systems with a given
>> linker in a given configuration that have no problem. But when you have
>> complex and.or derived types, or use dynamic linking, it becomes an
>> intractable problem.

Can you name any complex or derived types that wouldn't work?

I've run some successful tests with dynamic linking. But I don't know 
yet whether it works on all platforms.

> The problem here is that it is just a bad idea to use statics and type
> factories in this way. There will be problem after problem. What are these
> problems? The first problem is that of non-deterministic ordering of
> initialisers. The second problem is that you're doing work and calling
> functions before main(). The third problem are all the unknown problems that
> will arise by using this approach.

The order in which plugin factories are initialized shouldn't matter. 
The factory manager is initialized when the first plugin factory tries 
to register with it. So I don't see the problem here.

What is wrong with calling functions before main(), if you do it 
carefully? The client coder won't get the opportunity to call any 
function before main() through this library.

My response to the third problem is, just like the problem itself, yet 
unknown.

> This approach has been tried many times before. AFAICT, it has never ended
> well. It requires bad practise (singletons, globals). It is untestable. It
> doesn't work well with DLL's. If you use it in a threaded application, there
> will be problems because of the globals. It doesn't scale to use types that
> have other type components, or derive from other types.

I will be doing more research to see whether my approach is different 
from the ones that didn't end well.

I don't have any problems with using singletons, as long as they are 
used for the right purposes.

Why is it untestable? I don't have a clue here.

As I said, I ran a successful test using dynamically loaded libraries.

I don't see any problems with threaded applications. The 'global' 
factories are not accessible outside there compilation unit. And the 
global factory manager(s) don't change any global information.

I don't see why it doesn't scale to certain types. Can you give an 
example of a structure that wouldn't work?

> Yes, it can work in a simple, limited case. But because of the scaling
> problems, it is inadvisable to do this. I think that perhaps everyone has to
> try to do this once, before they realise that it is a bad idea ;)

I haven't reached the point that I realised it's a bad idea. I'm seeing 
more use-cases each day. That's keeping me from giving up too early. 
Moreover, I haven't seen any concrete counter-example yet. And even if 
can only prove it to work on just a part of the platforms, it will still 
be valuable. But in that case not for inclusion in Boost of course.

> I could well be wrong, and I don't think I will dissuade you from continuing
> your work on this. Best of luck.

Thanks. I really appreciate the time you spent on joining the 
discussion. Indeed you can't dissuade me from continuing this work, but 
still I really think it's valuable to have a sceptical counterweight to 
keep me from turning assumptions into beliefs and pointing me at 
potential problems I haven't really well thought out.

Best regards,
Dave van Soest