GCC 3.1 Release

GCC 3.1 Release

[Mark Mitchell]

Now that Richard has made GNATS immune to random new bugs being classified
as "high" priority, it makes sense to go back to using high-priority bugs
in GNATS -- rather than an external issuse list -- as our way to measure
what needs to be done before the release.

To that end, I've made sure that everything on the issues list is marked
"high" in GNATS, and checked in a new copy of the issues list that
indicates it is no longer in use.

Now we need to weed out any not-really-high-priority bugs in GNATS, and
fix what's there.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.1 Release

[Tom Tromey]

>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:

Mark> Now we need to weed out any not-really-high-priority bugs in
Mark> GNATS, and fix what's there.

FYI, this has already been done for the java and libgcj categories.

Tom

Re: GCC 3.1 Release

[Phil Edwards]

On Tue, Apr 02, 2002 at 02:23:00PM -0800, Mark Mitchell wrote:
> Now we need to weed out any not-really-high-priority bugs in GNATS, and
> fix what's there.

There are four hi-pri reports for libstdc++.  They may or may not qualify as
"not really," if you and Benjamin would like to make that call.


3759 -- basically fallout from the committee LWG's DR 225 and 229.  I vote
        that this PR be suspended until those DRs get resolved, just because
        there doesn't seem to be anything effective we can do until then.

3628 -- the std::rel_ops operators cause ambiguous overloads with vector
        and string iterators.

4260 -- Is it HPUX?  Is it libtool?  Is it libstdc++?  Is it collect2?

5396 -- This is one of those PRs that got set to high by the submitter.
        I plan to test this myself as soon as I get a working build
        on solaris.  Debugging this kind of thing is a nightmare, since
        printing out local and member variables in gdb fails with some
        kind of RTTI error, so stepping through the I/O library doesn't
        really gain anything.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: GCC 3.1 Release

[Joe Buck]

> On Tue, Apr 02, 2002 at 02:23:00PM -0800, Mark Mitchell wrote:
> > Now we need to weed out any not-really-high-priority bugs in GNATS, and
> > fix what's there.
> 
> There are four hi-pri reports for libstdc++.  They may or may not qualify as
> "not really," if you and Benjamin would like to make that call.
> 
> 
> 3759 -- basically fallout from the committee LWG's DR 225 and 229.  I vote
>         that this PR be suspended until those DRs get resolved, just because
>         there doesn't seem to be anything effective we can do until then.

This one should not be high priority, since the standards committee is
battling it out.  Certainly given the April 15th schedule, we should punt.

> 3628 -- the std::rel_ops operators cause ambiguous overloads with vector
>         and string iterators.

I'd really like to see this one fixed.  IMHO, the fixing isn't hard, it's the
arguments between the contributors that seem to get in the way (some going
so far as to try to deprecate std::rel_ops so we don't have to think about
a fix).  This causes portability problems so bad that I wound up turning
all the !='s into !(... == ...) in a big hunk of code that successfully
ran on about six compilers (including gcc 2.95.x and the very nitpicky
HP aCC).

> 4260 -- Is it HPUX?  Is it libtool?  Is it libstdc++?  Is it collect2?

No idea.  But is this issue even relevant for the 3.1 release, where minor
ABI breakage is *planned*?  (to fix some ABI conformance bugs).  If not,
then it's not a blocker for the release.

> 5396 -- This is one of those PRs that got set to high by the submitter.
>         I plan to test this myself as soon as I get a working build
>         on solaris.  Debugging this kind of thing is a nightmare, since
>         printing out local and member variables in gdb fails with some
>         kind of RTTI error, so stepping through the I/O library doesn't
>         really gain anything.

Is this a sync-with-stdio issue?  Does turning off synchronization make
the performance bug go away?

Re: GCC 3.1 Release

[Phil Edwards]

On Wed, Apr 03, 2002 at 04:01:34PM -0800, Joe Buck wrote:
> > 4260 -- Is it HPUX?  Is it libtool?  Is it libstdc++?  Is it collect2?
> 
> No idea.  But is this issue even relevant for the 3.1 release, where minor
> ABI breakage is *planned*?  (to fix some ABI conformance bugs).  If not,
> then it's not a blocker for the release.

That's my opinion also, but I'm not a HPUX user.


> > 5396 -- This is one of those PRs that got set to high by the submitter.
> >         I plan to test this myself as soon as I get a working build
> >         on solaris.  Debugging this kind of thing is a nightmare, since
> >         printing out local and member variables in gdb fails with some
> >         kind of RTTI error, so stepping through the I/O library doesn't
> >         really gain anything.
> 
> Is this a sync-with-stdio issue?  Does turning off synchronization make
> the performance bug go away?

The submitter's testcase is using fstreams, so it doesn't look to be s-w-s.

I started a solaris bootstrap just before I posted my summary, and it's still
going, so I haven't had a chance to poke at it yet.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: GCC 3.1 Release

[Mark Mitchell]

--On Wednesday, April 03, 2002 04:01:34 PM -0800 Joe Buck 
<Joe.Buck@synopsys.com> wrote:

>> On Tue, Apr 02, 2002 at 02:23:00PM -0800, Mark Mitchell wrote:
>> > Now we need to weed out any not-really-high-priority bugs in GNATS, and
>> > fix what's there.
>>
>> There are four hi-pri reports for libstdc++.  They may or may not
>> qualify as "not really," if you and Benjamin would like to make that
>> call.
>>
>>
>> 3759 -- basically fallout from the committee LWG's DR 225 and 229.  I
>> vote that this PR be suspended until those DRs get resolved, just because
>>         there doesn't seem to be anything effective we can do until then.
>
> This one should not be high priority, since the standards committee is
> battling it out.  Certainly given the April 15th schedule, we should punt.

Agreed, I've downgraded it.

>> 3628 -- the std::rel_ops operators cause ambiguous overloads with vector
>>         and string iterators.
=
> I'd really like to see this one fixed.  IMHO, the fixing isn't hard

Do you have a patch?  Is the problem the result of a compiler bug, or
a library bug?

>> 4260 -- Is it HPUX?  Is it libtool?  Is it libstdc++?  Is it collect2?

> No idea.  But is this issue even relevant for the 3.1 release, where minor
> ABI breakage is *planned*?  (to fix some ABI conformance bugs).  If not,
> then it's not a blocker for the release.

I've closed this issue.  As you say, we know there is ABI breakage.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.1 Release

[Jason Merrill]

BTW, I notice that most of the current high-priority c++ PRs are classified
as ice-on-illegal-code.  I don't think such bugs merit high priority, even
if they are regressions.

Jason

Re: GCC 3.1 Release

[Joe Buck]

> >> 3628 -- the std::rel_ops operators cause ambiguous overloads with vector
> >>         and string iterators.
> =
> > I'd really like to see this one fixed.  IMHO, the fixing isn't hard
> 
> Do you have a patch?  Is the problem the result of a compiler bug, or
> a library bug?

It's a library bug.  It can be fixed by adding explicit comparison
operators for the vector and string iterators.

The downside of that is that it adds a bit of extra bloat.

Re: GCC 3.1 Release

[Benjamin Kosnik]

> It's a library bug.  It can be fixed by adding explicit comparison
> operators for the vector and string iterators.

Enough talk. Let's see the patch.

:)

-benjamin

Re: GCC 3.1 Release

[Gabriel Dos Reis]

Joe Buck <Joe.Buck@synopsys.com> writes:

| > >> 3628 -- the std::rel_ops operators cause ambiguous overloads with vector
| > >>         and string iterators.
| > =
| > > I'd really like to see this one fixed.  IMHO, the fixing isn't hard
| > 
| > Do you have a patch?  Is the problem the result of a compiler bug, or
| > a library bug?
| 
| It's a library bug. 

Well, I'm not at all convinced that this is a library bug.  But I
guess we'll just restart an old discussion.

| It can be fixed by adding explicit comparison
| operators for the vector and string iterators.

Huh?!?

-- Gaby

Re: GCC 3.1 Release

[Mark Mitchell]

> It's a library bug.  It can be fixed by adding explicit comparison
> operators for the vector and string iterators.
>
> The downside of that is that it adds a bit of extra bloat.

If you can produce a patch for the problem, the I will review it --
and I'm sure the V3 folks will be happy to do so as well.  It sounds
like you're in the best position to produce the patch.

Thanks,

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.1 Release

[Joe Buck]

> > It's a library bug.  It can be fixed by adding explicit comparison
> > operators for the vector and string iterators.
> >
> > The downside of that is that it adds a bit of extra bloat.
> 
> If you can produce a patch for the problem, the I will review it --
> and I'm sure the V3 folks will be happy to do so as well.  It sounds
> like you're in the best position to produce the patch.

I'm going to give you a partial patch.  The reason is that I still
haven't won my battle with a company lawyer who doesn't like the FSF's
patent clause in the contribution document.  So instead I'll show you
how to fix the bug by giving one of the four new templates needed.
That way the size of my contribution will be smaller than the limit
RMS feels comfortable with for folks with no papers on file.

The issue is that, for std::rel_ops::operator!=, the types of the two
arguments are constrained to be the same, while in stl_iterator.h, we
define another operator!= template that allows the two arguments to be
different.  The solution is to add another template definition, as
follows:

*** /u/jbuck/gcc-3.1-pre/include/g++-v3/bits/stl_iterator.h~	Wed Apr 10
13:26:51 2002
--- /u/jbuck/gcc-3.1-pre/include/g++-v3/bits/stl_iterator.h	Wed Apr 10
16:43:56 2002
***************
*** 645,650 ****
--- 645,657 ----
	     const __normal_iterator<_IteratorR, _Container>& __rhs)
    { return !(__lhs == __rhs); }
  
