C++ std::fill与std::uninitialized_fill使用差异及常见问题

1. 未初始化原始内存上调用std::fill的后果 #

std::fill的核心语义是对迭代器范围内的每个已存在合法对象执行赋值操作（调用operator=），直接用在未初始化的原始内存上会触发以下问题：

• 对所有非平凡类型（含自定义构造/析构逻辑、虚函数、非POD成员的类型）属于明确的未定义行为。未初始化内存中不存在构造完成的合法对象，调用赋值运算符时，函数内部如果访问对象的成员变量（比如智能指针的指针值、容器的容量/长度字段），会直接读取到随机垃圾值，轻则逻辑错误、内存泄漏，重则程序崩溃、栈/堆内存被破坏。
• 哪怕是int、char这类平凡可复制的基础类型，这种写法也违反C++对象生命周期规则，编译器在O2/O3高优化等级下可能基于“目标范围一定存在合法对象”的假设做激进优化，生成不符合预期的执行代码。
• 如果类型的赋值运算符包含释放旧资源的逻辑（比如std::string、std::vector的赋值会先释放自身持有的堆内存），调用时会直接对垃圾地址做内存释放操作，必然触发段错误。

2. 已初始化内存上使用std::uninitialized_fill与std::fill的性能对比 #

首先需要明确：在存放了合法非平凡类型对象的已初始化内存上调用std::uninitialized_fill本身就违反函数前置条件，属于未定义行为——该函数只会在目标地址调用拷贝构造函数生成新对象，不会主动析构原有对象，会直接导致资源泄漏。仅从指令执行开销的角度对比，二者性能表现分以下几种情况：

• 对于平凡可复制类型（基础数值类型、无自定义构造/赋值/析构逻辑的POD结构体），主流标准库实现会对两个函数做完全等价的优化，最终都会生成批量按字/字节填充内存的CPU指令，性能没有任何差异。
• 对于非平凡类型：
  • 如果类型的拷贝构造函数和拷贝赋值运算符实现逻辑完全等价、无额外分支判断，开启优化后二者性能基本持平。
  • 绝大多数实际场景下的非平凡类型，拷贝赋值运算符会复用对象已申请的资源（比如容器赋值时如果原有容量足够就不会重新申请内存），而拷贝构造必须为新对象申请全新资源，此时std::uninitialized_fill的执行开销会明显高于std::fill。
  • 极个别特殊场景下如果拷贝赋值运算符包含额外的旧值校验、资源释放逻辑，而拷贝构造是极简实现，才可能出现std::uninitialized_fill更快的情况，但这种场景本身是错误用法，没有实际工程价值。

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