Understanding C++11 - Analysis and Application of New Features

C++11/14新特性尝试的一些代码及工程集合, 测试代码主要来源于《深入理解C++11 - C++11新特性解析与应用》.
其实蛮多很细节的新特性, 如User Defined Literal, Unrestricted Union等, 看起来就会很少使用, 未必需要全部掌握, 但至少应熟悉下, 不至于看到类似代码都完全摸不着头脑.

阅读与运行

Windows: 可通过cc_test.sln(VS2015)打开所有的工程及代码, 选择某个工程进行编译及运行即可.

Linux:

编译生成libcomm.so, 并创建软链接

 cd src_comm/
 g++ [-m32] -std=c++11 -fPIC -shared -Wl,-soname,libcomm.so.0 comm_tools.cc -o libcomm.so.0.0.1  
 sudo ln -s <absolute_path>/src_comm/libcomm.so.0.0.1 /usr/local/lib/libcomm.so.0  
 cd ..

编译生成待运行代码, 并运行即可

 g++ [-m32] -std=c++11 -I../src_comm/ xxx.cc -lpthread -lcomm    
 ./a.out

MacOSX
- (注: MacOSX上暂未创建XCode工程, 直接命令行编译运行)
- MacOSX上的动态链接方式有所区别, 有空研究下再做成.so/dylib, 目前libcomm先直接源码编译
```
 clang++ [-m32] -std=c++11 -I../src_comm/ ../src_comm/comm_tools.cc xxx.cc   
```

实验平台

Windows: Win10 64bit, Visual Studio 2015 Update 3
Linux: CentOS7 64bit, Kernel 3.10.0-229.el7.x86_64, gcc 4.8.5 20150623
MacOSX: MacBook Air (13-inch, Early 2015), OSX Version 10.11.6 (15G1217), Apple LLVM version 8.0.0 (clang-800.0.42.1)

实验

src_comm, src_comm_unittest

提供了一些通用/公用的头文件include, macro等, 方便使用, 同时提供了CC11Printf的实现及简单的unittest/sample实现.

comm_include.h
通用的头文件include, macro等, 同时提供了CC11Printf的导出及变长模板实现(参考 variadic_template 项目).
comm_tools.cc
提供了仅format参数版本的CC11Print的实现, 以供模板最终调用.
main.cc
sample code.

marco_test

确认下各个编译器下新的宏的一些定义与使用. 如__cplusplus, 理论上支持C++11的编译器值至少应是201103L. 原C++98/03的此宏定义值为199711L.

macro_check.cc
代码文件, 编译时不支持C++11则编译报错. 打印__cplusplus宏的值, STDC相关的几个宏, __VA_ARGS__宏用法, __func__宏等.
Windows上测试通过cc_test.sln打开后选择marco_test为启动项目, 编译运行即可.
Linux/MacOSX上测试
[g++|clang++] -m32 -std=c++11 macro_check.cc
./a.out
关于__cplusplus值在各平台编译器上的定义结论
- VS2015: 仍然为199711L, 而不是201103L. 看网上有人说可能是因为还未完全支持C++11特性, 所以微软还没有去修改此值. 故在使用Visual Studio时建议通过_MSC_VER宏来区分.
  - //MSVC++ 14.0 _MSC_VER == 1900 (Visual Studio 2015)
  - //MSVC++ 12.0 _MSC_VER == 1800 (Visual Studio 2013)
  - //MSVC++ 11.0 _MSC_VER == 1700 (Visual Studio 2012)
  - //MSVC++ 10.0 _MSC_VER == 1600 (Visual Studio 2010)
  - //MSVC++ 9.0 _MSC_VER == 1500 (Visual Studio 2008)
  - //MSVC++ 8.0 _MSC_VER == 1400 (Visual Studio 2005)
  - //MSVC++ 7.1 _MSC_VER == 1310 (Visual Studio 2003)
  - //MSVC++ 7.0 _MSC_VER == 1300
  - //MSVC++ 6.0 _MSC_VER == 1200
  - //MSVC++ 5.0 _MSC_VER == 1100
- GCC/clang: 201103L, 测试版本 gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-4) on CentOS7, clang-800.0.42.1 on OSX 10.11.6.

static_assert_test

静态断言的使用尝试, 分别应用于了枚举值的检查及模板函数中的长度检查.

