From: Jody Hagins (jody-boost-011304_at_[hidden])
Date: 2005-02-25 10:48:05
On Thu, 24 Feb 2005 20:51:43 -0800
"Robert Ramey" <ramey_at_[hidden]> 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
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
3. extended_type_info constructor is only visible to derived classes
(actually, extended_type_info_typeid::get_instance() creates all the
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!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk