“Z z z ……”,Solmyr又在打鼾了,虽然说上班时打呼噜是被小组禁止的,但没有人能阻止Solmyr在睡梦中梦想自己成为大虾,教训现实中的大虾Zero。梦中他正扁Zero扁的高兴,口水流了一写字台,没想到突然听到一声“Stupid”,猛地惊醒,看见原来是测试部门发来的EMail,抱怨他写的程序通不过测试。
XML:namespace prefix = o ns = "urn:schemas-microsoft-com:Office:office" />
他把程序代码装入了UltraEdit,看了一下,原来是那段字符串处理程序:
void f(string& s1, string& s2)
{
const char* cs = (s1 + s2).c_str();
cout << cs;
}
在他看来,这段程序没什么问题,他试着测试了一下,没什么问题,cs正确的显示了结果,不是么。“该死的测试部门,总是莫名其妙的发来这些毫无意义的邮件……”Solmyr嘴里嘟囔着,突然听到身后传来的声音“注意临时对象的生存期,孩子。”
Solmyr吓了一跳,是Zero,他总是在你受窘的时候出现,并无私的帮助你(虽然偶尔会带几句嘲笑和讽刺),这次他又想怎么样呢?“孩子,你知道临时对象的生存期吗?”“唔,我想,大概是,应该是在退出它的作用域(SCOpe)之后,它被析构吧。”Solmyr脸色苍白,支支吾吾的答道。
“不,不对,他们将会在创建他们的表达式的结尾被析构(“TCPL": a temporary object is destroyed at the end of the full expression in which it was created. A full expression is an expression that is not a subexpression of some other expression),不妨你再运行一下你的程序看看。”
Solmyr又运行了一次,令人惊讶的是这次的结果竟然和上次不一样,太夸张了。这时,Zero的声音又在耳旁响起“现在,说说为什么会是这样。Solmyr想了一下,突然大有领悟的说:“由于s1 + s2所产生的临时对象在表达式结束之后就被析构了,所以cs指向的内存就不一定存在了,可能还是原来的s1+s2,也可能是别的,所以就不能保证显示正确。”
“很好,可情况并不是总是那么简单,C++规定,临时对象可以做为常量引用和命名对象(named object)的初始器(initializer),就像下面一样:
void f(const string&, const string&);
void h(string& s1, string& s2)
{
const string& s = s1 + s2;
string ss = s1 + s2;
f(s, ss);
}
上面的代码将会运行的很好,而临时对象也会在常量引用和命名对象退出他们的作用域后被摧毁。 临时对象常会出现在以下场合:类型转换和函数返回。函数返回值一般能被编译器优化掉,所以你可以不必担心它带来的开销。而类型转换则破费思量,它的目的一般是为了使函数调用能够成功,如下:
void uppercasify(string& str);
// changes all chars in str to upper case
char subtleBookPlug[] = "Effective C++";
uppercasify(subtleBookPlug); // error!
为什么呢,你能告诉我吗?”
“因为要使函数调用成功,必须将subtleBookPlug转换成string类型,而编译器认为你要改变的subtleBookPlug,而类型转换后将产生一个类型为string的临时对象,而在void uppercasify(string& str)中,被改变的将是这个临时对象,而不是subtleBookPlug,这显然不是程序员所期望的,所以C++明智地禁止了这种行为。”
“很好,今天你表现的很好,我的孩子,但记住,千万不要在背后说测试部门的坏话,否则的话,哼哼……”
注:
本文所有例子均参考了
The C++ Programming Language 3rd More Effective in C++
如读者觉得没弄明白或没过瘾的话,可以参考TCPL Pg254-255, MEC Item 19, Item 20
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/10752043/viewspace-991611/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/10752043/viewspace-991611/