[Bug c++/15910] New: can't compile self defined void distance(std::vector<T>, std::vector<T>)

[Bug c++/15910] New: can't compile self defined void distance(std::vector<T>, std::vector<T>)

[king dot benjamin at mh-hannover dot de]

The following program does not compile:

-----
#include <vector>
 
double distance(const std::vector<double> & v1, const std::vector<double> & v2) 
{
  return 0;
}
 
int main(int argc, char* argv[])
{
  std::vector<double> v;
  double d;
  d = distance(v, v);
  return 0;
}
----

In response to a post to gcc-bugs@gcc.gnu.org, Jim Wilson wrote:

----
I am not a C++ expert, so I am really not the right person to be looking at 
this.  However, I suspect the problem is that the vector 
class is itself defined in namespace std, and uses the iterator classes, and 
that is somehow causing the search for the distance 
function to also look at the interator classes.  It isn't just the name 
distance, any name in stl_interator.h seems to cause the 
same problem.
 
I can get your testcase to compile if I change
  d = distance(v, v);
to
  d = ::distance(v, v);
----

-- 
           Summary: can't compile self defined void distance(std::vector<T>,
                    std::vector<T>)
           Product: gcc
           Version: 3.3.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: king dot benjamin at mh-hannover dot de
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: 3.3.2
  GCC host triplet: 3.3.2
GCC target triplet: 3.3.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug c++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[king dot benjamin at mh-hannover dot de]

------- Additional Comments From king dot benjamin at mh-hannover dot de  2004-06-10 14:42 -------
Created an attachment (id=6507)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=6507&action=view)
.ii file for the problematic code


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug c++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[king dot benjamin at mh-hannover dot de]

------- Additional Comments From king dot benjamin at mh-hannover dot de  2004-06-10 14:44 -------
Sorry, I forgot the compiler output when compilation fails: 
 
----
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.
2/include/g++-v3/bits/stl_iterator_base_types.h: In instantiation of `std::
iterator_traits<std::vector<double,
 std::allocator<double> > >':
minifail.cpp:11:   instantiated from here
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.
2/include/g++-v3/bits/stl_iterator_base_types.h:126: error: no
   type named `iterator_category' in `class std::vector<double,
   std::allocator<double> >'
----

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug c++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-06-10 14:45 -------
Jim is right -- the compiler looks into the namespace of the  
arguments when looking for a function 'distance' and therefore  
doesn't find the one in global namespace. It does find one  
in namespace std::, though, so tries to call it. In the  
process of this, it has to do some argument conversions, which  
fail -- this is what you get the error messages for.  
  
Jim already mentioned the correct way to write the program so  
that it compiles. Note that Intel's compiler also rejects this  
program.  
  
W.  

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug c++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-06-10 15:17 -------
Uhm, I'm not convinced about this. Why the hell should ::distance() cause a 
compilation error deep into v3?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug c++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-06-10 16:01 -------
::distance is fine but not distance because
distance (vector, vector) does not work as it should.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug c++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-06-10 16:04 -------
I know, but you are not telling me why.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug c++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-06-10 16:08 -------
If instantiating the *declaration* of a template std::distance() function 
(found through argument-dependent lookup) causes an error, this should fall 
under SFINAE and simply rejects the template function as a possible overload 
for the call. Then we would end up with an overload set containing 
only ::distance().

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug c++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-06-10 16:17 -------
The presence of ::distance is actually immaterial. You also get 
errors if no ::distance is present at all. I think ::distance 
isn't even in the overload set. Instead, gcc only finds the one 
in std:: and tries to convert arguments. 
 
W. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-06-10 16:23 -------
OK. So one of these:

- Either SFINAE does not work as expected while instantiating std::distance 
declaration
- Or v3 should be fixed to rely on SFINAE to reject invalid uses (with, eg, 
enable_if)

It pretty much depends on how distance is declared, but I tend to think that 
it's the latter. I'm tentatively moving the bug to be a v3 bug to catch v3 
specialist attention. I don't have a compiler tree handy to check myself right 
now.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |libstdc++


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[giovannibajo at libero dot it]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |giovannibajo at libero dot
                   |                            |it


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-06-10 17:38 -------
Alright, so here things go: in libstdc++ we have 
 
namespace std{ 
    template<typename _InputIterator> 
    inline typename iterator_traits<_InputIterator>::difference_type 
    distance(_InputIterator __first, _InputIterator __last) 
    { 
 
      return std::__distance(__first, __last, 
        std::__iterator_category(__first)); 
    } 
} 
 
Clearly this is a match for the call regarding the arguments to the 
function. There is a general iterator_traits template: 
 
  template<typename _Iterator> 
    struct iterator_traits 
    { 
      typedef typename _Iterator::iterator_category iterator_category; 
      typedef typename _Iterator::value_type value_type; 
      typedef typename _Iterator::difference_type difference_type; 
      typedef typename _Iterator::pointer pointer; 
      typedef typename _Iterator::reference reference; 
    }; 
 
In this case, we will instantiate it with _Iterator=std::vector<double> 
(oh, well, not really an iterator, but how can the compiler know). Now, 
in order to substitute all template arguments to std::distance correctly, 
_Iterator needs to have a difference_type typedef -- which indeed 
std::vector has, namely ptrdiff_t. So we have a match in std::distance, 
and this is what the compiler picks. So far everything is alright. 
 
The next step is that the compiler has to actually compile std::distance 
for this odd template argument that should be, but is not an iterator. 
It fails when finding out the iterator category: 
  __iterator_category(__first) 
This is defined as follows: 
  template<typename _Iter> 
    inline typename iterator_traits<_Iter>::iterator_category 
    __iterator_category(const _Iter&) 
    { return typename iterator_traits<_Iter>::iterator_category(); } 
We use again the general iterator_traits class template which 
yields that  
  iterator_category == _Iterator::iterator_category 
with _Iterator==std::vector. Here, we fail, because this local 
type doesn't exist, so we don't find a matching function 
  __iterator_category 
to call. This is exactly the compiler's error message. I think it 
is alright, though it may be somewhat confusing. 
 
I think there is not much we can do about this -- what the user would 
like is of course that std::distance is rejected right away, but we could 
only do this by putting more checks into the function signature (via SFINAE) 
that the type that was passed is indeed an iterator. Given the wide 
variability of iterator types, I fear that there is not very much we can 
do about things at this point. 
 
Giovanni, are you convinced that this isn't really a gcc problem? 
 
W. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-06-11 00:01 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

bangerth at dealii dot org wrote:

> Alright, so here things go: [...]

Thank you for the perfect analysys!

> I think there is not much we can do about this -- what the user would
> like is of course that std::distance is rejected right away, but we
> could
> only do this by putting more checks into the function signature (via
> SFINAE) that the type that was passed is indeed an iterator.
> Given the wide variability of iterator types, I fear that there is not
> very much we can do about things at this point.

Something like this could work, but it's totally untested:

/****/

// it's an iterator if it has a nested type called iterator_category
template <class T> struct is_iterator
{
    typedef char yes[1];
    typedef char no[2];

    template <class T> yes test(typename T::iterator_category* );
    template <class T> no test(...);

    enum { result = (sizeof(test<T>(0)) == sizeof(yes)) };
};

// or if it's a pointer
template <class T>
struct is_iterator<T*> { enum { result = 1 }; };

/****/

// handy SFINAE to be used in return types
template <bool B, class T> struct enable_if {};
template <class T> struct enable_if<true, T> { typedef T type; }

/****/

namespace std{
    template<typename _InputIterator>
    inline
    typename enable_if<  typename is_iterator<_InputIterator>::result,
        typename iterator_traits<_InputIterator>::difference_type  >::type
    distance(_InputIterator __first, _InputIterator __last)
    {
        .....
    }
}


> Giovanni, are you convinced that this isn't really a gcc problem?

Well, let's put in this way: when I look at the testcase for this bug, it
strikes me VERY ODD that it is not valid C++ code. If you name distance as
distance2 it works. The name clash between ::distance() and std::distance()
should not happen, it is not meant to happen (this is why there is a namespace
std in the first place!), and it is just a side effect of the complexity of the
language rules.

So yes, I think it is a problem in GCC, and I reckon it can be fixed pretty
much like I have shown.

