shadowed rel_ops operators

Richard Andrews richarda@ixla.com.au
Sun Jan 21 22:07:00 GMT 2001


> The only people reading comments in the headers are *us*.  If we're going to
> warn about this, we should do so more "proactively."  We can't use #warning;
> stl_relops.h gets included by too many things... hm.
> 
> *sigh*  We need a __builtin_warning that acts like #warning but only takes
> effect when the user actually uses it.  :-)

Actually, the header might be an appropriate location for the warning.

When I first encountered this problem, I was taken straight to bits/stl_iterator.h by the error message.
This might be an appropriate place to put a prominant warning like "If you get an error here it's probably because std::rel_ops conflicts with this operator. Please don't use rel_ops."

I agree it would be much better to have some way of informing the user via a compiler diagnostic.

A quick question: if rel_ops is so bad then why is it being included in so many places? 
I thought the whole point of this discussion was that rel_ops is bad and *I* as a user shouldn't be using it because it conflicts with libstdc++ internal operators. So why does anything else in libstdc++ use rel_ops?






More information about the Libstdc++ mailing list