信息学竞赛 CPP 应用篇

线程与进程

• 进程

  通常情况下，一个可执行程序在启动后，就是一个进程。

  它拥有独立的可支配的资源，比如：内存。

  32 位程序有独立的4G虚拟内存(由操作系统提供)

  我们所说的内存地址就是指的：虚拟内存地址。

  优点 操作系统对进程资源进行了很多保护，比如：两个进程的虚拟内存不会映射在同一物理地址上。

  缺点 进程通信很慢，很麻烦。

• 线程

  在同一进程中，可以同时有多个指令序列在执行。

  它们共享同一虚拟内存，及其它（如：文件句柄，socket等）进程资源

  但有自己的：工作栈，局部变量，执行断点等

  可以把线程看成是轻量级的进程。

  优点

  创建线程比进程的成本要小得多，所以快速、高效，可以创建大量的线程。

  多个线程共享内存，可以直接传递指针，很快速、方便。

  缺点

  没有保护机制，一个线程出错，可能所有线程都会挂掉。

  对共享数据的访问存在竞争问题，使用锁可能会引起死锁。

c++11 之前的多线程

虽然操作系统大都支持多线程技术，但标准上并不统一。

c++一直都没有一个线程的标准使用方法，而是要调用本地系统的API

在unix/liux 下，POSIX规范，需要include

pthread_create(thread, attr, start_routine, arg)

参数分别：标识符指针，属性对象，运行函数地址，传入的参数

线程的显式退出调用 pthread_exit

windows 下则是另一种景象。

需要 include

CreateThread(属性，初始栈，回调函数, 线程参数，控制参数，传出参数);

如果创建成功，则返回句柄，否则 NULL

c++11 线程

c++11 终于把多线程作为标准库的特性。

需要先包含头文件：

void f()
{
    for(int i=0; i<10; i++){
        cout << "thread: " << i << endl;
    }
}
int main()
{
    thread td(f);
    for(int i=0; i<10; i++){
        cout << "main...." << i << endl;
    }
    return 0;
}

通过 thread 类来创建线程对象，参数为一函数，其内容为线程执行的内容。

td 对象掌管着线程的控制权。

此后，新线程与main线程同时执行，共享本进程的资源

更进一步地，竞争着本进程的排它资源（比如：控制台输出）。

在程序员的角度来看，我们只能说，两个线程是并发的。并不知道是否并行。

如果只有一个cpu，则通过系统调度，让一个线程执行一小段时间，切换到另一个线程，再执行一小段时间，再切换。。。

如果有多个cpu，可能真的是同时在执行。

无论如何，都存在着如何正确有次序地共享资源的问题。

c++11 sleep

为了观察清楚，我们可能会希望程序执行中能放慢脚步，让我们看清楚交叉的过程。

这个简单的需求也是个问题。因为c++11之前，没有统一的标准，让程序等待一会儿。

各种不同的sleep，五花八门。如果希望平台无关，看来只好自己循环了。。。

提供的是： Sleep(秒);

linux的 提供的是： sleep(秒); usleep(微秒);

c++11 采用了 boost 中的方案：

std::this_thread::sleep_for 休眠一个时间段

std::this_thread::sleep_untill 休眠到一个时间节点

时间间隔的单位有预定义好的：

#include <chrono>
/*
std::chrono::nanoseconds
std::chrono::microseconds
std::chrono::milliseconds
std::chrono::seconds
std::chrono::minutes
std::chrono::hours
*/
// 休眠 5 秒钟：
this_thread::sleep_for(chrono::seconds(5));

原来的多线程程序可以修改为：

void f()
{
    for(int i=0; i<10; i++){
        this_thread::sleep_for(chrono::seconds(1));
        cout << "thread: " << i << endl;
    }
}
int main()
{
    thread td(f);
    for(int i=0; i<10; i++){
        this_thread::sleep_for(chrono::seconds(1));
        cout << "main...." << i << endl;
    }
    return 0;
}

等待到某一时刻：

cout << "begin" << endl;
chrono::system_clock::time_point p =
    chrono::system_clock::now() +
    chrono::seconds(5);
this_thread::sleep_until(p);
cout << "end" << endl;

计算程序执行的时间间隔

auto p1 = chrono::high_resolution_clock::now();
for(int i=0; i<100; i++){
    cout << i << endl;
}
auto p2 = chrono::high_resolution_clock::now();
chrono::duration<double, std::milli> ela = p2 - p1;
cout << "use: " << ela.count() << " ms" << endl;
return 0;

实时效果反馈

1. 关于进程与线程, 说法正确的是：__

• A 进程中至少包含一个线程，即主线程

• B 多个进程间通信，可以通过传递指针的方式

• C 同一进程的多个线程共用进程的栈

• D 一个线程崩溃不会影响到其它线程

2. 使用 sleep 而不是空循环等待的主要好处是？__

• A 等待的时间更准确

• B 代码更简洁

• C 更省资源，线程sleep期间不占用 cpu 资源

• D 兼容性更好

答案

1=>A 2=>C

多线程

在线程启动以后，就和主线程并列地运行了。

这时，主线中的线程对象是局部变量，当超出作用域后，会调用terminiate从而引发异常。

有两个选择：

• join

  一定要在被调线程结束前调用这个函数，它会使主线程直接进入阻塞模式。一直等到被join的线程执行结束，才会被唤醒。

  这个效果上看，与直接调用线程函数是一样的。

• detach

  还可以让出新线程的控制权，让它自生自灭。

  detach就果让线程对象与它实际关联的线程脱钩，把控制权转交给c++的运行库。

  这有点类似 unix 守护进程的概念。

  脱钩后，线程对象就变成一个空壳，不能再通过它控制线程或与新线程通信了。

  不管有没有 detach，主线程结束后，要回收所有资源，所有线程也会强制结束。

  void f()
  {
      for(int i=0; i<5; i++){
          this_thread::sleep_for(chrono::seconds(1));
          cout << "thread: " << i << endl;
      }
  }
  int main()
  {
      thread td(f);
      td.detach();
      this_thread::sleep_for(chrono::seconds(3));
      cout << "main end" << endl;
      return 0;
  }

线程函数的多种形式

• 普通函数

• 函数对象

• 匿名函数
• 成员函数

void f()
{
    cout << "void f() .." << endl;
}
struct F{
    F(int a):x(a){}
    void operator()(){
        cout << "F::operator() " << x << endl;
    }
    void f(){
        cout << "member f " << x << endl;
    }
    int x;
};
int main()
{
    thread t1(f);
    thread t2(F(20));
    thread t3([](){cout << "noname func" << endl; });
    F a(10);
    thread t4(F::f, &a);  // 相当于有参的函数
    t1.join();
    t2.join();
    t3.join();
    t4.join();
    return 0;
}

this_thread

get_id() 获得当前进程的ID

yield() 放弃本线程本轮的时间片，让给其它线程执行。

thread([](){
    cout << this_thread::get_id() << endl;
}).join();
cout << this_thread::get_id() << endl;

传参问题

线程函数可以有参数，个数不限，返回值如果有，会被忽略。

当传递指针的时候，会共享变量，这时要注意，当线程还在运行的时候，要保证共享的变量不会被销毁。

引用的传递有点不同，如果不加处理，编译器无法判断我们是想传引用，还是想传值。

可以这样处理：