Giovanni Bajo




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-06-11 00:59 -------
(In reply to comment #11)

>     template <class T> yes test(typename T::iterator_category* );

This should probably be:
   template <class T> yes test(typename 
std::iterator_traits<T>::iterator_category* );

which would also remove the need for this specialization:

> template <class T>
> struct is_iterator<T*> { enum { result = 1 }; };

Giovanni Bajo


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
           Keywords|                            |rejects-valid
   Last reconfirmed|0000-00-00 00:00:00         |2004-06-11 00:59:29
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2004-08-03 10:33 -------
I'm looking a bit into this. Frankly, I don't think we really want to complicate
std::distance with the enable_if bits. FWIW, Icc8 (+ Dinkum) behaves *exactly* in
the same way of gcc. On the other hand, the type traits support is in flux and
perhaps we'll be able to easily refine the library in these areas in the near
future. I'm suspending the PR.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |SUSPENDED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-08-03 10:44 -------
Well, Paolo, I don't think this is the right decision. Even if Dinkum does the 
same. It is very counterintuitive for the user: it does not make sense to not 
being able to define and naturally use ::whatever_name only because we define 
std::whatever_name. Especially since *there is* a way to fix this, as I showed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pcarlini at suse dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2004-08-03 10:50 -------
I'm saying 'suspended' not 'not a bug'!
First, the ongoing work on type traits + tr1 may simplify considerably this kind
of refinements, exploting enable_if idioms.
Second, if we really want to go this way, we should do it consistently: don't you
believe that most definitely *many* other places of the library could be amenable
to this treatment?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[pcarlini at suse dot de]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-08-03 11:17 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

Is there *anything* in the standard saying that the code is actually illegal?
This is a rejects-valid IMO.

Giovanni Bajo




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[gdr at gcc dot gnu dot org]

------- Additional Comments From gdr at gcc dot gnu dot org  2004-08-03 11:27 -------
(In reply to comment #7)
> If instantiating the *declaration* of a template std::distance() function 
> (found through argument-dependent lookup) causes an error, this should fall 
> under SFINAE and simply rejects the template function as a possible overload 

Why should it fall under SFINAE?

> for the call. Then we would end up with an overload set containing 
> only ::distance().

If you want ::disatnce, say ::distance.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[gdr at gcc dot gnu dot org]

------- Additional Comments From gdr at gcc dot gnu dot org  2004-08-03 11:29 -------
(In reply to comment #9)
> OK. So one of these:
> 
> - Either SFINAE does not work as expected while instantiating std::distance 
> declaration
> - Or v3 should be fixed to rely on SFINAE to reject invalid uses (with, eg, 
> enable_if)

On what grounds?  Just because you want it?

> 
> It pretty much depends on how distance is declared, but I tend to think that 
> it's the latter. I'm tentatively moving the bug to be a v3 bug to catch v3 
> specialist attention. I don't have a compiler tree handy to check myself right 
> now.
> 



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

Re: [Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[Gabriel Dos Reis]

"giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes:


| Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)
| 
| Is there *anything* in the standard saying that the code is actually illegal?
| This is a rejects-valid IMO.

Giovanni --

  Can you elaborate on why you believe this is a reject a valid?

-- Gaby

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2004-08-03 11:30 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

"giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes:


| Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)
| 
| Is there *anything* in the standard saying that the code is actually illegal?
| This is a rejects-valid IMO.

Giovanni --

  Can you elaborate on why you believe this is a reject a valid?

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[gdr at gcc dot gnu dot org]

------- Additional Comments From gdr at gcc dot gnu dot org  2004-08-03 11:33 -------
(In reply to comment #10)

> I think there is not much we can do about this -- what the user would 

Wolfgang, your analyzis makes the most sense to me.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[gdr at gcc dot gnu dot org]

------- Additional Comments From gdr at gcc dot gnu dot org  2004-08-03 11:38 -------
(In reply to comment #11)

> > Giovanni, are you convinced that this isn't really a gcc problem?
> 
> Well, let's put in this way: when I look at the testcase for this bug, it
> strikes me VERY ODD that it is not valid C++ code. If you name distance as
> distance2 it works. The name clash between ::distance() and std::distance()
> should not happen, it is not meant to happen (this is why there is a namespace
> std in the first place!), and it is just a side effect of the complexity of the
> language rules.

I don't buy that reasoning.
A class is not an iterator just because it happens to have 
a nested type named iterator_category.  Your SFINEA game does not
solve the fundamental problem.  It is just tryin to paper over the roots.
As such, I oppose any game to that effect in libstdc++.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-08-03 12:48 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

gdr at integrable-solutions dot net wrote:

>> Is there *anything* in the standard saying that the code is actually
>> illegal?
>> This is a rejects-valid IMO.

>   Can you elaborate on why you believe this is a reject a valid?

Because I think that picking up std::distance by Koenig lookup and having it
*abort compilation* instead of being reject as an invalid overload is just an
unintended side effect of the implementation. If you want to push it, it might
be an unintended side-effect of the standard - fine, the standard is broken.
But I won't never buy that the code is rightfully ill-formed as-is. It breaks
every single kind of orthogonality in the language: for instance, if I define a
::distance() with 3 parameters, it will compile.

When and if we agree there is *at least* a QoI issue here, we can discuss the
implementation details.


>A class is not an iterator just because it happens to have
>a nested type named iterator_category.

Sure, I'm just making the QoI issue less worse. There are other possible
implementations that come to mind. I can enable_if using a ConceptCheck on the
iterators - still much better than just aborting on *any* class.

Or maybe, we could have a way to use enable_if using as condition "does
iterator_traits<T> have a nested difference_type?".

Giovanni Bajo




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2004-08-03 13:01 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

"giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Additional Comments From giovannibajo at libero dot it  2004-08-03 12:48 -------
| Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)
| 
| gdr at integrable-solutions dot net wrote:
| 
| >> Is there *anything* in the standard saying that the code is actually
| >> illegal?
| >> This is a rejects-valid IMO.
| 
| >   Can you elaborate on why you believe this is a reject a valid?
| 
| Because I think that picking up std::distance by Koenig lookup and having it
| *abort compilation* instead of being reject as an invalid overload is just an
| unintended side effect of the implementation.

I'm more interested in chapter and verse, since you stated that this
is a reject-valid. 

| If you want to push it, it might
| be an unintended side-effect of the standard - fine, the standard is broken.

Then, take it to the C++ standards committee.

| But I won't never buy that the code is rightfully ill-formed as-is. It breaks

It is fundamentally broken as per the current standard.  If you
think the standard is broken, then take it to the committee and fix
the standard.

[...]

| Or maybe, we could have a way to use enable_if using as condition "does
| iterator_traits<T> have a nested difference_type?".

You could use iterator_traits, but again the code is fundamentally
broken. Papering over the problem is the wrong thing to do.  A broken
code should explose as soon as possible.  Otherwise, a QoI we don't do
a good job at spotting broken or dubious or non-portable codes.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-08-03 13:04 -------
I am with Gaby here: if we change the signature of std::distance, then 
only to be consistent with the language standard. Now, the signature 
of the distance function is quite clearly stated in 24.3.4. I'm not 
sure we should mess with it. 
 
It is true that the given argument (here: std::vector) does not satisfy 
the requirements of an input iterator as laid out in table 72. However, 
I don't know whether the standard allows us to actually check these 
requirements on template arguments in a way that not only rejects a 
program in which they are not satisfied (this would be the case if in 
the body of the std::distance function we had concept checks that made 
sure that the type of the template argument InputIterator is really an 
input iterator, and otherwise generate a compiler error), but rather 
_reject a given function from the overload set_ and allows us to pick 
a different function. 
 
Giovanni, if you believe that such a change that make a program valid 
that was previously invalid is allowed, you should point us to the 
respective clauses of the standard that states so. 
 
W. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-08-03 13:13 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

gdr at integrable-solutions dot net wrote:

>> Because I think that picking up std::distance by Koenig lookup and
>> having it *abort compilation* instead of being reject as an invalid
>> overload is just an unintended side effect of the implementation.
>
> I'm more interested in chapter and verse, since you stated that this
> is a reject-valid.

I don't see anything in the standard that tells me I cannot define a function
called "distance" in the global namespace. Nor that if I do it, I must call it
with an explicit scope specification. Hence, the code is valid, just like I can
define a function named "distance2". Bring me your chapter and verse which
tells that the code is ill-formed.

Really, are you implying that the committee *explicitally* wanted to avoid such
a case while writing the standard? It looks obvious to me that it would be
*great* if the code worked as-is, and it is just an unfortunate chain of events
(complex language rules) which break compilation.

I doubt we will ever going to agree here, Gaby. Really, I doubt it. The core
here is: I think it is correct by large common sense, I think it is crystal
clear that it is correct. So crystal clear that it took about 10 comments to
Wolfgang and me[1] understand why GCC was rejecting the code. You are defending
side-effects of complex language rules on normal-looking code as an explanation
of why it is invalid. You have the right of doing so, of course. Moreover, you
are the v3 maintainer, so I think I am out of luck here.

Giovanni Bajo

[1] and we both know C++ at a decent level, I presume.




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-08-03 13:21 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

bangerth at dealii dot org wrote:

> However,
> I don't know whether the standard allows us to actually check these
> requirements on template arguments in a way that not only rejects a
> program in which they are not satisfied, but rather
> _reject a given function from the overload set_ and allows us to pick
> a different function.

You do realize that this happens only because ::distance() is defined with name
"distance", has 2 parameters, and it is called with (at least) one argument
from namespace std, right? Do you really believe it makes sense to reject this
very special situation and allow any other orthogonally similar use of such a
function?

W are also allowed to define std::distance with a different prototype under the
as-if rule if we want to, and I think this improves the C++ experience for the
user, that is, we have a better compiler if we do.

I can agree (as I said) that we are not literally *forced* to do it, but not
that it would not be better doing it. This is why I haven't changed back
'enhancement' to 'rejects-valid'. Note that I still personally think it is
valid code, though.

Giovanni Bajo




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2004-08-03 13:28 -------
> I can agree (as I said) that we are not literally *forced* to do it, but not
> that it would not be better doing it. This is why I haven't changed back
> 'enhancement' to 'rejects-valid'.

By the way, since I'm also a libstdc++ maintainer and the PR is still categorized
as 'libstdc++', I would consider slightly unpolite you doing that. Sorry for the
needed punctualization. Paolo.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-08-03 13:32 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

pcarlini at suse dot de wrote:

>> I can agree (as I said) that we are not literally *forced* to do it,
>> but not that it would not be better doing it. This is why I haven't
>> changed back 'enhancement' to 'rejects-valid'.
> 
> By the way, since I'm also a libstdc++ maintainer and the PR is still
> categorized as 'libstdc++', I would consider slightly unpolite you
> doing that. Sorry for the needed punctualization. Paolo.

Sure.

Giovanni Bajo




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-08-03 13:44 -------
So, how about this: we probably all agree that "it would be nice if it 
worked", but we're unsure whether we can make that change while staying 
in accordance with the standard. The usual course for this is to draft 
a DR to the language, in this case one in which one would add a sentence 
somewhere to the general bits of the library specification that function 
declarations may be rejected if the template arguments do not match 
their constraints. (Here, this means that std::distance may verify that 
its InputIterator template argument does really satisfy the requirements 
listed in table 72 for input iterators.) 
 
If such a DR has sufficient support that it sounds likely that it may  
eventually be part of the standard, then implementing it in libstdc++ 
is a reasonable thing. 
 
Note that a clause like this in the standard would be very much in line 
with recent standardization work of constraints on template parameters 
in general (I'm sure Gaby has a lot to say about this) and would be 
an application of these constraints within the library. It is also 
worth mentioning that it would be strictly compatible: whatever is 
valid now will be valid in the future, though a number of programs 
(such as the one in this PR) were invalid before and will be valid 
afterwards. [1] 
 
W. 
 
[1] What does make me nervous, though, is the following: if the standard 
_allows_ us to check constraints on template parameters, and we do 
so, then the program in this PR will become valid. However, it will not 
necessarily become portable: other compiler libraries may not follow 
this "allows to" clause, and this program will not be compilable there. 
This is why I would much rather prefer if the standard actually prescribed 
the correct signature of std::distance, as this is the only way to make 
sure that programs remain compatible. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-08-03 13:51 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

pcarlini at suse dot de wrote:

> First, the ongoing work on type traits + tr1 may simplify
> considerably this kind of refinements, exploting enable_if idioms.

OK. Meanwhile, so that it does not seem I am here just to do FUD, this is
another proto-patch to fix this bug. This solution seems almost perfect to me:


template <class Iter>
typedef typename lazy_enable_if<
    has_difference_type<iterator_traits<T> >,
    get_difference_type<iterator_traits<T> >
>::type
distance(Iter first, Iter last) { ... }


with the following obvious definitions for the helpers:

template <bool C, class T> struct lazy_enable_if {};
template <class T> struct lazy_enable_if<true,T> { typedef typename T::type
type };

template <class T> struct get_difference_type {
    typedef typename T::difference_type type;
};

template <class T> struct has_difference_type {
    typedef char yes[1];
    typedef char no[2];

    template <class T> yes test(typename T::difference_type* );
    template <class T> no test(...);

    enum { result = (sizeof(test<T>(0)) == sizeof(yes)) };
};



> Second, if we really want to go this way, we should do it
> consistently: don't you believe that most definitely *many* other
> places of the library could be amenable to this treatment?

I don't know how many off-hand. Many other functions don't return a type which
is *indirectly* invalid if T is not an iterator (indirectly = causes an
instantiation error, rather than being directly invalid and trigger SFINAE), so
I don't think it affects v3 that much.

Giovanni Bajo




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[gdr at integrable-solutions dot net]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3276 bytes --]


------- Additional Comments From gdr at integrable-solutions dot net  2004-08-03 15:05 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

"giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes:

| gdr at integrable-solutions dot net wrote:
| 
| >> Because I think that picking up std::distance by Koenig lookup and
| >> having it *abort compilation* instead of being reject as an invalid
| >> overload is just an unintended side effect of the implementation.
| >
| > I'm more interested in chapter and verse, since you stated that this
| > is a reject-valid.
| 
| I don't see anything in the standard that tells me I cannot define a function
| called "distance" in the global namespace. Nor that if I do it, I must call it
| with an explicit scope specification. Hence, the code is valid,

If you're unable to produce chapter and verse as to why the code is
valid, then you're out of luck.  

| just like I can
| define a function named "distance2". Bring me your chapter and verse which
| tells that the code is ill-formed.

See the rather excellent explanation given by Wolfgang.  If you ever
happen to disagree with any of his technical points, please just point
it out instead of confusing what the standard says with what you would
like it to say.

| Really, are you implying that the committee *explicitally* wanted to

Please, do not put words in my mouth. 

| avoid such a case while writing the standard? It looks obvious to me
| that it would be 
| *great* if the code worked as-is,

It would be greate != it is valid according to the standard.
There are lots of things out there it would be great if they worked.

| and it is just an unfortunate chain of events
| (complex language rules) which break compilation.

If you believe the standard is broken, please take it up to the
standards committee and fix it.

| I doubt we will ever going to agree here, Gaby. Really, I doubt it. The core

That does not make prevent me from sleeping.

| here is: I think it is correct by large common sense, I think it is crystal
| clear that it is correct. 

  On appelle idées claires, celle qui sont au même degré de
  confusion que les siennes.

| So crystal clear that it took about 10 comments to
| Wolfgang and me[1] understand why GCC was rejecting the code. 

The fact that you're insisting in confusing your desire with actual
wording is not germane to that number of comments.

| You are defending
| side-effects of complex language rules on normal-looking code as an explanation
| of why it is invalid. You have the right of doing so, of course. Moreover, you

Please, stop putting words in mouth.  I'm not defending a language rule.
You came and tell people that this is a reject-valid PR.  The minimum
thing to do is to produce a chapter and verse or a chain of logical
inferences of why that is so.  Instead, you're telling people that it
would be great if it worked.  That is called a wishful thinking.

| are the v3 maintainer, so I think I am out of luck here.
| 
| Giovanni Bajo
| 
| [1] and we both know C++ at a decent level, I presume.

I'm not questionning your level of C++ understanding.  I asked a
rather different question.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2004-08-03 15:08 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

"giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes:

| bangerth at dealii dot org wrote:
| 
| > However,
| > I don't know whether the standard allows us to actually check these
| > requirements on template arguments in a way that not only rejects a
| > program in which they are not satisfied, but rather
| > _reject a given function from the overload set_ and allows us to pick
| > a different function.
| 
| You do realize that this happens only because ::distance() is defined with name
| "distance", has 2 parameters, and it is called with (at least) one argument
| from namespace std, right? Do you really believe it makes sense to reject this
| very special situation and allow any other orthogonally similar use of such a
| function?

What he believes make sense is different what what actually makes the
code valid or invalid.  
We're not going to fix random broken users codes.
The real issue is deeper than you seem to realize. 
Focusing on "distance" is in the tradition of the usual myopic view
where we consider things in small until they blow up in our hands.
If you want to fix the language, please take it to the committee.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2004-08-03 15:16 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

"bangerth at dealii dot org" <gcc-bugzilla@gcc.gnu.org> writes:

[...]

| [1] What does make me nervous, though, is the following: if the standard 
| _allows_ us to check constraints on template parameters, and we do 
| so, then the program in this PR will become valid. However, it will not 
| necessarily become portable: other compiler libraries may not follow 
| this "allows to" clause, and this program will not be compilable there. 

Indeed.  That is why I would prefer it b a requirement, not mere
allowance. Mere allowance is a royal route to non portability :-(

| This is why I would much rather prefer if the standard actually prescribed 
| the correct signature of std::distance, as this is the only way to make 
| sure that programs remain compatible. 

We're in violent agreement.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2004-08-03 15:19 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

"giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes:

| Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)
| 
| pcarlini at suse dot de wrote:
| 
| > First, the ongoing work on type traits + tr1 may simplify
| > considerably this kind of refinements, exploting enable_if idioms.
| 
| OK. Meanwhile, so that it does not seem I am here just to do FUD, this is
| another proto-patch to fix this bug. This solution seems almost perfect to me:
| 
| 
| template <class Iter>
| typedef typename lazy_enable_if<
|     has_difference_type<iterator_traits<T> >,
|     get_difference_type<iterator_traits<T> >
| >::type
| distance(Iter first, Iter last) { ... }

Please, do understand that
  
  (1) you're changing the signature of this template function;  I see
      nothing in the standard that allows this transmutation.  I would
      welcome any quote to that effect.

  (2) focusing on distance is wrong:  It is just the tip of the iceberg.

[...]

| > Second, if we really want to go this way, we should do it
| > consistently: don't you believe that most definitely *many* other
| > places of the library could be amenable to this treatment?
| 
| I don't know how many off-hand.

Every places where the constraints on the template parameter are in
comments, not in actual codes.  And there are lots of them.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[giovannibajo at libero dot it]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 558 bytes --]


------- Additional Comments From giovannibajo at libero dot it  2004-08-03 17:44 -------
>   On appelle idées claires, celle qui sont au même degré de
>   confusion que les siennes.

"A l'è inutil insegnà al mus, si piart timp in plui si infastidis la bestie".


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|giovannibajo at libero dot  |
                   |it                          |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-08-03 18:12 -------
Closing as I think this got out of hand, I opened a new bug, PR 16862 for keeping track of the main 
issues.  Now if you want to agruee in the new bug, remember I get two copies of the mail and I will 
again do this.

*** This bug has been marked as a duplicate of 16862 ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|SUSPENDED                   |RESOLVED
         Resolution|                            |DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[gdr at integrable-solutions dot net]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 542 bytes --]


------- Additional Comments From gdr at integrable-solutions dot net  2004-08-03 18:20 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

"giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes:

| >   On appelle idées claires, celle qui sont au même degré de
| >   confusion que les siennes.
| 
| "A l'è inutil insegnà al mus, si piart timp in plui si infastidis la bestie".

It takes two to tango, as they say.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2004-08-03 18:24 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| issues.  Now if you want to agruee in the new bug, remember I get two copies of the mail and I will 
| again do this.

You can manage to get only one copy ;-)

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-08-03 18:25 -------
*** Bug 16862 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-08-03 18:25 -------
[From my message to PR 16882] 
Andrew, 
All the analysis of what exactly happens, why, what can be done 
and why some people believe that we should or shouldn't can be 
found in the other PR. None of this information is present 
in this PR, so everyone working on the present one would have 
to look it up there. I don't see any reason in opening another PR 
for this, and therefore will close this and reopen the other one. 
 
