Maik,
Sorry for the slow answer, I'm on vacation this week. I may get time to look at it in more depth in a few days.
Fast answer:
I agree.
1 - The shared_library and type_map classes handle much of what you want for DSO. I'm still working on a few convenience functions for the shared_library class, and working on adding some safety mechanisms to help avoid problems with binary incompatibility. Is there any specific functionality you'd like to see that may not be there?
2 - There are very few interdependencies between classes in the library. Many of the classes require either the type_map class or the type info functionality, but there are few, if any, other interdependencies. This means that the library could be split up well in quite a number of ways. I hope to resolve the question of whether or not to split the library during a pre-review process.
Jeremy Pack
On Tue, Oct 21, 2008 at 3:03 AM, Maik Beckmann
<beckmann.maik@googlemail.com> wrote:
2008/10/21 Jeremy Pack <rostovpack@gmail.com>:
> Oliver,
> It depends on what you need the factories to do. Could you describe your use
> case in more detail?
> Boost.Extension is for using factories to create objects of classes declared
> in shared libraries.
> Jeremy Pack
Hi Jeremy,
During the last weeks I've spend some hour on boost.extension.
Organizing factories is what boost.extension is all about at the
moment. But I think means for portable loading of DSO (Dynamic Shared
Objects) are worth a project on its own. Consider this structure
- boost.dso
- portable dlopen
- convenience classes for resource handling
- boost.extension
- factory pattern
- reflection pattern
boost.dso will IMHO be suitable for many developers out there having
their own factories running, but like to have a well tested and
portable dlopen (aka. LoadLibrary on MS Windows). Providing this
needs a heavy testing harness which will take a notable amount of
developer time.
boost.extension itself can concentrate on how to plug and organize
loaded code into an application.
What do you think?
-- Maik