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