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