static_assert_test.cc
代码文件, 断言错误则编译时报错, 并输出错误信息.
小技巧
可以调用无关的断言检查, 应独立于调用外面, 以增强代码的可读性.
BOOST中提供的一份可在C++98使用的静态断言实现
主要问题:
- 不能显示的提示错误位置和内容
- 不能独立写在调用代码外面, 必须写在调用里面
其他
- 使用静态断言时, 应注意表达式只能为常量表达式, 因为需要在编译时推导出结果

noexcept_test

新增关键字noexcept用法的尝试.

noexcept_test.cc
代码文件, 包含两个TestCase及noexcept作为操作符时的用法示例.
NOTE
- 断言适用于排除逻辑上不可能存在的状态, 异常则通常适用于可能发生的错误;
- noexcept关键字作为修饰符时, 用于指定函数是否可能会抛出异常; 作为操作符时, 则用于判断表达式是否可能会抛出异常, 多用于模板中;
- C++98中的throw()被noexcept替代, 显示指定抛出异常的类型throw(type 1, ...)则已在C++11中废弃;
- delete/delete[]/析构函数默认都是不抛出异常的, 以阻止异常扩散;
- 声明为noexcept的函数, 若抛出了异常, 则程序直接调用std::terminate()以暴力结束进程.

in-class initialization test

C++11中更强大的“就地”声明/初始化.

inclass_initialization_test.cc
代码文件, =, {}的简单用法.
NOTE
- C++98仅支持静态整型/枚举型常量成员变量的就地初始化;
- C++11可支持非静态的成员变量的就地初始化, 同时支持=,{}两种形式;
- 关于静态成员变量的默认初始化, C++11与C++98一致, 均需要在头文件以外进行初始化, 以保证实现的唯一性.

sizeof_test

C++11中对sizeof操作符的扩展, 可支持直接取非静态成员变量的长度.

sizeof_test.cc
代码文件, 包含C++11中的新用法, 及之前编译器版本的技巧性方法.

friend_test

C++11中friend关键字用法的变化, 可扩展支持模板类的friend声明.

friend_test.cc
代码文件, 模板进行friend声明的示例, 编译运行时加上UNIT_TEST宏以观察效果.
using起别名(也是C++11中的一个新特性)
using Defender = DefenderT<int>
等同于
typedef DefenderT<int> Defender

inherit_constructor

C++11中使用using声明来允许派生类对象直接使用基类的函数及成员. 包括普通函数/构造函数等.

inherit_constructor_test.cc
代码文件, 多个TestCase尝试了using继承的使用, 及从多个基类进行派生时冲突的解决.
NOTE
- 继承时函数重名则重载
- 函数的默认参数不会被继承, 而是根据可能的调用情况, 继承所有的可能调用形式
- 从多个基类进行派生时, 若冲突则应显式定义冲突的构造函数以解决, 且指定调用基类的构造函数的版本, 否则总是会调用基类的默认构造函数
- 从多个基类进行派生时, 总是根据继承顺序来决定调用基类构造函数的顺序, 而与using声明甚至显式指定调用构造函数的顺序无关

delegating_constructor

C++11中的委托构造方法示例, 非常方便的用法.

delegating_constructor_test.cc
代码文件, 典型的委托构造用法, 及一个简单的用模板构造函数作为target contructor的示例.
Note
- 委托构造与列表初始化不能同时使用

rvalue_reference

C++11中的右值引用与移动语义.

main.cc, UnitTest.cc/h
测试代码的入口与框架.
HasPtrMem.cc/h, Copyable.cc/h, Moveable.cc/h
带有指针成员的类, 实现其拷贝构造/移动构造的代码, 包含移动构造的语义传递.
perfect_forwarding.cc/h
完美转发的简单实验, 主要为模板中的使用.
关键点
- 我理解的构造语义的触发条件: 使用右值对象/右值引用构造另外一个对象
- 对应的, 我理解的拷贝构造语义的触发条件: 使用左值对象/左值引用构造另外一个对象
- 通常的左/右值判断方法
  - 左值(lvalue): 方法1, =左边即为左值; 方法2, 可以取地址、有名字则为左值
  - 右值(rvalue): 方法1, =右边即为右值; 方法2, 不能取地址、没有名字则为右值
- C++11中的三种值(所有的值均属于这三者之一)
  - 纯右值(pure rvalue): 1) 临时变量 2) 不与对象关联的值
  - 将亡值(expiring rvalue): 将要被移动的对象
  - 左值(lvalue): 剩余的其他值均属于左值