+   // the following is to avoid conflict with std::rel_ops::operator!=
+   template<typename _Iterator, typename _Container>
+   inline bool
+   operator!=(const __normal_iterator<_Iterator, _Container>& __lhs,
+	     const __normal_iterator<_Iterator, _Container>& __rhs)
+   { return !(__lhs == __rhs); }
+ 
    // Random access iterator requirements
    template<typename _IteratorL, typename _IteratorR, typename
_Container>
    inline bool 

---------------------------------
This removes the ambiguity: in all cases where the new template can
be used, it wins over the one from rel_ops because it is more specific,
as well as the alternative template in stl_iterator.h.

In addition to the above, we also need the corresponding operator>,
operator>=, and operator<=.

Re: GCC 3.1 Release

[Gabriel Dos Reis]

Joe Buck <Joe.Buck@synopsys.com> writes:

[...]

| I'm going to give you a partial patch.  The reason is that I still
| haven't won my battle with a company lawyer who doesn't like the FSF's
| patent clause in the contribution document.  So instead I'll show you
| how to fix the bug by giving one of the four new templates needed.
| That way the size of my contribution will be smaller than the limit
| RMS feels comfortable with for folks with no papers on file.
| 
| The issue is that, for std::rel_ops::operator!=, the types of the two
| arguments are constrained to be the same, while in stl_iterator.h, we
| define another operator!= template that allows the two arguments to be
| different.  The solution is to add another template definition, as
| follows:

A better solution is to move all those things that have no business in
std:: into __gnu_cxx::.  If we don't do it now we can't do it in a dot
release as it would be an ABI change -- and I would hate to maintain
two different versions.

-- Gaby

Re: GCC 3.1 Release

[Joe Buck]

I wrote:
> | The issue is that, for std::rel_ops::operator!=, the types of the two
> | arguments are constrained to be the same, while in stl_iterator.h, we
> | define another operator!= template that allows the two arguments to be
> | different.  The solution is to add another template definition, as
> | follows:

Gaby writes:
> A better solution is to move all those things that have no business in
> std:: into __gnu_cxx::.  If we don't do it now we can't do it in a dot
> release as it would be an ABI change -- and I would hate to maintain
> two different versions.

I don't understand.  Do you mean that you want to move __normal_iterator
to a different namespace?

In any case, a decision to move things around seems to me to be orthogonal
to the operator!= issue.

Re: GCC 3.1 Release

[Mark Mitchell]

--On Wednesday, April 10, 2002 7:55 AM -0700 Joe Buck 
<Joe.Buck@synopsys.com> wrote:

>
>> > It's a library bug.  It can be fixed by adding explicit comparison
>> > operators for the vector and string iterators.
>> >
>> > The downside of that is that it adds a bit of extra bloat.
>>
>> If you can produce a patch for the problem, the I will review it --
>> and I'm sure the V3 folks will be happy to do so as well.  It sounds
>> like you're in the best position to produce the patch.
>
> I'm going to give you a partial patch.

OK, I understand your situtation.

I think your patch makes sense.  Benjamin what do you think?

Gaby, if we can do something like this, it will definitely make things
easier for users.  The standard specifies that std::rel_ops exists, and
it also specifies that iterators have an operator==, and it certainly
makes sense to make those two things work together if at all possible.

Joe's patch looks logical; do you have an alternative patch that you
think would be a cleaner solution?

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.1 Release

[Janis Johnson]

On Tue, Apr 02, 2002 at 02:23:00PM -0800, Mark Mitchell wrote:
> Now that Richard has made GNATS immune to random new bugs being classified
> as "high" priority, it makes sense to go back to using high-priority bugs
> in GNATS -- rather than an external issuse list -- as our way to measure
> what needs to be done before the release.
> 
> To that end, I've made sure that everything on the issues list is marked
> "high" in GNATS, and checked in a new copy of the issues list that
> indicates it is no longer in use.

What's the right way to ask for bugs to be high priority?

PR optimization/6177 (ia64 ICE with single-element complex array in
LAPACK) describes a bug introduced on April 2.  It affects i686 also.
An update to the PR includes a six line Fortran test case.

Janis

Re: GCC 3.1 Release

[Mark Mitchell]

> What's the right way to ask for bugs to be high priority?

You just did it.  It's probably best to copy me directly.

> PR optimization/6177 (ia64 ICE with single-element complex array in
> LAPACK) describes a bug introduced on April 2.  It affects i686 also.
> An update to the PR includes a six line Fortran test case.

OK, I've updated the bug list.

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.1 Release

[Christian Jönsson]

On Wed, Apr 10, 2002 at 10:14:39AM -0700, Janis Johnson wrote:

> An update to the PR includes a six line Fortran test case.

Is this tested by the g77 testsuite? If not, can't we incorporate the
PR's test case in g77's testsuite?

Cheers,

/ChJ

Re: GCC 3.1 Release

[Benjamin Kosnik]

> I think your patch makes sense.  Benjamin what do you think?

Seems fine. I'm interested in seeing a complete patch. Perhaps somebody 
could take Joe's sketched solution and make it complete, and add a testcase?

I'm in the middle of other issues, so I can't be more hands-on on this, 
sorry. 

-benjamin

Re: GCC 3.1 Release

[Paolo Carlini]

Benjamin Kosnik wrote:

>>I think your patch makes sense.  Benjamin what do you think?
>>
>Seems fine. I'm interested in seeing a complete patch. Perhaps somebody 
>could take Joe's sketched solution and make it complete, and add a testcase?
>
I can do this in the next two hours.

Ciao, Paolo.

Re: GCC 3.1 Release

[Gabriel Dos Reis]

Paolo Carlini <pcarlini@unitus.it> writes:

[...]

| Seriously, I have no problem implementing, completing with a testcase 
| and testing the solution sketched by Joe, and I'm indeed pleased to do 
| that, but if you think something different is in order, please explain 
| it in little more detail

I just realized that my replies to Mark and Joe didn't show up :-(

Yes, I meant moving the __normal_iterator<> definition into
__gnu_cxx:: with accompanying helper functions.  And also, Joe patch
should be put in that namespace also (since that is where Koenig
lookup should find them).

-- Gaby

Fixing libstdc++/3628 (was: Re: GCC 3.1 Release)

[Paolo Carlini]

Benjamin Kosnik wrote:

>Seems fine. I'm interested in seeing a complete patch. Perhaps somebody 
>could take Joe's sketched solution and make it complete, and add a testcase?
>
Hi all, FWIW, barring a different solution suggested by Gaby, I have already
tested with no regressions on i686-pc-linux-gnu the below.

It fixes the following testcase, which however, I have'nt integrated yet in
testsuite since I'm not sure where it properly belongs:

#include <vector>
#include <utility>

using namespace std::rel_ops;

int main()
{
    std::vector<int> v;
    std::vector<int>::iterator vi;

    vi != v.begin();
    vi > v.begin();
    vi <= v.begin();
    vi >= v.begin();
}

Ciao,
Paolo.

//////////////////

        libstdc++/3628
        * include/bits/stl_iterator.h: Add template definitions to avoid
        the conflict with std::rel_ops !=, >, <=, >= operators.

--- stl_iterator.h.~1.19.~    2002-02-08 08:34:54.000000000 +0100
+++ stl_iterator.h    2002-04-10 21:02:20.000000000 +0200
@@ -645,6 +645,13 @@
          const __normal_iterator<_IteratorR, _Container>& __rhs)
   { return !(__lhs == __rhs); }
 
+  // The following is to avoid conflict with std::rel_ops::operator!=
+  template<typename _Iterator, typename _Container>
+  inline bool
+  operator!=(const __normal_iterator<_Iterator, _Container>& __lhs,
+         const __normal_iterator<_Iterator, _Container>& __rhs)
+  { return !(__lhs == __rhs); }
+
   // Random access iterator requirements
   template<typename _IteratorL, typename _IteratorR, typename _Container>
   inline bool
@@ -658,18 +665,39 @@
         const __normal_iterator<_IteratorR, _Container>& __rhs)
   { return __rhs < __lhs; }
 
+  // The following is to avoid conflict with std::rel_ops::operator>
+  template<typename _Iterator, typename _Container>
+  inline bool
+  operator>(const __normal_iterator<_Iterator, _Container>& __lhs,
+        const __normal_iterator<_Iterator, _Container>& __rhs)
+  { return __rhs < __lhs; }
+
   template<typename _IteratorL, typename _IteratorR, typename _Container>
   inline bool
   operator<=(const __normal_iterator<_IteratorL, _Container>& __lhs,
          const __normal_iterator<_IteratorR, _Container>& __rhs)
   { return !(__rhs < __lhs); }
 
+  // The following is to avoid conflict with std::rel_ops::operator<=
+  template<typename _Iterator, typename _Container>
+  inline bool
+  operator<=(const __normal_iterator<_Iterator, _Container>& __lhs,
+         const __normal_iterator<_Iterator, _Container>& __rhs)
+  { return !(__rhs < __lhs); }
+
   template<typename _IteratorL, typename _IteratorR, typename _Container>
   inline bool
   operator>=(const __normal_iterator<_IteratorL, _Container>& __lhs,
          const __normal_iterator<_IteratorR, _Container>& __rhs)
   { return !(__lhs < __rhs); }
 
+  // The following is to avoid conflict with std::rel_ops::operator>=
+  template<typename _Iterator, typename _Container>
+  inline bool
+  operator>=(const __normal_iterator<_Iterator, _Container>& __lhs,
+         const __normal_iterator<_Iterator, _Container>& __rhs)
+  { return !(__lhs < __rhs); }
+
   template<typename _Iterator, typename _Container>
   inline __normal_iterator<_Iterator, _Container>
   operator+(typename __normal_iterator<_Iterator, 
_Container>::difference_type __n,

Re: Fixing libstdc++/3628 (was: Re: GCC 3.1 Release)

[Phil Edwards]

On Thu, Apr 11, 2002 at 12:29:35AM +0200, Paolo Carlini wrote:
> 
> It fixes the following testcase, which however, I have'nt integrated yet in
> testsuite since I'm not sure where it properly belongs:

How about 20_util/rel_ops.cc ?


>         libstdc++/3628
>         * include/bits/stl_iterator.h: Add template definitions to avoid
>         the conflict with std::rel_ops !=, >, <=, >= operators.

By the way, the changelog entry only gets sent to GNATS if the line reads

    PR libstdc++/3628

i.e., with the leading "PR " text.  I just noticed that none of Benjamin's
recent fixes have that text either.  Oh well.  :-)  No easy way to make it
work retroactively.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Fixing libstdc++/3628 (was: Re: GCC 3.1 Release)

[Paolo Carlini]

Phil Edwards wrote:

>How about 20_util/rel_ops.cc ?
>
[...]

>By the way, the changelog entry only gets sent to GNATS if the line reads
>
>    PR libstdc++/3628
>
>i.e., with the leading "PR " text.  I just noticed that none of Benjamin's
>recent fixes have that text either.  Oh well.  :-)  No easy way to make it
>work retroactively.
>

Thanks for both Phil!
I was completely unaware :-( of the required PR at the beginning...

Ciao,
Paolo.

Re: GCC 3.1 Release

[Joe Buck]

Gaby writes:

> Yes, I meant moving the __normal_iterator<> definition into
> __gnu_cxx:: with accompanying helper functions.  And also, Joe patch
> should be put in that namespace also (since that is where Koenig
> lookup should find them).

OK, so you're proposing the move to a different namespace in addition
to my patch, rather than instead of.  That's doable, but is there
really a strong reason to do the move?  What's the harm in having
additional __ names in std?

Re: GCC 3.1 Release

[Gabriel Dos Reis]

Joe Buck <Joe.Buck@synopsys.com> writes:

| Gaby writes:
| 
| > Yes, I meant moving the __normal_iterator<> definition into
| > __gnu_cxx:: with accompanying helper functions.  And also, Joe patch
| > should be put in that namespace also (since that is where Koenig
| > lookup should find them).
| 
| OK, so you're proposing the move to a different namespace in addition
| to my patch, rather than instead of.  That's doable, but is there
| really a strong reason to do the move?  What's the harm in having
| additional __ names in std?

No, you aren't having a __ name in std::.  You're defining another
user visible visible (operator==) in std::.  

-- Gaby

Re: GCC 3.1 Release

[Paolo Carlini]

Gabriel Dos Reis wrote:

>Please, if you're going to do this, don't add yet another non-standard
>operator in std::.  Consider moving the __normal_iterator bits in
>__gnu_cxx::.
>
Gaby, thanks for your feedback. However, consider that here in Italy is 
already evening and don't expect too much from me before tomorrow :-)

Seriously, I have no problem implementing, completing with a testcase 
and testing the solution sketched by Joe, and I'm indeed pleased to do 
that, but if you think something different is in order, please explain 
it in little more detail and, in any case, I cannot make promises on 
when I will be able to complete the task...

Ciao, Paolo.

Re: Fixing libstdc++/3628 (was: Re: GCC 3.1 Release)

[Mark Mitchell]

--On Thursday, April 11, 2002 12:48:45 AM +0200 Paolo Carlini 
<pcarlini@unitus.it> wrote:

> Phil Edwards wrote:
>
>> How about 20_util/rel_ops.cc ?
>>
> [...]
>
>> By the way, the changelog entry only gets sent to GNATS if the line reads
>>
>>    PR libstdc++/3628
>>
>> i.e., with the leading "PR " text.  I just noticed that none of
>> Benjamin's recent fixes have that text either.  Oh well.  :-)  No easy
>> way to make it work retroactively.

Gaby, I understand your objection here, I think.  You're saying that since
we're creating these new operators in namespace std, saying:

  "using std::operator=="

will pull in more things that it should.  Can a conforming program
detect that difference?

I agree that putting __normal_iterator and friends into a separate
namespace would be a cleaner solution.  It sounds pretty invasive,
though.  Do you think it's practical to do that quickly?

If not, I'd suggest we go with Joe/Paolo's patch, and then file a PR
about the "using std::operator==" issue.  I think that would probably
be a step forward.  Remember that sometimes we can't do everything
we'd like to, but we still want to make progress...

What are your thoughts on that?

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Fixing libstdc++/3628 (was: Re: GCC 3.1 Release)

[Paolo Carlini]

Hi all,

for concreteness, the below (tested i686-pc-linux-gnu) is the
complete non-invasive proposal.

Ciao, Paolo.

////////////

2002-04-13  Joe Buck  <joe.buck@synopsys.com>
            Paolo Carlini  <pcarlini@unitus.it>

        PR libstdc++/3628
        * include/bits/stl_iterator.h (class __normal_iterator):
        Add template definitions to avoid the conflict with
        std::rel_ops !=, >, <=, and >= operators.
        * testsuite/20_util/rel_ops.cc: New tests.

diff -prN libstdc++-v3-orig/include/bits/stl_iterator.h 
libstdc++-v3/include/bits/stl_iterator.h
*** libstdc++-v3-orig/include/bits/stl_iterator.h    Fri Feb  8 08:34:54 
2002
--- libstdc++-v3/include/bits/stl_iterator.h    Sat Apr 13 00:53:54 2002
*************** namespace std
*** 645,650 ****
--- 645,657 ----
           const __normal_iterator<_IteratorR, _Container>& __rhs)
    { return !(__lhs == __rhs); }
 
+   // The following is to avoid conflict with std::rel_ops::operator!=
+   template<typename _Iterator, typename _Container>
+   inline bool
+   operator!=(const __normal_iterator<_Iterator, _Container>& __lhs,
+          const __normal_iterator<_Iterator, _Container>& __rhs)
+   { return !(__lhs == __rhs); }
+
    // Random access iterator requirements
    template<typename _IteratorL, typename _IteratorR, typename _Container>
    inline bool
*************** namespace std
*** 658,675 ****
--- 665,703 ----
          const __normal_iterator<_IteratorR, _Container>& __rhs)
    { return __rhs < __lhs; }
 
+   // The following is to avoid conflict with std::rel_ops::operator>
+   template<typename _Iterator, typename _Container>
+   inline bool
+   operator>(const __normal_iterator<_Iterator, _Container>& __lhs,
+         const __normal_iterator<_Iterator, _Container>& __rhs)
+   { return __rhs < __lhs; }
+
    template<typename _IteratorL, typename _IteratorR, typename _Container>
    inline bool
    operator<=(const __normal_iterator<_IteratorL, _Container>& __lhs,
           const __normal_iterator<_IteratorR, _Container>& __rhs)
    { return !(__rhs < __lhs); }
 
+   // The following is to avoid conflict with std::rel_ops::operator<=
+   template<typename _Iterator, typename _Container>
+   inline bool
+   operator<=(const __normal_iterator<_Iterator, _Container>& __lhs,
+          const __normal_iterator<_Iterator, _Container>& __rhs)
+   { return !(__rhs < __lhs); }
+
    template<typename _IteratorL, typename _IteratorR, typename _Container>
    inline bool
    operator>=(const __normal_iterator<_IteratorL, _Container>& __lhs,
           const __normal_iterator<_IteratorR, _Container>& __rhs)
    { return !(__lhs < __rhs); }
 
