列表初始化
C++11:支持内置类型与自定义类型的列表初始化,其中自定义类型不是天然支持列表初始化,需要显示定义参数类型为initiaizer_list
的构造函数
1 | class A |
变量类型推导
- auto:编译时根据初始化表达式进行类型推导
- decltype:运行时类型识别,如果有参数列表,推导返回值类型,如果没有参数列表,只有函数名,推导为函数的接口类型
final与override
1 | class A final //不能被继承 |
默认成员函数控制
1 | class A |
右值引用
简单来说,左值:可以出现在=
的两边、或者可以取地址的
1 | int a = 1; |
右值:只能出现在=
的右边,或者不可以取地址(非绝对)
1 | 10 = 20; |
C++中的右值:
- 纯右值:常量、临时变量。
getA(A) = b; int* p = &(getA());
- 将亡值:声明周期即将结束的值
临时变量:函数以值返回的变量,调用类的构造函数创建的变量
- 左值引用:引用的实体既可以为左值,也可以为右值
1 | int& ra = a; |
- 右值引用
1 | int&& lr = 10; |
小结:
左值引用,右值引用的语法意义:都是变量的别名
左值引用:就可以引用左值,也可以引用右值,如果引用右值,需要为const左值引用
右值引用:引用右值
- 移动构造:参数类型为右值引用,提高拷贝的效率
- 相对于拷贝构造,可以实现浅拷贝的情况下,不产生错误
- 右值引用指向的实体一般是将亡值,可以直接获取右值引用所指向的实体资源,不需要深拷贝
- 移动赋值:参数类型为右值引用,也是浅拷贝,原理同上
move
:移动语义,将左值变为右值,使用时候需要注意保证属性被修改的左值在之后不会再用到
lambda表达式
[捕捉列表](参数列表)mutable->返回值类型{函数体}
- 捕捉列表(capture-list):在lambda函数的开始位置,编译器根据[]来判断接下来 的代码是否为lambda函数,捕捉列表能够捕捉上下文中的变量供lambda函数使用。
- 参数列表(parameters):与普通函数的参数列表一致,如果不需要参数传递,则可以连同()一起省略
- mutable:默认情况下,lambda函数总是一个const函数,mutable可以取消其常量性。使用该修饰符时,参数列表不可省略(即使参数为空)。
- 返回值类型(returntype):用追踪返回类型形式声明函数的返回值类型,没有返回值时此部分 可省略。返回值类型明确情况下,也可省略,由编译器对返回类型进行推导。
- 函数体(statement):在该函数体内,除了可以使用其参数外,还可以使用所有捕获到的变量。
1 | int a = 10; |
捕捉列表
- [var]:以值传递的方式捕捉变量var
- [=]:表示以值传递的方式捕捉父类作用域的所有变量
- [&]:表示以引用传递的方式捕捉父作用域的所有变量,如果是传引用形式,不需要mutable也可以修改捕捉列表中的变量
- [&var]:以引用传递的方式捕捉变量var
- [this]:以值传递方式捕捉当前的this指针
- 捕捉列表可以交叉使用
- 父类作用域不一定是直接父类作用域,嵌套的也可以
1 | int a = 1; |
lambda表达式不能相互赋值,但可以拷贝;可以吧lambda表达式赋给一个函数指针
1 | auto fun1 = [](int a, int b)->int{return a + b; }; |
线程库
头文件thread
函数名 | 功能 |
---|---|
thread | 构造一个线程对象,没有关联任何线程函数,即没有启动任何线程 |
thread(fun, args1, args2, …) | 构造一个线程对象,并关联线程函数fun,函数参数为args |
get_id() | 获取线程ID |
joinable() | 线程是否还在执行,joinable代表的是一个正在执行中的线程 |
join() | 该函数调用后会阻塞线程,当该函数结束后,主线程继续执行 |
detach() | 线程分离,把被创建的线程与线程对象分离 |
RAII:资源获取立即初始化,在构造函数中初始化资源,在析构函数中销毁资源
1 | class ThreadMange |
如果需要类的成员函数做线程函数,需要写完整的作用域,并且需要显示取地址,参数需要加上this所指的对象
1 | class B { |
如果函数参数类型为引用,在线程中需要修改原是变量,则需要听过ref转换
1 | void fun(int& a) |
原子性操作库(atomic)
1 | unsigned long sum = 0L; |
将一个变量声明为原子类型变量之后,不需要对该变量加互斥锁,线程也能够对该变量互斥访问,可以根据atomic
类模版,定义出需要的任意原子类型。
由于原子类型通常属于资源型数据,故在C++11中,标准库将拷贝构造,移动构造以及运算符重载默认置为delete
mutex
- mutex
try_lock:非阻塞加锁操作,如果其他线程没有释放当前锁,则直接返回加锁失败结果
lock:阻塞加锁操作,如果其他线程没有释放当前锁,阻塞等待,直到其他线程释放当前锁
unlock:解锁
- recursive_mutex:递归上锁,允许对互斥量进行多次上锁,但解锁需要调用与上锁相同的递归深度
- timed_mutex
- try_lock_for:接受一个时间范围,表示在这一段时间范围之内线程如果没有获得锁则被阻塞住(与 std::mutex 的 try_lock() 不同,try_lock 如果被调用时没有获得锁则直接返回 false),如果在此期间其他线程 释放了锁,则该线程可以获得对互斥量的锁,如果超时(即在指定时间内还是没有获得锁),则返 回 false。
- try_lock_until() :接受一个时间点作为参数,在指定时间点未到来之前线程如果没有获得锁则被阻塞住,如果在此期 间其他线程释放了锁,则该线程可以获得对互斥量的锁,如果超时(即在指定时间内还是没有获得 锁),则返回 false。
- recursive_timed_mutex
lock_guard
lock_guard类模版通过RAII的方式对其管理的互斥量进行了封装,在需要加锁的地方,使用任意一个互斥体实例化一个lock_guard,调用其构造函数即上锁,在出作用域前,lock_guard对象要被销毁,会调用其析构函数而自动解锁,可以有效避免死锁问题。
缺陷:太过单一,用户无法对该锁进行控制
unique_lock
相较于lock_guard有了更多的接口
上锁/解锁操作:lock、try_lock、try_lock_for、try_lock_until和unlock
修改操作:移动赋值、交换(swap:与另一个unique_lock对象互换所管理的互斥量所有权)、释放 (release:返回它所管理的互斥量对象的指针,并释放所有权)
获取属性:owns_lock(返回当前对象是否上了锁)、operator bool()(与owns_lock()的功能相同)、 mutex(返回当前unique_lock所管理的互斥量的指针)。
多线程安全
原子操作:指令不会被打断,线程安全操作,效率较高
atomic\
:把T类型数据封装成原子操作 加锁:通过多线程之间的加锁阻塞保证线程安全,效率较低,加锁解锁比较耗时(相对于原子操作)
mutex、recursive_mutex、timed_mutex、recursive_timed_mutex
lock:阻塞式加锁
unlock:解锁
try_lock:非阻塞式加锁
lock_guard、unique_lock:RAII实现,通过对象的生命周期控制锁的生命周期:
构造函数->加锁、析构函数->解锁
不支持拷贝操作
异常概念
- throw:当问题出现时,程序会抛出一个异常,通过throw关键字来完成
- catch:在想要处理问题的地方,通过异常处理程序捕获一场,catch用于捕获异常,可以有多个catch进行捕获
- try:try代码块中的代码表示将被激活特定的异常
1 | int fun2() |
异常的使用
异常的抛出和匹配原则:
- 异常是通过抛出对象而引发的,该对象的类型决定了应该激活哪个catch的处理代码。
- 被选中的处理代码是调用链中与该对象类型匹配且离抛出异常位置最近的那一个。
- 抛出异常对象后,会生成一个异常对象的拷贝,因为抛出的异常对象可能是一个临时对象,所以会生成一个拷贝对象,这个拷贝的临时对象会在被catch以后销毁。(这里的处理类似于函数的传值返回)
- catch(…)可以捕获任意类型的异常,但是不知道异常错误是什么。
- 实际中抛出和捕获的匹配原则有个例外,并不是类型完全匹配,可以抛出派生类对象,使用基类捕获。
在函数调用链中异常栈展开匹配原则:
- 首先检查throw本身是否在try块内部,如果是再查找匹配的catch语句。如果有匹配的,则调到catch的地方进行处理。
- 没有匹配的catch则退出当前函数栈,继续在调用函数的栈中进行查找匹配的catch。
- 如果到达main函数的栈,依旧没有匹配的,则终止程序。上述这个沿着调用链查找匹配的catch子句的过程称为栈展开。所以实际中一般都会加一个catch(…)捕获任意类型的异常,否则当有异常没捕 获,程序就会直接终止。
- 找到匹配的catch子句并处理以后,会继续沿着catch子句后面继续执行
异常的重新抛出:有可能单个的catch不能完全处理异常,在进行一些矫正处理后,希望再交给更外层的调用链函数来处理,catch则可以通过重新抛出异常传递给更上层的函数进行处理
异常安全:
- 构造函数完成对象的构造和初始化,最好不要在构造函数中抛出异常,否则可能导致对象不完整或没有完全初始化
- 析构函数主要完成资源的清理,最好不要在析构函数内抛出异常,否则可能导致资源泄漏(内存泄漏、句柄未关闭等)
- C++中异常经常会导致资源泄漏的问题,比如在new和delete中抛出了异常,导致内存泄漏,在lock和unlock之间抛出了异常导致死锁,而C++经常使用RAII来解决以上问题。
异常规范:
1 | // 这里表示这个函数会抛出A/B/C/D中的某种类型的异常 |
标准库中的异常体系
1 | void test() |
std::execptiom
是所有标准C++异常的父类,用所有异常的根基类的引用或指针进行捕捉,可以匹配所有继承体系的所有类型,通过根基类虚函数重写,完成多态的逻辑,最终通过多态完成对异常的精准处理
异常的优缺点
优点:
- 异常对象定义好了,相比错误码的方式可以清晰准确的展示出错误的各种信息,甚至可以包含堆栈调用的信息,这样可以帮助更好的定位程序的bug。
- 返回错误码的传统方式有个很大的问题是,在函数调用链中,深层的函数返回了错误,需要得层层返回错误,最外层才能拿到错误。
- 很多的第三方库都包含异常。
- 很多测试框架都使用异常,这样能更好的使用单元测试等进行白盒的测试。
- 部分函数使用异常更好处理,比如构造函数没有返回值,不方便使用错误码方式处理。比如T&operator这样的函数,如果pos越界了只能使用异常或者终止程序处理,没办法通过返回值表示错误。
缺点:
- 异常会导致程序的执行流乱跳,并且非常的混乱,并且是运行时出错抛异常就会乱跳。会导致踪调试时以及分析程序时比较困难。
- 异常会有一些性能的开销。但是在现代硬件速度很快的情况下,这个影响基本忽略不计。
- C++没有垃圾回收机制,资源需要自己管理,有了异常非常容易导致内存泄漏、死锁等异常安全问题,需要使用RAII来处理资源的管理问题。
- C++标准库的异常体系定义得不好,导致大家各自定义各自的异常体系,非常的混乱。
- 异常尽量规范使用,否则后果不堪设想,随意抛异常,外层捕获的用户苦不堪言。所以异常规范有两点:一、抛出异常类型都继承自一个基类。二、函数是否抛异常、抛什么异常,都使用 func()、throw();的方式规范化。