睁开眼看大神们的C++11

1、首先有个C11和有个C++11。。但是我还是没弄懂他们之前的区别。

2、本文主要讨论新增的变化中比较有争议性的部分。

3、C++存在的意义：有运行效率和开发效率的平衡性是接近最理想的，如果哪天出现了一门运行效率和开发效率总评估值超过C plus plus的语言，那CPP得进入历史的垃圾桶。

争议1：初始化列表方式，强制提升编码人员的素养

这种初始化方式怎么觉得是从脚本语言这边学习过来的，之前我在工作遇到同事用table写的的组件时他初始化的方式就是用这种大括号加内部赋值的形式调用的。细节不同，但是思想是一致的。

自定义的类要求重载[]、=操作才能支持C++11提供的初始化列表方式初始化，同时即要求自定义对象有无形参的构造函数（可以是隐式合成的）。 这样子初始化的方式分别调用了无参构造函数、[]下标重载函数、=赋值操作函数，之后或再调用赋值构造函数、普通构造函数等完成init行为。整体而言，效率不高，但是完成了接口的适应性。记住接口、库这两个词，感觉是这次C++11更新的核心目标之一。实际使用中，根据情况定义其他构造方法，这样子其他人实例化这个对象的才能直接通过构造函数的提示完成传参，而不是去阅读库或被调用模块的源码。简单点理解：写组件给别人使用时，要有接口说明，不要强迫别人去阅读你的实现代码才能使用之。

然而在注释和命名规范中，有一条是：用命名去代替注释。似乎这初始化列表构造和它是天敌，因为自定义类支持初始化列表方式意味着无处可命名，都是必要环节都是重载。库或组件的作者必须在其他地方注释，这样子将会要求C++编码人员有比较好的编程风格，意味着同事间的代码风格有一定类似，分分钟会导致工作者有负面情绪：who had written these codes。虽然{}方式增加检测类型窄化检测，提供了更加合理类型匹配，但是这一个设计仍将会具有争议性。

争议2：auto/decltype  这对组合是把双刃剑

这两个关键字将会增加了代码的不确定性，或者说降低可读性吧。原则上，能用基础类型和自定义类型声明的数据，尽量不要使用auto，一旦使用auto，等于该数据的类型范围被泛化了，只能使用decltype来锁定。但是这个组合有个很明显的优越性，使用库或者其他模块交互时，auto因为有自推断能力，从而匹配数据来源，降低了库或其他模块代码更新引发的编译时或运行时错误，增强了代码的向后兼容性。

而仅自己使用的局部代码除非必要，应该很少使用auto类型，可读性很差，比如某些开源的库代码，大家懂的。

争议3：lambda。

std::for_each(
    Q.m_pHead,Q.m_pTail,
    [=](QueueItem<Type> i)
    {
       this->push_back(i.item);
    }
)

双手点赞，真的很实用。代码风格开始和其他java或者Python这些趋同啦。跟仿函数的思想类似，主要用于局部匿名数据操作，只要注意参数的传递问题，其开发效率极高，具体的实现方式目前还没挖到，敬请期待。可以当他是可为实参的手写inline函数对象，这样子理解之后，思维顺畅了，再去认真补补它真正地设计思维，工作代码升级无压力。

争议4：线程的引入。这块我没啃完呢。至于final/overide、assert_static、智能指针优化之类，很早前就有类似的实现库，并且被大家所接受啦，C++必须与时俱进。