W. 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|DUPLICATE                   |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[bangerth at dealii dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |SUSPENDED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-08-03 12:56 -------
*** Bug 23213 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adah at netstd dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-08-03 13:03 -------
Just for reference, the thread from comp.lang.c++.moderated:
http://groups-beta.google.com/group/comp.lang.c++.moderated/browse_thread/thread/
3c449572456c8592

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[adah at netstd dot com]

------- Additional Comments From adah at netstd dot com  2005-08-04 05:27 -------
As the reporter of Bug 23213, I want to add my 2 cents (my opinions):

1) This bug is not in libstdc++, but in the C++ compiler.

2) The std::distance (as found by Koenig lookup) does not hide the global one 
the user defines, but the failure to complete the return type aborts the 
candidate building procedure (if we fake the type definitions required, the 
user-defined version will be correctly selected).  And SFINAE does not kick 
in.  I really cannot see why this is not a bug (providing something unrelated 
to user code will make the user code work!).

3) To complicate the matter, all "good" compilers I know fail in this case.  
However, I still believe it is the problem of the compilers.

Yongwei


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-08-04 10:13 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

"adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| 1) This bug is not in libstdc++, but in the C++ compiler.

yes and no.

[...]

| 3) To complicate the matter, all "good" compilers I know fail in this case.  
| However, I still believe it is the problem of the compilers.

Please take ti to the C++ standard committee.  The behaviour is that
described by the standard.  If you don't like it, have the committee
change it.  If you think name lookup is an easy exercise, give it a try.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[adah at netstd dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1179 bytes --]


------- Additional Comments From adah at netstd dot com  2005-08-05 05:41 -------
(In reply to comment #44)
> | However, I still believe it is the problem of the compilers.
> Please take ti to the C++ standard committee.  The behaviour is that
> described by the standard.  If you don't like it, have the committee

The behaviour I wanted is at least not *against* the standard, while being more 
natural and user-friendly.  As James Kanze quoted §14.7.1/5 in 
comp.lang.c++.moderated: "If the overload resolution process can determine the 
correct function to call without instantiating a class template definition, it 
is unspecified whether that instantiation actually takes place."

BTW, proposal N1799 directly addresses this problem and, if adopted, will make 
the program we are discussing legal instead of unspecified behaviour.

> change it.  If you think name lookup is an easy exercise, give it a try.

I never thought any part of a C++ compiler is easy.  I just try to express my 
opinions on this subject, as a common gcc user (I myself do *not* define any 
functions named distance).

> -- Gaby

Yongwei


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2005-08-05 13:10 -------
I fail to see how James' quote has any significance for this PR at all. It 
talks about overload resolution, which is not the question here at all. 
W. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[gdr at integrable-solutions dot net]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1177 bytes --]


------- Additional Comments From gdr at integrable-solutions dot net  2005-08-06 11:57 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

"adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| (In reply to comment #44)
| > | However, I still believe it is the problem of the compilers.
| > Please take ti to the C++ standard committee.  The behaviour is that
| > described by the standard.  If you don't like it, have the committee
| 
| The behaviour I wanted is at least not *against* the standard, while being more 
| natural and user-friendly.  As James Kanze quoted §14.7.1/5 in 
| comp.lang.c++.moderated: "If the overload resolution process can determine the 
| correct function to call without instantiating a class template definition, it 
| is unspecified whether that instantiation actually takes place."

Can you explain me clearly how that has any implication about how the
compiler should behave in this specific case?  We're not in an
unspecified territory here.  Please do read Paul M.'s explanation.

This PR should be colsed as INVALID.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2005-08-06 17:18 -------
I agree with Gaby: the standard pretty unambiguously lists the signature of 
std::distance, and the name lookup rules say that it needs to be found. What 
leeway do we have in rejecting it anyway and picking anything else? The fact 
that you want another function to be found is not a normative clause that 
can be derived from the standard. 
 
However, as has been proposed before: the correct course of action is to  
lobby the standards committee to introduce some notion of "concept" and  
specify that the std::distance function shall only be used if its arguments 
conform to a certain concept. This has been done in the past using means 
like boost::enable_if, but the standard doesn't use such things at present 
so I don't see how we can modify libstdc++ in a way that conforms with 
the present standard. 
 
I therefore close this PR as suggested by Gaby. 
 
W. 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|SUSPENDED                   |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[adah at netstd dot com]

------- Additional Comments From adah at netstd dot com  2005-08-08 02:26 -------
Sorry, but some of you here have not read carefully enough and acted in a 
haste.  Please test with the following code piece and make a decision AFTER 
that:

#include <iostream>
#include <vector>

int distance(std::vector<int> v1, std::vector<int> v2)
{
    std::cout << "I am chosen!" << std::endl;
    return v1.size() - v2.size();
}

// Begins the hack
namespace std {

template<>
struct iterator_traits<vector<int> >
{
    typedef int iterator_category;
    typedef int value_type;
    typedef int difference_type;
    typedef int distance_type;
    typedef int pointer;
    typedef int reference;
};

}
// End the hack

int main()
{
    std::vector<int> v1(3), v2(1);
    int d = distance(v1, v2);
    return 0;
}

The point is: adding the seemingly unrelated code will make the user distance 
be chosen.

Best regards,

Yongwei


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[adah at netstd dot com]

------- Additional Comments From adah at netstd dot com  2005-08-08 03:53 -------
Sorry for the tone in my previous comment.  I guess I was a little heated and 
acted in a haste.

This said, I still cannot think this bug report is `INVALID', from a user's 
point of view.  The test code showed it clearly enough.  However, this time let 
me try to see whether my point can find grounds in the current C++ Standard:

14.8.3/1: `When a call to that name is written (explicitly, or implicitly using 
the operator notation), template argument deduction (14.8.2) and checking of 
any explicit template arguments (14.3) are performed for each function template 
to find the template argument values (if any) that can be used with that 
function template to instantiate a function template specialization that can be 
invoked with the call arguments.  For each function template, if the argument 
deduction and checking succeeds, the template-arguments (deduced and/or 
explicit) are used to instantiate a single function template specialization 
which is added to the candidate functions set to be used in overload 
resolution. If, for a given function template, argument deduction fails, no 
such function is added to the set of candidate functions for that template.'

The instantiation is done after the `template argument deduction' is 
successful.  Note it is `template argument deduction' but not `function 
argument deduction'.  I fail to see why the return value type is not considered 
in the template argument deduction, though the Standard is somehow a little 
vague on this (I have found no explicit requirements or prohibitions.)

By the way, the current error message for the instantiation failure is not 
helpful at all to help the user identify the problem!

Yongwei


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-08-08 04:56 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

"adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:

[...]

| template<>
| struct iterator_traits<vector<int> >

Invalid.

[...]

| The point is: adding the seemingly unrelated code will make the user
| distance be chosen.

yes, we understood that.  The point is why is that a bug in the
compiler as opposed to a "bug" in the standard?  That is what you have
failed to explain so far.  The mere fact that you did not like the
result does not count as a bug in the compiler.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-08-08 04:59 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

"adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| This said, I still cannot think this bug report is `INVALID', from a user's 
| point of view. 

We're dealing with INVALID as whether it is a bug with respect to the
language standard.

[...]

| The instantiation is done after the `template argument deduction' is 
| successful.

Have you read Paul M.'s explanation?

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[adah at netstd dot com]

------- Additional Comments From adah at netstd dot com  2005-08-08 06:19 -------
(In reply to comment #52)
> Subject: Re:  can't compile self defined void distance(std::vector<T>, 
std::vector<T>)
> "adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:
> | This said, I still cannot think this bug report is `INVALID', from a user's 
> | point of view. 
> We're dealing with INVALID as whether it is a bug with respect to the
> language standard.
> [...]

I have not yet been able to deduce from the Standard that the OP's code is 
invalid.

> | The instantiation is done after the `template argument deduction' is 
> | successful.
> Have you read Paul M.'s explanation?

I know no one named Paul M.  He seems not here, either.

> -- Gaby

Yongwei


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[adah at netstd dot com]

------- Additional Comments From adah at netstd dot com  2005-08-08 06:31 -------
(In reply to comment #53)
> I know no one named Paul M.  He seems not here, either.

Really sorry that I missed the latest posting on comp.lang.c++.moderated by 
Paul Mensonides....

The explanation is good enough.  The result is bad enough.  The error message 
will make STL even more notorious.

Yongwei


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-08-08 10:25 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

"adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| > Subject: Re:  can't compile self defined void distance(std::vector<T>, 
| std::vector<T>)
| > "adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:
| > | This said, I still cannot think this bug report is `INVALID', from a user's 
| > | point of view. 
| > We're dealing with INVALID as whether it is a bug with respect to the
| > language standard.
| > [...]
| 
| I have not yet been able to deduce from the Standard that the OP's code is 
| invalid.

Then I strongly suggest you read the thred in comp.lang.c++.moderated
where the PR originates from.

