This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: shadowed rel_ops operators


On Mon, Jan 22, 2001 at 05:08:47PM +1100, Richard Andrews wrote:
> 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?

It's not bad because it conflicts with library-internal operators, 
but because it conflicts with any template operator of the same name.  
That said, it's a good question.  

A cursory examination suggests that the inclusions are just an 
inheritance from the SGI STL, in support of compilers that fail to
implement template overloading.  It appears that the includes can, 
and should, be eliminated.  Once they are eliminated, we can also 
add a #warning to stl_relops.h.

Nathan Myers
ncm at cantrip dot org

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]