在看别人的代码时，意外发现了一个标准库的问题（不知到标准委员会的c++ standard lib.core issue文件里有没有提到，不管它），是这样的，代码如下：
struct X
{
};
ostream& operator<<(ostream& out, X& x /*坏习惯*/)
{ ^^^^ ---- #1 non-const reference
...
return out;
}
void use1()
{
vector<X> v;
v.push_back(X());
copy(v.begin(),b.end(),ostream_iterator<X>(cout,"\n") ); //编译错误！
}
void use2()
{
X x;
cout<<x; //没问题
}
按照语义，use1和use2都应该通过编译，但事实是use1不能通过编译。原因就在于#1处，如果将X&改为X const&则万事大吉。
到底为什么呢？看一下ostream_iterator的定义吧：
其中有一个成员函数是这样的
ostream_iterator& operator=(const _Tp& __value)
{ ^^^^^^^^^^^^ -----#2 const reference
*_M_stream << __value; //应该转到用户重载的operator<<中去
...
}
上面的例子中的copy(...)每迭代进一步都要调用这个函数，将迭代器指向的值给它，然后在这个函数中的：*_M_stream << __value;其实就相当于cout<<__value，输出该值，又什么不对吗？看看参数__value的类型，是const &，而我们重载的那个operator<<只接受non-const引用，所以就找不到匹配的函数了。这里的关键在于，ostream_iterator的成员operator=为它的参数强加上了不该加的语义——const——而不管其原先是否为const。
解决方法有两种：
对于用户，解决办法是重载operator<<时注意第二个参数最好写成const引用参数，否则像上面的"copy(v.begin(),v.end(),ostream_iterator<X>(cout) )"调用方式就会出漏子了。这个篓子还不算严重，至少你还被阻止在编译期，另外一种情况更为严重——通过编译但运行结果让人摸不着头脑，我们为原先的例子加上一些代码：
ostream& operator<<(ostream& out,X* & px)
{
...
return out;
}
void use3()
{
X* px=new X;
cout<<px; //没问题，调用上面重载的operator<<(ostream&,X* &)
vector<X*> v;
v.push_back(px);
copy(v.begin(),v.end(),ostream_iterator<X*>(cout,"\n") ); //编译没问题，但结果确打印出px里面存放的地址
}
copy(...)为什么会打印出地址？因为ostream有一个成员函数是为void*重载的，所以发生了一个隐蔽的类型转换，调用了它。
与前面的错误相比，这种错误更为隐蔽。要到运行期才会出现。
对于库的设计者，这是个疏忽，有一个简单的解决办法，为ostream_iterator添加一个operator=成员函数，其调用参数是non-const引用。这样通过重载决议，上面的copy(...)将调用添加的版本，由于其参数是non-const引用，所以接下来会转往用户重载的operator<<去。这个解决方案要求编译器能在 const引用和non-const引用之间正确进行重载决议。