Re: [boost] [serialization] extended_type_info as extensions/plugins library ?

From: Janek Kozicki (janek_listy_at_[hidden])
Date: 2006-10-09 04:12:10

Robert Ramey said:     (by the date of Sun, 8 Oct 2006 22:13:26 -0700)

> The documentation contains a portable binary archive as part of
> an illustration on how to derive from an existing archives.
> Portable binary archives are not as fast as native binary
> archives - but faster than text based archives.

thanks. I'm still digging through the docs, so haven't read that yet.

> 
> > 7. the real question: is it possible to use extended_type_info for the
> > class factory purposes without actually using serialization, for
> > example like that below (with or without rtti). It's just your example,
> > slightly modified:
> ...
> > int main( int /* argc */, char* /* argv */[] )
> > {
> > // the most important line:
> > // this function takes 'const char* class_name' (or GUID ?) as an
> >    argument. polymorphic_base*
> > p=please_somehow__create_an_instance_of("polymorphic_derived1"); }
> 
> A ha - this is the missiing magic.  The equivalent of this code is currently
> buried in iserialer.hpp.  If you think about it - it HAS to be there in 
> order for serialization of exported pointers to function.

Ok, I'll have a look at it. I had similar experience with serialization
for yade. First - the factory was part of serialization, and looked like
very difficult to separate. But later we managed to separate this
library. Hovewer yade's serialization is much simpler. We've never
thought about exported pointers to function :)

So I understand that the case here is even more difficult.

> I believe it could be extracted from this location and moved to
> the extended_type_info code. I don't think it's trivial however.
> But I believe that the end result would be an (almost) complete
> solution for dynamically loading DLLS automatically
> whenever an exported class is required.

So I think that this should be the goal to pursue if we want to add an
extensions/plugin library into boost.

(also to Jeremy)

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.

-- 
Janek Kozicki                                                         |