Sohail Somani wrote:
Options
a) don't use export - use explicit archive level registration instead. b) some sort of explicit type registration. Users could just put at after the main entry point and/or in the DLL loading phase
How is (b) different from (a)? Is this related to your "load/save by name?"
The issue is the invocation of a function which impliles the construction of the required type. This occurs as a side effect of serializing the type in an archive. But it could ust as well be done explicitly before any threads are started. This explanation is much confused by the fact that I've used "registration" to mean more than one thing. One thing is the creation of the suitable extended_type_info object (which is being discussed here). while another thing is the construction of certain serialization objects which occur for every combination of archive type and serializable type which is serialized through a pointer. This latter is also done as a side effect of just using serialization.
And once embarks upon this kind of effort, its interesting to consider "finishing" extended type info with some missing functionality like "construct from export name".
I have no idea why the two affect each other!
Your idea is to refine, and improve extended_type_info. It has utility outside the serialization package. However to make this as useful as it should be would require adding some "missing" functions and improving the documentation to make it more of a "first class" boost module.
It would also be interesting to investigate if there is some sort of lock free solution - At least on some compilers/ processors.
I'm not going to touch lock-free lazily initialized singletons! I'd rather have my code work ;-)
Just goes to show that no good idea goes unpunished.
:-)
SOOO I'm am positive about the idea. However, like most good ideas, its a lot bigger than it first appears.
Don't see why myself. In multi-threaded builds of serialization, we link with Boost.Thread and use boost::once.
Having written this, it would seem that this is territory well traveled by those working on a good Singleton suitable for such a purpose.
I've worked on the above singleton, tested it on a few x86 OSes and it seems to work. But I would be very happy if someone has a better solution that is tested.
(Amazingly, I don't even know if boost has such a thiing) Ideally, I would just like to use that (assuming it doesn't import everything on planet earth).
I believe that Boost has everything you need for a *correct* solution.
Sohail