+   // The following is to avoid conflict with std::rel_ops::operator>=
+   template<typename _Iterator, typename _Container>
+   inline bool
+   operator>=(const __normal_iterator<_Iterator, _Container>& __lhs,
+          const __normal_iterator<_Iterator, _Container>& __rhs)
+   { return !(__lhs < __rhs); }
+
    template<typename _Iterator, typename _Container>
    inline __normal_iterator<_Iterator, _Container>
    operator+(typename __normal_iterator<_Iterator, 
_Container>::difference_type __n,
diff -prN libstdc++-v3-orig/testsuite/20_util/rel_ops.cc 
libstdc++-v3/testsuite/20_util/rel_ops.cc
*** libstdc++-v3-orig/testsuite/20_util/rel_ops.cc    Thu Jan  1 
01:00:00 1970
--- libstdc++-v3/testsuite/20_util/rel_ops.cc    Sat Apr 13 01:16:55 2002
***************
*** 0 ****
--- 1,44 ----
+ // 2002-04-13  Paolo Carlini  <pcarlini@unitus.it>
+
+ // Copyright (C) 2002 Free Software Foundation, Inc.
+ //
+ // This file is part of the GNU ISO C++ Library.  This library is free
+ // software; you can redistribute it and/or modify it under the
+ // terms of the GNU General Public License as published by the
+ // Free Software Foundation; either version 2, or (at your option)
+ // any later version.
+
+ // This library is distributed in the hope that it will be useful,
+ // but WITHOUT ANY WARRANTY; without even the implied warranty of
+ // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ // GNU General Public License for more details.
+
+ // You should have received a copy of the GNU General Public License along
+ // with this library; see the file COPYING.  If not, write to the Free
+ // Software Foundation, 59 Temple Place - Suite 330, Boston, MA 
02111-1307,
+ // USA.
+
+ // 20.2.1 Operators
+
+ #include <utility>
+ #include <vector>
+
+ using namespace std::rel_ops;
+
+ // libstdc++/3628
+ void test01()
+ {
+   std::vector<int> v;
+   std::vector<int>::iterator vi;
+
+   vi != v.begin();
+   vi > v.begin();
+   vi <= v.begin();
+   vi >= v.begin();
+ }
+
+ int main()
+ {
+   test01();
+   return 0;
+ }

Re: GCC 3.1 Release

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

[...]

| I think your patch makes sense.  Benjamin what do you think?
| 
| Gaby, if we can do something like this, it will definitely make things
| easier for users.  The standard specifies that std::rel_ops exists, and
| it also specifies that iterators have an operator==, and it certainly
| makes sense to make those two things work together if at all possible.


Mark,

  Here is a patch to move the __normal_iterator<> bits into
__gnu_cxx:: along with the patch suggested by Joe.  It also
incorporates Paolo's test.  Bootstrapped and tested on
i686-pc-linux-gnu (3.1 branch).

I'll apply the same thing to mainline.  Branch requires your approval
if I understand correctly.

-- Gaby

Index: ChangeLog
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/ChangeLog,v
retrieving revision 1.1057.2.73
diff -p -r1.1057.2.73 ChangeLog
*** ChangeLog	15 Apr 2002 20:35:46 -0000	1.1057.2.73
--- ChangeLog	16 Apr 2002 00:42:15 -0000
***************
*** 1,3 ****
--- 1,19 ----
+ 2002-04-16  Paolo Carlini <pcarlini@unitus.it>
+ 	* testsuite/24_iterators/rel_ops.cc: New test.
+ 	
+ 2002-04-16  Gabriel Dos Reis  <gdr@merlin.codesourcery.com>
+ 
+ 	* include/bits/type_traits.h (__normal_iterator): Declare in
+ 	__gnu_cxx.  Adjust use at global namespace.
+ 	* include/bits/stl_iterator.h (__normal_iterator): Move definition
+ 	into __gnu_cxx::. Add more operator overloads.  Tidy existing ones.
+ 	* include/bits/basic_string.h (basic_string): Adjust use of
+ 	__normal_iterator.
+ 	* include/bits/stl_vector.h (_Alloc>): Likewise.
+ 	* src/concept-inst.cc (__gnu_cxx): __normal_iterator<> is now here.
+ 	* src/locale-inst.cc (__gnu_cxx): Likewise.
+ 	* src/string-inst.cc (operator==): Instantiate in __gnu_cxx.
+ 
  2002-04-15  Steve Ellcey  <sje@cup.hp.com>
  
  	* gcc/libstdc++-v3/config/os/hpux/bits/os_defines.h
Index: include/bits/basic_string.h
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/include/bits/basic_string.h,v
retrieving revision 1.19.2.2
diff -p -r1.19.2.2 basic_string.h
*** include/bits/basic_string.h	1 Apr 2002 18:56:28 -0000	1.19.2.2
--- include/bits/basic_string.h	16 Apr 2002 00:42:16 -0000
*************** namespace std
*** 99,106 ****
        typedef typename _Alloc::const_reference 		    const_reference;
        typedef typename _Alloc::pointer 			    pointer;
        typedef typename _Alloc::const_pointer 	   	    const_pointer;
!       typedef __normal_iterator<pointer, basic_string> 	    iterator;
!       typedef __normal_iterator<const_pointer, basic_string> const_iterator;
        typedef reverse_iterator<const_iterator> 	const_reverse_iterator;
        typedef reverse_iterator<iterator> 		    reverse_iterator;
      
--- 99,107 ----
        typedef typename _Alloc::const_reference 		    const_reference;
        typedef typename _Alloc::pointer 			    pointer;
        typedef typename _Alloc::const_pointer 	   	    const_pointer;
!       typedef __gnu_cxx::__normal_iterator<pointer, basic_string>  iterator;
!       typedef __gnu_cxx::__normal_iterator<const_pointer, basic_string>
!                                                             const_iterator;
        typedef reverse_iterator<const_iterator> 	const_reverse_iterator;
        typedef reverse_iterator<iterator> 		    reverse_iterator;
      
Index: include/bits/stl_iterator.h
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/include/bits/stl_iterator.h,v
retrieving revision 1.19
diff -p -r1.19 stl_iterator.h
*** include/bits/stl_iterator.h	8 Feb 2002 07:34:54 -0000	1.19
--- include/bits/stl_iterator.h	16 Apr 2002 00:42:16 -0000
*************** namespace std
*** 548,554 ****
        return insert_iterator<_Container>(__x, 
  					 typename _Container::iterator(__i));
      }
!   
    // This iterator adapter is 'normal' in the sense that it does not
    // change the semantics of any of the operators of its iterator
    // parameter.  Its primary purpose is to convert an iterator that is
--- 548,557 ----
        return insert_iterator<_Container>(__x, 
  					 typename _Container::iterator(__i));
      }
! } // namespace std
! 
! namespace __gnu_cxx
! {  
    // This iterator adapter is 'normal' in the sense that it does not
    // change the semantics of any of the operators of its iterator
    // parameter.  Its primary purpose is to convert an iterator that is
*************** namespace std
*** 556,561 ****
--- 559,566 ----
    // The _Container parameter exists solely so that different containers
    // using this template can instantiate different types, even if the
    // _Iterator parameter is the same.
+   using std::iterator_traits;
+   using std::iterator;
    template<typename _Iterator, typename _Container>
      class __normal_iterator
        : public iterator<typename iterator_traits<_Iterator>::iterator_category,
*************** namespace std
*** 632,637 ****
--- 637,650 ----
        base() const { return _M_current; }
      };
  
+   // Note: In what follows, the left- and right-hand-side iterators are
+   // allowed to vary in types (conceptually in cv-qualification) so that
+   // comparaison between cv-qualified and non-cv-qualified iterators be
+   // valid.  However, the greedy and unfriendly operators in std::rel_ops
+   // will make overload resolution ambiguous (when in scope) if we don't
+   // provide overloads whose operands are of the same type.  Can someone
+   // remind me what generic programming is about? -- Gaby
+   
    // Forward iterator requirements
    template<typename _IteratorL, typename _IteratorR, typename _Container>
    inline bool
*************** namespace std
*** 639,649 ****
  	     const __normal_iterator<_IteratorR, _Container>& __rhs)
    { return __lhs.base() == __rhs.base(); }
  
    template<typename _IteratorL, typename _IteratorR, typename _Container>
    inline bool
    operator!=(const __normal_iterator<_IteratorL, _Container>& __lhs,
  	     const __normal_iterator<_IteratorR, _Container>& __rhs)
!   { return !(__lhs == __rhs); }
  
    // Random access iterator requirements
    template<typename _IteratorL, typename _IteratorR, typename _Container>
--- 652,674 ----
  	     const __normal_iterator<_IteratorR, _Container>& __rhs)
    { return __lhs.base() == __rhs.base(); }
  
+   template<typename _Iterator, typename _Container>
+   inline bool
+   operator==(const __normal_iterator<_Iterator, _Container>& __lhs,
+              const __normal_iterator<_Iterator, _Container>& __rhs)
+   { return __lhs.base() == __rhs.base(); }
+ 
    template<typename _IteratorL, typename _IteratorR, typename _Container>
    inline bool
    operator!=(const __normal_iterator<_IteratorL, _Container>& __lhs,
  	     const __normal_iterator<_IteratorR, _Container>& __rhs)
!   { return __lhs.base() != __rhs.base(); }
! 
!   template<typename _Iterator, typename _Container>
!   inline bool
!   operator!=(const __normal_iterator<_Iterator, _Container>& __lhs,
!              const __normal_iterator<_Iterator, _Container>& __rhs)
!   { return __lhs.base() != __rhs.base(); }
  
    // Random access iterator requirements
    template<typename _IteratorL, typename _IteratorR, typename _Container>
*************** namespace std
*** 652,681 ****
  	    const __normal_iterator<_IteratorR, _Container>& __rhs)
    { return __lhs.base() < __rhs.base(); }
  
    template<typename _IteratorL, typename _IteratorR, typename _Container>
    inline bool
    operator>(const __normal_iterator<_IteratorL, _Container>& __lhs,
  	    const __normal_iterator<_IteratorR, _Container>& __rhs)
!   { return __rhs < __lhs; }
  
    template<typename _IteratorL, typename _IteratorR, typename _Container>
    inline bool
    operator<=(const __normal_iterator<_IteratorL, _Container>& __lhs,
  	     const __normal_iterator<_IteratorR, _Container>& __rhs)
!   { return !(__rhs < __lhs); }
  
    template<typename _IteratorL, typename _IteratorR, typename _Container>
    inline bool
    operator>=(const __normal_iterator<_IteratorL, _Container>& __lhs,
  	     const __normal_iterator<_IteratorR, _Container>& __rhs)
!   { return !(__lhs < __rhs); }
  
    template<typename _Iterator, typename _Container>
    inline __normal_iterator<_Iterator, _Container>
    operator+(typename __normal_iterator<_Iterator, _Container>::difference_type __n,
  	    const __normal_iterator<_Iterator, _Container>& __i)
    { return __normal_iterator<_Iterator, _Container>(__i.base() + __n); }
