std::vector中emplace_back与push_back的差异及emplace_back避坑场景

问题解答 #

问题1：编译与运行时行为差异的原因 #

这两个容器方法的核心区别在于参数处理和对象构造的方式：

1. push_back的逻辑：
   push_back要求传入的参数是容器元素类型（std::regex）的对象，或者能通过隐式转换生成该类型的对象。但std::regex既没有接受std::nullptr_t的构造函数，也不支持从nullptr隐式转换为自身，因此编译器直接找不到匹配的push_back重载，触发编译错误。

2. emplace_back的逻辑：
   emplace_back是在容器内部就地构造元素，它会把传入的参数直接转发给元素类型的构造函数。这里nullptr可以隐式转换成const char*，而std::regex恰好有一个接受const char*的构造函数，因此编译器匹配这个重载，编译通过。但运行时，std::regex的构造函数不允许传入空指针，属于非法输入，所以触发运行时错误。

问题2：应避免使用emplace_back的场景 #

虽然emplace_back能减少对象拷贝/移动的开销，但以下场景建议优先用push_back，避免踩坑：

• 参数存在隐式转换风险时：就像示例中的情况，参数能隐式转换成元素构造函数的某个重载类型，但该重载接受此参数是不安全的。emplace_back会绕过类型检查直接调用构造函数，而push_back会因为无法隐式转换提前在编译期报错。
• 元素构造函数有歧义重载时：如果元素类型有多个构造函数，转发的参数可能匹配到非预期的重载，构造出不符合预期的对象，这类错误往往要到运行时才会暴露。
• 需要明确控制对象构造时：如果希望先构造好对象再添加到容器，emplace_back的就地构造会隐藏构造细节，增加调试难度。
• 元素拷贝/移动开销可忽略时：对于int、std::string这类轻量级对象，push_back的拷贝或移动开销极小，emplace_back的性能优势可以忽略，反而不如push_back直观安全。
• 依赖explicit构造函数的约束时：如果元素类型的构造函数标记了explicit，目的就是防止意外的隐式转换，但emplace_back可以直接调用该构造函数，违背了explicit的设计初衷。

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