Boost logo

Boost :

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;

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

struct base { virtual ~base() { } };
struct derived : public base { };
base * 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...

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at