! } // namespace std
  
  #endif 
  
--- 677,730 ----
  	    const __normal_iterator<_IteratorR, _Container>& __rhs)
    { return __lhs.base() < __rhs.base(); }
  
+   template<typename _Iterator, typename _Container>
+   inline bool
+   operator<(const __normal_iterator<_Iterator, _Container>& __lhs,
+              const __normal_iterator<_Iterator, _Container>& __rhs)
+   { return __lhs.base() < __rhs.base(); }
+ 
    template<typename _IteratorL, typename _IteratorR, typename _Container>
    inline bool
    operator>(const __normal_iterator<_IteratorL, _Container>& __lhs,
  	    const __normal_iterator<_IteratorR, _Container>& __rhs)
!   { return __lhs.base() > __rhs.base(); }
! 
!   template<typename _Iterator, typename _Container>
!   inline bool
!   operator>(const __normal_iterator<_Iterator, _Container>& __lhs,
! 	    const __normal_iterator<_Iterator, _Container>& __rhs)
!   { return __lhs.base() > __rhs.base(); }
  
    template<typename _IteratorL, typename _IteratorR, typename _Container>
    inline bool
    operator<=(const __normal_iterator<_IteratorL, _Container>& __lhs,
  	     const __normal_iterator<_IteratorR, _Container>& __rhs)
!   { return __lhs.base() <= __rhs.base(); }
! 
!   template<typename _Iterator, typename _Container>
!   inline bool
!   operator<=(const __normal_iterator<_Iterator, _Container>& __lhs,
! 	     const __normal_iterator<_Iterator, _Container>& __rhs)
!   { return __lhs.base() <= __rhs.base(); }
  
    template<typename _IteratorL, typename _IteratorR, typename _Container>
    inline bool
    operator>=(const __normal_iterator<_IteratorL, _Container>& __lhs,
  	     const __normal_iterator<_IteratorR, _Container>& __rhs)
!   { return __lhs.base() >= __rhs.base(); }
! 
!   template<typename _Iterator, typename _Container>
!   inline bool
!   operator>=(const __normal_iterator<_Iterator, _Container>& __lhs,
! 	     const __normal_iterator<_Iterator, _Container>& __rhs)
!   { return __lhs.base() >= __rhs.base(); }
  
    template<typename _Iterator, typename _Container>
    inline __normal_iterator<_Iterator, _Container>
    operator+(typename __normal_iterator<_Iterator, _Container>::difference_type __n,
  	    const __normal_iterator<_Iterator, _Container>& __i)
    { return __normal_iterator<_Iterator, _Container>(__i.base() + __n); }
! } // namespace __gnu_cxx
  
  #endif 
  
Index: include/bits/stl_vector.h
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/include/bits/stl_vector.h,v
retrieving revision 1.17.2.2
diff -p -r1.17.2.2 stl_vector.h
*** include/bits/stl_vector.h	27 Mar 2002 21:54:38 -0000	1.17.2.2
--- include/bits/stl_vector.h	16 Apr 2002 00:42:17 -0000
*************** public:
*** 175,182 ****
    typedef _Tp 						value_type;
    typedef value_type* 					pointer;
    typedef const value_type* 				const_pointer;
!   typedef __normal_iterator<pointer, vector_type> 	iterator;
!   typedef __normal_iterator<const_pointer, vector_type> const_iterator;
    typedef value_type& 					reference;
    typedef const value_type& 				const_reference;
    typedef size_t 					size_type;
--- 175,183 ----
    typedef _Tp 						value_type;
    typedef value_type* 					pointer;
    typedef const value_type* 				const_pointer;
!   typedef __gnu_cxx::__normal_iterator<pointer, vector_type> 	iterator;
!   typedef __gnu_cxx::__normal_iterator<const_pointer, vector_type>
!                                                         const_iterator;
    typedef value_type& 					reference;
    typedef const value_type& 				const_reference;
    typedef size_t 					size_type;
Index: include/bits/type_traits.h
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/include/bits/type_traits.h,v
retrieving revision 1.11
diff -p -r1.11 type_traits.h
*** include/bits/type_traits.h	2 Nov 2001 22:31:02 -0000	1.11
--- include/bits/type_traits.h	16 Apr 2002 00:42:17 -0000
*************** template<typename _Tp> struct _Is_normal
*** 322,334 ****
  };
  
  // Forward declaration hack, should really include this from somewhere.
! namespace std 
  {
    template<typename _Iterator, typename _Container> class __normal_iterator;
  }
  
  template<typename _Iterator, typename _Container>
! struct _Is_normal_iterator< std::__normal_iterator<_Iterator, _Container> > {
     typedef __true_type _Normal;
  };
  
--- 322,334 ----
  };
  
  // Forward declaration hack, should really include this from somewhere.
! namespace __gnu_cxx
  {
    template<typename _Iterator, typename _Container> class __normal_iterator;
  }
  
  template<typename _Iterator, typename _Container>
! struct _Is_normal_iterator< __gnu_cxx::__normal_iterator<_Iterator, _Container> > {
     typedef __true_type _Normal;
  };
  
Index: src/concept-inst.cc
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/src/concept-inst.cc,v
retrieving revision 1.3
diff -p -r1.3 concept-inst.cc
*** src/concept-inst.cc	4 Jan 2002 21:27:35 -0000	1.3
--- src/concept-inst.cc	16 Apr 2002 00:42:17 -0000
*************** namespace __gnu_cxx
*** 50,60 ****
    template void __aux_require_boolean_expr<bool>(bool const&);
  
    _Instantiate(_BidirectionalIteratorConcept<
!     std::__normal_iterator< std::locale::facet**,
      std::vector<std::locale::facet*,std::allocator<std::locale::facet*> > > > );
  
    _Instantiate(_BidirectionalIteratorConcept<
!     std::__normal_iterator< unsigned*,
      std::vector<unsigned, std::allocator<unsigned> > > > );
  
    _Instantiate(_ConvertibleConcept<std::locale::facet*, std::locale::facet*> );
--- 50,60 ----
    template void __aux_require_boolean_expr<bool>(bool const&);
  
    _Instantiate(_BidirectionalIteratorConcept<
!     __normal_iterator< std::locale::facet**,
      std::vector<std::locale::facet*,std::allocator<std::locale::facet*> > > > );
  
    _Instantiate(_BidirectionalIteratorConcept<
!     __normal_iterator< unsigned*,
      std::vector<unsigned, std::allocator<unsigned> > > > );
  
    _Instantiate(_ConvertibleConcept<std::locale::facet*, std::locale::facet*> );
*************** namespace __gnu_cxx
*** 68,82 ****
    _Instantiate(_InputIteratorConcept<std::locale::facet**> );
  
    _Instantiate(_InputIteratorConcept<
!     std::__normal_iterator< std::locale::facet* const*,
      std::vector<std::locale::facet*,std::allocator<std::locale::facet*> > > > );
  
    _Instantiate(_InputIteratorConcept<
!     std::__normal_iterator< std::locale::facet**,
      std::vector<std::locale::facet*,std::allocator<std::locale::facet*> > > > );
  
    _Instantiate(_InputIteratorConcept<
!     std::__normal_iterator< unsigned*,
      std::vector<unsigned, std::allocator<unsigned> > > > );
  
  #ifdef _GLIBCPP_USE_WCHAR_T
--- 68,82 ----
    _Instantiate(_InputIteratorConcept<std::locale::facet**> );
  
    _Instantiate(_InputIteratorConcept<
!     __normal_iterator< std::locale::facet* const*,
      std::vector<std::locale::facet*,std::allocator<std::locale::facet*> > > > );
  
    _Instantiate(_InputIteratorConcept<
!     __normal_iterator< std::locale::facet**,
      std::vector<std::locale::facet*,std::allocator<std::locale::facet*> > > > );
  
    _Instantiate(_InputIteratorConcept<
!     __normal_iterator< unsigned*,
      std::vector<unsigned, std::allocator<unsigned> > > > );
  
  #ifdef _GLIBCPP_USE_WCHAR_T
*************** namespace __gnu_cxx
*** 98,123 ****
    _Instantiate(_LessThanComparableConcept<unsigned> );
  
    _Instantiate(_Mutable_BidirectionalIteratorConcept<
!     std::__normal_iterator< std::locale::facet**,
      std::vector<std::locale::facet*,std::allocator<std::locale::facet*> > > > );
  
    _Instantiate(_Mutable_BidirectionalIteratorConcept<
!     std::__normal_iterator< unsigned*,
      std::vector<unsigned, std::allocator<unsigned> > > > );
  
    _Instantiate(_Mutable_ForwardIteratorConcept<
!     std::__normal_iterator< std::locale::facet**,
      std::vector<std::locale::facet*,std::allocator<std::locale::facet*> > > > );
  
    _Instantiate(_OutputIteratorConcept<
      std::locale::facet**, std::locale::facet*> );
  
    _Instantiate(_OutputIteratorConcept<
!     std::__normal_iterator< std::locale::facet**,
        std::vector<std::locale::facet*, std::allocator<std::locale::facet* > > >,
      std::locale::facet* > );
  