void f(int& x){
    this_thread::sleep_for(chrono::seconds(1));
    cout << x << endl;
}
int main()
{
    int x = 5;
    thread td(f, std::ref(x));
    x = 20;
    td.join();
    return 0;
}

同一个函数，可以创建出多个线程

void f(int x){
    this_thread::sleep_for(chrono::seconds(1));
    cout << x << endl;
}
int main()
{
    thread t1(f, 10);
    thread t2(f, 20);
    t1.join();
    t2.join();
    return 0;
}

实时效果反馈

1. 调用 a.detach() 后, a原来对应的线程，说法正确的是：__

• A a 原来的线程自由运行，直到代码结束。

• B a 原来的线程被挂起

• C a原来的线程后台运行，直到代码结束，或因主线程结束而强制结束

• D a原来的线程不受控制，无法访问它

2. a.join()的含义是：__

• A 让 a 线程进入休眠状态

• B 让调用方进入休眠状态，a结束才能唤醒

• C 把两个线程合并成一个线程

• D 强行抢占a线程的执行时间

答案

1=>C 2=>B

线程互斥

多个线程在更新共享变量的时候，会出现逻辑问题。

假设，A B 两个线程都对 变量 x 进行加的操作。

A: { x = x + 1; };

B: { x = x + 1; };

通常，解决的办法是加锁。也就是，互斥量：mutex

需要include

一般需要定义为全局变 量 lock() 加锁，unlock() 解锁

mutex g1;  //全局的排斥锁
void f()
{
    for(int i=0; i<10; i++){
        this_thread::sleep_for(chrono::milliseconds(500));
        g1.lock();
        cout << "thread: "
             << "<" << this_thread::get_id() << ">"
             << i << endl;
        g1.unlock();
    }
}
int main()
{
    thread t1(f);
    thread t2(f);
    t1.join();
    t2.join();
    return 0;
}

要真正理解 mutex，先需要理解 线程的状态

• lock 动作：

  若未锁，则锁之。

  若其它线程已锁，则自身进入阻塞态，等待唤醒

• unlock 动作：

  若已锁，唤醒等锁线程之一，若无等待线程，则开锁

  若未锁，则==不确定行为==

另注意：对自己锁过的mutex, 再锁一次，==行为不定==

如果，线程可能多次加锁同一互斥量，

则可考虑用recursive_mutex

其lock:

如果已锁，并且是自己锁的，则仍为锁态，但计数加１，不会发生阻塞

注意，lock 多少次，就要unlock多少次才能解开销量。要求：lock, unlock 严格对称。

有时，lock时不想一直等待，想有个最大忍耐限度，即：超时机制。

std::mutex;  // 非递归的互斥量
std::timed_mutex; // 带超时的非递归互斥量
std::recursive_mutex; // 递归的互斥量
std::recursive_timed_mutex;  // 带超互斥量

• mutex::try_lock()

  试锁，如果已被别人锁了，则返回　false

• timed_mutex::try_lock_for(时间间隔)

  在一段时间内试锁，如果此时间间隔内无法得到锁，则返回 false

• timed_mutex::try_lock_until(时刻)

  在某一时刻前试锁，如果此时刻前获得锁，则罢，否则返回false

timed_mutex g1;
void f()
{
    this_thread::sleep_for(chrono::seconds(1));
    if(!g1.try_lock_for(chrono::seconds(3)))
        cout << "fail .. " << endl;
    else{
        cout << "ok.." << endl;
        g1.unlock();
    }
}
int main()
{
    thread th(f);
    g1.lock();
    cin.ignore();
    g1.unlock();
    th.join();
    return 0;
}

实时效果反馈

1. 关于线程状态, 说法正确的是：__

• A 线程在阻塞态，经到一时间片段，会醒来，检查条件是否满足

• B 线程在阻塞态一直等到被某个事件唤醒

• C 线程在阻塞态被唤醒后直接进入运行态

• D 就绪态的线程可能会进入阻塞态

2. timedmutex::trylockfor(t)，行为是：_

• A 如果是本线程已锁过的，则返回true

• B 如果是其它线程已锁过的，则立即返回false

• C 如果是其它线程已锁过的，则阻塞本线程，直到目标解锁，或 t 时间用尽。

• D 如果目标未锁，则不做其它，直接返回true

答案

1=>B 2=>C

lock_guard

mutex的使用手册：

lock与unlock必须成对出现。

lock后，千万不要忘记调用 unlock，否则其它线程遭殃了。

如果出现了异常，也要小心，容易忘记了 unlock

….

这是不是很耳熟？　new delete 不就是这么说的吗？

然而，内存泄漏一直困扰程序员。

RAII 是一种很好的策略，这里也可以用。

它就是：lock_guard

lock_guard 是一个包装类型的模板类，仅仅封装某种类型的mutex，在析构时调用它的unlock成员函数而已。

mutex g1;
void f()
{
    g1.lock();
    for(int i=0; i<10; i++){
        if(i==6) throw -1;
        cout << this_thread::get_id() << ": " << i << endl;
    }
    g1.unlock();
}
int main()
{
    thread t1(f);
    thread t2(f);
    t1.join();
    t2.join();
    cout << "main end" << endl;
    return 0;
}

会发现，当一个线程抛出异常的时候，另一个线程就一直被锁着，没有机会被唤醒。

因为主线程在等待另一个线程的结束，因而也被阻塞着。

如果换用lock_guard

mutex g1;
void f()
{
    lock_guard<mutex> lg(g1);
    for(int i=0; i<10; i++){
        if(i==6) throw -1;
        cout << this_thread::get_id() << ": " << i << endl;
    }
}
int main()
{
    thread t1(f);
    thread t2(f);
    t1.detach();
    t2.detach();
    this_thread::sleep_for(chrono::seconds(1));
    cout << "main end" << endl;
    return 0;
}

使用注意：

• 中途不能解锁

• 对象不可复制

锁定应该尽量短，防止影响其它线程。有时仍需要手工控制锁定时机。

此时，可以采用“领养策略”

此策略，仍是用户自己控制锁定过程，但让lock_guard 来帮助解锁。

// 确保这之前互斥量已经锁定了
lock_guard<mutext> lg(g1, adopt_lock);
// 这只是接管了 g1, 但不会调 lock

为了不影响其它线程，锁的粒度要尽可能地小。

示例：

不用锁的情况：

int sum = 0;
void f(int x)
{
    for(int i=0; i<1000 * 100; i++) {
        sum += x;
    }
}
int main()
{
    sum = 0;
    thread t1(f, 1);
    thread t2(f, -1);
    t1.join(); t2.join();
    cout << sum << endl;
    return 0;
}

用锁的情况：

int sum = 0;
mutex g1;
void f(int x)
{
    for(int i=0; i<1000 * 100; i++) {
        lock_guard<mutex> lg(g1);
        sum += x;
    }
}
int main()
{
    sum = 0;
    thread t1(f, 1);
    thread t2(f, -1);
    t1.join(); t2.join();
    cout << sum << endl;
    return 0;
}

lock_guard 很轻量，没有特殊要求的情况下，应该使用它。

实时效果反馈

1. 关于lockguard, 说法正确的是：_

• A lock_guard 是一种RAII策略，在析构时会调用 unlock

• B lock_guard 在实例化对象的时候，一定会调用互斥量 lock

• C lock_guard　只能用于 mutex 互斥量

• D lock_guard 可以拷贝构造

2. std::adoptlock　含义是：_