| > | The instantiation is done after the `template argument deduction' is 
| > | successful.
| > Have you read Paul M.'s explanation?
| 
| I know no one named Paul M.  He seems not here, either.

Good.  As reported in earlier comments, the PR originated from a
discussion in comp.lang.c++.moerated.  I suggest you google and read
the thread before sending more comments on this PR.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-08-08 10:29 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

"adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| (In reply to comment #53)
| > I know no one named Paul M.  He seems not here, either.
| 
| Really sorry that I missed the latest posting on comp.lang.c++.moderated by 
| Paul Mensonides....
| 
| The explanation is good enough.  The result is bad enough.

As suggested in the very beginning, if you don't like the result take
it to the C++ committee.  That is the appropriate place to discuss 
standard specifications wrong with respect to user's point of view.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[adah at netstd dot com]

------- Additional Comments From adah at netstd dot com  2005-08-08 12:56 -------
(In reply to comment #56)
> Subject: Re:  can't compile self defined void distance(std::vector<T>, 
std::vector<T>)
> "adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:
> | (In reply to comment #53)
> | > I know no one named Paul M.  He seems not here, either.
> | 
> | Really sorry that I missed the latest posting on comp.lang.c++.moderated 
by 
> | Paul Mensonides....
> | 
> | The explanation is good enough.  The result is bad enough.
> As suggested in the very beginning, if you don't like the result take
> it to the C++ committee.  That is the appropriate place to discuss 
> standard specifications wrong with respect to user's point of view.
> -- Gaby

While I fully respect the labours of the Standard committee, and have come to 
realize the potential technical difficulties in this issue, you words leave me 
to wonder:

Does a compiler serve its users or the Standard committee?

Yongwei


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2005-08-08 13:20 -------
It serves its users by providing a reliable translator for the language 
defined by the standard. Think about the portability implications of 
compilers that willy-nilly implement some parts of the standard but not 
all, based on what they perceive as their users' best interest. 
 
If you go beyond toy projects, then best user interest will place a formally 
and well-defined, portable language over a language that always does what 
the user intuitively wants it to do. 
 
W. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-08-08 18:08 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

"adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| Does a compiler serve its users or the Standard committee?

Answer: Does a compiler that does not implement the standard specification  
serves its users?

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[adah at netstd dot com]

------- Additional Comments From adah at netstd dot com  2005-08-09 01:45 -------
(In reply to comment #59)
> Subject: Re:  can't compile self defined void distance(std::vector<T>, 
std::vector<T>)
> "adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:
> | Does a compiler serve its users or the Standard committee?
> Answer: Does a compiler that does not implement the standard specification  
> serves its users?
> -- Gaby

Answer to answer: Does a compiler that implement a wrong specification in the 
Standard serves the users?

A bug in the Standard does not prevent a bug in the compiler from being a bug!

I am not requiring that GCC must fix the bug (I do not want to argue here 
endlessly as well), but I am dissatisfied that you do not think it a bug.  Just 
imagine the complete loss of an innocent user that happens to define a distance
(vector<...>,...) (`I can name my global functions as I like, or what is the 
purpose of the std namespace?'), when the error messages seem to show that the 
compiler is talking nonsense!

BTW, I do not think a common user has channels to talk to the Standard 
committee.  Compiler vendors have.

My opinion is that the bug should be `suspended' or `deferred', while 
displaying a more friendly error message should be added to the to-do list of 
GCC.

Best regards,

Yongwei


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-08-09 08:35 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

"adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Additional Comments From adah at netstd dot com  2005-08-09 01:45 -------
| (In reply to comment #59)
| > Subject: Re:  can't compile self defined void distance(std::vector<T>, 
| std::vector<T>)
| > "adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:
| > | Does a compiler serve its users or the Standard committee?
| > Answer: Does a compiler that does not implement the standard specification  
| > serves its users?
| > -- Gaby
| 
| Answer to answer: Does a compiler that implement a wrong specification in the 
| Standard serves the users?

The core issue is how do you determine that a standard specification
is wrong?  Just because *you* don't like it?  Sorry, that is insufficient.
There is a well-known body and a well-known process to handle that.
Please take it to the C++ standard committee.

| I am not requiring that GCC must fix the bug

Bugzilla is about bugs in GCC.  If you think it is not a bug, then you
must take it to the place where they handle perceived bugs in the standard.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[adah at netstd dot com]

------- Additional Comments From adah at netstd dot com  2005-08-09 10:49 -------
(In reply to comment #61)
> Subject: Re:  can't compile self defined void distance(std::vector<T>, 
std::vector<T>)
> "adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:
> | ------- Additional Comments From adah at netstd dot com  2005-08-09 01:45 --
-----
> | (In reply to comment #59)
> | > Subject: Re:  can't compile self defined void distance(std::vector<T>, 
> | std::vector<T>)
> | > "adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:
> | > | Does a compiler serve its users or the Standard committee?
> | > Answer: Does a compiler that does not implement the standard 
specification  
> | > serves its users?
> | > -- Gaby
> | 
> | Answer to answer: Does a compiler that implement a wrong specification in 
the 
> | Standard serves the users?
> The core issue is how do you determine that a standard specification
> is wrong?  Just because *you* don't like it?  Sorry, that is insufficient.

Do *you* like it?  If you like it, then I suppose you like to frustrate GCC 
users?

> There is a well-known body and a well-known process to handle that.
> Please take it to the C++ standard committee.

Common users are not supposed to talk with the standard committee.  They may 
even not know it.  I have stated it clearly enough.

> | I am not requiring that GCC must fix the bug
> Bugzilla is about bugs in GCC.  If you think it is not a bug, then you