!   _Instantiate(_OutputIteratorConcept<std::__normal_iterator<
      unsigned*, std::vector<unsigned, std::allocator<unsigned> > >, unsigned> );
  
    _Instantiate(_OutputIteratorConcept<std::ostreambuf_iterator<
--- 98,123 ----
    _Instantiate(_LessThanComparableConcept<unsigned> );
  
    _Instantiate(_Mutable_BidirectionalIteratorConcept<
!     __normal_iterator< std::locale::facet**,
      std::vector<std::locale::facet*,std::allocator<std::locale::facet*> > > > );
  
    _Instantiate(_Mutable_BidirectionalIteratorConcept<
!     __normal_iterator< unsigned*,
      std::vector<unsigned, std::allocator<unsigned> > > > );
  
    _Instantiate(_Mutable_ForwardIteratorConcept<
!     __normal_iterator< std::locale::facet**,
      std::vector<std::locale::facet*,std::allocator<std::locale::facet*> > > > );
  
    _Instantiate(_OutputIteratorConcept<
      std::locale::facet**, std::locale::facet*> );
  
    _Instantiate(_OutputIteratorConcept<
!     __normal_iterator< std::locale::facet**,
        std::vector<std::locale::facet*, std::allocator<std::locale::facet* > > >,
      std::locale::facet* > );
  
!   _Instantiate(_OutputIteratorConcept<__normal_iterator<
      unsigned*, std::vector<unsigned, std::allocator<unsigned> > >, unsigned> );
  
    _Instantiate(_OutputIteratorConcept<std::ostreambuf_iterator<
*************** namespace __gnu_cxx
*** 133,151 ****
    _Instantiate(_RandomAccessIteratorConcept<char const*> );
  
    _Instantiate(_RandomAccessIteratorConcept<
!     std::__normal_iterator<char const*, std::string> > );
  
    _Instantiate(_RandomAccessIteratorConcept<
!     std::__normal_iterator<char*, std::string> > );
  
  #ifdef _GLIBCPP_USE_WCHAR_T
    _Instantiate(_RandomAccessIteratorConcept<
!     std::__normal_iterator<wchar_t const*,
      std::basic_string<wchar_t, std::char_traits<wchar_t>,
                                 std::allocator<wchar_t> > > > );
  
    _Instantiate(_RandomAccessIteratorConcept<
!     std::__normal_iterator<wchar_t*,
      std::basic_string<wchar_t, std::char_traits<wchar_t>,
                                 std::allocator<wchar_t> > > > );
  
--- 133,151 ----
    _Instantiate(_RandomAccessIteratorConcept<char const*> );
  
    _Instantiate(_RandomAccessIteratorConcept<
!     __normal_iterator<char const*, std::string> > );
  
    _Instantiate(_RandomAccessIteratorConcept<
!     __normal_iterator<char*, std::string> > );
  
  #ifdef _GLIBCPP_USE_WCHAR_T
    _Instantiate(_RandomAccessIteratorConcept<
!     __normal_iterator<wchar_t const*,
      std::basic_string<wchar_t, std::char_traits<wchar_t>,
                                 std::allocator<wchar_t> > > > );
  
    _Instantiate(_RandomAccessIteratorConcept<
!     __normal_iterator<wchar_t*,
      std::basic_string<wchar_t, std::char_traits<wchar_t>,
                                 std::allocator<wchar_t> > > > );
  
Index: src/locale-inst.cc
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/src/locale-inst.cc,v
retrieving revision 1.29.2.2
diff -p -r1.29.2.2 locale-inst.cc
*** src/locale-inst.cc	25 Mar 2002 21:49:09 -0000	1.29.2.2
--- src/locale-inst.cc	16 Apr 2002 00:42:17 -0000
*************** namespace std
*** 410,422 ****
      has_facet<messages<wchar_t> >(const locale&);
  #endif
  
-   // iterator
-   typedef vector<locale::facet*> vec_pfacet;
    template class vector<locale::facet*>;
!   template class __normal_iterator<locale::facet**, vector<locale::facet*> >;
!   template class __normal_iterator<locale::facet* const*,
!                                    vector<locale::facet*> >;
  
    // locale
    template
      char*
--- 410,428 ----
      has_facet<messages<wchar_t> >(const locale&);
  #endif
  
    template class vector<locale::facet*>;
! } // namespace std
! 
! namespace __gnu_cxx
! {
!   // iterator
!   typedef std::vector<std::locale::facet*> vec_pfacet;
!   template class __normal_iterator<std::locale::facet**, vec_pfacet >;
!   template class __normal_iterator<std::locale::facet* const*, vec_pfacet>;
! } // namespace __gnu_cxx
  
+ namespace std
+ {
    // locale
    template
      char*
*************** namespace std
*** 490,495 ****
--- 496,502 ----
      fill_n<locale::facet**, size_t, locale::facet*>
      (locale::facet**, size_t, locale::facet* const&);
  
+   using __gnu_cxx::__normal_iterator;
    template
      __normal_iterator<locale::facet**, vector<locale::facet*> >
      fill_n(__normal_iterator<locale::facet**, vector<locale::facet*> >,
Index: src/string-inst.cc
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/src/string-inst.cc,v
retrieving revision 1.24
diff -p -r1.24 string-inst.cc
*** src/string-inst.cc	16 Feb 2002 00:19:13 -0000	1.24
--- src/string-inst.cc	16 Apr 2002 00:42:17 -0000
*************** namespace std 
*** 48,56 ****
--- 48,64 ----
    template class basic_string<C>;
    template S operator+(const C*, const S&);
    template S operator+(C, const S&);
+ } // namespace std
+ 
+ namespace __gnu_cxx
+ {
+   using std::S;
    template bool operator==(const S::iterator&, const S::iterator&);
    template bool operator==(const S::const_iterator&, const S::const_iterator&);
+ }
  
+ namespace std
+ {
    // Only one template keyword allowed here. 
    // See core issue #46 (NAD)
    // http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_closed.html#46
Index: testsuite/24_iterators/rel_ops.cc
===================================================================
RCS file: testsuite/24_iterators/rel_ops.cc
diff -N testsuite/24_iterators/rel_ops.cc
*** /dev/null	1 Jan 1970 00:00:00 -0000
--- testsuite/24_iterators/rel_ops.cc	16 Apr 2002 00:42:17 -0000
***************
*** 0 ****
--- 1,45 ----
+ // 2002-04-13  Paolo Carlini  <pcarlini@unitus.it>
+ 
+ // Copyright (C) 2002 Free Software Foundation, Inc.
+ //
+ // This file is part of the GNU ISO C++ Library.  This library is free
+ // software; you can redistribute it and/or modify it under the
+ // terms of the GNU General Public License as published by the
+ // Free Software Foundation; either version 2, or (at your option)
+ // any later version.
+ 
+ // This library is distributed in the hope that it will be useful,
+ // but WITHOUT ANY WARRANTY; without even the implied warranty of
+ // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ // GNU General Public License for more details.
+ 
+ // You should have received a copy of the GNU General Public License along
+ // with this library; see the file COPYING.  If not, write to the Free
+ // Software Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307,
+ // USA.
+ 
+ // 20.2.1 Operators
+ 
+ #include <utility>
+ #include <vector>
+ 
+ using namespace std::rel_ops;
+ 
+ // libstdc++/3628
+ void test01()
+ {
+   std::vector<int> v;
+   std::vector<int>::iterator vi;
+ 
+   vi != v.begin();
+   vi > v.begin();
+   vi <= v.begin();
+   vi >= v.begin();
+ }
+ 
+ int main()
+ {
+   test01();
+   return 0;
+ }
+ 

Re: GCC 3.1 Release

[Gabriel Dos Reis]

Gabriel Dos Reis <gdr@codesourcery.com> writes:

[...]

| Mark,
| 
|   Here is a patch to move the __normal_iterator<> bits into
| __gnu_cxx:: along with the patch suggested by Joe.  It also
| incorporates Paolo's test.  Bootstrapped and tested on
| i686-pc-linux-gnu (3.1 branch).
| 
| I'll apply the same thing to mainline.

Done.

-- Gaby

Re: GCC 3.1 Release

[Mark Mitchell]

> I'll apply the same thing to mainline.  Branch requires your approval
> if I understand correctly.

Do it.  And thank you.  And please close the high-priority PR. :-)

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.1 Release

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| > I'll apply the same thing to mainline.  Branch requires your approval
| > if I understand correctly.
| 
| Do it.  And thank you.  And please close the high-priority PR. :-)

Done.  Thanks.

-- Gaby

rel_ops (was Re: GCC 3.1 Release)

[Joe Buck]

Gaby:
> | > I'll apply the same thing to mainline.  Branch requires your approval
> | > if I understand correctly.

Mark:
> | Do it.  And thank you.  And please close the high-priority PR. :-)

Gaby:
> Done.  Thanks.

I see that Gaby couldn't resist throwing in an editorial comment attacking
std::rel_ops.  After the attack, Gaby asks "Can someone remind me what
generic programming is about?"

I will remind him that the ability to define just operator== and operator<
and automatically get correct definitions of the other four, every time,
(at least for a large number of cases) is a powerful instance of of
generic programming, and this is exactly what generic programming is
about.  I have a large C++ project that greatly benefits from that
feature.

Sometimes this is not what's desired (especially when operator== and
operator< return some class rather than bool), but that is solved by
creating the rel_ops namespace.  Library implementers must pay a price for
rel_ops, as the standard library has to work even if the user imports the
rel_ops namespace, but it is not a large price.

I'm not going to ask that the comment be stricken, but I'm not crazy
about the idea of a lot of editorial commentary in the headers.
The one-line comment I originally had would have been enough for
maintainers (who need to be told why there is a seemingly redundant
definition).

Re: rel_ops (was Re: GCC 3.1 Release)

[Mark Mitchell]

> I'm not going to ask that the comment be stricken, but I'm not crazy
> about the idea of a lot of editorial commentary in the headers.