• A 意向锁，析构时不调用 unlock

• B 半路领养，不调用 lock

• C 延迟锁，稍后再调用 lock

• D 读锁，排斥写，不排斥读

答案

1=>A 2=>B

unique_lock

lock_guard 的优点：速度快，省资源，使用简单

lock_guard 缺点：简单粗暴，粒度没法控制，不灵活

是lock_guard 的升级版，可以做得更细腻（效率上低点，内存上多用点）

unique_lock实例化时可以加的额外参数：

adopt_lock ： 同 lock_guard, 表示已经锁过了，不调用 lock

defer_lock: 没有锁过，稍后再 明确调 lock

try_to_lock ：加锁，但不阻塞，以后可以检查状态

unique_lock 的成员函数：

示例

int sum = 0;
mutex g1;
void f(int x)
{
    unique_lock<mutex> uk(g1, defer_lock);
    for(int i=0; i<1000 * 10000; i++) {
        while(!uk.try_lock()){
            cout << this_thread::get_id();
            cout << " lock fail.." << endl;
            this_thread::sleep_for(
                chrono::milliseconds(200));
        }
        sum += x;
        uk.unlock();
    }
}
int main()
{
    sum = 0;
    thread t1(f, 1);
    thread t2(f, -1);
    t1.join(); t2.join();
    cout << sum << endl;
    return 0;
}

lock_guard 有的功能，unique_lock 都有。

但，如果 lock_guard 够用，就不要用 unique_lock，

因为，维护状态是有开销的。

用锁原则总结

• 共享对象的操作要考虑加锁

• 锁的颗粒度越小越好

• 尽量不要用 mutex 裸装上阵，危险处处！

• 如无特殊需要，用 lock_guard 即可

• 如控制上满足不了要求（一般是粒度），改用unique_lock

实时效果反馈

1. 关于uniquelock, 说法正确的是：_

• A unique_lock 比 lock_guard 更省资源

• B unique_lock 比 lock_guard 更快速

• C unique_lock 比 lock_guard 更灵活

• D unique_lock 比 lock_guard 更安全

2. uniquelock 对象调trylock函数时，为判断加锁成功否，==错误==的方法是：__

• A try_lock() 返回 true 则成功

• B try_lock 后，检查 owns_lock() 返回 true 则成功

• C try_lock 后，直接把 unique_lock 对象当bool量判断

• D try_lock 后， 把互斥量对象当 bool 量判断

答案

1=>C 2=>D

条件变量

mutex 的语义是互斥，为了保护共享资源，使之自动形成排队访问。

还有一种常见的需求是：

一个线程等待某个条件，条件满足了才可以执行，否则一直睡觉。

用mutex 也可以实现这个要求，但行为比较怪异。

vector<int> vec;
mutex g1;
void f()
{
    g1.lock();
    for(int i=0; i<vec.size(); i++){
        cout << "thread f: " << vec[i] << endl;
    }
    g1.unlock();
}
int main()
{
    g1.lock(); 
    thread t1(f); // 要确保 g1 已经 lock
    for(int i=0; i<10; i++) vec.push_back(i*10);
    cout << "vec ready" << endl;
    g1.unlock();
    t1.join();
    return 0;
}

这里要小心操作， 创建线程前，要保证 g1 已经加锁，然后，线程中的锁才会阻塞自己。

把排斥锁用于：等待-通知 的目的，很不直观，又容易出错。

改用 condition_variable 就好很多。

该对象的 .wait 方法实现在此变量下等待。直到有人调用该对象的 .notify_one, 或者 .notify_all。

需要加头文件：

vector<int> vec;
mutex mtx;
condition_variable cv;
void f()
{
    unique_lock<mutex> lck(mtx);
    cv.wait(lck);
    for(int i=0; i<vec.size(); i++){
        cout << "thread f: " << vec[i] << endl;
    }
}
int main()
{
    thread t1(f);
    {
        unique_lock<mutex> lck(mtx);
        for(int i=0; i<10; i++) vec.push_back(i*10);
    }
    cout << "vec ready" << endl;
    cv.notify_one();
    t1.join();
    return 0;
}

可以看到：

在调用 wait 前确保自己已经持有 unique_lock（间接持有mutex）。

notify 的时候，则不需要持有锁。

其动作的细节是：

.wait( ) 使本线程进入阻塞状态，但在睡眠前，unlock 持有的锁。

.notify_* 可能使得本线程醒来，醒来的第一件事是：lock

从工程实践的角度来说，这段代码还是不安全的。

因为线程可能因为其它的原因醒来，不一定是有人调了 notify_*

为避免莽撞，一般醒来要查一个标志（bool量），

这几乎成为了惯例：

vector<int> vec;
mutex mtx;
condition_variable cv;
bool ready;
void f()
{
    unique_lock<mutex> lck(mtx);
    while(!ready) cv.wait(lck);
    for(int i=0; i<vec.size(); i++){
        cout << "thread f: " << vec[i] << endl;
    }
}
int main()
{
    ready = false;
    thread t1(f);
    {
        unique_lock<mutex> lck(mtx);
        for(int i=0; i<10; i++) vec.push_back(i*10);
        ready = true;
    }
    cout << "vec ready" << endl;
    cv.notify_one();
    t1.join();
    return 0;
}

condition_variable 的强大之处在于：可以同时唤醒多个线程，这个自己实现很麻烦。

vector<int> vec;
mutex mtx;
condition_variable cv;
bool ready;
void f()
{
    {
        unique_lock<mutex> lck(mtx);
        while(!ready) cv.wait(lck);
    }
    for(int i=0; i<vec.size(); i++){
        cout << "thread ";
        cout << this_thread::get_id() << " :";
        cout << vec[i] << endl;
    }
}
int main()
{
    ready = false;
    thread t1(f);
    thread t2(f);
    {
        unique_lock<mutex> lck(mtx);
        for(int i=0; i<10; i++) vec.push_back(i*10);
        ready = true;
        cout << "vec ready" << endl;
    }
    cv.notify_all();
    t1.join();
    t2.join();
    return 0;
}

总结：

• condition_variable 要配合 unique_lock 使用，wait前要持有锁

• unique_lock 是包装了某个全局的 mutex

• 如果希望使用其它类型的 mutex，参见 condition_variable_any

实时效果反馈

1. 关于condtionvariable, 说法正确的是：_

• A 实例化的时候，需要传入锁对象

• B 调用 wait 的时候，需要传入锁对象

• C 调用 notify_* 的时候，需要传入锁对象

• D 不需要锁对象， 可以独立工作

2. conditionvariable 对象进入wait前后 ，锁的状态变化是：_

• A 锁态变为非锁态

• B 非锁态变为锁态

• C 没有变化

• D 不确定

答案

1=>B 2=>C

生产消费者模型

生产-消费者模型是典型的多线程协作场景

假设有若干个生产者，若干个消费者，它们独立运行。

大家共享一个队列，生产者往队列放东西，消费者取出东西。

当队列为空时，消费者睡觉，等待唤醒

当队列为满时，生产者睡觉，等待唤醒

需要一个 mutex 来实现互斥

需要两个 condition_variable，一个用于表达条件：队列非空，

一个用于表达条件：队列非满

