对比C++11，C++14改变比较大的有
Concept-lite
模板lambda表达式
函数返回decltype(auto)
第一个是给写库用的那些对模板不熟悉的可以直接跳过，对于熟悉模板的人来说，Concept-lite对于用户唯一的好处估计就是错误信息比较容易看懂了。因为只是lite，所以其实没太大用处。
模板lambda表达式可以让你少写巨长无比的类型，decltype(auto)也是
C++ 读C加加 C++是在C语言的基础上开发的一种通用编程语言，应用广泛。C++支持多种编程范式 －－面向对象编程、泛型编程和过程化编程。
第一个是Return type deduction for normal functions，参考链接是：Return type deduction for normal functions
这一个提案其实在C++11的时候就提到了，但是由于当时投票的时候时间已经不够了，这个提案也就顺延了。这个提案的意义是加强了auto，如在函数上，可以不像11那样，需要一个Trailing Return Type了。
举个例子吧
在11中，你需要这样:
auto f(int a, int b) -> decltype( a + b )
{
int i = a + b;
return i;
}
int main()
{
std::cout << f(1,2) << std::endl;
return 0;
}
然而在这个提案中，你就可以这样了
auto f(int a, int b)
{
int i = a + b;
return i;
}
int main()
{
std::cout << f(1,2) << std::endl;
return 0;
}
也就是说，可以不要那个“尾巴”了。
而且在这个提案中，auto也可以用在模板中了，具体可以看提案。
而对于这个提案，我们只在一个地方有疑问：
auto sum(int i) {
if (i == 1)
return i; // return type deduced to int
else
return sum(i-1)+i; // ok to call it now
}
这里，的确是这样的。但是我们当时提出了一个疑问，如果我这里的return statement是这样的
auto sum(int i) {
if (i == 1)
return i; // return type deduced to int
else
return sum(i-1)+i + 0.0; // 这样怎么办呢？
}
可能会说自动提升，但是这里的提案说应该deduce to int，是根据这里的i来判定的，但是我这里加了0.0后，一切就变了。这一个当时我们给了C++标准委员会的Michael Wong，不过很遗憾，我后面走了，不知道答复是什么。
另外一个是：Heterogeneous lookup in associative containers。 链接是：http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3465.pdf
这是一个有关Library的改进，是一个如果你没有熟悉STL，绝对想不到竟然没有的东西，因为我在拿到这个提案的时候，潜意识就是觉得以前竟然没有？
简单的来说，由于map等关联容器的内部数据结构和vector这样的不一样，所以你可以发现find等，在map中你是有对应的map成员函数来保证的，因为是平衡树的查找，可以保证是log级别的复杂度。在这篇提案前，有一个函数方法叫equal_range，而对于这个查找匹配元素，以前的map等关联容器只接受一个Key，而没有自定义的比较函数。那么如果没有内置的operator < 支持的话，你就只能使用std::equal_range来做了，但是很显然这个复杂度比log级别的要高，所以这篇提案就建议为关联容器的equal_range加上自定义比较函数的参数了，而自定义比较函数需要满足的条件是：strict weak orderings。这个就是那什么if ( x < y ) { return true;} if ( y < x ) {return false;}那一套，这个请参考C++标准库那本书相关的介绍，肯定有这个说明。
这里面，还有一个提案是：make_unique。链接是：ISO/IEC JTC1/SC22/WG21
N3656
顺便推荐一下，我原来经常看这篇提案的作者，来自微软的Stephan T. Lavavej，在Channel 9的一套很不错的关于STL的视频，我受益匪浅。这篇提案没有多少好说的了，C++11没有加进去，又是让人觉得匪夷所思，我们有了std::shared_ptr和std::make_shared，那么有了std::unique_ptr，为什么没有make_unique呢？
我负责看以及与同事分享的还有一篇提案：关于字符串Literal的值的。链接为：http://www.open-std.org/JTC1/sc22/WG21/docs/papers/2013/n3642.pdf 这篇提案没有特殊之处，主要是可以加入ms, s等东西，而对于这篇提案，我曾经提过一个反馈意见，为什么不更加精确到皮秒，这对于一些科学研究来说，是需要这么精确的。
最后说一篇不是我负责的，但是引起了我们激烈讨论的一篇提案：放松constexpr的限定。链接为：Relaxing constraints on constexpr functions
这篇提案可谓是深得标准委员会人员的心，不可否认，这篇提案对于普通开发人员无疑是福音，因为可以再次提高性能。但是对于编译器开发人员简直是噩梦的一篇提案。说实话，在C++11的所有特性中，constexpr绝对是一个很难实现的特性，我不能透露ibm编译器如何实现的，感兴趣的可以去参看GCC或者Clang的实现。直到现在，Visual C++的实现constexpr都是Partial的状态。众所周至，constexpr有一些限定，比如只能返回一条语句等，即使这样，编译器做起来都是很头痛的一件事情。这篇提案简直逆天了，要去掉这些条件，还可以加入if，for什么的了，，具体的可以参看提案内容。我只能说简直丧心病狂，完全不管编译器开发者的死活。当时我们激烈讨论了到底怎么实现的，但是也没有讨论出来什么。但就是这篇提案，标准委员会举双手双脚赞成，而且还说有实现的先例：D语言。我也不知道该说什么了。
其余还有一些比如泛型Lambda等，我这里就没有提了，因为我没有看这些提案，我就不说了。
最后总结一下就是，C++14可以称为更加完美的C++11，这是我的观点。我觉得这些提案本就应该在C++11出现，但是却由于各种因素才拖到C++14中了。 C++的确变得更加复杂了，但是对于今天学习C++的人来说是更幸福的，少了很多奇淫技巧，多了更多照顾开发者的东西。
======================2015年7月15日更新==============================
似乎这个一年前写的答案又被翻出来了，然后我就补一下去年留下的那个疑问的回复。
auto sum(int i) {
if (i == 1)
return i; // return type deduced to int
else
return sum(i-1)+i + 0.0; // 这样怎么办呢？
}
对于这个，是不允许的，编译器会报错，不会类型转换。
内容全部来源于网络收集，如有侵权，请联系网站删除：QQ号：24596024