Qt Creator新建QObject子类时构造函数为何默认标记为explicit

我此前从未特意关注过explicit关键字，也不太确定在类头文件中看到该关键字时应当如何理解其作用。在梳理自身代码时我注意到，在Qt Creator中新建继承自QObject的类时，向导生成的构造函数总是会被explicit关键字修饰，示例代码如下：

#ifndef SNEED_H
#define SNEED_H

#include <QObject>

class Sneed : public QObject
{
    Q_OBJECT
public:
    explicit Sneed(QObject *parent = nullptr);

signals:

};

#endif // SNEED_H

我已有多年Qt开发经验，此前从未遇到过因QObject子类构造函数缺少explicit关键字而引发的bug，现有几个疑问：

• 如果去掉构造函数前的explicit关键字，可能会引发什么类型的bug？
• 为什么QObject子类的新建类向导会专门生成explicit关键字？
• 我个人猜测这和禁止拷贝初始化有关，毕竟QObject本身也不允许拷贝操作，但我并不确定该猜测是否正确。

你的猜测只对了一半，explicit在这里的核心作用是禁止隐式类型转换，和QObject本身删除拷贝构造函数的机制是两个独立的设计约束。

去掉explicit可能触发的bug #

QObject子类的构造函数签名是T(QObject* parent = nullptr)，因为参数带默认值，属于可以单参数调用的构造函数。如果不加explicit，C++编译器会允许完全超出你预期的隐式类型转换，都是实际开发里真会踩的坑：

• 意外构造临时对象
  比如你写了个处理Sneed对象的函数void processSneed(const Sneed& obj)，某次手误把一个QObject*类型的指针当参数传了进去，没有explicit的话编译器根本不会报错——它会自动拿这个指针当parent，隐式构造一个临时Sneed对象传给函数，等函数执行完临时对象直接销毁。这类问题没有编译提示，运行时逻辑完全跑偏，排查起来非常费劲。
  举个能直接复现的错误例子：

  void processSneed(const Sneed& obj);
  QObject* runtimeObj = getRuntimeObject();
  processSneed(runtimeObj); // 无explicit时这行完全能编译，悄悄构造了临时Sneed对象
  

• 错误的初始化逻辑
  如果你手滑写出Sneed s = someParentPtr;甚至Sneed s = nullptr;，没有explicit时这些写法都是合法的，会直接调用构造函数生成新对象，根本不是你以为的给已有对象赋值、绑定parent的逻辑。
• 模板/容器操作的非预期行为
  操作Qt容器或者STL容器时，比如调用append、contains等方法传入QObject*参数，模板推导过程会自动触发隐式转换，生成临时对象插入容器，平白无故触发对象构造、对象树父子关系绑定，甚至会引出内存管理问题。

向导默认加explicit的原因 #

这不是Qt的特殊要求，是C++的通用编码规范：

• 所有支持单参数调用的构造函数，除非你明确设计要支持隐式转换，否则都应该加explicit，从语法层面堵死上面说的隐式转换风险，属于零成本的防御性编程。
• Qt官方源码里所有QObject子类的构造函数，全都是加了explicit修饰的，IDE向导只是严格遵循官方的编码风格而已。
• 你多年开发没遇到相关bug，只是因为你平时写代码本来就不会主动写隐式转换的逻辑，但风险一直存在——不管是手误还是模板自动推导触发的隐式转换，编译器默认都不会拦，加个关键字就能把这类问题直接掐死在编译阶段。

关于「禁止拷贝初始化」的猜测 #

这个理解不准确：

• QObject本身确实通过Q_DISABLE_COPY宏删除了拷贝构造、拷贝赋值运算符，本来就不允许Sneed s = anotherSneedObj;这类同类型拷贝操作，这个约束和构造函数加不加explicit没有关系。
• explicit管的是从其他类型（比如这里的QObject*、nullptr_t）到当前类类型的隐式转换，不是同类型之间的拷贝逻辑。

补充一点：从C++11开始，explicit也可以修饰多参数构造函数和自定义类型转换运算符，核心作用始终没变：禁止编译器自作主张做隐式转换，把类型转换、对象构造的控制权完全交给开发者。

内容的提问来源于stack exchange，提问作者Anon