如何感觉c++11没多少新东西啊小弟我列出来大家看一看

2013-09-28

怎么感觉c++11没多少新东西啊，我列出来大家看一看模板相关的就不列出来了，可能对些基础库的人影响很大，但

怎么感觉c++11没多少新东西啊，我列出来大家看一看
模板相关的就不列出来了，可能对些基础库的人影响很大，但我们多数人只是使用模板，写模板的情况比较少，就列不涉及模板的。
1、右值引用：这个比较有用，在一些情况下可以减少一次内存拷贝，提高了效率。
2、泛化的常数表达式，更科学了，不是什么大的改动。
3、初始化形式的扩展：这个会带来一些方便
4、自动类型推导：不考虑模板的话，就是代码能看起来舒服一些
5、以范围为基础的for循环：早该有了，来得太晚，大家可能都用for each 了。
6、Lambda函数与表示式：也是千呼万唤，算一个实质性的改进
7、构造函数的改良：有意义的小改动
8、显示虚函数重载：可能有点用吧
9、空指针：无所谓了，大家都习惯NULL了。
10、强枚举类型：更规范些，有点用
11、变长参数模板：这个虽然涉及模板，但真的很有用，比如tuple那个例子。
12、无限制的union：有用，像是BUG修复
13、新的字符串常量表示法：还好
为什么不引入点函数式编程呢
元编程那些东西咱没搞过，那里才是模板最大的用武之地，所以模板的一些改动不是太清楚意义有多大
元编程什么时候成了模板最大的用武之地了？
一般人平时会用到的模版技术大都脱离不了c++ primer的范围
boost那种把模版用的出神入化的神技，懂是很好，不懂其实也没什么差
[解决办法]
核心语言特性我现在主要也就用这么多。自己对号入座吧。
C99 preprocessor(N1653) ；
Static assertions(N1720) ；
Right angle brackets(N1757) ；
long long(N1811) ；
Built-in type traits(N1836) ；
auto-typed variables(N1984) ；
Delegating constructors(N1986) ；
Extern templates(N1987) ；
Generalized constant expressions(N2235) ；
Variadic templates v0.9(N2242) ；
New character types(N2249) ；
Template aliases(N2258) ；
Declared type of an expression v1.0(N2343) ；
Defaulted and deleted functions(N2346) ；
Strongly-typed enums(N2347) ；
Null pointer constant(N2431) ；
Explicit conversion operators(N2437) ；
Unicode string literals(N2442) ；
Raw string literals(N2442) ；
Inline namespaces(N2535) ；
New function declaration syntax for deduced return types(N2541) ；
Initializer lists (N2672) ；
Non-static data member initializers (N2756) ；
Rvalue references v3.0(N3053) ；
Lambda expressions and closures v1.1(N2927) ；
Range-based for(N2930) ；
Converting Lambdas to Function Pointers(N3052) ；
Explicit virtual overrides v1.0(N3272) 。

[解决办法]

引用:

Quote: 引用:

Quote: 引用:

Quote: 引用:

Quote: 引用:

Quote: 引用:

lambda就够翻新的了，有了这东西STL的易用度飞快上升
如果有意思的话C++还能实现go关键字

我失望的是没有同步/异步方面的语言层面的扩展，莫非要靠基础库来增强？

谁说没有，你当std::thread, std::atomic, std::async这些东西是死的？
虽然还是缺不少更high level的api,不过这些基础设施够你设计出那些api了

我怀疑的是，即使我们的程序里几个线程之间完全不干扰，编译器能把它们分派到不同的CPU上去吗？现在多核编程呼声那么高，C++做不到的话，恐怕我们要被迫学一门新语言了。

多线程依赖操作系统,分配那个cpu,那个核执行,都是系统分配的。跟用那种语言无关。

我没做过多核编程，不过凭感觉不是这样吧，操作系统分配不同线程到不同的的核得有依据吧，有些线程公用很多内存还要互相等，分到多核上也意义不大，有些线程互相之间几乎不冲突，分到多核上就成倍提升速度，这都得编译器从源代码里才能知道吧。期待有懂的来介绍一下

分配不同线程到不同的核看底层实现。C++在这里暴露的接口根本不知道有什么“核”，相关点看来也就（不要求一定实现的）std::thread::hardware_concurrency()而已，更别提affinity什么的管理接口了。至于线程同步至少现在主要还是要得用户控制。

[解决办法]
再给你标注一下

引用:

核心语言特性我现在主要也就用这么多。自己对号入座吧。
C99 preprocessor(N1653) 不明觉厉。。。C专有方面的个人用得少，谁知道就补充点。。。；
Static assertions(N1720) static_assert()编译期报错，一方面省了固定检查式报错可以拿到编译时完成（提高性能的同时也不降低程序质量），另一方面使用自定义的报错能使得报错信息更有意义；

Right angle brackets(N1757) template<... something< ... >>不用再写成template<... something< ... > >才没有编译问题的这么麻烦了；
long long(N1811) 至少64位的大整数。同样是能让64位宽的数据可以原生的编译而不用再浪费掉了，而之前是用短数据模拟的，即使处理器原生支持也得不到好处；
Built-in type traits(N1836) 没什么解释的必要了。。；
auto-typed variables(N1984) 这东西方便、但是增加编译时间，同时在某些场合有潜在的不确定性，另一些场合必不可少（例如后置返回型函数模板里用做返回型）；
Delegating constructors(N1986) 可以在同一个类中允许构造函数间互相调用（但是前提是需要满足一些特殊规则），从而在某些地方实现降低设计难度开销、提高可读性；
Extern templates(N1987) 也是个提供方便的东东。。。；
Generalized constant expressions(N2235) 提高性能的东东（其实是减少没必要的运行时重复计算），谁还没想起来到底是什么？其实就是constexpr。。。；
Variadic templates v0.9(N2242) 模板的数学性递归问题需要的东东。没有支持的话会很蛋疼。。。；
New character types(N2249) 国际化大势所趋，光允许一个char类型做字符串使用，又老又破。。。；
Template aliases(N2258) 同样是增加可读性和降低设计难度的东西，而且还又增加了一种模板定义方式（谁不同意可再提问）；
Declared type of an expression v1.0(N2343) 暂时没什么好说的。。。；
Defaulted and deleted functions(N2346) 提高程序质量的东西。其实很有用，但是估计很多人根本不重视。。。；
Strongly-typed enums(N2347) 本来就该有的东西，static const成员常数的写法非常不规范，另一方面经典枚举类型本身的作用域和类型转换问题也确实不好；
Null pointer constant(N2431) 不光是写法不同于NULL，而且还是一种独立的数据类型（NULL不能和nullptr相提并论）；
Explicit conversion operators(N2437) 增加可能性的东西，但是没考虑清楚就用的话，就等着呵呵吧；
Unicode string literals(N2442) 国际化。。。；
Raw string literals(N2442) 。。。；
Inline namespaces(N2535) 又一个增加易用性的东西；
New function declaration syntax for deduced return types(N2541) 举棋不定啊。。。早干吗去了；
Initializer lists (N2672) 不管是看着还是用着都感到很无语。。但确实能解决一些以前解决不好的问题；
Non-static data member initializers (N2756) 也是暂时没什么好说的。。。；
Rvalue references v3.0(N3053) 必须的。。。也是早干吗去了的东西。。。；
Lambda expressions and closures v1.1(N2927) 有人说是Lisp，觉得更有用的地方其实还是设计代理和多线程相关的东西（只是就事论事的看法）。。。；
Range-based for(N2930) 看起来漂亮，却也是编译器反向依赖于标准库的东西；
Converting Lambdas to Function Pointers(N3052) 。。。；
Explicit virtual overrides v1.0(N3272) 其实还有一个final，后一个貌似对非virtual的场合也可以用。

其实还有decltype和多线程相关的东西，还有大量的模板（尤其是traits、stl类内存管理相关和智能指针相关的改进）
[解决办法]
多线程相关的东西不是谁的责任，而是所有的东西——操作系统、编译器和硬件都要互相配合着跟上的东西。
其实这次C++11对多线程的支持主要有两方面：
一个是增加了通用的多线程库，这样不用再在不同的系统架构上做不同的实现了，只需要通过共同的方式编写，而让那些具体实现由运行时库去完成转换。
另一个是修改编译器来适应多线程开发。早期的编译器存在优化和顺序调整问题，这样编译出来的代码在多线程共享数据的时候可能会出问题。比如


if(thread_lock == -1)
  return;
else
  ++thread_lock;

其中thread_lock是某个线程间共享变量。编译后却有可能是（伪代码）


++thread_lock;
if(thread_lock == 0)
{
  --thread_lock;
  return;
}

这样多线程环境下没法正常运行。
但是通过编译器修改成专门针对多线程共享数据的探测，编译器现在知道thread_lock会被不同的线程访问，就不再会对thread_lock做这种优化，同时其他地方的其他变量编译器仍然能使用传统的手段进行优化。
多线程库也需要告诉编译器某些数据不能简单的直接使用传统汇编方式生成代码而需要使用处理器同步相关的指令（这些没法通过给老式编译器仅仅附加一个线程库就可以解决的，一定也要修改编译器本身）。当然传统的同步对象方式就不需要编译器做任何改动了，只需要用库封装一下就好

热点排行