- 对右值的引用会加上其生命周期, 与引用名一致
- 引用类型:
  - 左值引用(T&)、常量左值引用(const T&)、右值引用(T&&)、常量右值引用(const T&&)
  - const T& 左值引用为一个万能引用类型, 可以引用任意一种引用类型
  - 注意: 右值引用(rvalue reference) 本身是一个左值
- std::move 强制转换一个左值为右值引用, 以触发移动语义
- 拷贝构造函数、移动构造函数应分别根据是否需要拷贝语义、移动语义进行提供, 一般仅具有移动语义的成员变量通常为资源型, 由于不能复制
- 拷贝构造函数通常应提供参数为 const T& 的版本, 更通用
- std::move/std::forward/static_cast<T&&>基本等同, 但建议在触发移动语义时使用move, 完美转发时采用forward, 按照标准库建议的方式
- C++11的引用折叠规则(参考 3.3.6 完美转发 perfect forwarding)
其他
- VS2015不支持关闭Return Value Optimize, 而此优化对本实验的影响很大, 故主要使用GCC/clang进行实验
- GCC/clang编译命令(打开or关闭HAS_MOVE_CONSTRUCTOR宏进行拷贝构造/移动构造的区别实验)
  [g++|clang++] -std=c++11 -I../src_comm/ [-DHAS_MOVE_CONSTRUCTOR] -fno-elide-constructors HasPtrMem.cc UnitTest.cc Copyable.cc Moveable.cc perfect_forwarding.cc main.cc
- 可使用is_reference/is_lvalue_reference/is_rvalue_reference等几个小工具判断是何种引用类型(UnitTest.cc->TestCase3())
- 可使用is_move_constructible等几个小工具判断是否有移动语义(UnitTest.cc->TestCase8())

pod_test

C++中的POD概念(Plain Old Data)的理解, 包括Trivial和Standard Layout两个子概念, 示例代码.

pod_test_types.h
各种示例的Trivial, Standard Layout, POD类型的定义, 主要来源于书上.
main.cc
入口及对各种定义的类型的判断示例.
关键点
- C++11中的POD类型, 需同时满足Trivial和Standard Layout两个条件
- POD的主要意义为
  - 与C的互操作性(兼容性), 可字节赋值, 可安全地使用memset/memcpy等操作之
  - 可安全的静态初始化
- 类型是否为Trivial的判断条件
  - 对于默认构造函数(无参数构造函数), 拷贝构造函数, 移动构造函数, 析构函数, 拷贝赋值运算符, 移动赋值运算符而言,
    - 要么未显式定义(由编译器自动生成默认的版本)
    - 要么显式定义但加上=default关键字(参考后续的第七章讲述)
  - 不能包含虚函数及虚基类
  - 注: 定义了有参数的构造函数不影响是否Trivial的判断, 但会使编译器不再生成无参数的版本, 故需要显式定义并加上=default关键字.
- 类型是否为Standard Layout的判断条件
  - 所有非静态成员需要有相同的访问权限(public, private, protected)
  - 满足下面两个条件之一(我自己的翻译)
    - 最多派生程度的类(也即最后的派生类)没有非静态成员, 并且最多一个基类有非静态成员
    - 或者没有基类有非静态成员(也即派生类可以有非静态成员了)
    摘抄下标准的英文原文:
    either has no non-static data members in the most derived class and at most one base class with non-static data memembers, or has no base classes with non-static data members
    
    (关于这段英文中"in the most derived class"的解释: most修饰derived class, 表示最高级的意思, 也即字面意思为最高级的衍生类)
  - 类中的第一个非静态成员的类型与基类不同
  - 没有虚函数和虚基类
  - 递归定义: 所有非静态数据成员均为符合Standard Layout的类型, 其基类也符合Standard Layout
- 可通过std::is_trivial<T>, std::is_standard_layout<T>, std::is_pod<T>这几个模板来进行是否的判断

explicit_test

explicit关键字使用尝试的示例.

main.cc
入口及示例代码.
关键点
- explicit关键字用于禁止隐式类型转换
- explicit只对一个实参的构造函数有效. 需要多个实参的构造函数不能用于执行隐式转换, 所以无须将这些构造函数指定为explicit的. (摘自《C++ Primer 5th》 P.265)
- explicit只能在类内声明时使用
- C++11中explicit关键字同时扩展到了自定义的类型转换操作符上, 以支持所谓的“显式类型转换”.

initializer_list

initializer_list的使用尝试的示例, 包括使用列表初始化普通变量、容器类等, 以及使用initializer_list<T>使自定义类型支持列表初始化, 列表初始化在Narrowing(类型收窄)时的表现等.

