C++的未来，以及未来的未来
C++的未来，以及未来的未来
7月15日-20日，标准委员会在Toronto开了一次会，IBM做的东。从会后的文档来看，除了把一些已经基本成熟的提案加入草案，进一步明确了打算C++0x的新特性，以及留到再下一版本的C++标准的提案。从中我们可以清晰地看到C++未来，以及未来的未来的发展趋势。文档“State of C++ Evolution”(http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2336.html)包含了最新的发展情况。本文便是基于这篇文档。
首先，是一个清单，包含已经投票通过，合并到working paper的提案。从编程技术的角度来讲，比较主要的内容包括：
A Proposal to Add an Rvalue Reference to the C++ Language
Template aliases for C++
Variadic Templates
Delegating Constructors
Decltype
Rvalue Reference为C++提供了检测右值引用的能力，使C++具备了move语义和完美转发。（详见http://blog.csdn.net/pongba/archive/2007/07/10/1684519.aspx和http://blog.csdn.net/pongba/archive/2007/07/18/1697636.aspx）。
Template aliases完善了C++的别名体系：
template <typename T>
using MyVector=vector <T, allocator <T> > ;
Vec <int> v; // same as vector <int, Alloc <int> > v;
使我们可以更灵活地创建类型别名。非常有用。（真想立刻得到它，我急等着用呢）。
Variadic Template则进步更大。提供了可变的模板类型参数，也就是说，同一个模板的参数的数量是可变的：
template <typename T, unsigned PrimaryDimension, unsigned... Dimensions>
class array { /* implementation */ };
array <double, 3, 3> rotation_matrix; // 3x3 rotation matrix
array <double, 3, 3, 3> 3d_array; //3x3x3 array
Variadic Template使得我们可以拥有真正任意结构的tuple，类型安全的printf()等崭新的基础设施。
Delegating Constructors使我们可以“复用”一个“基本”的构造函数：
class X {
int i_;
public:
X( int i ) : i_(i) { }
X() : X(42) { } // “复用”X(int i)
};
这个新特性可以大幅减少构造函数上的重复代码，提高效率。
Decltype可以使我们提取一个表达式的类型：
int a=1; float b=2;
typedef decltype(a+b) result_t;
typedef decltype(string::c_str) cstr_t;
其他还有一些非常有用的特性，诸如static_assert、Generalized Constant Expressions等都非常实用，只是不如上述几大特性影响大。
接下来是一大堆正在审查的提案。分成了7大部分：
Voting at next meeting。下次会议打算投票表决的提案。目前只有一个Universal Character Names in Literals。
Proposed wording under review in Core。正在核心语言小组（标准委员会的一个小组，负责核心语言特性相关提案的审查）中审查的提案。这些提案都已经有的wording，并都在做最终的详细审查。比较出名的包括：
1.A name for the null pointer: nullptr；C++终于可以不需要再用0来代表null指针了。
2.Initializer lists；一种通用的初始化列表（即{1,2,3,4,5}）方案，扩展到了几乎所有类型。
3.Explicit Conversion Operators；类型转换操作符是个麻烦制造者，主要因为它是默认implicit转换的。现在，可以为它加上explicit关键字，迫使其必须执行explicit转换。就像explicit constructor一样。
4.Inheriting Constructors；可以直接复用基类的构造函数了。通过using default关键字。
5.Proposal for new for-loop；想要foreach关键字的人可以满意了，只是依旧使用for关键字：for(int& a : array){…}。
6.Sequencing and the concurrency memory model；C++在并发上是够糟糕的，现在大牛们正在给标准做透析呢。
7.以及期盼已久的Concept；已经有很多的文章写concept了。不清楚的请看http://blog.csdn.net/pongba/archive/2007/08/04/1726031.aspx。
Blessed by evolution - wording available for initial review by Core。提案完整的wording已经有了，也提交核心小组。但核心小组还没有深入地研究。比较重要的包括：
1.Thread-Local Storage；并发编程中非常重要的特性。C++自然不应该落下。
2.Member Initializers；可以在类声明中直接为一个成员赋值，相当于默认初始化。很可爱的一个特性。
3.General Attributes for C++；attribute，用.net的人肯定很熟悉。挺有用的特性，不知标准委员会的那帮死脑筋怎么看。
Core issues addressed by specific papers。核心语言的一些问题，大到值得写一整篇paper了。目前只有一个Syntactic Disambiguation Using the Template Keyword
Active topics in Evolution。这些提案正在审查，有明确的意向将其加入下一版标准。都是重量级的提案：
1.Transparent Garbage Collection for C++；GC就不用说了吧。人人想要，但又四处挨骂的特性。不过请放心，C++的GC是可选的，而且性能优先。想了解大概，请看http://blog.csdn.net/g9yuayon/archive/2007/07/23/1702694.aspx。
2.Optimization-robust finalization；有了GC，自然需要finalization，这个提案也必不可少。
3.Lambda expressions and closures for C++；另一个可爱的特性，C#3.0已经有了。boost的那个替代品终于可以退休了。
Active topics in Concurrency sub-group。正在并发小组里最终审查的提案。并发看来是最头大的问题了，所以标准委员会专门成立了一个Concurrency sub-group，来啃这块硬骨头。包括：Dynamic initialization and concurrency；C++ Data-Dependency Ordering；Non-Memory Actions；Object Aliasing and Threads。
Active topics in both Concurrency and Library sub-groups。并发小组和库小组一同审查的提案。包括：Atomic operations with multi-threaded environments；Proposed Text for Parallel Task Execution；Thread Pools and Futures；A Multi-threading Library for Standard C++。
从这些Active的提案中可以看到，下个版本标准的进步主要集中在三大方面：
1.扩展编程技术，强化泛型编程的能力，诸如concept、Variadic Templates、Template aliases、auto、Decltype等；
2.强化传统的技术，简化和方便编程，包括GC、rvalue reference、Delegating Constructors、Initializer lists等；
3.并发。没有并发的语言，将无法在21世纪生存。
这些内容表明，目前C++的进化主要集中在编程技术的发展上。已经加入和打算加入标准草案的特性，都大大地拓展了C++原本已经非常强大的编程机制。届时，C++将会再一次站在编程技术的前沿。
接着的两个大类包含了以上这些提案的背景论文和发展过程中产生的提案。对历史感兴趣的可以研究研究。
再下来，是两个同样吸引人的大类。都是在C++0x之后的标准中可能会引入的提案，也就是“未来的未来”。
Heading for a separate TR。包含了打算在C++0x之后的TR（也就是C++0x sp1）中包含的提案。这些提案都不错，只是这次来不及了，等下次吧：
1.Decimal Types for C++。decimal没什么好说的，C++在这方面还是缺那么一点的。毕竟应用摆在那里。
2.Modules in C++。C++缺少Modules，时常遭人诟病。想想也是，Ada83就有了Module，其他很多语言都有，C++缺了如此重要的东西，是该骂。
Not ready for C++0x, but open to resubmit in future。这些提案肯定赶不上C++0x了。有的因为来不及，有的因为缺少足够的动机。但不管怎么说，这些提案还是很有价值的，所以标准委员会把它们放在将来考虑。让我比较感兴趣的包括：
1.PME: Properties, methods and events；属性、方法和事件是比较时髦的语言特性。不过说实话，个人觉得除了property外，其他两个都没有什么实际意义。method和member function是一回事。event完全可以通过库实现，比如boost::signal。property则无法通过模拟实现。（我曾经试过，但不好使）。
2.Draft Proposal for Dynamic Libraries in C++；动态链接库对于不同项目，甚至不同语言，共享组件有无可比拟的作用。不过要实现这些特性，需要C++有更统一的编译模型和对象模型。怎么把那些浑身是刺的编译器厂商捏在一块儿，是个比较艰巨的工作。何况还有模板的问题。
3.Draft proposal for adding Multimethods to C++；multimethod十几年前就已经想加入标准，到现在还只是一个提案。唉。
4.Reflection in C++；反射也是时髦货，可以提供更完全的类型信息。是个好东西。
5.Expliciting default parameters；旨在进一步简化函数默认值的使用。但为什么不再加上命名参数呢？
6.Contract Programming For C++0x；Contract Programming可以个时鲜货，搞好了可以大大提高软件开发的质量和效率。不过目前还只是理论上多些。
7.Macro scopes；macro不受命名域的限制，很讨厌吧。（比如MFC里的max/min宏）。应该给它们加上一道紧箍咒。
8.Overloading Operator.() & Operator.*()；关于这个问题，D&E里已经有过探讨，不知为什么还会有这样的提案。
9.Toward Opaque typedefs in C++0X；typedef是弱类型的，仅仅是类型的别名，无法参与重载。有一个“强类型”的typedef也是件很不错的事。（Matthew Wilson在Imperfect C++中费了不小的力气模拟了这种机制）。
10.Toward a Proposal for Object Templates in C++0x；让对象也模板化，很有创意，当然也有实际需求。不知道这种比较“另类”的提案最终会怎么样。
可以看出，在未来的未来，人们对C++的要求从扩展和强化编程技术，回到增强语言的交互能力上。其中最主要的是module、dll和reflection。其他基本上就是对C++的一些修修补补。
当然，也可能在C++0x出台之后，石破天惊，冒出一些新的技术来，就像concept那样。不过总体上而言，C++0x已经够先进的了，也应该回过头来，还上一些陈年旧账了。
[解决办法]
的确，其中有N多期待已久的东西加入：
有了可变长template参数，loki::typelist 再见了
concept不用说了，从stl-> boost-> 现在，期待不是一会会了～
Template aliases for C++(AA好像还叫它template typedef呵呵)繁杂的adaptor定义可以收编了
rvalue reference实现完美的move语义转发，哦，太好了～
Decltype呵呵，还有叫typeof()的，范性之福啊
nullptr和init list也是听BS说了很久了，看到
vector <int> v = {1,2,3,4};的语法就令人激动
foreach关键字终于，终于，
LAMBDA,GC哎，等了那么久终于快要看到你们的
[解决办法]
如果从实践的需求中抽象不出来理念，就不能作为提案。一个提案被通过，不会因为某个特殊应用的需求，而是因为这个提案所提炼的理念是合理的。
我相信每个语言背后都有自己的哲学。
我不关心“做完”和“做好”，每个人对这两个词理解不同，我觉得没有多大区别。
我只是不同意把“消除重复代码，建立更严谨、更不易出错的代码”这个程序员的问题强加成C++的限制.
STL这种东西，虽然有时也会用，但每次用的时候都有些迷失，感觉就想用C写OO的代码一样，在构建的时候常常摸不着概念。有时我都会觉得STL都不应该是C++语言的一部分，所以看到STL的修修补补我就反感.....
[解决办法]
“有时我都会觉得STL都不应该是C++语言的一部分”
那，C标准库函数是不是也不应该是C语言的一部分？
