Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c++ > #71013

Re: std::copy with std::ostream_iterator<std::array...>

Path csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From Bo Persson <bo@bo-persson.se>
Newsgroups comp.lang.c++
Subject Re: std::copy with std::ostream_iterator<std::array...>
Date Fri, 3 Jan 2020 15:09:38 +0100
Lines 80
Message-ID <h79092F4t0jU1@mid.individual.net> (permalink)
References <qukdjv$fco$1@dont-email.me> <h762c4FgmbdU1@mid.individual.net> <qul14t$msl$1@dont-email.me>
Mime-Version 1.0
Content-Type text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding 7bit
X-Trace individual.net yhWcNFHnSaYgbKvAeakz4w0ZUId+3eNO93xWgiuD/9rwoKzgF2
Cancel-Lock sha1:UZq1x+8Azql59B22dUOXAPO36wo=
User-Agent Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1
In-Reply-To <qul14t$msl$1@dont-email.me>
Content-Language sv
Xref csiph.com comp.lang.c++:71013

Show key headers only | View raw


On 2020-01-02 at 16:10, Ralf Goertz wrote:
> Am Thu, 2 Jan 2020 12:26:59 +0100
> schrieb Bo Persson <bo@bo-persson.se>:
> 
>> On 2020-01-02 at 10:37, Ralf Goertz wrote:
>>> Hi,
>>>
>>> I don't get the problem in the following program. If I use
>>>
>>> using Coords=Foo;
>>>
>>> everything is okay but with
>>>
>>> using Coords=std::array<int,2>
>>>
>>> I get bombarded with (for me) undecipherable template errors
>>> originating from the std::copy line. Note that without that line it
>>> works for both types, so the operator overload "<<" should not be
>>> the problem.
>>
>> But it is.  :-)
>>
>> Argument dependent lookup will search for an operator in the
>> namespace(s) of the arguments (thus its name :-).
>>
>> If you (or a standard algorithm) use an operator<< with two types
>> from namespace std (for example, std::ostream and std::array), the
>> compiler will look for an operator<< also in namespace std. There are
>> lots of them, but none for std::array.
>>
>> Your operator is in the global namespace, but std::array is not. So
>> that operator will not be found.
>>
>> It works for Foo, because the type and the operator are in the same
>> namespace.
> 
> Thanks for the explanation. I figured as much after having read Paavo's
> reply. But two questions remain. First, I thought it would be illegal
> (or at least frowned upon) for user code to inject anything into the std
> namespace. And what is the difference for the line
> 
> std::cout<<*ls.begin()<<std::endl;
> 
> (ls being of type std::set<std::array<int,2>>) although I have defined
> the operator in the global namespace and both operands are in std (I
> guess). Shouldn't the rule you quoted also lead to a lookup failure?
> 

Yes, but there are more rules (lots of them)...

The compiler also does an Unqualified name lookup

https://en.cppreference.com/w/cpp/language/unqualified_lookup

(about 10 pages of rules) for "<< *ls.begin" and finds the global one 
from main(), because the call is done from the global namespace.


The code for std::copy is inside namespace std so the search for an 
operator starts there. And it finds lots of operator<< in the namespace, 
so it stops there:

"For an unqualified name, that is a name that does not appear to the 
right of a scope resolution operator ::, name lookup examines the scopes 
as described below, until it finds at least one declaration of any kind, 
at which time the lookup stops and no further scopes are examined."


And then the compiler performs an overload resolution (another 30 pages 
in the standard) for the names it has found.

The complete process is *way* too complicated to fully describe in a 
post here, so the recommendation is to always declare the operators in 
the same namespace as (at least one of) the operands, and avoid most of 
the complications.



     Bo Persson

Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

std::copy with std::ostream_iterator<std::array...> Ralf Goertz <me@myprovider.invalid> - 2020-01-02 10:37 +0100
  Re: std::copy with std::ostream_iterator<std::array...> Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-02 12:27 +0200
  Re: std::copy with std::ostream_iterator<std::array...> Bo Persson <bo@bo-persson.se> - 2020-01-02 12:26 +0100
    Re: std::copy with std::ostream_iterator<std::array...> Ralf Goertz <me@myprovider.invalid> - 2020-01-02 16:10 +0100
      Re: std::copy with std::ostream_iterator<std::array...> James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-02 23:13 -0500
        Re: std::copy with std::ostream_iterator<std::array...> Ralf Goertz <me@myprovider.invalid> - 2020-01-03 07:49 +0100
          Re: std::copy with std::ostream_iterator<std::array...> James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-03 08:30 -0500
      Re: std::copy with std::ostream_iterator<std::array...> Bo Persson <bo@bo-persson.se> - 2020-01-03 15:09 +0100
  Re: std::copy with std::ostream_iterator<std::array...> Ike Naar <ike@sdf.lonestar.org> - 2020-01-04 21:46 +0000
    Re: std::copy with std::ostream_iterator<std::array...> Ralf Goertz <me@myprovider.invalid> - 2020-01-05 16:06 +0100
      Re: std::copy with std::ostream_iterator<std::array...> Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-05 18:24 +0000
        Re: std::copy with std::ostream_iterator<std::array...> Öö Tiib <ootiib@hot.ee> - 2020-01-05 10:56 -0800
          Re: std::copy with std::ostream_iterator<std::array...> Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-05 19:55 +0000

csiph-web