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 12:17:47

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.

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

Maybe my definition of "fair amount" is out of the norm.  I consider
msvc_typeid.hpp to be a fair amount, and to handle other corner cases I
have found, it requires a bit more than that.

> > , 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.

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.

> 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.  Support for older compilers stopped at a certain
version, and use of more modern versions required upgrading to a
compiler that supported the new code.  So, getting code to work on a
whole range of compilers is a new realm for me.  I find it difficult
(especially when I am "guessing" at how these compilers will behave),
and, frankly, no fun at all.
</lame_excuse>