#include <iostream>
#include <thread>
#include <mutex>
#include <condition_variable>
#include <queue>
#include <ctime>  // srand
using namespace std;
queue<int> Q;
mutex mtx;
condition_variable cv_emp, cv_ful;
// consumer 消费者
void f1()
{
    srand(time(0));
    unique_lock<mutex> lck(mtx, defer_lock);
    while(1){
        lck.lock();
        while(Q.empty()) cv_emp.wait(lck);
        cout << this_thread::get_id();
        cout << " consum " << Q.front() << endl;
        Q.pop();
        if(Q.size()<=10) cv_ful.notify_all();
        lck.unlock();
        int t = rand()%1000;
        this_thread::sleep_for(chrono::milliseconds(t));
    }
}
// producer 生产者
void f2()
{
    srand(time(0));
    unique_lock<mutex> lck(mtx, defer_lock);
    for(int i=0; i<30; i++){
        lck.lock();
        while(Q.size()>10) cv_ful.wait(lck);
        cout << this_thread::get_id();
        cout << " produce " << i << endl;
        Q.push(i);
        cv_emp.notify_all();
        lck.unlock();
        int t = rand()%1000;
        this_thread::sleep_for(chrono::milliseconds(t));
    }
}
int main()
{
    thread t1[3], t2[3];
    for(int i=0; i<3; i++) t1[i] = thread(f1); //消费者
    for(int i=0; i<3; i++) t2[i] = thread(f2); //生产者
    for(int i=0; i<3; i++) t1[i].join();
    for(int i=0; i<3; i++) t2[i].join();
    return 0;
}

这里要注意 wait 的动作：

进入睡眠前，unlock

醒来后 lock，这个lock 会把同伴阻住。

实时效果反馈

1. 关于条件量, 说法正确的是：__

• A 两个不同的条件量，必须使用不同的 mutex

• B 同一个条件量，只能用同一个 mutex

• C 条件量可以不需要unique_lock 而单独使用

• D 以上都不对

2. 上例中，当所有生产者线程结束一段时间后，消费者线程处于什么状态？__

• A 结束态

• B 阻塞态

• C 就绪态

• D 僵尸态

答案

1=>D 2=>B

死锁问题

使用锁的两大魔鬼：

• 忘记了 unlock，导致被阻塞线程一直醒不过来
• 循环等待，产生死锁，谁也醒不过来

死锁的形成：持有锁，并申请等待另一把锁

产生死锁的示例

mutex mtx_a;
mutex mtx_b;
void f()
{
    cout << "f .. begin" << endl;
    mtx_a.lock();
    cout << "mtx_a locked" << endl;
    this_thread::sleep_for(chrono::milliseconds(200));
    mtx_b.lock();
    cout << "mtx_a, mtx_b locked" << endl;
    this_thread::sleep_for(chrono::milliseconds(100));
    mtx_b.unlock();
    mtx_a.unlock();
    cout << "f .. end" << endl;
}
void g()
{
    cout << "g ... begin" << endl;
    mtx_b.lock();
    cout << "mtx_b locked" << endl;
    this_thread::sleep_for(chrono::milliseconds(200));
    mtx_a.lock();
    cout << "mtx_a, mtx_b locked" << endl;
    this_thread::sleep_for(chrono::milliseconds(100));
    mtx_a.unlock();
    mtx_b.unlock();
    cout << "g ... end" << endl;
}
int main()
{
    thread t1(f);
    thread t2(g);
    t1.join();
    t2.join();
    return 0;
}

解决方案

• 检测出死锁，牺牲某个线程
• 避免死锁的发生

按某个顺序持有锁（比如：字母序）

线程中计划锁哪些东西，要先规划好。

std::lock

传入多个互斥量为参数，有可能引起阻塞，但醒来一定保证拿到所有的锁。

此函数会自行决定锁的顺序和策略，可能会调用 lock ,try_lock,unlock等，

目标是保证不死锁，同时兼顾锁的使用效率。

是自动解决死锁问题的方案之一。

与之对应的，还有一个 std::try_lock 原理相仿

把前边的例子改为：

void f()
{
    cout << "f .. begin" << endl;
    lock(mtx_a, mtx_b);
    cout << "mtx_a, mtx_b locked" << endl;
    this_thread::sleep_for(chrono::milliseconds(100));
    mtx_b.unlock();
    mtx_a.unlock();
    cout << "f .. end" << endl;
}
void g()
{
    cout << "g ... begin" << endl;
    lock(mtx_b, mtx_a);
    cout << "mtx_a, mtx_b locked" << endl;
    this_thread::sleep_for(chrono::milliseconds(100));
    mtx_a.unlock();
    mtx_b.unlock();
    cout << "g ... end" << endl;
}

注意，解锁的时候仍是单独分别解锁。

原则是，只要可能，尽快解锁，免得影响其它线程。

另外，为了避开手工操作 mutex，也可以使用 lock_gard 来管理 mutex

void g()
{
    cout << "g ... begin" << endl;
    lock(mtx_b, mtx_a);
    cout << "mtx_a, mtx_b locked" << endl;
    {
        lock_guard<mutex> lck1(mtx_a, adopt_lock);
        lock_guard<mutex> lck2(mtx_b, adopt_lock);
        this_thread::sleep_for(chrono::milliseconds(100));
    }
    cout << "g ... end" << endl;
}

因为 mutex 已经加锁，所以 lock_guard 需要 adopt_lock 领养策略

实时效果反馈

1. 下列哪个选项, 无助于减少或避开死锁：__

• A 按照统一的固定顺序申请锁

• B 尽早释放不用的锁

• C 使用 try_lock，不使线程进入阻塞时持有锁

• D 直接使用 mutex 而不是 lock_guard

2. 对std::lock，说法==错误==的是：__

• A 不一定按参数顺序来申请锁

• B 不一定用 lock， 也可能会用 try_lock

• C 也可能对已经持有的锁，调用 unlock

• D 该函数不会阻塞当前的线程

答案

1=>D 2=>D

thread_local

c++11新引入的一种存储类型修饰符。

c++原有的存储类型：

• 代码中的字面量
• 静态变量（全局，局部静态，静态成员变量）
• 栈变量
• 堆变量

现在又多了一个：thread_local

以此修饰符修饰的变量，具有线程的生存周期：

线程开始时生成，线程结束时销毁。

可以修饰：全局变量，static成员变量，本地static变量。

其实质是：c语言原来的全局存储的静态类型，分离出一种对线程隔离效果的全局类型。

c语言产生的年代，还没多线程的需求，不可能那么高瞻远瞩地设计。

• 普通的全局变量

  int x = 0;
  void g()
  {
      x++;  // 理应使用 mutex 来实现互斥访问，不是本节要点
      cout << x << endl;
  }
  void f()
  {
      for(int i=0; i<10; i++) g();
  }
  int main()
  {
      thread t1(f);
      thread t2(f);
      t1.join();
      t2.join();
      return 0;
  }

• 局限于线程中的“全局变量”

thread_local int x = 0;  // 实际上，只修改了这一个地方
void g()
{
    x++;
    cout << x << endl;
}
void f()
{
    for(int i=0; i<10; i++) g();
}
int main()
{
    thread t1(f);
    thread t2(f);
    t1.join();
    t2.join();
    return 0;
}

• thread_local 型变量的生存期：

每个thread_local变量在线程创建的时候创建，然后对本线程而言，相当于全局变量；

当线程销毁的时候，会同时销毁当初创建的这个thread_local变量。

这个变量当然不可能是静态存储的。