main.cc
入口及Test Case代码, 同时包括以intializer_list<T>作为函数参数/返回值等.
ILMyData.cc/h, ILPeople.cc/h
自定义类型基于initializer_list<T>来支持列表初始化, 并与操作符重载([]/=)组合后的所见即所得的初始化方式.
关键点
- initializer_list可用于普通变量初始化/容器类型初始化/自定义类型初始化等;
- C++11中的几种初始化方式:
  - =加上赋值表达式, 如 int a = 3 + 4;
  - =加上花括号(列表初始化), 如int a = {3 + 4};
  - 圆括号, 如int a = (3 + 4);
  - 花括号(列表初始化), 如int a {3 + 4};
    其中后两种方式可用于堆内存上的初始化, 如int * b = new int(10); double* d = new double {1.2f};
- 自定义类型/函数参数/函数返回值支持列表初始化的方式:
  (C++11内部的STL支持列表初始化也是采用的这个方法)
  include <intializer_list>, 然后定义一个 initializer_list<T> 作为参数的函数/构造函数或作为返回值的函数
- initializer_list列表初始化方法与其他初始化方式相比的重要优势: 防止类型收窄
  - 类型收窄(Narrowing)的含义: 简单理解即初始化变量时会丢失精度/表达不完整
  - 如何防止类型收窄: 原编译器通常会报warning, 而在C++11中采用列表初始化, 则编译器将报error, 以更好的保证安全性. (注: 实测下来, vs2015/clang报错了，但GCC并没有...)

Unresricted_Union

C++11中对于Union使用的扩展, 包括可支持非POD类型成员, 可支持静态成员函数(仅非匿名Union)等.

main.cc
入口及测试代码, 尝试了Unrestricted_Union的用法, 及验证了初始化时的一些行为.
关键点
- Unrestricted_Union可支持非POD类型成员, 在非匿名时同时可支持静态成员函数;
- Unrestricted_Union的初始化行为, 如T t = {0}时, 默认类似于memset(&t, 0, sizeof(t)), 但若T t = {1}时, 默认行为为初始化t第一个成员, 其他成员相当于未初始化. 使用时需要注意;
- Unrestricted_Union含有非POD类型成员时, 默认构造函数会被移除, 需通过placement new的方式显式定义构造函数;
其他
- 在静态成员的支持上, 不同编译器又有所不同. GCC与标准一致, 不能有静态成员变量, 仅支持静态成员函数, 但vs2015和clang++可以支持const static的静态成员变量..

user_defined_literal

C++11中允许用户自定义字面量的方便用法尝试.

main.cc
入口及测试代码.
关键点
- C++11中支持用户自定义Literal的方式, 是定义其Literal函数;
- Literal函数的形参可支持整型(仅unsigned long long), 浮点数(仅long double), const char*, char四种;
  - 整型和浮点型若实参超过了unsigned long long/long double的表示范围, 则会自动调用const char*版本;
  - 形参为const char*的函数, 参数表还会自带一个size, 由编译器自动解析填入;
- 杂项
  - Literal函数声明时""与_C之间需要有空格(实验下来vs2015/clang++无所谓, 但GCC要求有);
  - 一般建议以下划线开始为后缀, 以免与内置的如L/LL/f等后缀冲突;

inline_namespace

C++11中inline namespace的用法示例, 及ADL(Argument-Dependent name lookup)的行为示例.

main.cc
入口及示例代码.
关键点
- C++11中新增的inline namespace, 允许了父namespace中直接访问inline namespace中的内容, 不必再展开/加前缀;
- C++11中允许直接在父namespace中定义/特化模板;
- 关于ADL(Argument-Dependent name lookup), 即调用函数时若在已知namespace找不到, 则会去参数的namespace中搜索; 实际会破坏封装性, 应慎用之. 但应了解下, 以便看到类似代码时能了解其原理.

using_alias

C++11中可以使用using起别名且支持模板别名的示例.

main.cc
入口及示例代码.
关键点
- using和typedef起别名没有本质区别, 但using可支持模板别名而typedef不支持, 也即using更加灵活些
- 可以使用is_same<T1, T2>模板判断两个类型是否相同

SFIENA

C++11中对SFIENA(Subsitution failure is not an error)规则进行了进一步的描述, 尝试试用.

main.cc
入口及示例代码.
杂项
- 某种意义上来讲, SFIENA有点类似于模板函数的重载;
- 具体的SFIENA规则在C++11中细化了什么, 其实没太理解...遗留下, 有些经验后再回顾..

auto_decltype

