"RIVASSEAU Jean Noel" wrote in message news:87F60F7FA02FF749AFB02BD9FCAA6B04AC5928@naserv31.nanterre.oberthurcs.com... Hello, To be more precise: I need to serialize objects via pointers to base class. And I need to do it without RTTI. While using extended_type_info_no_rtti for my classes I always get an "unregistered_class" exception at run time. For which class do you get this exception? But I have done the following: in all my classes, in the implementation unit (.cpp) I have included explicitely the headers needed for the archives I use: #include #include Then I have something like that in each class: #include #include #include #include namespace boost { namespace serialization { template<class Archive> void serialize(Archive & ar, PrimitiveMemberVariableSpecification & m, const unsigned int version) { ar & boost::serialization::base_object<MemberVariableSpecification>(m); ar & m.unused_primitive_type; } } // namespace serialization } // namespace boost BOOST_CLASS_TYPE_INFO( PrimitiveMemberVariableSpecification, extended_type_info_no_rtti<PrimitiveMemberVariableSpecification> ) BOOST_CLASS_EXPORT(PrimitiveMemberVariableSpecification) (Here the name of the class is PrimitiveMemberVariableSpecification. Is the above being done for the base class as well? I also want to report a bug in the documentation: the doc says that you should write: <skip> correct - good call. Normally the BOOST_CLASS_EXPORT should *register* all my classes. Why doesn't it work? I have of course also written a correct get_key() virtual function for all my classes. If I just change extended_type_info_no_rtti to extended_type_info_typeid, everything works fine, but I do want extended_type_info_no_rtti. This suggests that all derived classes are being exported. Also, keeping everything in the headers files seems to be a nightmare, although that is what Robert Ramsey recommends. I get tons of multiple definitions errors at link time if I do that (something like: multiple definition of `boost::archive::detail::guid_initializer<MemberVariableSpecification>::instance' with gcc - MinGW 3.4.2) This would surprise me. It suggests that boost/archive/...archive.hpp files are being included in several places. In order to avoid the bothersome warnings above and speed build time. I try to organize my code so that non-inline code is instantiated in only one place. This is not strictly a requirement but generally I've found that things work better this way. And I'm not just referring to serialization code but C++ template code in general. In theory, it shouldn't matter, but in practice things work better this way. So what works well for me is: Include serialization code in the headers corresponding to each type. That way all if the types are imported into different executables they are all all consistent with each other. include boost/archive/... headers only once in each executable. This will eliminate multiple definition errors. This might take a little bit of code re-organization and should not be strictly necessary - but it has worked well for me. Generally I also recommend that any boost/archive/...hpp headers be included before any boost/serialization/...hpp headers. This is not strictly necessary - though it was at one time - but I'm in the habit of doing it. If I find I can't do it, I'm wondering if I "accidently" included a boost/archive/....hpp in another header - which can lead to multiple definition warnngs. Also if I do this an import the module into another executable, I might be instantiating code that isn't called. By sticking to the "rules of thumb" above, I generally avoid some problems and or surprises. Note that there are couple of cases where header order does make a difference. a) boost/serialization/export.hpp has to follow all the boost/archive/...hpp files for each combination of type/archive export to be instantiated. b) boost/serialization/base_object.hpp has to follow all the boost/archive/*.hpp files. This is an oversight which will be corrected in the next version. I have looked at the documentation for two days, read absolutely everything and still do not understand. Maybe I should look at the code ??? LOL - if you like the documentation - you'll love the code ! But, trapping the exception will tell you which class isn't being "registered" which will be helpful information. Robert Ramey