The package documentation on this subject. There is also a program - test_no_rtti - which tests a type designated to use a different system than rtti and verify that it can interoperate with one that does. I should note that although I designed, implemented and tested, and documented this facility, I don't know how well it will work in a real project. I've recieved very little feedback on this aspect of the library. I don't know if this indicates that it works well, or that it is rarely if ever used. I suspect the latter. Note that RTTI is only need for serialization of pointers so if your application doesn't need to do that - you will have no problem. Robert Ramey Miguel Silvestre wrote:

Hi!

I turnned off the RTTI because in my projct it must be disconnected. No turn the RTTI on and the file compiled and run successfully.

...

S.

It seems to me that I'm in big trouble!!!!!!! Isn't there any way of doing this with the rtti turned off at visual studio???

On 1/18/07, Robert Ramey <ramey@rrsd.com> wrote:

...

If you're compiling from the IDE, you might double check that the RTTI option is actually set to true. In my experience with MSVC this option is by default reset to off.

Robert Ramey

Miguel Silvestre wrote:

...

...

Hi!

I'm tryingto compile and test the test_no_rtti for deriving pointers of derived classes.

I'm getting a crash in the file dbgheap.c line 266 when the boost tries to do this: return dynamic_cast<T>(u); on file smart_cast.hpp line 76.

I'm using VC-80 compiler. In the attach I send the file (a little bit modified, since I'm looking for this to compile :S).

Any sugestion please????

-- Miguel Silvestre

...

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

"Miguel Silvestre" <msilvestre@gmail.com> wrote in message news:864c24fd0701190440rfc273a4yadded581316d7069@mail.gmail.com...

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