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