其它使用场合

• 静态成员变量

  仅仅是面向对象的封装性的体现。

  变量还是静态的，全局的，只是使用权限上加以约束。

  改用 thread_local 后，保持对线程的全局语义，但已经不是静态的了。

• 局部static变量

  本质上，还是静态全局的，只是作用域局限在一个函数范围。

  改用 thread_local 后，保持对线程调用该函数的全局语义，但已经不是静态的了。

void g()
{
    thread_local int x = 0;
    x++;
    cout << x << endl;
}
void f()
{
    for(int i=0; i<10; i++) g();
}
int main()
{
    thread t1(f);
    thread t2(f);
    t1.join();
    t2.join();
    return 0;
}

实时效果反馈

1. 关于threadlocal, 说法正确的是：_

• A thread_local变量在多个线程间共享

• B thread_local变量存储在静态空间

• C thread_local变量在线程创建时申请，在线程销毁时释放

• D thread_local变量不可以是用户定义类型

答案

1=>C

未来承诺

c++11 future & promise

我们在早前的课程中，一直有这样一个观念：

程序中，如果能不用全局变量，就尽量不用。

在学习线程时，为了通信，又不得不用全局变量，这不是灾难吗？

虽然，也可以 thread_local 变量，然后把指针传给另一个线程，但把指针传来传去的..

考虑如下的常见场景：

线程A，需要线程B的计算结果，以便进一步的计算。如果结果没出来就等待。

用一个全局量，加一个mutext，当然可以，但大量这样的情况，早晚会一片混乱！

c++11 的线程方案，并不能用join等待一个线程结束，并获得它的返回值。(linux的可以)

因为，c++11 提供了另一套更完备的解决方案。

大体思路是：

用一pormise 对象，关联到一个 future对象，

把promise对象传到计算线程中，

自己可以做其它事。。。

调用 future对象的 get_value，此时，如果对方没准备好结果，引起阻塞。

直到拿到了结果才返回。

此刻，在大洋彼岸，另一线程的情况：

结果一出来，就调用 promise 对象的set_value

。。。。

听上去有点头大？？

90%的应用中，需求足够单纯。可以用 async 这个简化包装。

相当于一个套餐，用着省事。

#include <iostream>
#include <thread>
#include <future>
#include <chrono>
using namespace std;
int f(int x, int y)
{
    this_thread::sleep_for(chrono::seconds(2));
    return x * 10 + y;
}
int main()
{
    future<int> res = async(launch::async, f, 5, 8);
    cout << "do other things" << endl;
    int r = res.get();
    cout << r << endl;
    return 0;
}

这里，

launch::async  //表示创建新线程
launch::deferred  // 表示延迟处理，同步调用，不创建新线程
launch::async ｜ launch::deferred // 表示系统自己看着办

deferred可能是lazy模式，一直到get() 才会真的去处理

另外，如果线程中抛出了异常，可以在主线程中抓住，这很令人感动。。

实时效果反馈

1. 关于async函数模板, 说法正确的是：__

• A async 必然会引起创建新线程

• B async 会阻塞当前线程，返回计算线程的计算结果

• C async 会立即返回一个 future对象

• D async 会返回一个 promise 对象

2. 如果在async创建的线程中发生了异常，以下正确的是：__

• A 在新线程和async的主调线程中都可能 catch

• B 只能在新线程中catch

• C 只能在async的主调线程中catch

• D 与操作系统有关

答案

1=>C 2=>A

原子变量

加锁固然能解决多线程的一些问题。但工程实践表明，惹出的麻烦也不少。

能不能不加锁，也可以实现共享呢？

上图，假设 N 是个线程间共享的全局变量。

一个线程对它的操作，一般情况下可以看作 3 步：

• 读取 N
• 对 N 运算: ${N \longrightarrow N_1}$
• 写回新的值 ${N_1}$

如果，能保证，这3步操作不在线程间交叉，则不会引起冲突。

某一系列动作能不被其它线程干扰，则称之为原子操作

这个不被干扰，也有两层境界：

1. 这一系列动作，在一个线程时间片完成，中间不被打断
2. 允许中间打断（不在一个时间片），但期间所有欲染指者均被阻塞

显然，对1，需要操作系统一级的支持。

对2， 只是算法技巧，让使用者感觉这一系列动作是原子的。

atomic

c++11 提供的 atomic 模板系统地考虑了这些问题，甚至走得更远。

• 对自己的类型使用模板，可以保证写入、读取的原子性。
• 对常用内置类型提供了很多保证原子性的操作
• 对于编译器的乱序优化，提供了各种控制手段
• compareexchange* 提供原子性的另一种解决方案（已经被干扰了，如何处理？）

简单变量的原子操作

对简单变量的操作，也需要加锁，解锁，有时感觉很麻烦

int x ; x++;

bool b; b = !b;

如果不用锁，后果很严重：

int sum = 0;  //没有加锁保护的全局变量
void f(int x)
{
    for(int i=0; i<x; i++) sum++;
}
int main()
{
    thread t1(f, 1000*100);
    thread t2(f, 1000*100);
    t1.join();
    t2.join();
    cout << sum << endl;
    return 0;
}

如果没有原子量一说，x++ 的动作可能是：

【读取 x 值到寄存器; 寄存器值加1; 写回到 x】

这三个动作可能不会一气呵成，中间可能被其它线程打断。这就危险了。。。

所谓原子就是一系列不可被分割的动作。

它们要么不去执行，要么就全部执行，不会出现执行了一半被其它线程插进来的窘况。

如果能保证某一系列动作的原子性，就不需要用 lock 了。

需要 include

只把定义sum的一句改掉就可以了

atomic<int> sum{0};

atomic 是个模板，我们可以通过重载方法，来实现自己的原子类型。

c++11 已经替我们实现了常见类型的原子化。

上例中的 x++ 就是原子化的，因而不需要加锁

用 mutex 与原子量的耗时比较

int sum = 0;
mutex mtx;
void f(int x)
{
    for(int i=0; i<x; i++) {
        mtx.lock();
        sum++;
        mtx.unlock();
    }
}
int main()
{
    auto t = clock();
    thread t1(f, 1000*1000);
    thread t2(f, 1000*1000);
    t1.join();
    t2.join();
    cout << sum << endl;
    t = clock() - t;
    cout << t << endl;
    return 0;
}

实时效果反馈

1. 关于使用atomic代替锁的好处, 说法正确的是：__

• A 执行更高效，更不容易出错

• B 更好的操作系统兼容性

• C 更广泛的应用领域，比如：嵌入式系统

• D 对多核处理器更有利

2. 对于 atomic x，哪个动作不是原子的？__

• A x = 5;

• B x++;

• C x.fetch_add(3);

• D x += 6;

答案

1=>A 2=>D

GUI与Qt

GUI(Graphical User Interface) 图形用户接口

c++标准中并没有包含GUI，开发图形化界面要依靠第三方的库。

但小到桌面应用，大到大型游戏，很多应用都是用c++开发的，主要因为c++的性能优势。

框架十分多，常见的：

microsoft MFC windows平台

Qt 跨平台，可编写 Web，桌面，移动应用，艺术级的UI组件

Fltk 跨平台 小巧 静态，快速生成应用 OpenGL 支持3D

Wx Widgets 学院派 跨平台 免费

。。。

选择时要考虑的点：