C++11中auto和decltype关键字的使用及限制, 及auto与decltype组合使用追踪/推导返回类型的用法.

main.cc
入口及使用示例代码.
静态类型语言与动态类型语言的区分
- 简单的区分
  - 定义时不需要关注类型, 则为动态
  - 定义时必须要显式指明类型, 则为静态
- 严谨些的定义
  - 运行时进行类型检查, 则为动态
  - 编译时进行类型检查, 则为静态
auto的一些使用细则
1. auto与*,&的使用
  - 若想定义指针类型, auto*等同于auto
  - 若想定义引用类型, 必须显式auto&
2. auto与cv(const, volatile)的使用
  - auto定义默认不会带右值的cv属性, 除非定义的是引用或者指针
    (遗留问题: 貌似还没了解到可直接判断变量是否具有cv属性的方法? 故无法验证? 此问题也不太影响应用, 留待有机会验证)
3. auto一行定义多个变量时
  - 从左至右推导, 实际仅第一个变量的类型是有auto推导出来的
4. 标准/编译器对auto使用的4个限制
  - auto不能用于形参
  - auto不能用于非静态成员变量
  - auto不能用于数组
  - auto不能用于模板实例化参数
decltype与auto的主要异同
- decltype通过表达式推导, 而auto通过赋值推导;
- decltype能够带走cv限制符(对象的成员不会继承), 而auto不能
- decltype可直接推导出引用类型, 而auto必须显式使用auto&定义引用类型
- 冗余的&, *等两者都会忽略
decltype的推导规则 decltype(e)
- 如果e是一个没有带括号的标记符表达式(id-expression)或者类成员访问表达式, 那么decltype(e)就是e所命名的实体类型; 若e是一个被重载的函数, 则会导致编译器错误;
- 否则, 假设e的类型是T, 如果e是一个将亡值, 那么decltype(e)为T&&;
- 否则, 假设e的类型是T, 如果e是一个左值, 则decltype(e)为T&;
- 否则, 假设e的类型是T, 则decltype(e)为T.
decltype的应用
- decltype与auto一起使用, 追踪/推导返回类型
- 与typedef/using一起使用, 为推导出的类型起别名
- 重用匿名类型(不推荐的应用方式)
杂项
- typeid(x).name()输出的类型名, g++/clang++编译时输出的是类型的简写形式, 诸如i/d/l/f/Pi/..., 需要通过c++flit -t <类型简写>来还原原始类型名称, 示例诸如:
- typeid(x).name()输出的类型名, vs2015输出的是完整的类型名, 更方便直接查看.
- RTTI机制
  - 即typeid()所返回的信息，实际对应type_info数据, 可在运行时获得;
  - 此机制有一定的运行时开销, 理论上编译器允许关闭(如GCC的-fno-rttion选项, 虽然我的实验平台上不支持)
- 关于typeof
  - 此为GCC编译器的扩展, 而非语言特性; C++11中使用auto和decltype可完全替代之;

range_for

C++11中基于范围的for的用法.

main.cc
入口及示例代码.
可用的前提条件
- 迭代的范围必须是可确定的
  - 若是数组, 必须长度已知, 第一个元素和最后一个元素中间的范围即为迭代范围
  - 若是类, 需要有begin()和end(), begin()和end()中间的范围即为迭代范围
- 迭代的对象必须支持++, ==等操作符
  - STL中的容器都是支持的
  - 用户自定义类, 需要提供这些操作符的实现
注意事项
- 若迭代需要修改内容, 则声明迭代对象时应声明为引用类型
- 使用auto声明迭代对象, 此变量不会是迭代器, 而是迭代器解引用后的值
for_each
- 模板库中原本也有一个for_each的实现, 通过迭代调用外部处理函数来实现功能, 内部实际就是一个循环, 仅省去了程序员写for循环的动作, 貌似意义不大

strong_typed_enum

C++11中的强类型枚举的用法.

main.cc
入口及示例代码.
C++98中的enum的缺陷
- 类型名及成员名都是全局可见的, 属于非强作用域类型
- 会默认隐式转换为整型进行比较
- 占用存储空间及符号性不确定
C++11中的strong-typed enum的优势
- 强作用域, 成员名称不会输出到其父作用域空间
- 转换限制, 不会与整型隐式地相互转换
- 可以指定底层类型, 默认为int, 可以指定为除wchar_t外的所有整型
杂项
- 使用上enum class与enum struct没有任何区别
- 当程序中需要"数值的名字"的时候, 通常的三种实现方式
  - 宏
  - 枚举
  - 静态常量

