introduction.html

制作本书的目的是为了方便大家的阅读。转载时请保持本电子书的完整性。 前言、条款2、16、21、44根据从Addison-Wesley出版社下载的开放条款翻译。条款26、27、28、45根据从Sc

class Widget { ... };
</pre>
<p>我这么写：</p>
<pre>
template&lt;<span class="highlight">typename</span> T&gt;
class Widget { ... };
</pre>
<p>用这个场景里，class和typename表示完全相同的东西，但我发现typename能更清楚地表示我通常想要说的：T可以是<em>任何</em>类型；不必是一个类。如果你喜欢使用class来声明类型参数，那也可以。在这个场景里是用typename或class完全是风格的问题。</p>
<p>在另一个场景里，这不再是风格问题。为了避免潜在的解析含糊（我将提供给你细节），你被要求在依赖形式类型参数的类型名字之前使用typename。这样的类型被称为<dfn>依赖类型</dfn>，一个例子将帮助阐明我所说的。假设你想为函数写一个模板，给定一个STL容器，返回容器中的最后一个元素是否大于第一个元素。这是一种方法：</p>
<pre>
template&lt;typename C&gt;
bool lastGreaterThanFirst(const C&amp; container)
{
	if (container.empty()) return false;
	<span class="highlight">typename</span> C::const_iterator begin(container, begin());
	<span class="highlight">typename</span> C::const_ierator end(container.end());
	return *--end &gt; *begin;
}
</pre>
<p>在这个例子里，局部变量begin和end的类型是C::const_iterator。const_iterator是依赖形式类型参数C的一种类型。因为C::const_iterator是一种依赖类型，你被要求在它之前放上typename这个词。（一些编译器错误地接受没有typename的代码，但这样的代码不可移植。）</p>
<p>我希望你注意到了在上面例子里我对颜色的使用。那是为了让你的注意力集中于特别重要的部分代码。通常，我加亮相关例子之间的差别，正如我在Widget例子里演示两种可能的声明参数T的方法。用于唤起例子中特别值得注意的部分的颜色也延伸到图表。例如，来自<a href="item_05.html">条款5</a>的这张图使用颜色来区分当新元素被插入list时受影响的两个指针：</p>
<p><img src="image/item_05-1.png" alt="Item 5-1" width="650" height="260" /></p>
<p>我也为章号使用颜色，但这样的使用完全没有理由。这作为我的第一本两色的书，我希望你能原谅我的一点色彩丰富。</p>
<p>我最喜爱的参数名中的有两个是lhs和rhs。它们分别代表“左手边”和“右手边”，而且当声明操作符时，我发现它们特别有用。 这是来自<a href="item_19.html">条款19</a>的一个例子：</p>
<pre>
class Widget { ... };
bool operator==(const Widget&amp; Ihs, const Widget&amp; rhs);
</pre>
<p>当这个函数在这样的场景下被调用时，</p>
<pre>if (x == y) ...			// 假设x和y是Widget</pre>
<p>x，在“<code>==</code>”的左边，在operator==里面被称为lhs，而y被称为rhs。</p>
<p>至于类名Widget，与GUI或者工具无关。这指示我为“做某件事的某个类”使用的名字。有时，正如第7页上的，Widget是一个类模板而不是一个类。在这样的情况里，你可能发现我仍然称Widget为一个类，即使这真的是一个模板。只要对讨论的东西不会产生歧义，忽略类和类模板、结构体和结构体模板、函数和函数模板之间的差别就不会伤害任何人。在可能混淆的情况下，我会分清模板和它们产生的类、结构体和函数。</p>
<h2>涉及效率的条款</h2>
<p>我考虑过在《Effective STL》中包含一章关于效率的，但我最后决定当前的组织是更好的。仍然，许多项目关注与减少空间和运行期需要。为了方便你的性能提高，这里有一张包含实际上关于效率的章节的表：</p>
<table cellpadding="0" cellspacing="0">
	<tr>
		<td><a href="item_04.html">条款4：用empty来代替检查size()是否为0</a></td>
		<td>23</td>
	</tr>
	<tr>
		<td><a href="item_05.html">条款5：尽量使用区间成员函数代替它们的单元素兄弟</a></td>
		<td>24</td>
	</tr>
	<tr>
		<td><a href="item_14.html">条款14：使用reserve来避免不必要的重新分配</a></td>
		<td>66</td>
	</tr>
	<tr>
		<td><a href="item_15.html">条款15：小心string实现的多样性</a></td>
		<td>68</td>
	</tr>
	<tr>
		<td><a href="item_23.html">条款23：考虑用有序vector代替关联容器</a></td>
		<td>100</td>
	</tr>
	<tr>
		<td><a href="item_24.html">条款24：当关乎效率时应该在map::operator[]和map-insert之间仔细选择</a></td>
		<td>106</td>
	</tr>
	<tr>
		<td><a href="item_25.html">条款25：熟悉非标准散列容器</a></td>
		<td>111</td>
	</tr>
	<tr>
		<td><a href="item_29.html">条款29：需要一个一个字符输入时考虑使用istreambuf_iterator</a></td>
		<td>126</td>
	</tr>
	<tr>
		<td><a href="item_31.html">条款31：了解你的排序选择</a></td>
		<td>133</td>
	</tr>
	<tr>
		<td><a href="item_44.html">条款44：尽量用成员函数代替同名的算法</a></td>
		<td>190</td>
	</tr>
	<tr>
		<td><a href="item_46.html">条款46：考虑使用函数对象代替函数作算法的参数</a></td>
		<td>201</td>
	</tr>
</table>
<h2>《Effective STL》的方针</h2>
<p>构成本书50个条款的方针是基于世界上最有经验的STL程序员的见解和建议。这些方针总结了你应该总是做的——或总是避免做的——以发挥标准模板库的最大功效。同时，它们只是方针。在一些条件下，违反它们是有意义的。例如，<a href="item_07.html">条款7</a>的标题告诉你在容器销毁前应该删除容器内new得的指针，但那个条款的正文说明只适用于当容器销毁时被那些指针指向的对象也得跟随而去的情况。情况经常如此，但不永远为真。类似的，<a href="item_35.html">条款35</a>的标题恳求你使用STL算法进行简单的忽略大小写字符串比较，但条款的正文指出在一些情况里，你最好使用不仅在STL之外，而且甚至不是标准C++一部分的一个函数！</p>
<p>只有你足够了解你正写的软件，它运行的环境，以及建立它的场景，才能确定违反我提出的方针是否合理。多数时候，不是，而且伴随每个条款的讨论解释了为什么。在一些情况里，它是。对指南奴隶般的盲从是不对的，但骑士般的漠视也不对。在一个人冒险之前，你应该保证你有一个好原因。</p>
</body>
</html>