C++向线程函数传递参数

C++11的多线程，传递参数时，有几个细节需要注意，如果没有处理好，有可能会得不到预期结果，甚至发生崩溃。

值类型参数

值类型的参数，很简单，直接传递，无论线程是detach还是join，都能稳定运行。

引用类型参数

关于引用类型的参数，先要举一个例子，详细说明一下在创建thread对象时，thread构造函数做的事情。

class A
{
public:
    A(int a):m_a(a)
    {
        std::cout << "A的构造函数，线程：" << std::this_thread::get_id() << ",this:"<

在运行该程序前，我们可以预测一下代码执行流程。由于线程参数使用的是引用，所以子线程应该会引用主线程中创建的对象a。但实际运行结果并不是这样，运行结果如下：

从打印的日志，可以推断出代码的执行顺序为：

1. 主线程启动，线程ID为：5672。
2. 在主线程中创建A的对象a。
3. 在主线程中调用A的复制构造函数，这个是在创建线程对象时，线程的构造函数对传入的对象a进行复制。
4. 子线程对象被创建后，就开始执行，线程ID为：52336。
5. 子线程执行完毕。
6. 子线程中的资源被销毁，在主线程复制出来对象也被销毁，所以在子线程中会调用A的析构函数。
7. 主线程执行完毕，第2步中在主线程中创建出来的对象a，被销毁，所以在主线程中也会调用A的析构函数。

所以，虽然函数的第二个参数期待传入一个引用，但是std::thread的构造函数并不知晓，构造函数无视函数期待的参数类型，并“盲目”拷贝已提供的变量。如果你期望主线程和子线程引用的同一个对象，那这种传参方式肯定不是不行，这就必须使用std::ref()来进行包装：

std::thread threadF(f, std::ref(a));

运行结果如下：

但这也引出另外一个问题，上面代码，如果把线程以detach运行，对象a出了作用域，就会被析构，那么引用就会失效，线程中引用a时，就会造成不可预知的问题。

隐式类型转换造成的隐患

众做周知，默认情况下，如果传递的实参类型与形参类型不匹配，则c++会尝试把实参类型转为形参类型，比如：

class A
{
public:
    A(int a):m_a(a)
    {
        std::cout << "A构造函数，线程：" << std::this_thread::get_id() << ",this:"<

程序运行结果如下：

可以看出程序的运行结果如下：

1. 主线程启动，线程ID为：46424。
2. 在主线程中构造子线程，把int型a，传入子线程的构造函数中
3. 在子线程中创建A的临时对象，线程ID为：44148
4. 线程函数启动，并执行。
5. 子线程执行完毕，A的临时对象被析构。

上面的实例看起来是没有问题，但存在一个隐患，临时对象的创建是在子线程中进行的，如果指向动态变量的指针作为参数传递给线程，且在子线程还没有使用该指针指向的资源之前，资源就被释放掉了，程序就发生不可预知的后果。拿官方示例说明：

void f(int i,std::string const& s);
void oops(int some_param)
{
  char buffer[1024]; // 1
  sprintf(buffer, "%i",some_param);
  std::thread t(f,3,buffer); // 2
  t.detach();
}

buffer是一个局部的字符数组变量，f需要一个const string的引用，主线程构造子线程t时，会把buff传入，即const char*，在子线程中会把const char*隐式转化为string。由于这个隐式转换是在子线程中进行的，所以时机不能确定，有可能发生在buff被释放后，就会造成崩溃。
所以不建议在子线程中进行隐式类型转换，尽量在主线程中显式类型装换。

void f(int i,std::string const& s);
void not_oops(int some_param)
{
  char buffer[1024];
  sprintf(buffer,"%i",some_param);
  std::thread t(f,3,std::string(buffer));  // 使用std::string，避免悬垂指针
  t.detach();
}