intelligent_pointer_and_gc

C++11中的智能指针用法, 及垃圾回收相关的一些讨论.

main.cc
入口及示例代码.
C++11中的智能指针
- unique_ptr: 唯一地引用某个堆内存, 不能拷贝赋值给其他指针(即不能让其他指针同时引用), 可以move给其他unique_ptr
- shared_ptr: 可以多个指向同一块堆内存, 实现上采用引用计数的方式, 引用计数减为0时指向的内存会被析构
- weak_ptr: 可以指向shared_ptr引用的内存, 但不影响引用计数, 从而可以用来判断内存的有效性
  均可以调用reset()接口显式地标记指针不再引用内存
垃圾回收方法的分类
- 基于引用计数的垃圾回收器(reference counting garbage collector)
- 基于跟踪处理的垃圾回收器(tracing garbage collector)
  - 标记-清除(Mark-Sweep)
  - 标记-整理(Mark-Compact)
  - 标记-拷贝(Mark-Copy)
C++11对垃圾回收的支持
- C++11标准为最小垃圾回收定义了方法/接口, 但基本上编译器都未实现...仅做mark..
杂项
- C++98中的auto_ptr在C++11中废弃, 由上述三个指针替代之
- 可以使用get_pointer_safety()接口获取编译器是否支持最小垃圾回收, 但我的实验平台上GCC-4.8.5连这个接口都未支持, VS2015和clang++上可以获取出不支持最小垃圾回收..

constexpr

C++11中constexpr常量表达式/常量函数的用法, 可用于编译时常量的定义与计算.

main.cc
入口及示例代码.
const与constexpr的区别
- 通常情况下, const用于描述运行时常量, 而constexpr用于描述编译时常量(可编译时计算值).
- 以下两句通常没有区别, 但若cosntexpr修饰的变量没有被用到, 可能编译器并不会为其产生数据, 而const修饰的则总是会产生数据
  - const int i = 1;
  - constexpr int j = 1;
常量表达式函数的要求:　
- 函数体只有单一的return语句(不产生实际代码的语句可以不影响, 如static_assert/using/typedef等)
- 函数必须返回值(不能是void函数)
- 在使用前必须已有定义
- return返回语句表达式中不能使用非常量表达式的函数、全局数据, 且必须是一个常量表达式
constexpr用于自定义类型
- 需要自定义常量构造函数
  - 函数体必须为空
  - 初始化列表只能由常量表达式来赋值
- 常量性体现在类型上, 证据就是成员变量可供内部的常量函数使用
constexpr可以实现编译时期计算, 可完成类似于模板元编程的功能, 可编译时递归.

variadic_template

C++11中变长模板的讨论及示例.

main.cc
入口及示例代码.
关键点
- C++11中可支持变长模板, 包括变长类型模板与非类型模板, 具体实现上是采用变长参数包的方式进行封装, 编译时递归解包;
- 关于用途的初步认识, 可用于实现C++11 style 的printf, 类型安全;
- 可使用sizeof...获取变长参数包中的参数个数;
- TODO: 积累一定经验后再回顾进阶的内容...

quick_exit

C++11中新增的quick_exit, 理论上比exit更加快速退出, 因为不会去调用析构释放内存, 而直接丢给操作系统.

