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

From: David Abrahams (dave_at_[hidden])
Date: 2005-02-25 12:55:49

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

> On Fri, 25 Feb 2005 11:05:02 -0500
> David Abrahams <dave_at_[hidden]> wrote:
>
>
> Thanks, David!
>
>
>> > 2. To add support for expressions and lvalues
>> 
>> What do you mean by "support for lvalues?"  typeid is _supposed_ to
>> strip top-level reference.
>
> I meant supporting typeid of functions and objects, like...
>
> struct foo { };
> foo f;
> typeid(f);
>
>  
>> ?? I don't know what "workaround" you're referring to, but detecting
>> null pointers is pretty trivial.
>
>
> Sure, detecting a null pointer before it is dereferenced is trivial, but
> I am not aware of trivial ways to detect a null pointer being
> dereferenced.
>
> struct base { virtual ~base() { } };
> struct derived : public base { };
> base * get_base_ptr();
> typeid(*get_base_ptr());
>
> If get_base_ptr() returns 0, this is not undefined behavior, nor does it
> SEGV, but specifically, it should throw std::bad_typeid.

Heh, 5.2.8/2.  That's _almost_ a very silly exception to the rest of the
C++ rules.

You can deal with this either of 2 ways:

  1. Declare this library to be a workaround for broken
     implmentations.  Inside such a library you can always do
     something strictly illegal but in practice portable. I don't know
     of a machine anywhere that will hiccup when fed this:

     int* f(int& p) { return &p; }
     int* p = 0;
     int* q = f(p);

  2. Write a separate pointee_typeid function.

> Well, for gcc, I have most of the stuff working, even when I assume that
> gcc is broken, and force it to use the workaround code.  However, I
> still run into some problems because typeid behaves differently for
> polymorphic and nonpolymorphic types.  From the docs, is_polymorphic
> requires features that are not present in some compilers.  I am a bit
> concerned about trying workarounds that I can not test because I do not
> have those compilers available.

If the compilers are broken anyway, I wouldn't worry about it.
There's no rule that every Boost library has to work perfectly on
every nonconforming compiler.  If there are problems, we'll find out,
and adjust accordingly.

>
>> I think you're giving up too easily.
>
> Fair enough, but I wouldn't quite say I was giving up.  I feel that I do
> not have enough information at this time to keep going.  Specifically, I
> am concerned that I may not be able to get common functionality across
> the board because of bad typeid() implementations.  I think there are at
> least two areas that can not be overcome without correct native typeid()
> support (exception of deref NULL and not evaluating the expression).  I
> think we can come close on the others, but I am not sure how close on
> some older compilers.  So, I am not ready to call it quits, and I am
> sorry that is how it came across.  Instead, I think I need assistance
> from others who have other platforms available to them to determine how
> we should proceed with typeid().
>
>
>
>> 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.
>
>
> Thank you very much for your insights.  I hope I have "continued" the
> conversation, and not "deadened" it.  I certainly do not pretend to have
> all the answers, so do not take me as being argumentative.  However, the
> questions I have been forced to answer leave me scratching my head as
> how I can do so for other compilers...
>
>
> <lame_excuse>
> FWIW, my experience with C++ is quite detailed, but my experieince with
> backward portability is very small.  I have been (un)fortunate in that I
> have never had to work on a project that required backward compatibility
> with older compilers.  

You're still not... except inasmuch as you want to replace the code in
Boost.Python, it needs to work as well as it used to on platforms that
library supports.

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