On Fri, 25 Feb 2005 11:05:02 -0500 David Abrahams <dave@boost-consulting.com> 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>