main.cc
入口及示例代码.
退出的几个函数对比: terminate/abort/exit/quick_exit
- terminate/abort: 异常退出
  - 通常terminate的实现是调用abort
  - `terminate通常在出现没有捕获的异常时调用
  - abort被调用时会有SIGABRT信号
- exit/quick_exit: 正常退出
  - 理论区别: exit会调用析构函数, quick_exit不会; 正常退出时操作系统会回收内存, 故若程序想要快速退出, 可以不去做显式的内存回收工作. 此即quick_exit的目标用途.
  - 实验结果: exit与quick_exit在vs2015和GCC下都没有调用析构, 所以可以认为没区别... 用clang++编译时没有找到quick_exit的支持

atomic

C++11中支持的原子类型, 及有关memory_order的使用示例.

main.cc
入口及示例代码.
关键点
- 互质的本质, 需要同步的总是数据而不是代码
- C++11已内置了一部分atomic类型, 也可以使用atomic<T>自定义(需删除拷贝构造、移动构造和拷贝赋值运算符)
- 关于特殊的atomic_flag类型: lock free, 仅有test_and_set与clear两种操作, 可用于实现自旋锁.
memory_order
- 保证代码顺序一致性的两点:
  - 编译器保证原子操作的指令间顺序不变
  - 处理器对原子操作的汇编指令的执行顺序不变(weak order处理器出于优化性能的考虑, 会打乱看似不影响的指令的执行顺序)
- C++11中memory_order七种枚举值
  - memory_order_relaxed: 不对执行顺序做任何保证
  - memory_order_acquire: 本线程中, 所有后续的读操作必须在本条原子操作完成后才能执行
  - memory_order_release: 本线程中, 所有之前的写操作完成后才能执行本条原子操作
  - memory_order_acq_rel: 同时包含memory_order_acquire和memory_order_release
  - memory_order_consume: 本线程中, 所有后续的有关本原子类型的操作, 必须在本条原子操作完成之后执行
  - memory_order_seq_cst: 全部存取都按顺序执行(默认值)
- 典型的4种内存顺序模型:
  - 顺序一致的
  - 松散的(relax)
  - release-acquire
  - release-consume
- 对于并行编程来说, 可能最根本的还是思考如何将大量计算的问题, 按需分解成多个独立的、能够同时运行的部分, 并找出真正需要在线程间共享的数据

thread_local_storage

C++11中对线程局部存储(TLS, thread local storage)的支持, 通过thread_local关键字.

main.cc
入口及示例代码.
杂项
- 原各编译器分别都自定义了TLS标准, 如g++/clang++/xlc++中的__thread;
- 在TLS中一个常常被讨论的问题: TLS变量的静态/动态分配问题, 即程序一开始分配还是线程开始运行时分配(标准并未强制规定);
- C++11对TLS仅做了语法上的统一, 并未做性能上的规定

nullptr

C++11中新增的nullptr关键字示例代码.

main.cc
入口及示例代码.
关键点
- nullptr主要解决的问题: 原NULL的二义性问题, 即是C++中的0or C中的(void*)0, 又表示指针, 重载时意义表达不清;
- nullptr的类型nullptr_t定义: typedef decltype(nullptr) nullptr_t, 通过类型推导的
- C++11标准定义的一些关于nullptr_t和nullptr的规则:
  - 所有的nullptr_t类型的数据都是等价的, 行为也完全一致;
  - nullptr_t类型的数据可以隐式地转换为任意一个指针类型;
  - nullptr_t类型数据不能转换为非指针类型, 即使使用reinterpret_cast<非指针类型>(nullptr_t)也是不可以的.(vs2015上是可以的, 啪啪打脸);
  - nullptr_t类型数据不适用于算术运算表达式(vs2015上是可以的, 啪啪打脸);
  - nullptr_t可以用于关系运算符表达式.
- 在模板的类型推导时, nullptr会被推导成T, 而不是T*; 若要推导成T*, 则需要显式(void*)nullptr;
- nullptr不支持取地址操作;
杂项
- (void*)0为C的用法, C++中并不支持

default_delete_control

C++11中的默认函数控制 =default,=delete的用法.

main.cc
入口及示例代码.
关键点
- =default: 显式定义默认的版本(让编译器自动生成实现)
- =delete: 显式删除默认的版本(指示编译器不要自动实现)
- explicit与=delete不要同时使用, 没有任何好处, 会带来问题

lambda

C++11中的lambda函数相关使用与讨论.

main.cc
入口及示例代码.
关键点
- lambda函数语法
  - capturemutable -> return-type {statement}
    - [capture] 捕获列表.
    - (parameters) 参数列表. 不需要传递则可省略.
    - mutable 修饰符, 默认情况下, lambda函数总是一个const函数, mutable可以取消其常量性. 使用此修饰符时参数列表不可省略(即使参数为空).
    - ->return-type 返回类型. 不需要返回值或返回值明确(可推导)时, 都可以省略.
    - {statement} 函数体.
- 捕捉列表(多个捕捉项时可以以逗号分隔)
  - [var] 表示值传递方式捕捉变量var
  - [=] 表示值传递方式捕捉所有父作用域的变量(包括this)
  - [&var] 表示引用传递方式捕捉变量var
  - [&] 表示引用传递方式捕捉所有父作用域的变量(包括this)
  - [this] 表示值传递方式捕捉当前的this指针
- 捕捉列表的值传递时机
  - 值传递方式捕捉变量, 值是在lambda函数定义时决定. 所以定义后修改值, 并不会影响lambda函数中看到的值.
  - 引用传递方式捕捉变量, 值是在lambda函数调用时决定.
- 与C++11中的lambda等价的是有常量operator()的仿函数. 此仿函数是编译器实现lambda函数的一种形式.
- lambda 并不是仿函数的完全替代者, 主要原因是捕捉列表的限制(标准规定仅能捕捉父作用域中的自动变量, 编译器通常会扩展一些)
- 使用lambda替代仿函数通常应满足的条件:
  - 是局限于一个局部作用域中使用的代码逻辑
  - 这些代码逻辑需要被作为参数传递
杂项
- lambda函数可以向具有同样原型的函数指针转换(不能有捕获变量), 反之不行.
- lambda与仿函数的共同内涵: 都具有初始状态, 同时接受参数进行计算.
- 居然没提供 const T& 的捕捉传递方式?!!

align

C++11中对对齐的支持示例.

main.cc
入口及示例代码.
关键点
- C++11中添加的两个关键字
  - alignof: 查看对齐方式(vs2015上不支持查看变量的对齐方式, G++上可以)
  - alignas: 设置对齐方式
- STL中的支持: align/align_storage/align_union
  - 这个没太完全理解, 有必要时再实验
杂项
- C中经常有些超长结构体需要对齐, 原来的典型做法是手动加入padding数据. 现在则可以使用对齐关键字/宏(C11中也有对应的支持).

attribute

C++11中支持的通用属性扩展.

main.cc
入口及示例代码.
关键点
- C++11中目前定义了两个属性, 以帮助编译器可做优化:
  - [[noreturn]]: 告知编译器此函数不会返回(如必然抛出异常、中断程序等)
  - [[carries_dependency]]: 可携带memory_order信息, 未深入研究, 需要时再研究
- 编译器对属性的一些扩展
  - GNUC: attribute (( attribute-list ))
    - 常用属性如 noreturn, format, const, aligned等
  - MSVC: __declspec(extended-decl-modifier)
    - 常用属性如 noreturn, oninline, align, dllimport, dllexport等

unicode

C++11中对Unicode的支持的一些扩展.

main.cc
入口及示例代码.
关键点
- C++11中引入的类型
  - char16_t: 用于存储utf-16编码的字符串,同时有对应的std::u16string
  - char32_t: 用于存储utf-32编码的字符串, 同时有对应的std::u32string
  - 原char类型: 用于存储utf-8的字符串, 同时有对应的std::string
- 前缀声明类型让编译器产生数据
  - u8: 表示字符串为utf-8编码, 如 u8"你好啊" 为utf-8字符串
  - u : 表示字符串为utf-16编码, 如 u"你好啊" 为utf-16字符串
  - U : 表示字符串为utf-32b编码, 如 U"你好啊" 为utf-32字符串
- 字符串中直接表示Unicode字符
  - \u加4个十六进制数: 表示一个UTF-16字符, 如\u4F60
  - \U加8个十六进制数: 表示一个UTF-32字符, 如\U0001d10b
- 对Unicode支持的影响因素
  - 语言
  - 源文件的保存格式
  - 编译过程
  - 输出设备(如Linux的Shell是否支持该编码类型的输出)
- UTF-8/16/32的应用
  - UTF-8为变长编码, 优势在于存储时节约空间, 但缺点是不能直接数组式的访问, 故不太适合在内存中操作(比如计算第N个元素的时间复杂度不再是O(1)). 定长的UTF-16和UTF-32则更适合在内存中操作.
  - 所以, 一般总是倾向于在I/O读写时采用UTF-8, 在内存中则采用UTF-16/32.

raw_string_literal

C++11中对原生字符串字面量的支持.

main.cc
入口及示例代码.
关键点
- C++11中支持raw_string_literal的格式
  - R"(内容)" : 示例R"(hello, \n world)"
  - 对Unicode支持的raw_string_literal, 可以使用u8R, uR, UR这几个前缀, 分别对应UTF-8, UTF-16, UTF-32编码

其他杂项

区分三个编译器的宏
- VS2015: _MSC_VER
- Clang: __clang__
- GCC: !defined(__clang__) && defined(__GUNC__)
- 注: Clang编译器覆盖了GNUC的宏, 故同时需要区分时, 对于GCC要确定没有定义__clang__

Reference Links

http://stackoverflow.com/questions/70013/how-to-detect-if-im-compiling-code-with-visual-studio-2008
http://en.cppreference.com/w/cpp/compiler_support
http://stackoverflow.com/questions/28166565/detect-gcc-as-opposed-to-msvc-clang-with-macro

Contacts

Author's Email: wangyoucao577@gmail.com.

Files

README.md

Latest commit

History