Robert,
I'm developing a plugin system and I will be loading several DLLs. Basically, as far as I know, this means having one factory_map per DLL (on Windows).
This depends on how you want to use the factory_maps. Do you want to close the shared libraries that you aren't using? If not, just use the same factory_map for every shared library. Unless you have a LOT of separate shared libraries, this is usually a good solution (if you have a lot, you may not want the unused libraries taking up RAM). If you do want to close unused shared libraries, it's a bit trickier. I had some code that did this, but have let it languish because it didn't cover a number of special cases. Here is more or less how it worked: - Create a counted_factory_map instead of a factory_map. Internally, a counted_factory_map contains a separate map and shared_library object for each shared library. - Whenever you ask it to add a constructor for a class T, it instead adds a constructor for a class counted<T> (which is a derived class of T), which increments and decrements a counter whenever it is created or destroyed. - There is a function in the shared library that can be called to see how many objects are currently live from the given shared library. - You can call a function on the counted_factory_map to do garbage collection - ie, close shared libraries with no live objects. The reasons this code is not currently used in Extension: - It requires a duplicate of almost every class in Extension - a counted version and a non-counted version. - The counted versions have very high coupling - whereas the uncounted versions of shared_library and factory_map are very loosely coupled. It also makes it impossible to use parameter_map in its current form. - It requires, in the common case, the use of mutexes to protect the counters. This requires linking in the Thread library. - It only works if all you are doing in a shared library is constructing objects using counted_factory. If you take a reference to anything else in a shared library, you risk having a dangling reference when all of the counted<T> objects are destroyed. Note that this can be alleviated by using a separate shared_library instance if you want to do anything besides populate a counted_factory_map, since a shared library is only closed when all shared_library instances referencing it are destroyed (it is also possible to force a shared library to remain open until program termination - by passing false as the second parameter to the shared_library constructor). There were a few other special cases that broke it as well - but I can't remember what they were right now. I can update that code if people are interested. I certainly wouldn't mind suggestions about how to avoid some of the problems that I listed, or a different way of handling this sort of "garbage collection" of unused shared libraries. Thanks! Jeremy Pack