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

From: David Abrahams (dave_at_[hidden])
Date: 2005-02-25 11:05:02

Jody Hagins <jody-boost-011304_at_[hidden]> writes:

> The library, as used in Boost.Python, relies on calling the no-parameter
> template function, type_id, to get the type info object.  Use of
> typeid() by itself is absent, because of the problem with compilers
> getting the typeid() implementation correct.  For example:
>
> struct foo { /* ... */ };
> boost::python::type_info ti = boost::python::type_id< foo >();
>
> Unfortunately, boost::python::type_id<>() has a couple major drawbacks
> (and a number of "minor" ones).
>
> 1. It only supports type-id calls, with a specific type passed as a
> template parameter.  The ability to compute type_info based on the
> result of an expression is scant (a bit more functionality can possibly
> be obtained with more tricks like the ingenious typeof() stuff recently
> posted).

Yeah, it's hard to suppress actual evaluation of the expression
without typeof.

> 2. To add support for expressions and lvalues

What do you mean by "support for lvalues?"  typeid is _supposed_ to
strip top-level reference.

> overloads of type_id()
> can be provided.  This works reasonably well (with enough machinery to
> get around compiler problems), but the spec for typeid() says that the
> expression is not supposed to be evaluated (unless the expression is an
> lvalue of a polymorphic type, or dereferences a pointer to a polymorphic
> type).  I have yet to see a way to call a function and prevent the
> expression from being evaluated (maybe with some modern tricks and
> is_polymorphic -- but we are then probably leaving several compilers
> behind as well).  Also, I have been unable to get the "workaround" to
> throw std::bad_typeid when dereferencing a null pointer, as specified in
> 5.2.8.2).

?? I don't know what "workaround" you're referring to, but detecting
null pointers is pretty trivial.

> 3. For compilers with bad cv-qualifier support wrt typeid(), it requires
> a fair amount of machinery to get rid of the cv-qualifiers. 

It shouldn't.

> Unfortunately, the same machinery makes it difficult to preserve the
> polymorphic requirements of 5.2.8.2

Details?  Oh, I think I can guess...

> , and I have yet to find the right
> code to get this to work (though I think it may be possible).

It should be pretty trivial if you just add an additional function
parameter.

> Thus, we face a dilemma.  Either always use the native typeid(), knowing
> that your compiler may not fully support it "by the book" or provide
> some workaround, that will not provide everything either.  By fixing
> some things, others are broken.  

I think you're giving up too easily.

> So, let's move to type_info.  I think this one is a bit more clear
> (though we still need some compiler workarounds).  However, the only
> real workarounds I have found so far involve "broken" comparison
> operators.  I think these are fairly well known, and mostly solved.  I
> also have a fairly extensive set of tests for native std::type_info, as
> well as the new boost::type_info.  However, I am still hung up on the
> whole typeid thing stated above.
>
>
>
> I tend to think that most use of typeid() will work as expected.  The
> "major" problems concern quite old compilers (I think), 

Yeah.  There are actually older EDG compilers (e.g. SGI Irix) for
which the problems can be insoluble.  Comparison across shared
libraries is done based on addresses, and in different translation
units, the same type may have different string representations.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com