Martin Bonner wrote:
From Janek Kozicki: So I think that this should be the goal to pursue if we want to add an extensions/plugin library into boost.
Think of it. With two separate libraries (one for serialization and one for plugins) the user will have to register each class twice. Serialization already registers classes with GUID (Global Unique IDentifier) so plugins/extensions library should take advantage of that.
I'm not convinced. It seems to me that the registration for plugins and for serialization is rather different.
Serialization: - When you see this GUID, this is how to create the class.
Plugins: - This is another object with an IFoo interface.
Almost but not quite. This is another object with an IFo interface. But which object. There can be many different types. So each type is identified by a GUID - same one used by the serialization system. So the magic missing function is BOOST_CLASS_EXPORT(IFoo_derived_1, IFOO_ONE) IFoo *ifptr = static_cast<IFoo *>(extended_type_info::create_object(IFOO_ONE)) This is basically how microsoft COM works. This system would be simple, fast, powerful and easy to implement. It would be upto the programmer to ensure that the static_cast is correct.
Perhaps I'm misunderstanding what you mean by plugin, but I think of something like Internet Explorer, or Photoshop, where the application has a bunch of IFoo pointers, and it iterates through all of them to extend its menu. When the menu is clicked it calls the appropriate function through the IFoo pointer.
This is exactly the case that I have in mind.
I don't really see how the two relate.
Hopefull the above will clarify this. RObert Ramey