有了concepts之后，模板将保持它们的灵活性和性能。在委员会可以接受一个具体的concept设计之前，仍然有很多工作要做。然而，由于承诺显著更好的类型检查、更好的错误信息和更好的表达力，concepts将成为一个极有可能的扩展。它将使得我们从目前的标准容器、迭代器、和算法开始就能设计出更好的程序库接口。 最后，考虑最后一行用于输出我们的vector元素的代码：
for (auto p = v.begin(); p!=v.end(); ++p)
cout << *p << endl; |
这儿与98的区别在于我们不需要提及迭代器的类型：auto的含义是“从初始化器（initializer）中推导出所声明的变量的类型”。这种对auto的使用方式可以大大消除当前替代方式所导致的冗长和易出错的代码，例如：
for (vector< double, My_alloc >::const_iterator
p = v.begin(); p!=v.end(); ++p)
cout << *p << endl; |
这儿提到的新的语言特性的目标都在于简化泛型编程，原因在于泛型编程已经是如此流行，“使得现有语言设施受到了很大的压力”。许多“modern”的泛型编程技术接近于“write only”技术，并有孤立于其用户的危险。为了使得泛型编程成为主流（就象面向对象编程成为主流那样），我们必须使模板代码更易于阅读、编写和使用。许多目前的用法只管编写时候的好处。但真正好的代码应该简洁（相对于它要做的事情来说）、易于检查和易于优化（也就是高效）。这就意味着许多简单的思想可以在0x中简单地进行表达，并且结果代码坚定不移得高效。在C++98中前者的情况可不是这样，至少对于非常大范围的依赖于模板的技术的情况不是如此。借助于更好的类型检查和类型信息更广泛的使用，C++代码将会变得更简短、清晰、易于维护，也更容易获得正确性。
库设施
从理想上说，我们应该尽量不修改C++语言，而集中于扩充标准库。然而，那些具有足够大的通用性的能够进入标准的库设计起来并不容易，而且一如既往，标准委员会缺乏足够的资源。我们由相对少的一组志愿者构成，并且都有“日常工作”。这就给我们能对新库进行的冒险添加了不幸的限制。另一方面，委员会很早就开始库的工作了，一个关于库的技术报告（Library TR）也在最近被投票通过了，它提供了一些对程序员来说具有直接的用处的设施：
◆哈希表（Hash Tables）
◆正则表达式（Regular Expressions）
◆通用智能指针（General Purpose Smart Pointers）
◆可扩展的随机数字设施（Extensible Random Number Facility）
◆数学专用函数（Mathematical Special Functions）
我尤其赏识能够有标准版本的正则表达式和哈希表（名为unordered_map）。此外，Library TR还为基于STL构建泛型库的人们提供了广泛的设施：
◆多态函数对象包装器（Polymorphic Function Object Wrapper）
◆Tuple类型◆Type Traits◆增强的成员指针适配器（Enhanced Member Pointer Adaptor）
◆引用包装器（Reference Wrapper）
◆用于计算函数对象返回类型的统一方法（Uniform Method for Computing Function Object Return Types）
◆增强的绑定器（Enhanced Binder）
这儿不是详述这些库的细节或者深入讨论委员会希望提供的更多的设施的场合。如果你对此感兴趣，我建议你看看WG21站点（参见后面的“信息资源”）上的提案、库“期望列表（wish list）”（在我的主页上），以及BOOST库（）。我个人希望看到更多的对应用程序构建者有着直接好处的库，例如Beman Dawes的用于操纵文件和目录的库（当前是一个BOOST库）以及一个socket库。
目前的提案列表仍然相当的保守，并不是各个地方都如我所期望的那样进取。不过，还有更多来自于委员会海量的建议中的提案正被考虑，将有更多的库或者成为C++0x标准的一部分或者成为将来委员会的技术报告。不幸的是，资源的缺乏（时间、财力、技能、人力等）仍将继续限制我们在这个方向上的进展。悲哀的是，我无法给大家太希望得到的一个新标准库——一个标准GUI库——带来希望。GUI库对于C++标准委员会的志愿者来说是一个太大的任务，而且是一个太困难的任务，因为已经有很多（非标准、大型、有用、但受支持的）GUI库的存在。请注意，纵然它们是非标准的，主要的C++ GUI库还是有比大多数编程语言更多的用户，并且通常有更好的支持。
除了这些通用的库之外，委员会还在“Performance TR”中提呈了一个到最基层的硬件的库接口。该TR的首要目标是帮助系统程序员，同时还驳斥了有关C++代码性能低下以及C++正变得不适合低层任务的流言蜚语。
总结
“将一个数组中所有的形状绘制出来”是面向对象编程中一个经典的例子（回想早期Simula的日子）。使用泛型编程，我们可以将其泛化，从而支持绘制任意容器（着Shape指针）中的每个元素。
template
void draw_all(C& c)
where Usable_as
{
for_each(c, mem_fun(&Shape::draw));
} |
在C++0x中，我们希望将Container作为一个标准concept，将Usealbe_as作为一个标准判断式。其中for_each算法已经在C++98中有了，但是接受容器（而非一对迭代器）作为参数的版本要依赖于C++0x中的concept.其中的where子句用于支持算法来表达其对于实参的要求。就这里来说，draw_all（）函数（明确）要求容器中的元素必须可以被作为（即可以隐式转换为）Shape*使用。这里的where子句通过简单要求一个Shape*容器，为我们提供了某种程度的灵活性和通用性。除了元素为Shape*的任何容器外，我们还可以使用那些元素可以被用作Shape*的任何容器，例如list
>（其中shared_ptr将有可能成为C++0x标准库中的一个类）、或者元素类型继承自Shape*的容器，例如deque.
假设我们有p1、p2、p3三个点，我们可以编写如下代码来draw_all（）：
vector v = {
new Circle(p1,20),
new Triangle(p1,p2,p3),
new Rectangle(p3,30,20)
};
draw_all(v);
list> v2 = {
new Circle(p1,20),
new Triangle(p1,p2,p3),
new Rectangle(p3,30,20)
};
draw_all(v2); |
“绘制所有形状”的例子很重要，因为如果你可以很好地实现它，那么你就掌握了大多数面向对象编程中关键的东西。通过融合泛型编程（concepts与模板）、常规编程（例如独立标准库函数mem_fun（））和简单数据抽象（mem_fun（）函数返回的函数对象），上面的代码演示了多范型编程的力量。这个简单的示例为我们开启了一扇通往许多优雅和高效的编程技巧的大门。
我希望在看完上面的例子之后，你的反应是“如此简单！”，而不是“如此聪明！如此高级！”在我看来，许多人都在聪明和高级的道路上太过投入。但设计与编程的真正目的是使用最简单的方案来完成工作，并用尽可能清晰的方式来表达。C++0x设计的目标便是更好地支持这样的简单方案。
【责编:huangchunmei】
--------------------next---------------------