I do think it is a bug (also clear enough, as I still call it a `bug').  Even 
though it might be due to a bug in the Standard.

> must take it to the place where they handle perceived bugs in the standard.
> -- Gaby

Yongwei


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-08-09 11:07 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

"adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| Do *you* like it?

It is immaterial as far as GCC is concerned.  I know where to raise
such issues and I've suggested you do the same.  You seem not to
understand that comp.lang.c++.moderated and comp.std.c++ are the
appropriate places.  Insisting here will not help you.  At this point,
the only thing you're doing here is sabotaging your own cause by
frustrating people, who otherwise might be disposed to listen to and
support you.  If that was your original purpose, then you have
partially succeeded. 

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[adah at netstd dot com]

------- Additional Comments From adah at netstd dot com  2005-08-09 13:26 -------
(In reply to comment #63)
> | Do *you* like it?
> It is immaterial as far as GCC is concerned.  I know where to raise

Why immaterial?  I just cannot imagine anybody that *likes* this behaviour.  
If no one likes it, how can you call it reasonable behaviour (just because a 
C++ god nodded)?  If it is not reasonable behaviour, why can't you accept that 
it is a bug?  By the way, I think a `bug' here can really be a design flaw, or 
an enhancement request.

> such issues and I've suggested you do the same.  You seem not to
> understand that comp.lang.c++.moderated and comp.std.c++ are the

I posted about one day ago on comp.std.c++.  No one answered.  I do not know 
any better way to contact anybody that might be in the committee.

> appropriate places.  Insisting here will not help you.  At this point,

Reproaching me in this way won't help you, either.

I repeat one thing: I do not have the OP's problem.  As a programmer that has 
some familiarity with the language and the Standard, it is hard to encounter 
this kind of problems. --- People that encounter this bug most probably know 
little (if any) of the C++ Standard, and people know well about the Standard 
most probably won't encounter this bug at all. --- This fact strengthens my 
point that it is a bug.

> the only thing you're doing here is sabotaging your own cause by
> frustrating people, who otherwise might be disposed to listen to and

If you had not spoken in this kind of tones, I might have been much more 
considerate and constructive.  However, I have already tried to be calm and 
constructive instead of being flamy.

I just cannot understand why you have never shown any patience and sympathy on 
this issue.

> support you.  If that was your original purpose, then you have
> partially succeeded. 
> -- Gaby

Yongwei


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[adah at netstd dot com]

------- Additional Comments From adah at netstd dot com  2005-08-09 13:36 -------
(In reply to comment #58)
> It serves its users by providing a reliable translator for the language 
> defined by the standard. Think about the portability implications of 
> compilers that willy-nilly implement some parts of the standard but not 
> all, based on what they perceive as their users' best interest.

Generally you are right.  However, people that encounter this bug most 
probably know little (if any) of the C++ Standard (and thus care little about 
conformance to the Standard), and people know well about the Standard most 
probably won't encounter this bug at all.  So I do not think this point really 
holds.

> If you go beyond toy projects, then best user interest will place a formally 
> and well-defined, portable language over a language that always does what 
> the user intuitively wants it to do.

This is reasonable.  That was why I thought it was not necessary to `fix' this 
bug after some discussions.  I just thought it was still a bug, and some 
measures need to be taken to warn the user about this problem.  It might be of 
low priority, but simply marking it as `INVALID' just covers this problem.  
More people might discover this bug again and report it again, though they 
might not be as _____ (fill in adjectives that you like) as I am.

>  
> W. 

Yongwei


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

Re: [Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[Andrew Pinski]

> This is reasonable.  That was why I thought it was not necessary to `fix' this 
> bug after some discussions.  I just thought it was still a bug, and some 
> measures need to be taken to warn the user about this problem.  It might be of 
> low priority, but simply marking it as `INVALID' just covers this problem.  
> More people might discover this bug again and report it again, though they 
> might not be as _____ (fill in adjectives that you like) as I am.

Even documentioning what the standard say in the non bug section of bug reporting
web page, does not help people to read the docs.  There is no way really to fix
this.  Look at the sequence point docs in bug reporting web page and then look at
all the dupicate bugs.

-- Pinski

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[pinskia at physics dot uc dot edu]

------- Additional Comments From pinskia at physics dot uc dot edu  2005-08-09 13:40 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

> This is reasonable.  That was why I thought it was not necessary to `fix' this 
> bug after some discussions.  I just thought it was still a bug, and some 
> measures need to be taken to warn the user about this problem.  It might be of 
> low priority, but simply marking it as `INVALID' just covers this problem.  
> More people might discover this bug again and report it again, though they 
> might not be as _____ (fill in adjectives that you like) as I am.

Even documentioning what the standard say in the non bug section of bug reporting
web page, does not help people to read the docs.  There is no way really to fix
this.  Look at the sequence point docs in bug reporting web page and then look at
all the dupicate bugs.

-- Pinski


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2005-08-09 14:11 -------
I think we should all recuse ourselves from this discussion, since we just 
keep iterating our same old positions: 
 
Yongwei believes that this is a defect in the standard and that gcc should 
not follow the standard in this respect. 
 
Gaby and I believe that gcc should follow the standard, and probably both 
believe that the standard does not have a defect in this respect. We believe 
that changing the standard would require a massive change in the language, 
since it would either a) require the introduction of concepts (so that 
std::distance can only be called with arguments that match the concept 
of an iterator; same for all other similar functions), or b) abandoning  
argument dependent (Koenig) name lookup. Neither sounds like an appealing 
idea. We believe that users can work around this perceived problem by 
simply calling  
  ::distance (arg1, arg2) 
to get to their own implementation, not the one in std:: 
 
Since we can't seem to find an agreement, let's just leave it at that. 
 
W. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-08-09 17:28 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

"adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| (In reply to comment #63)
| > | Do *you* like it?
| > It is immaterial as far as GCC is concerned.  I know where to raise
| 
| Why immaterial? 

Because we have a standard.  If you want to change the standard, pleae
do so.  GCC bugzilla is the erong place.  You're not helping your
cause here.

| I just cannot imagine anybody that *likes* this behaviour.  

That is orthogonal to GCC bugs.

| If no one likes it, how can you call it reasonable behaviour

Please your words and don't credit me for things I did not say.

| (just because a 
| C++ god nodded)?  If it is not reasonable behaviour, why can't you accept that 
| it is a bug?

A bug in *what*?  That seems to the issue you seem incapable to understand.

| > such issues and I've suggested you do the same.  You seem not to
| > understand that comp.lang.c++.moderated and comp.std.c++ are the
| 
| I posted about one day ago on comp.std.c++.  No one answered.

Impatience will not help you.

| I do not know 
| any better way to contact anybody that might be in the committee.

Do consider that committee members read comp.std.c++.  Since you're
not the center of the universe, do allow time and credit people for
reading what you wrote.

| > appropriate places.  Insisting here will not help you.  At this point,
| 
| Reproaching me in this way won't help you, either.

That is more a statement of fact that "reproaching".

[...]

| > the only thing you're doing here is sabotaging your own cause by
| > frustrating people, who otherwise might be disposed to listen to and
| 
| If you had not spoken in this kind of tones,

which tone?  You jumped in this discussion with the firm belief that
it is a GCC bug, with NO understanding of the rules that govern the
behaviour.  And only reluctantly admitted an explanation of the behaviour.
If you have a problem with GCC, I'm very happy to help you and I'll
encourage other people to help you.  If you want to be a pain in the
ass treating people here as obscure ignorants, then you won't find my
support.  That is very simple. 

| I might have been much more considerate and constructive.  

And you do believe that being condenscending and non-constructive
would help your cause?  That would be very naive.

| I just cannot understand why you have never shown any patience

In effect, I've shown more patience and consideration than needed.
I've always pointed you to the right place to discussion this issue,
giving you hints to material your should digest before claiming this
being a GCC bug.  You've choosen not to consider them.  I can't take blame
for your deliberate choice to ignore advices.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-08-09 17:36 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

"adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| (In reply to comment #58)
| > It serves its users by providing a reliable translator for the language 
| > defined by the standard. Think about the portability implications of 
| > compilers that willy-nilly implement some parts of the standard but not 
| > all, based on what they perceive as their users' best interest.
| 
| Generally you are right.  However, people that encounter this bug most 
| probably know little (if any) of the C++ Standard (and thus care
| little about conformance to the Standard), and people know well
| about the Standard most probably won't encounter this bug at all.

If GCC should start ignoring standard semantics that Random
P. considers a problem for Lambda User, then we would not even have a
working compiler.  And those who know could not even use the compiler.
There are several ways to fix the situation: change the standard
and/or educate people.  

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[adah at netstd dot com]

------- Additional Comments From adah at netstd dot com  2005-08-10 02:40 -------
Since I do not think I can find appropriate words to respond to Gaby without 
inflaming the discussion, I think I had better suppress my will to argue with 
him it for the moment.  Not that I want to ignore his messages.  On the 
contrary, I have read every word.  Sorry that I had ignored some of his advice 
before.  Some was useful.  Regret that I am not an expert in the C++ Standard, 
as most C++ users are not.

(In reply to comment #66)
> Subject: Re:  can't compile self defined void distance(std::vector<T>, 
std::vector<T>)
> > This is reasonable.  That was why I thought it was not necessary to `fix' 
this 
> > bug after some discussions.  I just thought it was still a bug, and some 
> > measures need to be taken to warn the user about this problem.  It might be 
of 
> > low priority, but simply marking it as `INVALID' just covers this problem.  
> > More people might discover this bug again and report it again, though they 
> > might not be as _____ (fill in adjectives that you like) as I am.
> Even documentioning what the standard say in the non bug section of bug 
reporting
> web page, does not help people to read the docs.  There is no way really to 
fix
> this.  Look at the sequence point docs in bug reporting web page and then 
look at
> all the dupicate bugs.
> -- Pinski

Now to your point.  Please notice that my current stance is not that GCC should 
fix this `bug'.  I have stated it days ago.  But the user's failure is really 
UNEXPECTED, and this is a PROBLEM.  To avoid this problem, a better diagnostic 
message should be emitted.  Just try compiling the OP's program to see my point.

My bug report was a duplicate too, but I did do a search on `Koenig'.  I did 
not search on `distance' because I did not think it was the point.

(In reply to comment #67)
> I think we should all recuse ourselves from this discussion, since we just 
> keep iterating our same old positions: 
>  
> Yongwei believes that this is a defect in the standard and that gcc should 
> not follow the standard in this respect. 
>  
> Gaby and I believe that gcc should follow the standard, and probably both 
> believe that the standard does not have a defect in this respect. We believe 

I cannot help wondering why (though this might be better discussed on 
comp.std.c++: I do hope you can discuss there).  IMHO, the current bahaviour is 
violating the rationale of the std namespace.

> that changing the standard would require a massive change in the language, 
> since it would either a) require the introduction of concepts (so that 
> std::distance can only be called with arguments that match the concept 
> of an iterator; same for all other similar functions), or b) abandoning  
> argument dependent (Koenig) name lookup. Neither sounds like an appealing 

If this bug should ever be fixed, I would prefer this approach:

c) Failure to instantiate a template function should automatically remove it 
from the candidates of overload resolution.

> idea. We believe that users can work around this perceived problem by 
> simply calling  
>   ::distance (arg1, arg2) 
> to get to their own implementation, not the one in std:: 

Passing this information to the user is difficult, unless GCC emits a 
diagnostic message to help users do so, as GCC is currently doing on the 
missing of `typename'.

> Since we can't seem to find an agreement, let's just leave it at that. 
>  
> W. 

I am not an unreasonable person.  I just want to see a reasonable ending.

Yongwei


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

Re: [Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[Andrew Pinski]

On Aug 9, 2005, at 10:41 PM, adah at netstd dot com wrote:

>
> Passing this information to the user is difficult, unless GCC emits a
> diagnostic message to help users do so, as GCC is currently doing on 
> the
> missing of `typename'.

even then as I said before when it comes down to it, nobody reads those
messages as they think their code is correct.

See my example when sequence points, we do warn about it in 4.0.0 and 
above
(for C++; for C, we have warned since at least 3.0.4) and people still 
file bugs.

Another example of where people don't read is the changes page, which 
describes
changes to the compiler which could hinder (or benefit) them.  One 
example is
the change in the namelookup for templates to be more towards the 
standard.  That
example shows that we still get bug reports so even with a better error 
message,
people will have something to complain about.

-- Pinski

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[pinskia at physics dot uc dot edu]

------- Additional Comments From pinskia at physics dot uc dot edu  2005-08-10 02:49 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)


On Aug 9, 2005, at 10:41 PM, adah at netstd dot com wrote:

>
> Passing this information to the user is difficult, unless GCC emits a
> diagnostic message to help users do so, as GCC is currently doing on 
> the
> missing of `typename'.

even then as I said before when it comes down to it, nobody reads those
messages as they think their code is correct.

See my example when sequence points, we do warn about it in 4.0.0 and 
above
(for C++; for C, we have warned since at least 3.0.4) and people still 
file bugs.

Another example of where people don't read is the changes page, which 
describes
changes to the compiler which could hinder (or benefit) them.  One 
example is
the change in the namelookup for templates to be more towards the 
standard.  That
example shows that we still get bug reports so even with a better error 
message,
people will have something to complain about.

-- Pinski



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[adah at netstd dot com]

------- Additional Comments From adah at netstd dot com  2005-08-10 03:11 -------
(In reply to comment #71)
> Subject: Re:  can't compile self defined void distance(std::vector<T>, 
std::vector<T>)
> On Aug 9, 2005, at 10:41 PM, adah at netstd dot com wrote:
> >
> > Passing this information to the user is difficult, unless GCC emits a
> > diagnostic message to help users do so, as GCC is currently doing on 
> > the
> > missing of `typename'.
> even then as I said before when it comes down to it, nobody reads those
> messages as they think their code is correct.
> See my example when sequence points, we do warn about it in 4.0.0 and 
> above
> (for C++; for C, we have warned since at least 3.0.4) and people still 
> file bugs.
> Another example of where people don't read is the changes page, which 
> describes
> changes to the compiler which could hinder (or benefit) them.  One 
> example is
> the change in the namelookup for templates to be more towards the 
> standard.  That
> example shows that we still get bug reports so even with a better error 
> message,
> people will have something to complain about.
> -- Pinski

It is regretful that many people cannot read.  But many people *can* read.  
Converting from GCC 2 to GCC 3 made my code much more conformant to the C++ 
standard, owing to the messages like that of `typename'.  And the messages 
emitted by a compiler are read more often than something in a doc page.

The main problem of the current error message is that it even mentions nothing 
about std::distance.  So even an experienced programmer can have difficulty 
finding out the problem if he does not know std::distance and has not 
encountered the problem before.  Not to say understand the problem.  As the 
very beginning, adding a message like `In instantiation of std::distance...' 
will be helpful.

Yongwei


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-08-10 03:17 -------
(In reply to comment #72)
> encountered the problem before.  Not to say understand the problem.  As the 
> very beginning, adding a message like `In instantiation of std::distance...' 
> will be helpful.

But it is not instantiating std::distance just yet, it is looking at the return values/parameter types.

ICC produces about the same error message:

/opt/intel/include/c++/xutility(290): error: class "std::vector<double, std::allocator<double>>" has no 
member "iterator_category"
        typedef typename _Iter::iterator_category iterator_category;
                                ^
          detected during instantiation of class "std::iterator_traits<_Iter> [with _Iter=std::vector<double, 
std::allocator<double>>]" at line 12 of "t.cc"

compilation aborted for t.cc (code 2)

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[adah at netstd dot com]

------- Additional Comments From adah at netstd dot com  2005-08-10 03:34 -------
(In reply to comment #73)
> > encountered the problem before.  Not to say understand the problem.  As the 
> > very beginning, adding a message like `In instantiation of 
std::distance...' 
> > will be helpful.
> But it is not instantiating std::distance just yet, it is looking at the 
return values/parameter types.

But it is about to instantiate std::distance, right?  Even if not right, my 
point is still that one should notified of the existence of std::distance 
somehow.

> ICC produces about the same error message:
> /opt/intel/include/c++/xutility(290): error: class "std::vector<double, 
std::allocator<double>>" has no 
> member "iterator_category"
>         typedef typename _Iter::iterator_category iterator_category;
>                                 ^
>           detected during instantiation of class "std::iterator_traits<_Iter> 
[with _Iter=std::vector<double, 
> std::allocator<double>>]" at line 12 of "t.cc"
> compilation aborted for t.cc (code 2)

Do you think this message is helpful for a user that encounters this problem?

That is just one place to show that GCC can do better than commercial compilers.

Yongwei


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[adah at netstd dot com]

------- Additional Comments From adah at netstd dot com  2005-08-10 04:31 -------
The error message I am imagining (not sure of its feasibility):

.../stl_iterator_base_types.h: In instantiation of 
`std::iterator_traits<std::vector<int, std::allocator<int> > >':
.../stl_iterator_funcs.h: In instantiation of (return type of?) `std::distance
(std::vector<int>, std::vector<int>' (as found by argument-dependent lookup: 
use a scope modifier like `::' if this is not what you want):
test1.cpp:32:   instantiated from here
...

Yongwei


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-08-10 11:35 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

"adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| Now to your point.  Please notice that my current stance is not that
| GCC should fix this `bug'.  I have stated it days ago.  But the
| user's failure is really UNEXPECTED, and this is a PROBLEM.

Please, do consider that the outcome of this is the specification of
"argument dependent name lookup".  It is the same rules that apply
whether the function is called "distance" or "freebies" and the
namespace is called "std" or "foobar".  Just saying, "ah, this is std,
therefore the outcome is unexpected" is not sufficient.  To
appreciate the issue and argue you NEED to understand the rules.
Furthermore, and more importantly, GCC bugzilla is the not the place
to record UNEXPECTED or PROBLEM with the C++ standard.

| To avoid this problem, a better diagnostic message should be
| emitted.  Just try compiling the OP's program to see my point. 

Just consider how you would formulate the rules for name lookup to
appreciate the point people are making here.  There is no magic.  We
don't have the keyword "readmymind".

[...]

| I cannot help wondering why (though this might be better discussed
| on comp.std.c++: I do hope you can discuss there).  IMHO, the
| current bahaviour is violating the rationale of the std namespace.

You seem to focuse on namespace std, without understanding that this
issue has nothing particular to do with std.  Would have the issue
have been different if the namespace was called std?  If you think
yes, then I suggest you give it more thoughts.

[...]

| c) Failure to instantiate a template function should automatically remove it 
| from the candidates of overload resolution.

If you want to modify standard rules, please, again take it to the
committee in charge of C++.  

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[adah at netstd dot com]

------- Additional Comments From adah at netstd dot com  2005-08-11 02:01 -------
(In reply to comment #76)
> Subject: Re:  can't compile self defined void distance(std::vector<T>, 
std::vector<T>)
> "adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:
> | Now to your point.  Please notice that my current stance is not that
> | GCC should fix this `bug'.  I have stated it days ago.  But the
> | user's failure is really UNEXPECTED, and this is a PROBLEM.
> Please, do consider that the outcome of this is the specification of
> "argument dependent name lookup".  It is the same rules that apply
> whether the function is called "distance" or "freebies" and the
> namespace is called "std" or "foobar".  Just saying, "ah, this is std,
> therefore the outcome is unexpected" is not sufficient.  To
> appreciate the issue and argue you NEED to understand the rules.
> Furthermore, and more importantly, GCC bugzilla is the not the place
> to record UNEXPECTED or PROBLEM with the C++ standard.

Is it a guideline of GCC Bugzilla that a PRoblem owing to the C++ Standard is 
never considered a PRoblem at all?  If it is, please show me where I can read 
it.

> | To avoid this problem, a better diagnostic message should be
> | emitted.  Just try compiling the OP's program to see my point. 
> Just consider how you would formulate the rules for name lookup to
> appreciate the point people are making here.  There is no magic.  We
> don't have the keyword "readmymind".

If the instantiation of a function (its body or its return type, arguments, 
etc.) fails during overload resolution, then the complete name of the function 
should be output.  If this function is in some namespace and the original 
function call is not qualified, then an additional warning on argument-
dependent lookup should be emitted.

Simple rules.  I do not think it is magic.  Just that some contexts need to be 
remembered.

> [...]
> | I cannot help wondering why (though this might be better discussed
> | on comp.std.c++: I do hope you can discuss there).  IMHO, the
> | current bahaviour is violating the rationale of the std namespace.
> You seem to focuse on namespace std, without understanding that this
> issue has nothing particular to do with std.  Would have the issue
> have been different if the namespace was called std?  If you think
> yes, then I suggest you give it more thoughts.

No.  If I put it simply, then this behaviour violates the rationale of 
namespaces.  Please notice that I always consider it a problem in the C++ 
compiler (nothing to do with one specific namespace) instead of libstdc++.  
Again I can say yes.  This problem is most likely encountered by a user using 
the std namespace.  Logically, `violates the rationale of the std namespace' 
does not contradict `violates the rationale of namespaces'.

However, on this point you are basically right.  I should have expressed better.

> [...]
> | c) Failure to instantiate a template function should automatically remove 
it 
> | from the candidates of overload resolution.
> If you want to modify standard rules, please, again take it to the
> committee in charge of C++.  
> -- Gaby

This is not the behaviour I am currently requesting.  I just wanted to told 
Wolfgang there is a third way to `fix' the problem which I prefer better than 
his suggestions.

Yongwei


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[adah at netstd dot com]

------- Additional Comments From adah at netstd dot com  2005-08-11 03:51 -------
Hi Gaby,

I have read Sutter's Modest Proposal on fixing ADL that you referred to me.  If 
you had told me earlier about this instead of bluntly telling me this was not a 
GCC bug, I would have much more quickly given up the request to `fix' this 
behaviour.  (Hey, PLEASE do not argue with me on this: it is just an after 
comment on facts.)

Since the future is undecided on how to make the program pass (I believe it 
*is* the consensus of C++ gurus that the OP's program should compile, though it 
is undefined and nonportable under the current C++ Standard), it is premature 
to take measures to `correct' the current behaviour.  However, the error 
message *is* user unfriendly.  I suppose no one objects to this.  So my request 
is still that the error message should be improved.

Yongwei


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-08-11 06:31 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

"adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:
 
| > Furthermore, and more importantly, GCC bugzilla is the not the place
| > to record UNEXPECTED or PROBLEM with the C++ standard.
| 
| Is it a guideline of GCC Bugzilla that a PRoblem owing to the C++ Standard is 
| never considered a PRoblem at all? 
                      
Ahem.  Can you read?
 
| If it is, please show me where I can read it.

I'm very willing to do so if you provide evidence that you can read.

| should be output.  If this function is in some namespace and the original 
| function call is not qualified, then an additional warning on argument-
| dependent lookup should be emitted.
| 
| Simple rules.  I do not think it is magic.

Surely, your rules do not require magic.  They just appear nonsensical to
me.  As argument dependent name lookup has become an essential part of
C++ libraries, begining the standard one.

| No.  If I put it simply, then this behaviour violates the rationale of 
| namespaces. 

Which rationale?

| This is not the behaviour I am currently requesting.  I just wanted to told 
| Wolfgang there is a third way to `fix' the problem which I prefer better than 
| his suggestions.

Essentially, you're here just to argue.

-- Gaby
 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-08-11 06:46 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

"adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| Hi Gaby,
| 
| I have read Sutter's Modest Proposal on fixing ADL that you referred to me.  If 
| you had told me earlier about this instead of bluntly telling me this was not a 
| GCC bug,

It still is NOT a GCC bug, no matter how you put it.  GCC
correctly implements the standard specifications.  Just because you
happen not to like the consequences of the rules under some
circumstances does not make it a GCC bug.  Furthermore, I've suggested
from the very outset that you take the issue to the C++ committee --
which if you have done, you would have discovered the many facets of
fixes you are discovering now. That was no "bluntly telling" you.  It
is not a GCC bug, it is a fact.  You would have learnt more about the
subject when you took it to the apporpriate place, is also a fact.
But, you were obsessed by the very idea that it must be a GCC bug,
rejecting outright suggestions to  take the issue to the appropriate
places and only  afterward half-admitting that is what you would have
done and are putting blame on other people for your irrational
refusal to give more thoughts to the issue and move and discuss it in
the apporpriate forums.  
 
-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[adah at netstd dot com]

------- Additional Comments From adah at netstd dot com  2005-08-12 02:10 -------
(In reply to comment #79)
> Subject: Re:  can't compile self defined void distance(std::vector<T>, 
std::vector<T>)
> "adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:
>  
> | > Furthermore, and more importantly, GCC bugzilla is the not the place
> | > to record UNEXPECTED or PROBLEM with the C++ standard.
> | 
> | Is it a guideline of GCC Bugzilla that a PRoblem owing to the C++ Standard 
is 
> | never considered a PRoblem at all? 
>                       
> Ahem.  Can you read?

Show an official page.

> | If it is, please show me where I can read it.
> I'm very willing to do so if you provide evidence that you can read.

The only thing I can say is that you are an absolutely incurably rude person.

> | should be output.  If this function is in some namespace and the original 
> | function call is not qualified, then an additional warning on argument-
> | dependent lookup should be emitted.
> | 
> | Simple rules.  I do not think it is magic.
> Surely, your rules do not require magic.  They just appear nonsensical to
> me.  As argument dependent name lookup has become an essential part of
> C++ libraries, begining the standard one.

I do not invalidate ADL.  Just that ADL is causing problems, and some 
diagnostic messages (only when problems occur) can help people encountering 
these problems identify their problems.

Not only I am saying that ADL is causing unwanted problems.  I do not think 
Herb Sutter's opinion that the OP's program *should* compile is less authentic 
than yours.

> | No.  If I put it simply, then this behaviour violates the rationale of 
> | namespaces. 
> Which rationale?

Name separation.  People can use names freely (in their own namespace or the 
global namespace) without worrying that the name is used in another namespace.

> | This is not the behaviour I am currently requesting.  I just wanted to told 
> | Wolfgang there is a third way to `fix' the problem which I prefer better 
than 
> | his suggestions.
> Essentially, you're here just to argue.

I am afraid that it is YOU that are here to argue, and to *flame*.

> -- Gaby

Yongwei


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

Re: [Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[Andrew Pinski]

> 
> 
> ------- Additional Comments From adah at netstd dot com  2005-08-12 02:10 -------
> (In reply to comment #79)
> > Subject: Re:  can't compile self defined void distance(std::vector<T>, 
> std::vector<T>)
> > "adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:
> >  
> > | > Furthermore, and more importantly, GCC bugzilla is the not the place
> > | > to record UNEXPECTED or PROBLEM with the C++ standard.
> > | 
> > | Is it a guideline of GCC Bugzilla that a PRoblem owing to the C++ Standard 
> is 
> > | never considered a PRoblem at all? 
> >                       
> > Ahem.  Can you read?
> 
> Show an official page.
http://gcc.gnu.org/bugs.html

"In particular, bugs caused by invalid code have a simple work-around: fix the code."

"With each release, we try to make G++ conform closer to the ISO C++ standard (available at http://www.ncits.org/cplusplus.htm). We have also implemented some of the core and library defect reports (available at http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html & http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html respectively)."

http://gcc.gnu.org/gcc-3.4/changes.html

"GCC 3.4 has many improvements in the C++ frontend. Before reporting a bug, please make sure it's really GCC, and not your code, that is broken."

There are more.

-- Pinski

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[pinskia at physics dot uc dot edu]

------- Additional Comments From pinskia at physics dot uc dot edu  2005-08-12 02:14 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

> 
> 
> ------- Additional Comments From adah at netstd dot com  2005-08-12 02:10 -------
> (In reply to comment #79)
> > Subject: Re:  can't compile self defined void distance(std::vector<T>, 
> std::vector<T>)
> > "adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:
> >  
> > | > Furthermore, and more importantly, GCC bugzilla is the not the place
> > | > to record UNEXPECTED or PROBLEM with the C++ standard.
> > | 
> > | Is it a guideline of GCC Bugzilla that a PRoblem owing to the C++ Standard 
> is 
> > | never considered a PRoblem at all? 
> >                       
> > Ahem.  Can you read?
> 
> Show an official page.
http://gcc.gnu.org/bugs.html

"In particular, bugs caused by invalid code have a simple work-around: fix the code."

"With each release, we try to make G++ conform closer to the ISO C++ standard (available at http://www.ncits.org/cplusplus.htm). We have also implemented some of the core and library defect reports (available at http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html & http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html respectively)."

http://gcc.gnu.org/gcc-3.4/changes.html

"GCC 3.4 has many improvements in the C++ frontend. Before reporting a bug, please make sure it's really GCC, and not your code, that is broken."

There are more.

-- Pinski


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[adah at netstd dot com]

------- Additional Comments From adah at netstd dot com  2005-08-12 02:32 -------
(In reply to comment #82)
> > Show an official page.
> http://gcc.gnu.org/bugs.html
> "In particular, bugs caused by invalid code have a simple work-around: fix 
the code."
> "With each release, we try to make G++ conform closer to the ISO C++ standard 
(available at http://www.ncits.org/cplusplus.htm). We have also implemented 
some of the core and library defect reports (available at http://www.open-
std.org/jtc1/sc22/wg21/docs/cwg_defects.html & http://www.open-
std.org/jtc1/sc22/wg21/docs/lwg-defects.html respectively)."
> http://gcc.gnu.org/gcc-3.4/changes.html
> "GCC 3.4 has many improvements in the C++ frontend. Before reporting a bug, 
please make sure it's really GCC, and not your code, that is broken."
> There are more.
> -- Pinski

Thanks, Pinski.  These I have read.

What I have not is that a PRoblem resulting from an deficiency of the C++ 
Standard is not considered a PRoblem.  It is clear that many C++ gurus do think 
it a deficiency of the C++ Standard.

And it is arguable whether the OP's code is broken or not.  But this is not 
what I want to argue here.  My current request is exactly to tell the user that 
his code might be broken (unspecified and non-portable) under the current C++ 
Standard.  I do not think it is against any rule of the GCC community.

Yongwei


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[pinskia at physics dot uc dot edu]

------- Additional Comments From pinskia at physics dot uc dot edu  2005-08-12 02:38 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)


On Aug 11, 2005, at 10:32 PM, adah at netstd dot com wrote:
> What I have not is that a PRoblem resulting from an deficiency of the 
> C++
> Standard is not considered a PRoblem.  It is clear that many C++ gurus 
> do think
> it a deficiency of the C++ Standard.

Yes but you said using GCC bugzilla for deficiencies in C++.  GCC 
bugzilla is not
for that but only for GCC deficiencies so if the C++ standard says one 
thing and
you disagree with it, GCC bugzilla is not correct place to raise the 
issue, even
if many "C++ gurus" says this is a bug in GCC, you should get a 
clarification
from the standards committee which is not hard as DR reports are open 
to anyone
and not limited to committee members.


-- Pinski



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

Re: [Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[Andrew Pinski]

On Aug 11, 2005, at 10:32 PM, adah at netstd dot com wrote:
> What I have not is that a PRoblem resulting from an deficiency of the 
> C++
> Standard is not considered a PRoblem.  It is clear that many C++ gurus 
> do think
> it a deficiency of the C++ Standard.

Yes but you said using GCC bugzilla for deficiencies in C++.  GCC 
bugzilla is not
for that but only for GCC deficiencies so if the C++ standard says one 
thing and
you disagree with it, GCC bugzilla is not correct place to raise the 
issue, even
if many "C++ gurus" says this is a bug in GCC, you should get a 
clarification
from the standards committee which is not hard as DR reports are open 
to anyone
and not limited to committee members.


-- Pinski

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[adah at netstd dot com]

------- Additional Comments From adah at netstd dot com  2005-08-12 03:00 -------
(In reply to comment #84)
> Subject: Re:  can't compile self defined void distance(std::vector<T>, 
std::vector<T>)
> On Aug 11, 2005, at 10:32 PM, adah at netstd dot com wrote:
> > What I have not is that a PRoblem resulting from an deficiency of the 
> > C++
> > Standard is not considered a PRoblem.  It is clear that many C++ gurus 
> > do think
> > it a deficiency of the C++ Standard.
> Yes but you said using GCC bugzilla for deficiencies in C++.  GCC 
> bugzilla is not
> for that but only for GCC deficiencies so if the C++ standard says one 
> thing and
> you disagree with it, GCC bugzilla is not correct place to raise the 
> issue, even
> if many "C++ gurus" says this is a bug in GCC, you should get a 
> clarification
> from the standards committee which is not hard as DR reports are open 
> to anyone
> and not limited to committee members.
> -- Pinski

Arguing for the principles is difficult, if the one point we disagree is not 
explicitly listed officially somewhere (I am not convinced unless I see a 
statement like that GCC wants to be a bug-for-bug translator of the C++ 
Standard).  So I am not to argue with you. :-)

Please understand that my reason to post comments here was not because this was 
a C++ problem, but because I hoped the behaviour of GCC in this aspect could be 
better.  And I want to say that IMO it was a little premature to mark this bug 
as `REJECT-INVALID': `SUSPEND' is much better (I admit the state change 
irritated me a little, and my bitter quarrel with Gaby somehow began there).  
When the WG21 has decided this *is* a bug of the Standard, you will then reopen 
the bug again?  I simply do not think it a good idea to stick to every exact 
word of the Standard (it will change after all).  Admittedly it is only my 
personal opinion.

Even if you cannot agree with a word of all stated above, I suppose I am still 
allowed to request to improve the error message so that a user can recognize 
*WHAT* is going wrong and *WHERE*.

Yongwei


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-08-12 03:39 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

"adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| What I have not is that a PRoblem resulting from an deficiency of the C++ 
| Standard is not considered a PRoblem.

This is where it is obvious that Yongwei is trying to play Illiterate.
Because what I wrote was

  #  Furthermore, and more importantly, GCC bugzilla is the not the place
  #  to record UNEXPECTED or PROBLEM with the C++ standard.
 
-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-08-12 03:41 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

"adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Additional Comments From adah at netstd dot com  2005-08-12 02:10 -------
| (In reply to comment #79)
| > Subject: Re:  can't compile self defined void distance(std::vector<T>, 
| std::vector<T>)
| > "adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:
| >  
| > | > Furthermore, and more importantly, GCC bugzilla is the not the place
| > | > to record UNEXPECTED or PROBLEM with the C++ standard.
| > | 
| > | Is it a guideline of GCC Bugzilla that a PRoblem owing to the C++ Standard 
| is 
| > | never considered a PRoblem at all? 
| >                       
| > Ahem.  Can you read?
| 
| Show an official page.

An official page that you cannot read?  Just try again to read

  # Furthermore, and more importantly, GCC bugzilla is the not the place
  # to record UNEXPECTED or PROBLEM with the C++ standard.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-08-12 03:45 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

"adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| So I am not to argue with you. :-)

You have shown sufficient evidence to the contrary.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[adah at netstd dot com]

------- Additional Comments From adah at netstd dot com  2005-08-12 03:47 -------
(In reply to comment #86)
> Subject: Re:  can't compile self defined void distance(std::vector<T>, 
std::vector<T>)
> "adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:
> | What I have not is that a PRoblem resulting from an deficiency of the C++ 
> | Standard is not considered a PRoblem.
> This is where it is obvious that Yongwei is trying to play Illiterate.
> Because what I wrote was
>   #  Furthermore, and more importantly, GCC bugzilla is the not the place
>   #  to record UNEXPECTED or PROBLEM with the C++ standard.
>  
> -- Gaby

You were blinded by your anger.  I sought a `guideline of GCC Bugzilla'.  I did 
not think your words represent a `guideline of GCC Bugzilla'.  Sorry.

If you do, please put `a problem resulting from an deficiency of the C++ 
Standard is not considered a problem' to an official page.

Yongwei


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2005-08-12 04:05 -------
We're already at comment 85 in this PR, so this is definitely going to be my 
last message. 
 
While I sympathize with your desire to have a better error message, you seem 
not to understand the implications of what you ask us to do. First, ADL 
(Koenig lookup) is meant particularly to allow separation of names into 
different namespaces, even though it allows for lookup of names across 
namespaces. Consider this example: 
----------------------- 
// this is provided by the compiler: 
namespace std { 
  template <typename T> void swap (T &,T &); 
 
  template <typename I> void bubble_sort (I &i1, I &i2) { 
    //bubble sort is implemented using swap(*i1, *i2) 
} 
 
// user code 
namespace User { 
  class MyClass {...}; 
  void swap (MyClass &, MyClass &) { user's implementation } 
} 
 
void main () { 
  std::vector<User::MyClass> v; 
  std::bubble_sort (v.begin(), v.end()); 
} 
-------------------------- 
If it weren't for the name lookup rules that people complain about, then the 
user defined 
User::swap would never be called from inside std::bubble_sort; rather, you 
would only ever get the 
default std::swap, which would most likely not what you wanted. See the 
problem? 
In this example, you definitely do want ADL to work as it is supposed to, 
but in the example used in this PR you don't. That's not consistent. It 
would also not be very helpful to print a warning message to the screen 
saying "hey, you may have wanted std::swap, but I picked User::swap anyway", 
which would be the exact opposite of what you would want in the case you 
present in this PR. 
 
So your second solution was to ask that functions that don't compile properly 
to simply be dropped from name lookup. Now, that's getting really messy: 
--------------------------- 
int f(int i) { 
  do_something(); 
  // oops, forgot return value -- compiler error 
} 
 
int g(int i) { 
  return f(i); 
} 
 
int h(int i) { 
  return g(i); 
} 
 
int h(double) { 
  return 1; 
} 
 
int main () { 
  h(1); 
} 
---------------------- 
What the user clearly wanted was to call h(int). However, h(int) calls a 
function that has a user error -- oops. So f() and g() don't compile, should 
h(int) be dropped from the overload list (without an error, as per your 
suggestion), and h(double) be used with the standard conversion of the  
argument '1' from int to double? 
 
So, in neither case is changing the rules of the language a very good choice, 
which is exactly why Gaby and I claim that there is no defect in the standard: 
everything else one could possible come up with is even more completely 
ununderstandable. 
 
I hope this explains why we don't want to change the compiler to do something 
different than what the standard prescribes -- because we're reasonably sure 
that the standard wouldn't follow our precedent and we'd be eternally 
incompatible after that. 
 
The question remains whether we can do anything about the weird error message 
one gets with code like yours. That it isn't very helpful is completely 
undisputed, but that doesn't mean that anyone has an idea of how to improve 
it. 
 
W. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-08-12 04:05 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

"adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:

[...]

| > Because what I wrote was
| >   #  Furthermore, and more importantly, GCC bugzilla is the not the place
| >   #  to record UNEXPECTED or PROBLEM with the C++ standard.

[...]

| If you do, please put `a problem resulting from an deficiency of the C++ 
| Standard is not considered a problem' to an official page.
              ^^^^^^^^^^^^^^^^^^^^^^^^

One more evidence that you cannot read.

This is GCC bugzilla.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[adah at netstd dot com]

------- Additional Comments From adah at netstd dot com  2005-08-12 05:12 -------
I am not sure whether we can finish here (not to challenge you, but that I am 
still a little misunderstood).  See below (for pure technical discussions, and 
just to reply to you).

(In reply to comment #90)
> While I sympathize with your desire to have a better error message, you seem 
> not to understand the implications of what you ask us to do. First, ADL 

On the contrary, I do.

> (Koenig lookup) is meant particularly to allow separation of names into 
> different namespaces, even though it allows for lookup of names across 
> namespaces. Consider this example: 
[Example snipped]
> In this example, you definitely do want ADL to work as it is supposed to, 
> but in the example used in this PR you don't. That's not consistent. It 

It is consistent.

What I thought when I entered the discussion here was that ADL should work but 
the instantiation error should remove it from the candidate list (e.g. to 
extend SFINAE).  So I did think ADL worked here, and there was no consistency.

Herb Sutter's opinion (N1792) is a little different.  He thinks that ADL should 
not work in the OP's example, because distance is simply not an `interface' of 
std::vector (technically, instead of from human eyes).  But it is also self-
consistent.

> would also not be very helpful to print a warning message to the screen 
> saying "hey, you may have wanted std::swap, but I picked User::swap anyway", 
> which would be the exact opposite of what you would want in the case you 
> present in this PR.

This was not what I used to want.  But since I learnt that the future was still 
undecided which way the committe would take to solve this issue, it is safer to 
have a better diagnostice message *now*.

> So your second solution was to ask that functions that don't compile properly 
> to simply be dropped from name lookup. Now, that's getting really messy: 
> --------------------------- 
> int f(int i) { 
>   do_something(); 
>   // oops, forgot return value -- compiler error 
> } 
>  
> int g(int i) { 
>   return f(i); 
> } 
>  
> int h(int i) { 
>   return g(i); 
> } 
>  
> int h(double) { 
>   return 1; 
> } 
>  
> int main () { 
>   h(1); 
> } 
> ---------------------- 
> What the user clearly wanted was to call h(int). However, h(int) calls a 
> function that has a user error -- oops. So f() and g() don't compile, should 
> h(int) be dropped from the overload list (without an error, as per your 
> suggestion), and h(double) be used with the standard conversion of the  
> argument '1' from int to double? 

This can be a valid point.  Practically it is a little difficult to 
differentiate an instantiation error from a program error.

Though, Sutter's suggestion is still a way to go.

> So, in neither case is changing the rules of the language a very good choice, 
> which is exactly why Gaby and I claim that there is no defect in the 
standard: 
> everything else one could possible come up with is even more completely 
> ununderstandable.

I think the above discussion is enough and I do not need to add comments 
here?  :-)

> I hope this explains why we don't want to change the compiler to do something 
> different than what the standard prescribes -- because we're reasonably sure 
> that the standard wouldn't follow our precedent and we'd be eternally 
> incompatible after that. 
> 
> The question remains whether we can do anything about the weird error message 
> one gets with code like yours. That it isn't very helpful is completely 
> undisputed, but that doesn't mean that anyone has an idea of how to improve 
> it. 

I stated long ago (several days indeed) that this could be of lower priority, 
but it needs to be agreed on and added to a to-do list.  Before your message I 
had not seen a single agreement, but only flames.

> W.

Yongwei


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-08-12 06:19 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

"adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| Herb Sutter's opinion (N1792) is a little different.  He thinks that
| ADL should not work in the OP's example, because distance is simply
| not an `interface' of std::vector (technically, instead of from
| human eyes).  But it is also self-consistent.

All those are assertions, little evidence.  Notice that what is
considered an "interface" varies from one individual to another
individual.  And we just don't have a definition for it, so you're
still using your "human eyes" definition, i.e. projection of your own
wishes. 

I was in the room when ADL was discussed at the last meeting in Norway
-- and indeed, I was part of the people who fiercely encouraged Herb
to bring forward "his modest proposal" (and that does not mean I agree
with every word contained in the proposal, but my interest in getting
the issue addressed).  At that time, I was presenting possible ways
the concept proposal may reduce the uncontrolled power of ADL.  I have
suggested that you give a try to the exercise of "name lookup".  That
suggestion still holds.  Untill, you have done so it is almost certain
then you will completely miss its the depth and ramifications.  It is
no Herb's opinion against mine.  It is a matter of precisely and
consistently defining the rules so that the most common cases are
gotten right. No, it is not GCC's job.  Furthermore, if you want to
eliminate ADL effects; you have to break existing codes and ban ADL.
Herb's suggestion already breaks some existing reasonable codes -- and he
acknowledges that.  You can argue from your notion of engineering and
intuition, but that is all.  And you have to have everbody else's
notion of engineering and intuition intersect with your before moving.
Once, the rules get written and ADL isstill supported, one will always
find cases that is considered either "intuitively and obviously
correct" or "intuitively and obviously wrong".  The reason is very
simple: ADL was *designed on purpose* to make overload set across separate
scopes -- something which did not exist before.  Once you're given
that, all bets are off.  The only thing you can do is to work to get
what you consider to be the most common cases "intuitively and
obviously right".  And live with the rest. 

[...]

| it is safer to have a better diagnostice message *now*.

you get a better diagnostic when you can precisely spell out what
alternate rules can be or give a precise consistent algorithms.  You
haven't so far.  Just arguing. 

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[adah at netstd dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5713 bytes --]


------- Additional Comments From adah at netstd dot com  2005-08-12 08:52 -------
I am glad it is again normal discussions.

(In reply to comment #93)
> Subject: Re:  can't compile self defined void distance(std::vector<T>, 
std::vector<T>)
> "adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:
> | Herb Sutter's opinion (N1792) is a little different.  He thinks that
> | ADL should not work in the OP's example, because distance is simply
> | not an `interface' of std::vector (technically, instead of from
> | human eyes).  But it is also self-consistent.
> All those are assertions, little evidence.  Notice that what is
> considered an "interface" varies from one individual to another
> individual.  And we just don't have a definition for it, so you're
> still using your "human eyes" definition, i.e. projection of your own
> wishes. 