• 是否有跨平台的需求
• 是否要兼顾移动设备和 web 应用
• 是否要定制组件，对组件的丰富、细腻要求多高
• 开发环境与开发效率
• 商用有哪些限制
• 借鉴已有的成功案例

Qt 历史

1991 奇趣科技开发 挪威[TrollTech]

1996 商业领域 是Linux 流行桌面KDE的基础

2008 奇趣被诺基亚收购，成为诺基亚的编程语言

2012 诺基亚没落后，几经波折，又被Digia 公司收购

2014 发布跨平台集成环境 Qt Creator，从Qt5 开始实现了对主流平台的全面支持

Qt 按不同的版本发行，分商业版和开源版

开源版是　LGPL　协议

Qt 优点

• 跨平台，一次编写到处编译
• 接口简单，上手快
• 有配套的IDE工具，能快速构建应用，开发效率高
• 可支持嵌入式开发

最简示例

选择编译环境时：

自动生成的工程：

使用窗体设计器

点击*.ui 进入它的设计视图

本质上，是在编辑一个XML文件

可以用 ctrl+F2 切换到XML视图，ctrl+F3切换到设计视图

建议不要手工编辑这个XML文件

左边是组件，可以拖动到form上

然后，在右边修改它的各种属性

再加入一个Button组件

为按钮添加事件：

至此，我们没写一行代码，第一个应用程序就完成了！

实时效果反馈

1. 关于Qt的优势, 说法==错误==的是：__

• A 跨多种平台，包括移动和嵌入式

• B 接口简单，上手容易

• C 有开源版本

• D 有软件巨头背书

2. *.ui　文件是：__

• A 窗体组件文件，以二进制形式存储

• B 窗体组件文件，以XML 格式存储

• C 国际资源文件，以文件格式存储

• D 图片文件，以二进制形式存储

答案

1=>D 2=>B

Qt框架分析

看一下工程中的主要文件：

文件分析

main.cpp 应用程序的入口，

其功能是：创建应用程序，创建窗口，显示窗口，运行应用程序，开启消息循环

#include "mainwindow.h"
#include <QApplication>
int main(int argc, char *argv[])
{
    QApplication a(argc, argv);　//代表应用程序
    MainWindow w;　　// 主窗口对象
    w.show();　　// 显示窗口
    return a.exec();　// 运行程序，并等待处理消息
}

mainwindow.h 定义窗体类的头文件

#ifndef MAINWINDOW_H
#define MAINWINDOW_H
#include <QMainWindow>
namespace Ui {　　// 命名空间
class MainWindow;　　//不是下面这个MainWindow类，
    // 而是ui_mainwindow.h中定义的类
    // 这个文件是由mainwindow.ui 自动生成的
}　// 这相当于一个外部文件声明
class MainWindow : public QMainWindow
{
    Q_OBJECT　　// 使用Qt的信号与槽机制，必须用这个宏
public:
    explicit MainWindow(QWidget *parent = 0);
    ~MainWindow();
private:
    Ui::MainWindow *ui; //就是前边声明的类，代表ui组件的入口　
};
#endif // MAINWINDOW_H

mainwindows.cpp 主窗体类的实现代码

#include "mainwindow.h"
#include "ui_mainwindow.h"　// 很重要，包含所有窗体上的内容
// 这个.h文件是自动生成的，不要手工修改，改了也没用
MainWindow::MainWindow(QWidget *parent) :
    QMainWindow(parent), 
    ui(new Ui::MainWindow)　　// 向ui注入值
{
    ui->setupUi(this);　//此处创建了各个组件，建立属性，
        //建立信号与槽的连接等初始化工作
}
MainWindow::~MainWindow()
{
    delete ui;
}

mainwindow.ui 窗体设计文件

这个不是标准ｃ++的文件，无法直接编译它

实际上，它是一个普通的XML文件

<?xml version="1.0" encoding="UTF-8"?>
<ui version="4.0">
 <class>MainWindow</class>
.....
  <widget class="QToolBar" name="mainToolBar">
   <attribute name="toolBarArea">
....
....
   </hints>
  </connection>
 </connections>
</ui>

这里边定义了所有在设计时指定的信息，需要一个预处理过程，

把它转化生成为c++可以编译的文件。

窗体设计器　—> mainwindow.ui —-> ui_mainwindow.h

这个　ui_mainwindow.h 是可以用 c++编译的，是标准的c++语法

其中，用面向对象的方式，封装了整个窗体上的所有组件。

综上，我们拿到了ui 指针，就可以访问窗体上的所有组件，并用代码改变它的属性。

【演示】给按钮添加一个click事件，改变按钮上的文本。

实时效果反馈

1. 关于QOBJECT宏的作用, 说法正确的是：_

• A 每个Qt类都必须要这个宏

• B 每个想要使用　signals & slots 的类必须用这个宏

• C 在窗体定文件中需要这个宏

• D 在主程序文件中需要这个宏

2. mainwindow.ui 与 uimainwindow.h 的关系是：_

• A mainwindow.ui 预处理后，生成ui_mainwindow.h文件

• B ui_mainwindow.h　预处理后，生成　mainwindow.ui 文件

• C 窗体设计器直接生成 ui_mainwindow.h

• D 所有的Qt窗体程序都用 ui_mainwindow.h 作为公共定义

答案

1=>B 2=>A

信号和槽

信号和槽是Qt编程的基础。

不同的GUI系统，体系结构可能很大不同，但都需要面对同样的需求。

比如：如何处理界面上发生的事件。

有用回调函数(callback function)的，有MVC模型的，观察者模式的。。。

Qt 发明了 signals & slots 机制，使交互机制变得灵活、直观、简单。

信号(signal) 就是在特定情况下发生的事件。类似广播出去。

槽(slot) 就是一个响应函数。

信号和槽是完全隔离的，信号发出者并不知道该信号会被谁处理。

槽是一个有某种约定的普通函数，它可以被直接调用，也可以被关联到槽。

关联的方法：

QObject::connt(sender, SIGNAL(信号), receiver, SLOT(槽函数));

关联约定

• 一个信号可以关联到多个槽
• 多个信号可以关联到一个槽
• 一个信号可以关联到另一个信号
• 信号的参数与槽的参数要匹配（信号至少能满足槽的参数）
• 一般情况下，当信号发生时，槽函数会被立即触发，就像调用槽函数一样。

关联方法

下面举例常见的三种信号与槽的关联方法：

• 设计视图的Signals & Slots 面板

依次选 发送者，信号，接收者，槽

如果还觉得不直观，可以用可视化编辑

在弹出的框中

这两种方法本质上是一样的

只关联已有槽，删除也容易

• 添加新的槽和关联

在组件上： 右键 ｜ 转到槽，会自动添加槽，其名字是有规律的。

可以自己在槽函数中加入处理逻辑

槽的名字有特殊含义，Qt就是用这个名字来识别的

删除时，只要.h 和.cpp中删除了相应代码即可（关联是动态的）

• 手工生成槽函数和关联

手工添加槽函数：

void myCheck(bool b);

并在其中添加逻辑代码

手工添加关联：

ui->setupUi(this);
connect(ui->checkBox_3, SIGNAL(clicked(bool)),
        this, SLOT(myCheck(bool)));

手工删除槽和关联代码

实时效果反馈

1. 关于Qt信号和槽, 说法正确的是：__

• A 信号和槽的参数个数和格式必须严格匹配

• B 信号与槽必须一对一匹配

