On Thu, 24 Feb 2005 20:51:43 -0800 "Robert Ramey" <ramey@rrsd.com> wrote:
The serialization library deals with a lot of these issues. I've managed to make it work with all the compilers that boost supports. I didn't have problems getting it to this point - but I had no choice but to resolve them all somehow. The result of my efforts is extended_type_info and void_cast. Asside from the fact that not all compilers handled the 'const' the same way, I also needed a little more information than the normal typid() delivers. Specifically I wanted to cast between pointers at runtime eventhough the classes weren't polymorphic in the usual sense.
I toyed with the idea of documenting extended_type_info and void_cast separatly. But I sort of bogged down while trying to imagine how it might be used by other applications. I do think it could be enhanced and documented to handle the applications you have in mind - but I can't say for sure.
Given that you've already invested a lot of effort understanding all the issues related to this, I would much appreciate it if you could take a look at extended_type_info and void_cast in the serialization package and render your assessment of their more general utility.
OK. I am leaving tonight, for the weekend, and I doubt I will have a chance to look at it before then. However, I will look at it next week and let you know my thoughts. I took a BRIEF glance, and here are my initial comments. Please correct/redirect me where I am in error. Also, note that I have not had time to think whether these comments mean I agree/disagree with the choices, they are just initial thoughts (and may even be totally inaccurate). 1. extended_type_info is a base class for all other type_info classes. 2. extended_type_info disables copy/ctor and copy/assignment, which is one of the perceived benefits of using a user defined type_info replacement. 3. extended_type_info constructor is only visible to derived classes (actually, extended_type_info_typeid::get_instance() creates all the instances). 4. No conversion from std::type_info to extended_type_info. 5. Must register explicitly to use (via extended_type_info::key_register or defining extended_type_info_no_rtti<T>::type_key, or setting the public "key" member variable). 6. I realize (as of 1996), the default linkage of inline functions is external, but I am still reluctant to put static "singleton" data inside an inline function. 7. I still think you have the same issues with typeid() that I describe earlier, since all of your access to std::type_info is through a naked call to typeid(). I could not find any code that tried to get around broken implementations of typeid(). 8. Your "solution" is similar to that in Boost.Python as it is to use the extended_type_info and extended_type_info_typeid<T>::get_instance(), which has different semantics than typeid(). However, you go a step further to prevent any kind of unexpected results, since you can not create an extended_type_info out of a std::type_info. 9. Your concept may provide benefits outside serialization, but I think it is a separate tool, and I do not think it addresses the desire to have a more usable std::type_info. Thanks again for working with me on this!