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


 > I have made the changes on my system and recompiled my extensive list
of
> container code without any problems that I can see. So it looks like
its
> 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
considerations.)

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
types.)

----

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?


Rich

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