• C 可以用connect函数把信号和槽关联在一起

• D 槽必须有特殊的名字， 不能随意命名

2. 当使用UI设计器生成槽函数时，在哪个代码中，最终把信号和槽关联？：__

• A ui->setupUi(this);

• B Qt编译器内置的机制

• C ui(new Ui::Dialog)

• D 通过XML文件关联，运行时读取

答案

1=>C 2=>A

布局管理

早期的桌面应用，一般窗口的大小是固定的，这样就很少有布局的要求；

至多是组件间的对齐关系。

随着移动应用、嵌入设备、web应用的普及，桌面应用对布局的要求越来越强烈。

比如：横竖屏的切换，分辨率的调整。。。。

简单地说，布局管理，主要任务是处理：当窗体改变大小的时候，如何调整组件的位置，大小，以达到更人性化的呈现效果。

Qt提供了十分丰富的布局管理控制，主要在：Layouts 和 spacers 这两个面板中。

常用的布局

• vertical Layout 垂直布局
• Horizontal Layout 水平布局
• Grid Layout 网格布局

可以拖放布局到窗口中，再把组件拖放到布局里。

布局中可以再嵌套布局，形成十分复杂的行为

这是在水平布局中嵌套垂直布局的情况。

此外，也可以先放组件，以后再配布局。这通过工具栏上的布局按钮或右键菜单来完成。

占位器组件

俗称：弹簧

• horizonal spacer 水平点位器

• vertical spacer 垂直点位器

当需要让一些组件靠某一边对齐时，可以用弹簧配合组件的其它属性来完成。

当布局改变大小的时候，组件需要响应这种变化。

其主要的影响因素是：

整个窗体上的最外层布局

整个窗体上可以有一个最外层的布局，当窗体改变大小的时候，这个布局跟随调整大小。

可以选中窗体，再用工具栏的布局按钮来完成，

也可以在窗体上，右键 | 布局 ，来选相应的菜单。

如果需要取消窗体上的最高布局，同样方法，选：“打破布局”。

综合示例

实时效果反馈

1. 关于Qt常用的布局组件, 说法==错误==的是：__

• A 垂直布局

• B 水平布局

• C 网格布局

• D 流布局

2. 如何让一个按钮，总是在窗体的右下角：__

• A 直接拖放到右下角

• B 左边加弹簧，水平布局

• C 左边加弹簧，水平布局，外面再其上加弹簧，垂直布局

• D 无法实现

答案

1=>D 2=>C

可视化UI设计

UI可视化设计的本质是生成一个XML文件。

Qt 可以设计模式和源文件模式来查看这个XML文件

ctrl + F2 切换到源码模式

ctrl + F3 切换到设计模式

我们不要直接去修改 XML 文件，而应该在界面上修改。

• 通过 Container 可以实现“国中国”的效果。

比如，对：checkBox 和 radio Button 的分组，很常用。

container 本身可以设布局方式，如果不设，然后却参加到另一个布局中，可能会有怪异的表现。

container 可以看作窗体中的一个子窗体

• 伙伴关系

  

点击伙伴关系按钮，可以设置Label与其它组件的伙伴关系。

设置伙伴关系的目的是：可以通过快捷方式让焦点快速跳到伙伴组件上。

直接在界面上通过拖放来设置伙伴关系

• Tab序

通过按tab键，可以让焦点在各个输入组件间跳，其顺序是可以控制的。

Qt 并不是新的语言，虽然我们用了可视化设计，没有自己写代码，但这只不过是Qt 替我们堆砌了一些冗长、乏味的代码，最终依然是需要生成了cpp的源码才能工作的。

而这些代码（如果我们需要查看）在 ui_xxx.h 中

这个文件不在项目的源文件中，是每次编译之前动态生成的。

xxx.ui 是一个标准的XML文件，Qt对这个文件进行解析，生成了 ui_xxx.h

实时效果反馈

1. UI可视化设计的原理, 说法正确的是：__

• A 界面设计，产生了XML文件，预处理为 .h 文件

• B 界面设计，直接产生了cpp文件

• C 界面设计，直接产生了 .h 文件

• D 界面设计，直接产生了 二进制码

2. UI可视化设计中，设置伙伴关系的主要目的是：__

• A 使标签跟随输入组件移动

• B 使输入组件有一定的顺序

• C 使标签的样式与伙伴一致

• D 快速定位到输入组件

答案

1=>A 2=>D

代码化UI设计

虽然Qt提供了可视化的UI设计方式，但有时也会用到代码直接设计UI的情景。

直接用代码与可视化 —> XML—> ui_xxx.h 的本质是一样。

用代码会更繁琐一些，但控制能力，灵活性也会更强一些。

其基本步骤大体分为：

• 建立界面元素的对象，及其关系
• 编写槽函数
• 建立槽函数与信号的连接关系

目标

功能很简单，点击radioButton，让下面的文本框中的字变颜色。

实现

新建项目

选QWidget为继承类

widget.h 文件

#ifndef WIDGET_H
#define WIDGET_H
#include <QWidget>
#include <QRadioButton>
#include <QPlainTextEdit>
#include <QButtonGroup>
class Widget : public QWidget
{
    Q_OBJECT
public:
    Widget(QWidget *parent = 0);
    ~Widget();
private slots:
    void mySetColor(int id);
private:
    QRadioButton* rbtnBlack;
    QRadioButton* rbtnRed;
    QRadioButton* rbtnBlue;
    QPlainTextEdit* txtEdit;
    QButtonGroup* btngColor;
};
#endif // WIDGET_H

widget.cpp 文件

#include "widget.h"
#include <QHBoxLayout>
#include <QVBoxLayout>
#include <QButtonGroup>
Widget::Widget(QWidget *parent)
    : QWidget(parent)
{
    rbtnBlack = new QRadioButton("黑");
    rbtnRed = new QRadioButton("红");
    rbtnBlue = new QRadioButton("兰");
    QHBoxLayout* lay = new QHBoxLayout;
    lay->addWidget(rbtnBlack);
    lay->addWidget(rbtnRed);
    lay->addWidget(rbtnBlue);
    txtEdit = new QPlainTextEdit;
    txtEdit->setPlainText("haha \n测试");
    QFont font = txtEdit->font();
    font.setPointSize(20);
    txtEdit->setFont(font);
    QVBoxLayout* lay2 = new QVBoxLayout;
    lay2->addLayout(lay);
    lay2->addWidget(txtEdit);
    setLayout(lay2);
    btngColor = new QButtonGroup(this);
    btngColor->addButton(rbtnBlack,0);
    btngColor->addButton(rbtnRed,1);
    btngColor->addButton(rbtnBlue,2);
    connect(btngColor, SIGNAL(buttonClicked(int)),
            this, SLOT(mySetColor(int)));
}
Widget::~Widget()
{
}
void Widget::mySetColor(int id)
{
    QPalette pl = txtEdit->palette();
    switch (id) {
    case 0:
        pl.setColor(QPalette::Text, Qt::black);
        break;
    case 1:
        pl.setColor(QPalette::Text, Qt::red);
        break;
    case 2:
        pl.setColor(QPalette::Text, Qt::blue);
    }
    txtEdit->setPalette(pl);
}

实时效果反馈

1. 下列说法正确的是：__

• A 所有的界面效果都可以通过可视化UI设计来完成

• B 所有的界面效果都可以通过纯代码UI设计来完成

