Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #71013
| 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
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