在看别人的代码时,意外发现了一个标准库的问题(不知到标准委员会的c++ standard lib.core issue文件里有没有提到,不管它),是这样的,代码如下:
struct X
{
};
ostream& operator<<(ostream& out, X& x /*坏习惯*/)
{ ^^^^ ---- #1 non-const reference
...
return out;
}
void use1()
{
vector
v;
v.push_back(X());
copy(v.begin(),v.end(),ostream_iterator
(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
(cout) )"调用方式就会出漏子了。这个篓子还不算严重,至少你还被阻止在编译期,另外一种情况更为严重——通过编译但运行结果让人摸不着头脑,我们为原先的例子加上一些代码:
ostream& operator<<(ostream& out,X* & px)
{
...
return out;
}
void use3()
{
X* px=new X;
cout<vector v;
v.push_back(px);
copy(v.begin(),v.end(),ostream_iterator(cout,"/n") ); //编译没问题,但结果确打印出px里面存放的地址
}
copy(...)为什么会打印出地址?因为ostream有一个成员函数是为void*重载的,所以发生了一个隐蔽的类型转换,调用了它。
与前面的错误相比,这种错误更为隐蔽。要到运行期才会出现。
对于库的设计者,这是个疏忽,有一个简单的解决办法,为ostream_iterator添加一个operator=成员函数,其调用参数是non-const引用。这样通过重载决议,上面的copy(...)将调用添加的版本,由于其参数是non-const引用,所以接下来会转往用户重载的operator<<去。这个解决方案要求编译器能在 const引用和non-const引用之间正确进行重载决议。
--------------------------------------------------------------
to 大家:
这个问题我已经不打算再往下讨论了,问题已经很明显,关键是如何折衷,这倒是需要库的开发者的经验来决定了。我也不想在这个问题上耗费精力了,只不过,虽然是个小问题,但可以看出大家思考问题的深度和广度,我将文章改了一下,把我的几个关键回帖写到了下面,以表明我的意见,因为很多朋友都是光看了文章没看我后面的回帖就下的结论。
--------------------------------------------------------------------------------------------------------------------------------------
to solotony:
你的问题我也想过,但是你有没有想过:
第一:程序员不一定都那么有自觉性,一旦他们无意间犯下了这个隐蔽的错误(?),却得到了不一致性的编译(或运行)结果,他们可能无所适从。如何理解“直接输出没有问题而放到模板容器中就有问题呢”,最关键的是对于指针,问题处在运行期,更惨。光就这个不一致性,就应该将重载版本加上去。如果不加,除非你有办法将这种情况下的普通输出也禁止,但这显然是不行的。
第二:对于要用到用户重载的operator<<的类来说,自定义的输出语义应该在该类的对象身上,应该是“该对象知道如何将自身输出到流”而不是“流知道如何获取对象的信息并输出”,这个“输出”的行为是对象拥有,而非流。对于对象来说,任何流都是一样,抽象的说就是一个“管子”,具有最基本的有关输出的一集语义。所以,输出只不过是对象自身的一个行为,这个行为是否为const,则由该对象(类)决定——谁规定对象在输出自身的时候不能改变自身的状态的?虽然我一时举不出例子,但是肯定有!至少,当这种情况出现的时候,你不能不让用户的代码通过编译吧。
第三:对于一个拥有“引用”语义的指针来说,输出它就输出它指向的对象又有何不可呢?本来,指针和引用的语义就十分相近。另外,在一个具有输出输入(serialize&unserialize)的系统中,输入输出都属于同一个系统,不关系统使用者的事,使用者也不必知道输出了哪些东西,读入了哪些东西,这是个黑箱,MFC的序列化就是例子。形象一点说,A负责将一个指针输出去,A也会负责将它读出来,至于如何出如何入则全都是A的事情,所以A不会对这种语义感到迷惑。极端情况下,A输出一个指针(实际输出了一个对象)但要求B来读入,那么它们之间应该就此有一个“契约”,如果A和B开发的是一个系统的两部分,那么这种“契约”就应该表现为对输出输入格式的约定。如果B是用户,那么A应该给B提供文档(或用户手册)。即使是后一种情况,用户一般只会看到一个对象,至于这个对象是否经由指针输出则仍然是程序员的事情。唯一的坏情况是代码重用,这就要求程序员有好的编码习惯和文档习惯,从另一个方面说,没有好习惯,即使程序语义明确也会给重用造成麻烦。再说这种语义也属常见,一个稍有素质的代码阅读者也不至于看不到那个重载过的operator<<,就算跟踪也跟踪到了。如果是二进制重用呢?很显然,又回到上面说的黑箱的情况了,打住。
第四:根据Stroustrup的意思,“不应该强求程序员做他们不愿意做的事情,在模棱两可的事情上保持自由度”,按照你的观点,库就某种程度上强制了程序员一定要将被输出参数置为const的(否则就不一致,而一致性对于避免语义含混是非常重要的),万一程序员有特殊要求呢?
-------------------------------------------------------------------------------------------------------------------------------------------
to rainmain123:
标准库不是黑盒,C++标准库符合Open Close Principle。
只有二进制复用的库才是完整的黑盒。STL是个可扩展的库,“白盒”的成分比较大一点。
另外,你说的的确有道理,我也这么认为,但这里的问题并非在于哪一方对哪一方不对,而是一个权衡利弊的问题。
我是这样权衡的:
这里有两种做法,第一,维持ostream_iterator的原状,其结果是:
1. 用户在使用ostream_iterator并自定义operator<<时被强制将其第二个参数设为const &(或干脆
为值拷贝传递参数),这也就是强制用户将对象的“打印自身到输出流”的行为const化。
1的问题在于:
(1) 虽然ostream_iterator有此限制,但是考虑下面的三份代码:
copy(v.begin(),v.end(),ostream_iterator(cout));
for(iter_type iter=v.begin();iter!=v.end();++iter)
{
cout<<*iter;
}
for_each(v.begin(),v.end(),cout<<_1);
这三份代码语义完全一样,最后的for_each还使用了标准库函数,但是它们的行为因
由于用户重载的operator<<而异。
(2)考虑一种特殊需求,有一种文件对象,其限制是在其生命期里只能被输出一次,
后续的输出都是nop(无操作),很显然,这是一种特殊的文件,就像那些“只能被读一次,然后就自动
销毁”的密码一样。很显然,这种需求是存在的。当遇到这种情况时,operator<<的第二个参数总该是
non-const &了吧!但是ostream_iterator却阻止编译继续,难道不是个问题吗?我知道你可能会想到
mutable关键字,但这个关键字只能解决语法问题,不能解决语义问题,就不细说了。这里的关键是,如
果维持ostream_iterator原状,那么对于特殊要求来说就无所适从。
2.对于指针,如果用户自定义的是operator<<(...,X* &),那么用ostream_iterator将输出指针中的
地址值,而如果用户自定义的是operator<<(...,X* const&),那么就能按照用户自定义的意愿输出。这
个行为是会让人迷惑的!特别是当cout<
迷惑人,除非有办法将cout<
为如果不一致就会导致迷惑。
总的说来,如果维持现状,只有一个极其有限的优点,就是当且仅当用户使用ostream_iterator向流中输
出时,能够在编译期确保“输出”操作是const的。但如果用户手写循环输出或以另外的函数输出,
ostream_iterator就鞭长莫及了。而缺点则是牺牲了对特殊情况的支持(自由度),和一致性——谁都看
得出自由度和一致性是多么重要。
第二种做法,增加一个成员的operator =(T&)函数,其结果是:
1. 用户必须适当注意操作的const性——这本来就是用户的职责。虽然前一种情况下
ostream_iterator能起到(强制)提醒用户这一点的程度,但是在语言里并没有这种内建的“提醒”能力
,所以说到底这种强制提醒还是极其有限的,归根到底还是靠用户的自觉性,而自觉性则是每个C++用户
的必备能力——C++语言设计理念就是如此:不强迫用户,但告诉用户做正确的事。这正如operator*也可
以被重载来作除法一样,C++不强制,但是程序员要自觉。
2. 顾全了语义的一致性。
3. 提供了自由度,现在对特殊情况也支持了。
----------------------------------------------------------------------------------------------------------------------------------
to Cynics:
你可能误会我的意思了,我的意思是为ostream_iterator 添加 一个重载函数,这样ostream_iterator就有两个版本的operator = :
ostream_iterator& operator = ( _Ty const & ); -- #1//原来的
ostream_iterator& operator = ( _Ty & ); -- #2//新加的
这样,不管用户如何重载operator << ,行为都会一致,例如:
一: ostream& operator<<(ostream& , X const & );
{
cout<< x; //调用 #1
copy(..., ostream_iterator(cout) ); //调用 #1
}
二: ostream& operator<<(ostream& , X & );
{
cout<< x; //调用 #2
copy(..., ostream_iterator(cout) ); //调用 #2
}