By `technical' I meant algorithmically recognizable.

> I was in the room when ADL was discussed at the last meeting in Norway
> -- and indeed, I was part of the people who fiercely encouraged Herb
> to bring forward "his modest proposal" (and that does not mean I agree
> with every word contained in the proposal, but my interest in getting
> the issue addressed).  At that time, I was presenting possible ways
> the concept proposal may reduce the uncontrolled power of ADL.  I have
> suggested that you give a try to the exercise of "name lookup".  That
> suggestion still holds.  Untill, you have done so it is almost certain
> then you will completely miss its the depth and ramifications.  It is
> no Herb's opinion against mine.  It is a matter of precisely and
> consistently defining the rules so that the most common cases are
> gotten right. No, it is not GCC's job.  Furthermore, if you want to
> eliminate ADL effects; you have to break existing codes and ban ADL.
> Herb's suggestion already breaks some existing reasonable codes -- and he
> acknowledges that.  You can argue from your notion of engineering and
> intuition, but that is all.  And you have to have everbody else's
> notion of engineering and intuition intersect with your before moving.
> Once, the rules get written and ADL isstill supported, one will always
> find cases that is considered either "intuitively and obviously
> correct" or "intuitively and obviously wrong".  The reason is very
> simple: ADL was *designed on purpose* to make overload set across separate
> scopes -- something which did not exist before.  Once you're given
> that, all bets are off.  The only thing you can do is to work to get
> what you consider to be the most common cases "intuitively and
> obviously right".  And live with the rest. 

These statements I agree.  You enlightened me that there are more than one way 
to go to make the OP's code work, and Wolfgang showed that my opinion might be 
practically difficult to implement.  Thanks for that.

Please note I mentioned Herb's proposal only to reply to Wolfgang.  I never 
said, not even hinted, that it should be implemented in GCC now.

> [...]
> | it is safer to have a better diagnostice message *now*.
> you get a better diagnostic when you can precisely spell out what
> alternate rules can be or give a precise consistent algorithms.  You
> haven't so far.  Just arguing.

Has a user to be a compiler writer to give enhancement suggestions, I wonder?

Though you may still think it is not an algorithm, I am trying again (in Gene 
Bushuyev's way):

Function overload_resolution(function_name, arguments,
                             current_namespace, function_namespace)
{
    set<Function> overload_set;
    set<Function> failed_set;
    for (Function function = parse_tree.functions.begin();
         function != parse_tree.functions.end(); ++function)
    if (function->name == function_name
        && function->check_lookup_rules(current_namespace, function_namespace))
    {
        if (function->is_a_template())
        {
            try
            {
                if (!function->is_explicitly_specialized())
                    template_arguments = function
                        ->deduce_template_arguments(arguments); // 14.8.2
                instance = function->instantiate(template_arguments) // 14.7.1
                overload_set.insert(instance); // 14.8.3/1
            }
            catch (const SubstitutionFailure&)
            {
                failed_set.insert(*function); // only for reporting purposes
                // do nothing with this candidate according to 14.8.3/1
            }
            catch (InstantiationFailure& e)
            {
                e.add_instantiation_failure_point(*function);
                if (is_unqualified(function_namespace)
                        && current_namespace != namespace_of(*function))
                    e.add_diagnositics(
                            "Instantiation failed on a result from"
                            " argument-dependent lookup: Use a scope"
                            " modifier like `::' if it is not what you"
                            " want");
                throw e;
            }
        }
        else
            overload_set.insert(*function);
    }

    set<Function> matched_set = overload_set.find_best_viable_function();

    if (matched_set.empty())
        throw no_match_error(failed_set); // just a hint for user - not required

    if (matched_set.size() > 1)
        throw many_match_error(matched_set);

    // don't instantiate templates unless necessary 14.7.1/9
    if (matched_function.is_a_templ­ate_instance())
         compiler.instantiated_function­_set.insert(matched_function);

    return matched_function;
}

> -- Gaby

Yongwei

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-08-12 09:04 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

"adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| > | Herb Sutter's opinion (N1792) is a little different.  He thinks that
| > | ADL should not work in the OP's example, because distance is simply
| > | not an `interface' of std::vector (technically, instead of from
| > | human eyes).  But it is also self-consistent.
| > All those are assertions, little evidence.  Notice that what is
| > considered an "interface" varies from one individual to another
| > individual.  And we just don't have a definition for it, so you're
| > still using your "human eyes" definition, i.e. projection of your own
| > wishes. 
| 
| By `technical' I meant algorithmically recognizable.

you still fail to provide such a definition for "interface".

-- Gaby



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[adah at netstd dot com]

------- Additional Comments From adah at netstd dot com  2005-08-12 09:23 -------
(In reply to comment #95)
> | > | Herb Sutter's opinion (N1792) is a little different.  He thinks that
> | > | ADL should not work in the OP's example, because distance is simply
> | > | not an `interface' of std::vector (technically, instead of from
> | > | human eyes).  But it is also self-consistent.
> | > All those are assertions, little evidence.  Notice that what is
> | > considered an "interface" varies from one individual to another
> | > individual.  And we just don't have a definition for it, so you're
> | > still using your "human eyes" definition, i.e. projection of your own
> | > wishes. 
> | 
> | By `technical' I meant algorithmically recognizable.
> you still fail to provide such a definition for "interface".
> -- Gaby

Why should I?  Herb defined it in Exceptional C++, Item 32:

For a class X, all functions, including free functions, that both

* `mention' X
* are `supplied with' X

are logically part of X, because they form part of the interface of X.

Yongwei


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-08-12 09:44 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

"adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| > you still fail to provide such a definition for "interface".
| > -- Gaby
| 
| Why should I?

Because, it is *you* who brought that topic in this discussion.

|  Herb defined it in Exceptional C++, Item 32:
| 
| For a class X, all functions, including free functions, that both
| 
| * `mention' X
| * are `supplied with' X
| 
| are logically part of X, because they form part of the interface of X.

That definition bans std::swap as currently usable
with std::complex<double>, e.g. 

   std::complex<double> w, z;
   swap(z, w);

You would have hard-time convincing me that I want that behaviour for
standard C++, let alone GCC.  Furtheremo more, you have to define
"supplied with".  If N gives me

     namespace N {
        struct X { };
     }

and M adds

    namespace M {
       using N::X;
       f(X);
    }

is M::f part of N::X's interface?



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[adah at netstd dot com]

------- Additional Comments From adah at netstd dot com  2005-08-12 10:50 -------
(In reply to comment #97)
> Subject: Re:  can't compile self defined void distance(std::vector<T>, 
std::vector<T>)
> "adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:
> | > you still fail to provide such a definition for "interface".
> | > -- Gaby
> | 
> | Why should I?
> Because, it is *you* who brought that topic in this discussion.
> |  Herb defined it in Exceptional C++, Item 32:
> | 
> | For a class X, all functions, including free functions, that both
> | 
> | * `mention' X
> | * are `supplied with' X
> | 
> | are logically part of X, because they form part of the interface of X.
> That definition bans std::swap as currently usable
> with std::complex<double>, e.g. 
>    std::complex<double> w, z;
>    swap(z, w);

Herb's opinion is that one should write `std::swap(...)'.  `Swap' is just an 
algorithm, and has nothing to do with `complex' per se.  It is clearly stated 
in Section 4.3 of his proposal.

> You would have hard-time convincing me that I want that behaviour for
> standard C++, let alone GCC.  Furtheremo more, you have to define
> "supplied with".  If N gives me
>      namespace N {
>         struct X { };
>      }
> and M adds
>     namespace M {
>        using N::X;
>        f(X);
>     }
> is M::f part of N::X's interface?

I guess `No'.  Herb's rationale is in C++ Coding Standards:

57. Keep a type and its nonmember function interface in the same namespace.

Please differentiate between what I request and what we discuss.  I did not 
advocate to implement Herb's proposal here.  At least not yet.

Best regards,

Yongwei


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-08-12 11:45 -------
Subject: Re:  can't compile self defined void distance(std::vector<T>, std::vector<T>)

"adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| > | For a class X, all functions, including free functions, that both
| > | 
| > | * `mention' X
| > | * are `supplied with' X
| > | 
| > | are logically part of X, because they form part of the interface of X.
| > That definition bans std::swap as currently usable
| > with std::complex<double>, e.g. 
| >    std::complex<double> w, z;
| >    swap(z, w);
| 
| Herb's opinion is that one should write `std::swap(...)'.

However it fails to scale to generic functions.  "swap" has come close
to the status of "operator", needing no qualification. 

| `Swap' is just an algorithm,

completely irrelevant to the issue under consideration.

| and has nothing to do with `complex' per se.

Wrong.  The code as written above is written on purpose and has
well-defined behaviour.  It can be generalized to well-defined and
well-behaved function.  At this point, I suggest, again, that you go
back read the history of ADL and why it was introduced.

And, please refrain from reciting half-digested material.

| It is clearly stated in Section 4.3 of his proposal.

yes, but you chose to ignore that it is his proposal, not something
adopted by the C++ committee and my explicit note in previous message.
You cannot expect meaning discussion if you chose to selectively
ignore facts.

| > You would have hard-time convincing me that I want that behaviour for
| > standard C++, let alone GCC.  Furtheremo more, you have to define
| > "supplied with".  If N gives me
| >      namespace N {
| >         struct X { };
| >      }
| > and M adds
| >     namespace M {
| >        using N::X;
| >        f(X);
| >     }
| > is M::f part of N::X's interface?
| 
| I guess `No'.

Then your definition ot "interface" suddenly becomes useless.

|  Herb's rationale is in C++ Coding Standards:

Rationales vary from people to people.  If you want to discuss
standard C++ specified semantics and its implementation by GCC, you
have to come with something the C++ committee agrees on, otherwise
you're out of luck.

| 57. Keep a type and its nonmember function interface in the same namespace.
| 
| Please differentiate between what I request and what we discuss.  

You suggested to implement semantics according to "technical" meaning
of "interface".  When pressed to give a precise meaning, you hide
yourself behind something else, claiming that it is different from
what you request.  If you believe it is not what you advocate, then
keep it out and speak of what *you* advocate.  Otherwise, you're just
continuing to annoy people who might otherwise be disposed to listen
to you.

| I did not advocate to implement Herb's proposal here.  

Then keep it out.  I'm NOT here just to discuss; it you want a chat room,
this is not the right place.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

[adah at netstd dot com]

------- Additional Comments From adah at netstd dot com  2005-08-12 14:02 -------
(In reply to comment #99)
> "adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> writes:
> 
> | > | For a class X, all functions, including free functions, that both
> | > | 
> | > | * `mention' X
> | > | * are `supplied with' X
> | > | 
> | > | are logically part of X, because they form part of the interface of X.
> | > That definition bans std::swap as currently usable
> | > with std::complex<double>, e.g. 
> | >    std::complex<double> w, z;
> | >    swap(z, w);
> | 
> | Herb's opinion is that one should write `std::swap(...)'.
> 
> However it fails to scale to generic functions.  "swap" has come close
> to the status of "operator", needing no qualification. 

Give evidence.

I am on Herb's side that there is no evident reason to use `swap' on standard
types while using `std::swap' on user types.

> | `Swap' is just an algorithm,
> 
> completely irrelevant to the issue under consideration.

Give the reason why it is irrelevant.

> | and has nothing to do with `complex' per se.
> 
> Wrong.  The code as written above is written on purpose and has
> well-defined behaviour.  It can be generalized to well-defined and
> well-behaved function.  At this point, I suggest, again, that you go
> back read the history of ADL and why it was introduced.

Things are not wrong just because you said it was wrong.  Give evidence.

> And, please refrain from reciting half-digested material.

Please refrain from giving immature comments.

> | It is clearly stated in Section 4.3 of his proposal.
> 
> yes, but you chose to ignore that it is his proposal, not something
> adopted by the C++ committee and my explicit note in previous message.
> You cannot expect meaning discussion if you chose to selectively
> ignore facts.

You chose to talk about his proposal, not I.  My sole purpose to mention his
proposal was to show to Wolfgang that there are two `consistent' ways dealing
with ADL.  Consistency was the thing we focused on.

> | > You would have hard-time convincing me that I want that behaviour for
> | > standard C++, let alone GCC.  Furtheremo more, you have to define
> | > "supplied with".  If N gives me
> | >      namespace N {
> | >         struct X { };
> | >      }
> | > and M adds
> | >     namespace M {
> | >        using N::X;
> | >        f(X);
> | >     }
> | > is M::f part of N::X's interface?
> | 
> | I guess `No'.
> 
> Then your definition ot "interface" suddenly becomes useless.
> 
> |  Herb's rationale is in C++ Coding Standards:
> 
> Rationales vary from people to people.  If you want to discuss
> standard C++ specified semantics and its implementation by GCC, you
> have to come with something the C++ committee agrees on, otherwise
> you're out of luck.
> 
> | 57. Keep a type and its nonmember function interface in the same namespace.
> | 
> | Please differentiate between what I request and what we discuss.  
> 
> You suggested to implement semantics according to "technical" meaning
> of "interface".  When pressed to give a precise meaning, you hide
> yourself behind something else, claiming that it is different from
> what you request.  If you believe it is not what you advocate, then
> keep it out and speak of what *you* advocate.  Otherwise, you're just
> continuing to annoy people who might otherwise be disposed to listen
> to you.

His rationale is consistent with his proposal how to change the wording in the
Standard.  Technically it is clear how to apply his principles to choose which
functions his modified ADL should find.

> | I did not advocate to implement Herb's proposal here.  
> 
> Then keep it out.  I'm NOT here just to discuss; it you want a chat room,
> this is not the right place.

I was replying to Wolfgang, as I said above.  Even in that message I did not
advocate it.  In all recent messages the only thing I advocated is the
improvement of the error message, and how.

Sorry I am afraid it is you that cannot read.

> -- Gaby

Yongwei

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910