📄 8991.htm
字号:
<HTML>
<HEAD>
<meta http-equiv='Content-Type' content='text/html; charset=gb2312'>
<style >
.fst{padding:0px 15px;width:770px;border-left:0px solid #000000;border-right:0px solid #000000}
.fstdiv3 img{border:0px;border-right:8px solid #eeeecc;border-top:6px solid #eeeecc}
</style>
<title>
Effective C++ 2e Item29
</title>
</HEAD>
<BODY >
<center>
<div align=center><div class=fst align=left><div class=fstdiv3 id=print2>
<b>
Effective C++ 2e Item29 </b><p>类和函数: 实现</p>
<p>c++是一种高度类型化的语言，所以，给出合适的类和模板的定义以及合适的函数声明是整个设计工作中最大的一部分。按理说，只要这部分做好了，类、模板以及函数的实现就不容易出问题。但是，往往人们还是会犯错。</p>
<p>犯错的原因有的是不小心违反了抽象的原则：让实现细节可以提取类和函数内部的数据。有的错误在于不清楚对象生命周期的长短。还有的错误起源于不合理的前期优化工作，特别是滥用inline关键字。最后一种情况是，有些实现策略会导致源文件间的相互联结问题，它可能在小规模范围内很合适，但在重建大系统时会带来难以接受的成本。</p>
<p>所有这些问题，以及与之类似的问题，都可以避免，只要你清楚该注意哪些方面。以下的条款就指明了应该特别注意的几种情况。</p>
<p><br>条款29: 避免返回内部数据的句柄</p>
<p>请看面向对象世界里发生的一幕：</p>
<p>对象a：亲爱的，永远别变心！<br>对象b：别担心，亲爱的，我是const。</p>
<p>然而，和现实生活中一样，a会怀疑，"能相信b吗？" 同样地，和现实生活中一样，答案取决于b的本性：其成员函数的组成结构。</p>
<p>假设b是一个const string对象：</p>
<p>class string {<br>public:<br> string(const char *value); // 具体实现参见条款11<br> ~string(); // 构造函数的注解参见条款m5</p>
<p> operator char *() const; // 转换string -> char*;<br> // 参见条款m5<br> ...</p>
<p>private:<br> char *data;<br>};</p>
<p>const string b("hello world"); // b是一个const对象</p>
<p>既然b为const，最好的情况当然就是无论现在还是以后，b的值总是"hello world"。这就寄希望于别的程序员能以合理的方式使用b了。特别是，千万别有什么人象下面这样残忍地将b强制转换掉const（参见条款21）：</p>
<p>string& alsob = // 使得alsob成为b的另一个名字，<br> const_cast<string&>(b); // 但不具有const属性</p>
<p>然而，即使没有人做这种残忍的事，就能保证b永远不会改变吗？看看下面的情形：</p>
<p>char *str = b; // 调用b.operator char*()</p>
<p>strcpy(str, "hi mom"); // 修改str指向的值</p>
<p>b的值现在还是"hello world"吗？或者，它是否已经变成了对母亲的问候语？答案完全取决于string::operator char*的实现。</p>
<p>下面是一个有欠考虑的实现，它导致了错误的结果。但是，它工作起来确实很高效，所以很多程序员才掉进它的错误陷阱之中：</p>
<p>// 一个执行很快但不正确的实现<br>inline string::operator char*() const<br>{ return data; }</p>
<p>这个函数的缺陷在于它返回了一个"句柄"（在本例中，是个指针），而这个句柄所指向的信息本来是应该隐藏在被调用函数所在的string对象的内部。这样，这个句柄就给了调用者自由访问data所指的私有数据的机会。换句话说，有了下面的语句：</p>
<p>char *str = b;</p>
<p>情况就会变成这样：</p>
<p>str------------------------->"hello world\0"<br> / <br> /<br>b.data</p>
<p>显然，任何对str所指向的内存的修改都使得b的有效值发生变化。所以，即使b声明为const，而且即使只是调用了b的某个const成员函数，b也会在程序运行过程中得到不同的值。特别是，如果str修改了它所指的值，b也会改变。</p>
<p>string::operator char*本身写的没有一点错，麻烦的是它可以用于const对象。如果这个函数不声明为const，就不会有问题，因为这样它就不能用于象b这样的const对象了。</p>
<p>但是，将一个string对象转换成它相应的char*形式是很合理的一件事，无论这个对象是否为const。所以，还是应该使函数保持为const。这样的话，就得重写这个函数，使得它不返回指向对象内部数据的句柄：</p>
<p>// 一个执行慢但很安全的实现<br>inline string::operator char*() const<br>{<br> char *copy = new char[strlen(data) + 1];<br> strcpy(copy, data);</p>
<p> return copy;</p>
<p>}</p>
<p>这个实现很安全，因为它返回的指针所指向的数据只是string对象所指向数据的拷贝；通过函数返回的指针无法修改string对象的值。当然，安全是要有代价的：这个版本的string::operator char* 运行起来比前面那个简单版本要慢；此外，函数的调用者还要记得delete掉返回的指针。</p>
<p>如果不能忍受这个版本的速度，或者担心内存泄露，可以来一点小小的改动：使函数返回一个指向const char的指针：</p>
<p>class string {<br>public:<br> operator const char *() const;</p>
<p> ...</p>
<p>};</p>
<p>inline string::operator const char*() const<br>{ return data; }</p>
<p>这个函数既快又安全。虽然它和最初给出的那个函数不一样，但它可以满足大多数程序的需要。这个做法还和c++标准组织处理string/char*难题的方案一致：标准string类型中包含一个成员函数c_str，它的返回值是string的const char*版本。关于标准string类型的更多信息参见条款49。</p>
<p>指针并不是返回内部数据句柄的唯一途径。引用也很容易被滥用。下面是一种常见的用法，还是拿string类做例子：</p>
<p>class string {<br>public:</p>
<p> ...</p>
<p> char& operator[](int index) const<br> { return data[index]; }</p>
<p>private:<br> char *data;<br>};</p>
<p>string s = "i'm not constant";</p>
<p>s[0] = 'x'; // 正确, s不是const</p>
<p>const string cs = "i'm constant";</p>
<p>cs[0] = 'x'; // 修改了const string，<br> // 但编译器不会通知</p>
<p>注意string::operator[]是通过引用返回结果的。这意味着函数的调用者得到的是内部数据data[index]的另一个名字，而这个名字可以用来修改const对象的内部数据。这个问题和前面看到的相同，只不过这次的罪魁祸首是引用，而不是指针。</p>
<p>这类问题的通用解决方案和前面关于指针的讨论一样：或者使函数为非const，或者重写函数，使之不返回句柄。如果想让string::operator[]既适用于const对象又适用于非const 对象，可以参见条款21。</p>
<p>并不是只有const成员函数需要担心返回句柄的问题，即使是非const成员函数也得承认：句柄的合法性失效的时间和它所对应的对象是完全相同的。这个时间可能比用户期望的要早很多，特别是当涉及的对象是由编译器产生的临时对象时。</p>
<p>例如，看看这个函数，它返回了一个string对象：</p>
<p>string somefamousauthor() // 随机选择一个作家名<br>{ // 并返回之</p>
<p> switch (rand() % 3) { // rand()在<stdlib.h>中<br> // (还有<cstdlib>。参见条款49)<br> case 0:<br> return "margaret mitchell"; // 此作家曾写了 "飘"，<br> // 一部绝对经典的作品<br> case 1:<br> return "stephen king"; // 他的小说使得许多人<br> // 彻夜不眠<br> case 2:<br> return "scott meyers"; // 嗯...滥竽充数的一个<br> } <br> </p>
<p> return ""; // 程序不会执行到这儿，<br> // 但对于一个有返回值的函数来说，<br> // 任何执行途径上都要有返回值<br>}</p>
<p>希望你的注意力不要集中在随机数是怎样从rand产生的问题上，也不要嘲笑我把自己和这些作家联系在一起。真正要注意的是，somefamousauthor的返回值是一个string对象，一个临时string对象（参见条款m19）。这样的对象是暂时性的，它们的生命周期通常在函数调用表达式结束时终止。例如上面的情况中，包含somefamousauthor函数调用的表达式结束时，返回值对象的生命周期也就随之结束。</p>
<p>具体看看下面这个使用somefamousauthor的例子，假设string声明了一个上面的operator const char*成员函数：</p>
<p>const char *pc = somefamousauthor();</p>
<p>cout << pc; </p>
<p>不论你是否相信，谁也不能预测这段代码将会做些什么，至少不能确定它会做些什么。因为当你想打印pc所指的字符串时，字符串的值是不确定的。造成这一结果的原因在于pc初始化时发生了下面这些事件：<br>1. 产生一个临时string对象用以保存somefamousauthor的返回值。<br>2. 通过string的operator const char*成员函数将临时string对象转换为const char*指针，并用这个指针初始化pc。<br>3. 临时string对象被销毁，其析构函数被调用。析构函数中，data指针被删除（代码详见条款11）。然而，data和pc所指的是同一块内存，所以现在pc指向的是被删除的内存--------其内容是不可确定的。</p>
<p>因为pc是被一个指向临时对象的句柄初始化的，而临时对象在被创建后又立即被销毁，所以在pc被使用前句柄已经是非法的了。也就是说，无论想做什么，当要使用pc时，pc其实已经名存实亡。这就是指向临时对象的句柄所带来的危害。</p>
<p>所以，对于const成员函数来说，返回句柄是不明智的，因为它会破坏数据抽象。对于非const成员函数来说，返回句柄会带来麻烦，特别是涉及到临时对象时。句柄就象指针一样，可以是悬浮（dangle）的。所以一定要象避免悬浮的指针那样，尽量避免悬浮的句柄。</p>
<p>同样不能对本条款绝对化。在一个大的程序中想消灭所有可能的悬浮指针是不现实的，想消灭所有可能的悬浮句柄也是不现实的。但是，只要不是万不得已，就要避免返回句柄，这样，不但程序会受益，用户也会更信赖你。<br>
</p>
</DIV></div></div>
</center></BODY></HTML>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -