This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: shadowed rel_ops operators
- To: libstdc++ at gcc dot gnu dot org
- Subject: Re: shadowed rel_ops operators
- From: Nathan Myers <ncm at nospam dot cantrip dot org>
- Date: Fri, 19 Jan 2001 23:46:07 -0800
- References: <0C79E524ECB8D311BB48009027765E8A0B74B8@BASKETBALL>
- Reply-To: libstdc++ at gcc dot gnu dot org
On Sat, Jan 20, 2001 at 03:29:44PM +1100, Richard Andrews wrote:
> > > 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.
The rel_ops operators are where they are because they *don't*
*work* *right*. Dragging them into std:: would violate the
standard by breaking useful conforming programs.
> 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?
Yes. It is not the iterator operators that break rel_ops, but rather
the rel_ops operators that break the iterator operators, as indeed they
break all similar operators.
The rel_ops operators are not useful. They were a mistake. If you
insist on using them, you will have trouble. Nobody will care, because
you asked for it.
Nathan Myers
ncm at cantrip dot org