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

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-10-09 01:13:26

Janek Kozicki wrote:

... thanks for spotting the typos and other documentation improvements.

> 5. if I use extended_type_info with rtti, will my binary files be
> portable between various platforms? (I assume that without rtti they
> will be)

I'm not sure what you're refering to when you say "binary files".

In the serialization library, binary_archives are not guarenteed
to be portable.

> 6. a bit related question: does binary serialization take care of
> endianess and different sizes of fundamentals across various
> platforms?

No - that's why binary archives are not portable.  If portability
is a requirement, than a different archive must be used.  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.

> 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. 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.

Robert Ramey