• C 使用可视化UI设计后，很难再用代码介入

• D 代码化设计UI运行效率更高

2. 关于QButtonGroup 说法正确的是：__

• A QButtonGroup 是可视化组件，类似groupBox

• B QButtonGroup 是逻辑组件，只能用代码操控

• C QButtonGroup 一般需要自已 delete

• D QButtonGroup 可以调整布局

答案

1=>B 2=>B

菜单

主窗口与对话框窗口的区别在于：

主窗口中，一般有主菜单，工具栏，状态栏。

主菜单可以在设计时生成，也可以用代码动态生成或修改。

• 设计时

  

• 代码生成也可以，也可生成多级菜单

核心概念是 Action

Action

action 代表一个动作项，可以是一个主菜单的末级，也可以右键弹出菜单的末级。

也可以把Action放到工具栏上，

这样，在多个操作路径下，可以对应同一个Action

而Action的信号可以关联到槽。

Action还可以设置统一的图标，统一的悬浮提示，甚至使用统一的皮肤管理。

Action 可以独立于主菜单而存在

右键菜单

有多种方法，一种方法是：重载QMainWindow的contextMenuEvent函数

在其中实现自己的逻辑。

可以先在界面上建立Action

然后，用代码构建右键菜单，再把Action加入到菜单的末级

QMenu m;
QMenu m1("1111");
m1.addAction(ui->actionmy1);
m1.addAction(ui->actionmy2);
m.addMenu(&m1);
m.addAction(ui->actiona11);
m.exec(QCursor::pos());

实时效果反馈

1. 关于Action, 说法正确的是：__

• A Action 是一种QWidget

• B Action可以单独创建，可以被主菜单、工具栏、右键菜单共享

• C Action有特定成员函数，点击时被触发

• D Action只管理文字，不包含图标

2. 在创建右键菜单时，QMenu为什么可以用栈对象？__

• A exec 在用户选菜单的过程中是阻塞的，QMenu对象在这期间一直有效

• B QMenu 是特殊对象，contextMenuEvent 函数结束时，它仍在

• C QMenu 不应该这样用，虽然没报错，但操作菜单时，QMenu已经销毁

• D QMenu虽然销毁了，但Action还在

答案

1=>B 2=>A

Qt类库概述

Qt在使用类库的方式，在标准的c++基础上进行了扩展。

引入了元对象系统，信号与槽，属性等特征。

元对象编译器（Meta Object Compiler）是一个预处理器，在编译前把Qt特性先预处理为：c++可以识别的标准代码。

QObject 是所有使用元对象系统的类的基类。

要求其内部声明 private 的： Q_OBJECT 宏。

元对象系统提供了很多特性。

除了信号与槽外，另一个常用的是：属性

很多面向对象的高级语言，比如 delphi，都提供了属性这一个概念。

c++ 没有在语言层面提供这一概念。

Qt 通过元对象系统弥补了这一缺憾。

简单地说，属性，就是对象的虚假的“成员变量”

从外部的观点来看，某个对象具有某种类型的变量，但实际上，

对它的读写操作可能分别由不同的成员函数来完成。

这有什么用处呢？

1. 面向对象的封装原则。对象的属性好比智能类型，不只简单的读写，至少能防误

   比如： age， 设置为负数，或其它不合理数值，会被发现并拒绝

2. 对象使用的一致性。比如，在脚本语言中，如何操作c++对象，需要一致的方法。

3. 对属性的读写可能引发一系列复杂的动作。

   比如：写age的值，可能顺带引发一个信号。

   这样，我们在修改一个对象的属性的时候，可能触发一系列的动作。

属性示例

新建一个 QBoy 类，包含一个age 属性

可以 读， 可以写，

写入成功的时候，触发一个 ageChanged 信号

最后，我们把这个信号 和 一个自己定义的槽关联 起来

使用属性需要在类中用 Q_OBJECT 宏

然后用宏添加属性：

Q_PROPERTY(int age READ age WRITE setage NOTIFY ageChanged)

Qt类库

Qt不仅仅是提供了跨平台GUI快速开发能力，

其类库还包含了很多其它功能：

• 基本模块
• 附加模块
• 增值模块
• 技术预览模块

基本模块中的内容已经很丰富

实时效果反馈

1. 关于属性, 说法正确的是：__

• A 属性是c++11引入的特性

• B 属性是所有面向对象语言都提供的特性

• C 属性是Qt通过元对象机制提供的特性

• D 属性就是成员变量

2. 下列哪个功能不在Qt的基本模块中：__

• A Qt GUI

• B QML

• C Qt SQL

• D Qt SVG

答案

1=>C 2=>D

Qt全局定义

Qt的全局定义都在头文件中，包括常量、宏、函数、模板等。

数据类型

更明确的，平台无关的类型定义

qint8, qint16, qint32, qint64, quint8, quint16….

qreal, qfloat16 见名知义

函数或模板函数

常用的

宏定义

常用的

• QT_VERSION, QT_VERSION_STR

版本信息，可用于条件编译

• Q_UNUSED(name)

假装使用一个变量，防止警告信息

• forever 无限的死循环

• foreach 对容器类的遍历

  用于容器的遍历

c++11 已经引入了 for(:) 语法，可以不用这个

• qDebug

显示调试信息，可以通过 Qt_NO_DEBUG_OUTPUT 关闭显示

容器类

Qt 提供了很多模板类型的容器。

比STL的更灵巧、安全、易用。

（效率不作为首要考虑，因为GUI本身不是效率优先的应用）

最大特色是：存储优化、线程安全

也是分为：顺序容器和关联容器。

示例

QList<QString> a;
a.append("123");
a.prepend("abc");
a.insert(1,"xxx");
a[1] = "ttt";
for(auto i: a){
    qDebug() << i;
}

QQueue<int> a;
a.enqueue(1);
a.enqueue(2);
a.enqueue(3);
while(!a.isEmpty()){
    qDebug() << a.dequeue();
}

实时效果反馈

1. a,b 是浮点数，Qt编程中, 解决避免浮点数精确比较的方案是：__

• A fAbs(a-b) < 1e-6

• B a === b

• C a ~= b

• D aFuzzyCompare(a,b)

2. 使用Qt容器，最重要的理由是：__

• A 运行速度快

• B 语法更易懂易用

• C 占用存储空间小

• D 线程安全

答案

1=>D 2=>D

Qt容器

Qt 容器从逻辑上看，与STL容器差异不大，但更多考虑了易用性、便利性。

简单示例

QSet<int> a;
a << 1 << 2 << 3;
QSet<int> b;
b << 3 << 4 << 5;
auto c = a + b;
qDebug() << c;
auto d = a - b;
qDebug() << d;
qDebug() << a.contains(2);

对自定义的类型

struct Stu{
    Stu(const QString& s, int a){
        name = s;
        age = a;
    }
    bool operator==(const Stu& t) const{
        return name == t.name && age == t.age;
    }
    QString name;
    int age;
};
QDebug operator<<(QDebug dbg, const Stu& t)
{
    dbg << "Stu(" << t.name << "," << t.age << ")";
    return dbg;
}
uint qHash(const Stu& stu)
{
    return qHash(stu.name) + stu.age;
}

使用：

QSet<Stu> a;
a << Stu("zhang", 15) << Stu("Li", 12);
a << Stu("zhang", 15);
qDebug() << a;