Re: [boost] Re: typeid/type_info proposal (long, go get another jolt cola)

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
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!