I agree.  We don't need editorial comments about languages, operating
systems, or other similar things in comments.  We really don't even
need editorial comments about GCC itself in comments -- although
saying "if we had this, then we could clean up that" is sometimes a
useful reminder.

But, C++ and its runtime library are what they are; it's up to us to
implement them as well as we can without judging which features we
like and which we don't.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: rel_ops (was Re: GCC 3.1 Release)

[Joe Buck]

I wrote:
> > I'm not going to ask that the comment be stricken, but I'm not crazy
> > about the idea of a lot of editorial commentary in the headers.

Mark wrote:
> I agree.  We don't need editorial comments about languages, operating
> systems, or other similar things in comments.

Thanks, but I wouldn't want this little dispute take away from my
gratitude to Paolo and Gaby for helping me to get this problem resolved.
I realize (rather, it has been pointed out to me) that I hadn't said
"thank you" yet.  Thank you.

Having the high-priority bug fixed is so much better than not having it
fixed that a comment I don't care for in a header that few will read is a
small price to pay.

Gaby, sometimes we seem to get on one another's nerves.  I'm sorry about
that, but I am grateful for all your contributions to GCC.

Re: rel_ops (was Re: GCC 3.1 Release)

[Gabriel Dos Reis]

Joe Buck <Joe.Buck@synopsys.com> writes:

| Gaby:
| > | > I'll apply the same thing to mainline.  Branch requires your approval
| > | > if I understand correctly.
| 
| Mark:
| > | Do it.  And thank you.  And please close the high-priority PR. :-)
| 
| Gaby:
| > Done.  Thanks.
| 
| I see that Gaby couldn't resist throwing in an editorial comment attacking
| std::rel_ops.

Joe, I didn't "attack" std::rel_ops.  I simply stated a *fact*: the
operators in std::rel_ops are greedy and tend to take precedence over
operators that would have been selected, were stg::rel_ops absent.

| After the attack, Gaby asks "Can someone remind me what
| generic programming is about?"
| 
| I will remind him that the ability to define just operator== and operator<
| and automatically get correct definitions of the other four, every time,
| (at least for a large number of cases) is a powerful instance of of
| generic programming, and this is exactly what generic programming is
| about.

I appreciate your answer, but it doesn't answer my concern and as such
doesn't enlighten the point std::rel_ops is serving generic programming
here: It causes more trouble than it solves.

[...]

| I'm not going to ask that the comment be stricken, but I'm not crazy
| about the idea of a lot of editorial commentary in the headers.

I think you're taking this issue more personally than it should.
Qualifying my comments as being attacking std::rel_ops is far too
extreme.  

Am I mistaken to think that the std::rel_ops issue is more about
Joe/Gaby than about anything else?

-- Gaby

Re: rel_ops (was Re: GCC 3.1 Release)

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| > I'm not going to ask that the comment be stricken, but I'm not crazy
| > about the idea of a lot of editorial commentary in the headers.
| 
| I agree.

Mark,

  I don't think I were attacking anything in saying that std::rel_ops
isn't friendly since it is a *fact* that they tend take over operators
that would have been selected otherwise -- they are "isolated" but as
soon as they're brought into scope, they tend to things.

I'm disappointed that Joe is taking this issue personally.

-- Gaby

Re: rel_ops (was Re: GCC 3.1 Release)

[Mark Mitchell]

--On Tuesday, April 16, 2002 07:49:23 PM +0200 Gabriel Dos Reis 
<gdr@codesourcery.com> wrote:

> Mark Mitchell <mark@codesourcery.com> writes:
>
>| > I'm not going to ask that the comment be stricken, but I'm not crazy
>| > about the idea of a lot of editorial commentary in the headers.
>|
>| I agree.
>
> Mark,
>
>   I don't think I were attacking anything in saying that std::rel_ops
> isn't friendly since it is a *fact* that they tend take over operators
> that would have been selected otherwise -- they are "isolated" but as
> soon as they're brought into scope, they tend to things.

I should admit that I didn't read the comment.  (I still haven't.)  I
should have before making any comment.

Let's not take this any further; everyone's thrilled that the bug is
fixed!  I'm grateful to Joe for pointing out the problem and proposing
a patch, Paolo for developing it further, and you for moving the stuff
into namespaces and incorporating the whole bit.  Me, I just sit in the
middle and watch all you folks work. :-)

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: rel_ops (was Re: GCC 3.1 Release)

[Richard B. Kreckel]

Hi,

On 16 Apr 2002, Gabriel Dos Reis wrote:
> Joe Buck <Joe.Buck@synopsys.com> writes:
> | Gaby:
> | > | > I'll apply the same thing to mainline.  Branch requires your approval
> | > | > if I understand correctly.
> | 
> | Mark:
> | > | Do it.  And thank you.  And please close the high-priority PR. :-)
> | 
> | Gaby:
> | > Done.  Thanks.
> | 
> | I see that Gaby couldn't resist throwing in an editorial comment attacking
> | std::rel_ops.
> 
> Joe, I didn't "attack" std::rel_ops.  I simply stated a *fact*: the
> operators in std::rel_ops are greedy and tend to take precedence over
> operators that would have been selected, were stg::rel_ops absent.

Sorry, that beats me.  When you overload or specialize any operator> then
a templated operator> that would match the same signature should not take
precedence, be it in some namespace or not.  And it doesn't seem to happen
in GCC as far as I can see and it would be a freaking bug if it happened
as far as I can tell.  Gaby, I have repeatedly asked you to explain the
problems you keep mentioning but you never answered.  Could someone please
enlighten me and provide a scenario where the operators in std::rel_ops
take precendence over operators that would have been selected otherwise.

Maybe just blind
              -richy.
-- 
Richard B. Kreckel
<Richard.Kreckel@Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>

Re: rel_ops (was Re: GCC 3.1 Release)

[Joe Buck]

Richard Kreckel writes:
> Sorry, that beats me.  When you overload or specialize any operator> then
> a templated operator> that would match the same signature should not take
> precedence, be it in some namespace or not.  And it doesn't seem to happen
> in GCC as far as I can see and it would be a freaking bug if it happened
> as far as I can tell.  Gaby, I have repeatedly asked you to explain the
> problems you keep mentioning but you never answered.  Could someone please
> enlighten me and provide a scenario where the operators in std::rel_ops
> take precendence over operators that would have been selected otherwise.

Before the bug was fixed, the problem was not that std::rel_ops::operator!=
took precedence over the != for __normal_iterator, it was that neither one
took precedence (there was an ambiguity).  This meant that some valid
programs failed to compile.

The bug is now fixed for 3.1, so let's not fight about it any more.
Users of 3.0.4 might have some difficulties if they have programs that
say

using std::rel_ops;

and then use vector iterators.  A workaround is to change code that uses
!= on iterators from something like

	iter != vec.end()

to
	!(iter == vec.end())

for 3.0.x if you see a compilation failure.  This will not be needed for
3.1.

Re: rel_ops (was Re: GCC 3.1 Release)

[Phil Edwards]

On Wed, Apr 17, 2002 at 08:52:50PM +0200, Richard B. Kreckel wrote:
> Could someone please
> enlighten me and provide a scenario where the operators in std::rel_ops
> take precendence over operators that would have been selected otherwise.

The problem is not that they take precendence /over/ other operators, it's
that they don't allow other operators to take precedence over themselves.
They become equal candidates.  Then the compiler pukes out due to the
ambiguity.  (To see this, use the rel_ops operators with vector or string
iterators, /without/ the recently applied patch.)

At least, that seems to be the problem.  Gaby?


In a perfect world (or at least in mine *grin*), we could tell the compiler
that, in the case of ambiguous matches, check to see if one of the functions
is in the std::rel_ops namespace, and if so, temporarily discard that one,
and see if the ambiguity remains.  (Blue-sky idea, probably flaky.)


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: rel_ops (was Re: GCC 3.1 Release)

[Joe Buck]

Phil writes:
> In a perfect world (or at least in mine *grin*), we could tell the compiler
> that, in the case of ambiguous matches, check to see if one of the functions
> is in the std::rel_ops namespace, and if so, temporarily discard that one,
> and see if the ambiguity remains.  (Blue-sky idea, probably flaky.)

Such a trick, I believe, would conflict with the ISO standard, though
I suppose it could be considered an extension.
But no matter, it isn't needed.  I don't believe that it is difficult
to avoid conflicts with std::rel_ops.

To review this once more: std::rel_ops defines things like

template <class _Tp>
inline bool operator!=(const _Tp& __x, const _Tp& __y) {
  return !(__x == __y);
}

The things to note about this definition are:

1) it is completely general (seen by many as a bad thing, and in fact
   it would be a bad thing if it weren't confined to its own namespace;
   the user should choose to use it or not)

2) the types of both arguments are constrained to be the same.

Point #2 and the rules of C++ guarantee that any more-specific operator!=
definition will always be preferred to this one guarantee that there will
never be an ambiguity between this definition and any user definition of
operator!= that uses the same type for both arguments.

Conflicts will only occur if the user definition (or more specific
definition in the system library) permits the arguments to be of different
types but allows them to be of the same type.  If this happens, then it is
possible that, for a call to operator!= with two arguments that are of
exactly the same type, the two definitions of operator!= will be seen as
equal cost, and neither will be seen as a specialization of the other,
so the compiler will report an ambiguity.

