"Miguel Silvestre"
Well this example (test_no_rtti)only compiles if the rtti option is enable in the visual studio 2005.
This test tests the extended type info implementation using one that is not based on RTTI. It also tests that two different extended_type_info implementations can be used in the same program. I had envisioned that the selection of an extended_type_info implemenation would be an attribute of the type rather than an attribute of the compiler. In retrospect this might not have been the correct choice. Note that the it is possible to select the "Default" type info implementation simply including the proper appropriate header before any other serialization/archive headers. I called my demo non-rtti implementation of extended_type_info type_info_no_rtti. This demo implementation leveraged on the BOOST_CLASS_EXPORT registration of a GUID string associated with every class. So usage of this implementation of extended type_info depends on BOOST_CLASS_EXPORT being used for all serializable classes. Note that the association of an externalizable string with a type is something that may be useful beyond serialization and hence is (or should be) a part of extended_type_info.hpp. This is also the reason that it wasn't called BOOST_SERIALIZATION_CLASS_EXPORT or something like that. With the passage of time and the benefit of hindsight, I've come to realize that some things I would do differently now. There are few of these sorts of "loose ends" I might like to address. But addressing them would consume a lot more time than it would first appear so things will move slowly along this front.
By the way, what kind of C++ application does not use pointers??? :-/
Hmmm - I think the question in this context would be: "How often is it necessary to serialize pointers?". The answer here is "Not very often". An the follow up question: "How often is it necessary to serialize polymorphic pointers?" Answer: "Even less often". So serialization of pointers in much less frequent then the usage of pointers. Which brings me to my opinion:"Pointers are overused". I think many programs could be improved by diminishing the usage of pointers. In my view, many programs could be improved by: a) replacing new with static variables or better yet instances created on the stack; b) replacing pointer member variables with references or if appropriate const references. This elminates the need for any explict storage management. The usage of reference rather than pointer makes clear the reference is not the "owner". Using a pointer loses this distinction. Of course I'm aware that this is not always appropriate. But in many cases I think the first instinct is to create a pointer and then fix up the storage management by applying shared_ptr. If one is really concientious, he will use weak_ptr on those things which are observers rather than "owners". Basically I think usage of shared_ptr is "too easy" in that if will often make something work which might better be considered more carefully. Robert Ramey