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