The way to solve it is to add a third definition that will be seen by
the compiler as more specific than either of the alternatives.  Generally
speaking, this will be a symmetric form of the user definition.  In the
particular case that we just fixed, the problem was with the following
definition:

  template<typename _IteratorL, typename _IteratorR, typename _Container>
  inline bool
  operator!=(const __normal_iterator<_IteratorL, _Container>& __lhs,
	     const __normal_iterator<_IteratorR, _Container>& __rhs)
  { return __lhs.base() != __rhs.base(); }

Ambiguities will arise where we generate a match that uses the same
value for _IteratorL and _IteratorR.  For this case, both templates
generate exact matches, and neither covers a strict subset of the other's
range of applicability.

The trick of adding a third tie-breaker, in this case

  template<typename _Iterator, typename _Container>
  inline bool
  operator!=(const __normal_iterator<_Iterator, _Container>& __lhs,
             const __normal_iterator<_Iterator, _Container>& __rhs)
  { return __lhs.base() != __rhs.base(); }

applies in all such cases.  The above template always wins when both
it and the rel_ops template are exact matches.

Re: rel_ops (was Re: GCC 3.1 Release)

[Gabriel Dos Reis]

"Richard B. Kreckel" <kreckel@ginac.de> writes:

| Hi,
| 
| On 16 Apr 2002, Gabriel Dos Reis wrote:
| > Joe Buck <Joe.Buck@synopsys.com> writes:
| > | Gaby:
| > | > | > I'll apply the same thing to mainline.  Branch requires your approval
| > | > | > if I understand correctly.
| > | 
| > | Mark:
| > | > | Do it.  And thank you.  And please close the high-priority PR. :-)
| > | 
| > | Gaby:
| > | > Done.  Thanks.
| > | 
| > | I see that Gaby couldn't resist throwing in an editorial comment attacking
| > | std::rel_ops.
| > 
| > Joe, I didn't "attack" std::rel_ops.  I simply stated a *fact*: the
| > operators in std::rel_ops are greedy and tend to take precedence over
                                             ^^^^
| > operators that would have been selected, were stg::rel_ops absent.
| 
| Sorry, that beats me.  When you overload or specialize any operator> then
| a templated operator> that would match the same signature should not take
| precedence, be it in some namespace or not.  And it doesn't seem to happen
| in GCC as far as I can see and it would be a freaking bug if it happened
| as far as I can tell.  Gaby, I have repeatedly asked you to explain the
| problems you keep mentioning but you never answered.

The keyword here is *tend*.

Now, you asked for a testcase, and it is easy to produce one, so here
we are (and I to think I provided one in the past). Consider the following

    struct X {
      // some stuff
    };
   
    bool operator!=(const X&, const X&);

   struct X : Y {
     // add some customization, but essential the same as X.
   };

  // no operator== for 'Y's, as they're essentially the same.

In absence of std::rel_ops::operator!=, the the above operator will be
preferred.  But as soon as, std::rel_ops_operator!= is in scope,
things break.

Just compile the following and see what happens.

    #include <utility>
    #include <iostream>

    struct X { };

    struct Y : X { };

    bool operator!=(const X&, const X&)
    {
	std::cout << "::operator!=(const X&, const X&)\n";
	return false;
    }

    void f()
    {
	X() != X();
    }

    void g()
    {
	using namespace std::rel_ops;
	Y() != Y();
    }

    int main()
    {
	f();
	g();
    }

In Joe's example, both operators were considered equal.  In the above
example std::rel_ops::operator!= takes precedence.  Hence my word
"tend". 

|  Could someone please
| enlighten me and provide a scenario where the operators in std::rel_ops
| take precendence over operators that would have been selected otherwise.

See above.

-- Gaby

Re: rel_ops (was Re: GCC 3.1 Release)

[Gabriel Dos Reis]

Joe Buck <Joe.Buck@synopsys.com> writes:

| Richard Kreckel writes:
| > Sorry, that beats me.  When you overload or specialize any operator> then
| > a templated operator> that would match the same signature should not take
| > precedence, be it in some namespace or not.  And it doesn't seem to happen
| > in GCC as far as I can see and it would be a freaking bug if it happened
| > as far as I can tell.  Gaby, I have repeatedly asked you to explain the
| > problems you keep mentioning but you never answered.  Could someone please
| > enlighten me and provide a scenario where the operators in std::rel_ops
| > take precendence over operators that would have been selected otherwise.
| 
| Before the bug was fixed, the problem was not that std::rel_ops::operator!=
| took precedence over the != for __normal_iterator, it was that neither one
| took precedence (there was an ambiguity).

std::rel_ops::operator!= can take precedence in specific cases (not
for __normal_iterator).  See the example I just posted.

-- Gaby

Re: rel_ops (was Re: GCC 3.1 Release)

[Gabriel Dos Reis]

Phil Edwards <phil@jaj.com> writes:

| On Wed, Apr 17, 2002 at 08:52:50PM +0200, Richard B. Kreckel wrote:
| > Could someone please
| > enlighten me and provide a scenario where the operators in std::rel_ops
| > take precendence over operators that would have been selected otherwise.
| 
| The problem is not that they take precendence /over/ other operators, it's
| that they don't allow other operators to take precedence over themselves.

:-)

You're right.

But it is also true that in some cases, they do take precedence over
some operators.  
The crux being that sometimes, the standard conversion derived -> base
is attempted only when there is no match that would could solve the
overload; and it such cases, things break.  See the example I just posted.

| They become equal candidates.  Then the compiler pukes out due to the
| ambiguity.  (To see this, use the rel_ops operators with vector or string
| iterators, /without/ the recently applied patch.)
| 
| At least, that seems to be the problem.  Gaby?

Yes, in the specific case of __normal_iterator, that is what happens.

| In a perfect world (or at least in mine *grin*), we could tell the compiler
| that, in the case of ambiguous matches, check to see if one of the functions
| is in the std::rel_ops namespace, and if so, temporarily discard that one,
| and see if the ambiguity remains.  (Blue-sky idea, probably flaky.)

That isn't conforming and I'm not sure I would like to implement that
feature, I might be definitely labelled "anti-rel-ops" ;-)

[ Phil, I'm getting mailer-daemon notices telling me that your address
isn't valid.  What is up? ]

-- Gaby

Re: rel_ops (was Re: GCC 3.1 Release)

[Gabriel Dos Reis]

Joe Buck <Joe.Buck@synopsys.com> writes:

[...]

| 2) the types of both arguments are constrained to be the same.
| 
| Point #2 and the rules of C++ guarantee that any more-specific operator!=
| definition will always be preferred to this one guarantee that there will
| never be an ambiguity between this definition and any user definition of
| operator!= that uses the same type for both arguments.

With an appropriate definition of "more-specific", the code I just sent
is a counterexample to the above statement :-) 

| Conflicts will only occur if the user definition (or more specific
| definition in the system library) permits the arguments to be of different
| types but allows them to be of the same type.  If this happens, then it is
| possible that, for a call to operator!= with two arguments that are of
| exactly the same type, the two definitions of operator!= will be seen as
| equal cost, and neither will be seen as a specialization of the other,
| so the compiler will report an ambiguity.

Not always.  Sometimes, it will take the std::rel_ops version because
it provides a "best match" (according to the standard).

| The way to solve it is to add a third definition that will be seen by
| the compiler as more specific than either of the alternatives.

Actually, this might not be always practical.

-- Gaby

Re: rel_ops (was Re: GCC 3.1 Release)

[Phil Edwards]

On Fri, Apr 19, 2002 at 09:54:02PM +0200, Gabriel Dos Reis wrote:
> Phil Edwards <phil@jaj.com> writes:
> 
> | In a perfect world (or at least in mine *grin*), we could tell the compiler
> | that, in the case of ambiguous matches, check to see if one of the functions
> | is in the std::rel_ops namespace, and if so, temporarily discard that one,
> | and see if the ambiguity remains.  (Blue-sky idea, probably flaky.)
> 
> That isn't conforming and I'm not sure I would like to implement that
> feature, I might be definitely labelled "anti-rel-ops" ;-)

Oh, it's definitely nonconforming, but most of my ideas for extensions
are nonconforming.  :-)


> [ Phil, I'm getting mailer-daemon notices telling me that your address
> isn't valid.  What is up? ]

There was some network flakiness earlier today.  Things should be normal
again.  (Note that it's no longer pedwards@, but phil@.)


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: rel_ops (was Re: GCC 3.1 Release)

[Joe Buck]

> | Conflicts will only occur if the user definition (or more specific
> | definition in the system library) permits the arguments to be of different
> | types but allows them to be of the same type.  If this happens, then it is
> | possible that, for a call to operator!= with two arguments that are of
> | exactly the same type, the two definitions of operator!= will be seen as
> | equal cost, and neither will be seen as a specialization of the other,
> | so the compiler will report an ambiguity.
> 
> Not always.  Sometimes, it will take the std::rel_ops version because
> it provides a "best match" (according to the standard).

Right.  For example, if I define

bool operator!=(const foo&, const foo&);

and then I have a class bar that derives from foo, the std::rel_ops
version will be a better match for 

bar b1, b2;
...
b1 != b2;

because the exact template match is better than the standard conversion
to the base class.

However, anyone who does a using directive to bring in rel_ops is saying
that it is OK to define != in terms of ==, so this doesn't matter.  The
only cases that are problems are those in which neither is preferred.

> | The way to solve it is to add a third definition that will be seen by
> | the compiler as more specific than either of the alternatives.
> 
> Actually, this might not be always practical.

If so, the alternative is to be sure not to use rel_ops. :-)  However,
since the standard library has to support rel_ops to be correct, at least
the standard library implementers need to use such techniques.