This is the mail archive of the
mailing list for the libstdc++ project.
RE: shadowed rel_ops operators
- To: "'Nathan Myers '" <ncm at nospam dot cantrip dot org>, "'libstdc++ at gcc dot gnu dot org '" <libstdc++ at gcc dot gnu dot org>
- Subject: RE: shadowed rel_ops operators
- From: Richard Andrews <richarda at ixla dot com dot au>
- Date: Sat, 20 Jan 2001 15:29:44 +1100
> I have made the changes on my system and recompiled my extensive list
> container code without any problems that I can see. So it looks like
> safe to do this.
The rel_ops members were sequestered there to keep them out of trouble.
(They would have been removed entirely but for political
Exposing them is dangerous because (IIRC) they are too greedy; they
interfere with other template operators that users define. (Recall
that users are allowed to specialize std:: templates on their own
From my position it seems that the templated __normal_iterator operators are
just as "greedy" as the rel_ops operators.
For my situation (inheriting from iterators) they are worse than using
rel_ops in <iterator> since they prevent me from using rel_ops which is
guaranteed by the standard [20.2]. I'm not sure what the "political"
considerations are you are alluding to. Maybe someone can fill me in since
I'm relatively new to this group.
It seems to me that having any templated operators that can overlap those in
rel_ops in some situation _WILL_ under particular conditions conflict with
rel_ops in an unresolvable manner so unless the rel_ops operators are used
OR every iterator has only member operators, standard code will fail to
compile under libstdc++.
Am I missing something here?