How to resolve ADL(?) issue using std::copy and std::ostream_iterator

[Chris Johnson]

Greetings all. I am really stuck on this one as I can't seem to grok if
I am abusing the C++ language or if I am simply using components of the
C++ Standard Library incorrectly. Here is the code:

#include <string>
#include <map>
#include <iostream>
#include <utility>
#include <iterator>

typedef std::pair<std::string, std::stringSTR;

#ifdef NON_COMPLIANT
// Works but my understanding this is forbidden by
// Standard ISO/IEC 14882.2003 17.4.3.1-1
// since I introduce code into namespace std
namespace std {
{
std::ostream& operator<<(std::ostream& os, STR const& ip) {
os << ip.first << " " << ip.second << std::endl;
return os;
}
}
#else
// Generates error
// std::copy can't find a suitable candidate for operator<<
std::ostream& operator<<(std::ostream& os, STR const& ip) {
os << ip.first << " " << ip.second << std::endl;
return os;
}
#endif

int main(int argc, char** argv, char** env) {
std::map<std::string, std::stringtest;
test["foo"] = "bar";
test["baz"] = "qux";

std::ostream_iterator<STRo(std::cout);
std::copy(
test.begin(),
test.end(),
o);

return 0;
}

If compiled with the macro definition NON_COMPLIANT line 12 violates the
Standard section 17.4.3.1-1 commented on in the code but that seems to
be the only way to allow for std::copy to deduce the correct context of
operator<<, is this correct? (I apologize if I am not using the correct
terminology - please educate me accordingly on this as well)

If my understanding above is correct then can I conclude that I simply
do not understand how to use the Standard C++ library correctly in this
case? The code appears to be a logical use of the components at play
but my compiler disagrees with my thinking.

Thank you for reading and any insight you can assist me with in advance.
Chris

[Alf P. Steinbach]

* Chris Johnson:

Greetings all. I am really stuck on this one as I can't seem to grok if
I am abusing the C++ language or if I am simply using components of the
C++ Standard Library incorrectly. Here is the code:

#include <string>
#include <map>
#include <iostream>
#include <utility>
#include <iterator>

typedef std::pair<std::string, std::stringSTR;

#ifdef NON_COMPLIANT
// Works but my understanding this is forbidden by
// Standard ISO/IEC 14882.2003 17.4.3.1-1
// since I introduce code into namespace std
namespace std {
{
std::ostream& operator<<(std::ostream& os, STR const& ip) {
os << ip.first << " " << ip.second << std::endl;
return os;
}
}
#else
// Generates error
// std::copy can't find a suitable candidate for operator<<
std::ostream& operator<<(std::ostream& os, STR const& ip) {
os << ip.first << " " << ip.second << std::endl;
return os;
}
#endif

int main(int argc, char** argv, char** env) {
std::map<std::string, std::stringtest;
test["foo"] = "bar";
test["baz"] = "qux";

std::ostream_iterator<STRo(std::cout);
std::copy(
test.begin(),
test.end(),
o);

return 0;
}

If compiled with the macro definition NON_COMPLIANT line 12 violates the
Standard section 17.4.3.1-1 commented on in the code but that seems to
be the only way to allow for std::copy to deduce the correct context of
operator<<, is this correct? (I apologize if I am not using the correct
terminology - please educate me accordingly on this as well)

There are a number of related active issues at <url:
http://std.dkuug.dk/jtc1/sc22/wg21/docs/lwg-toc.html>, but I'm not sure
whether this is one of them.

Related paper by Howard Hinnant: <url:
http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1387.htm>.

I think this question belongs in [comp.std.c++], and I suggest you post
the question there.

If my understanding above is correct then can I conclude that I simply
do not understand how to use the Standard C++ library correctly in this
case? The code appears to be a logical use of the components at play
but my compiler disagrees with my thinking.

I think you can conclude that /probably/ the standard is a bit defective
in this regard, there being a number of related active issues.

Thank you for reading and any insight you can assist me with in advance.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Howard Hinnant]

In article <JbTpg.28904$FR1.15119@dukeread05>,
Chris Johnson <de*********@gmail.comwrote:

Greetings all. I am really stuck on this one as I can't seem to grok if
I am abusing the C++ language or if I am simply using components of the
C++ Standard Library incorrectly. Here is the code:

#include <string>
#include <map>
#include <iostream>
#include <utility>
#include <iterator>

typedef std::pair<std::string, std::stringSTR;

#ifdef NON_COMPLIANT
// Works but my understanding this is forbidden by
// Standard ISO/IEC 14882.2003 17.4.3.1-1
// since I introduce code into namespace std
namespace std {
{
std::ostream& operator<<(std::ostream& os, STR const& ip) {
os << ip.first << " " << ip.second << std::endl;
return os;
}
}
#else
// Generates error
// std::copy can't find a suitable candidate for operator<<
std::ostream& operator<<(std::ostream& os, STR const& ip) {
os << ip.first << " " << ip.second << std::endl;
return os;
}
#endif

int main(int argc, char** argv, char** env) {
std::map<std::string, std::stringtest;
test["foo"] = "bar";
test["baz"] = "qux";

std::ostream_iterator<STRo(std::cout);
std::copy(
test.begin(),
test.end(),
o);

return 0;
}

If compiled with the macro definition NON_COMPLIANT line 12 violates the
Standard section 17.4.3.1-1 commented on in the code but that seems to
be the only way to allow for std::copy to deduce the correct context of
operator<<, is this correct? (I apologize if I am not using the correct
terminology - please educate me accordingly on this as well)

If my understanding above is correct then can I conclude that I simply
do not understand how to use the Standard C++ library correctly in this
case? The code appears to be a logical use of the components at play
but my compiler disagrees with my thinking.

Thank you for reading and any insight you can assist me with in advance.
Chris

Your understanding is correct in on all counts. The standard is simply
deficient in this area. I had hoped that tuple I/O would save the day
here (pair simply being a special case of tuple length 2). However I/O
was stripped from the tuple library shortly before it was voted into
TR1. tuple is now in the C++0X working draft (still missing I/O). I am
hopeful that it can gain I/O in time for C++0X, but as yet there is no
such concrete proposal.

-Howard

[Alf P. Steinbach]

* Howard Hinnant:

I had hoped that tuple I/O would save the day
here (pair simply being a special case of tuple length 2). However I/O
was stripped from the tuple library shortly before it was voted into
TR1. tuple is now in the C++0X working draft (still missing I/O). I am
hopeful that it can gain I/O in time for C++0X, but as yet there is no
such concrete proposal.

I think the problem here is both more general and fundamental: that it
should be valid (not UB) to overload at least some functions in the
'std' namespace, namely, those that serve as customization points.

Perhaps it is already valid, i.e. that somewhere the standard mentions
that it's OK to provide overloads of std::operator<< for user-defined
type (any such wording would be compatible with §17.4.3.1/1, which
refers to exceptions), but I failed to find that. Perhaps ADL "should"
find the user-defined ::operator<<, but at least with my preferred
compiler it didn't, and checking the details in the standard is
laborious work. So I'm assuming the OP's problem is real: ADL doesn't
find ::operator<<, and defining std::operator<< is Strictly Verboten.

Under that assumption: supporting tuple i/o is all well and good, but it
won't solve the OP's problem for some class that can't be expressed as a
tuple; only a more general solution can do that.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Howard Hinnant]

In article <4g*************@individual.net>,
"Alf P. Steinbach" <al***@start.nowrote:

Under that assumption: supporting tuple i/o is all well and good, but it
won't solve the OP's problem for some class that can't be expressed as a
tuple; only a more general solution can do that.

The general problem is that the standard has a hole in it. It provides
I/O for all scalar types, and for several standard class types,
including:

basic_string
bitset
complex

But the standard is lacking I/O for several standard types, including:

pair
all of the containers (except string)

This isn't an ADL issue as there are no user-defined types in the OP's
problem. They're all standard types. Indeed, if there were a
user-defined type in the OP's problem, e.g.:

typedef std::pair<MyString, std::stringSTR;

then ADL would save the day.

We could possibly say that it is ok for users to add stuff into
namespace std that does not depend on user-defined types. But I think
eliminating the motivation for doing so by providing commonly needed
functionality (such as I/O) for standard types would be a superior
solution.

-Howard

[Bo Persson]

"Howard Hinnant" <ho************@gmail.comskrev i meddelandet
news:ho**********************************@syrcnyrd rs-03-ge0.nyroc.rr.com...

In article <4g*************@individual.net>,
"Alf P. Steinbach" <al***@start.nowrote:

>Under that assumption: supporting tuple i/o is all well and good,
but it
won't solve the OP's problem for some class that can't be expressed
as a
tuple; only a more general solution can do that.

The general problem is that the standard has a hole in it. It
provides
I/O for all scalar types, and for several standard class types,
including:

basic_string
bitset
complex

But the standard is lacking I/O for several standard types,
including:

pair
all of the containers (except string)

This isn't an ADL issue as there are no user-defined types in the
OP's
problem. They're all standard types. Indeed, if there were a
user-defined type in the OP's problem, e.g.:

typedef std::pair<MyString, std::stringSTR;

then ADL would save the day.

We could possibly say that it is ok for users to add stuff into
namespace std that does not depend on user-defined types.

But how do we know exactly what overload are already provided?

But I think
eliminating the motivation for doing so by providing commonly needed
functionality (such as I/O) for standard types would be a superior
solution.

Right!
Bo Persson

[Chris Johnson]

Howard Hinnant wrote:

In article <4g*************@individual.net>,
"Alf P. Steinbach" <al***@start.nowrote:

--8<--[SNIP]--8<--

But the standard is lacking I/O for several standard types, including:

pair
all of the containers (except string)

I think I can say safely say that I now understand this where before
posting I did not.

This isn't an ADL issue as there are no user-defined types in the OP's
problem. They're all standard types. Indeed, if there were a
user-defined type in the OP's problem, e.g.:

typedef std::pair<MyString, std::stringSTR;

then ADL would save the day.

In fact, using a user defined type, it does. I now know what
(correctly) ADL is.

Thanks for the insight to all that have responded - I learned a few
things as a result. I can't thank everyone enough.

Chris