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 |