C++模板栈push扩容的指针用法是否存在风险、低效或内存泄漏？

核心问题梳理 #

1. 异常安全缺失，可直接引发内存泄漏 #

你在扩容段的实现顺序存在严重风险：

// 原代码扩容片段
T* temp = arr;
arr = nullptr; // 无意义的赋值
arr = new T[max_s];

• 如果new T[max_s]分配失败抛出std::bad_alloc，此时旧内存的地址仅保存在局部变量temp中，异常向上抛出后栈展开，temp被销毁，你将完全丢失旧内存的指针，无人能释放这块堆内存，直接造成内存泄漏。
• 后续for循环中如果任意元素的赋值运算符抛出异常，此时新内存的地址已经赋值给arr，旧内存的地址仅存在于temp中，同样会在异常抛出后丢失，造成旧内存泄漏。
• 类层面还存在更基础的风险：未实现自定义析构函数、拷贝/移动构造、拷贝/移动赋值运算符（违反C++三/五法则），哪怕push逻辑完全正确，也会出现堆内存永久泄漏、浅拷贝导致的同一块内存二次释放、多个Stack实例共用同一块内存的未定义行为。此外类中还有未被使用的T def_val成员，会额外增加每个实例的构造、析构开销，属于无意义冗余。

2. 效率低下的实现细节 #

• 多余的对象构造开销：new T[max_s]会先默认构造全部max_s个T对象，之后你再将前size个对象覆盖为旧栈中的元素，剩余max_s - size个默认构造的对象完全是无意义的开销，大尺寸T类型下成本会非常高。
• 扩容因子过小：每次仅扩容5个元素，当栈元素数量较多时，会频繁触发「申请新内存-拷贝旧数据-释放旧内存」的全流程，远低于倍增扩容（1.5/2倍容量）的效率。
• 无移动优化：拷贝旧元素时直接用赋值操作，对于管理了外部资源的T类型，完全可以用移动语义将旧内存中的元素转移到新内存，避免不必要的深拷贝开销。

3. 无意义的冗余操作 #

arr = nullptr这行代码没有任何实际作用，既不能提升安全性，反而直接放大了内存泄漏的风险，属于完全多余的逻辑。

合规扩容逻辑参考 #

应优先保证旧内存的可追溯性，调整操作顺序为：

1. 先申请新的内存块
2. 拷贝/移动旧元素到新内存
3. 释放旧内存块
4. 再将arr指针指向新内存
   同时需要配套实现析构函数、拷贝/移动相关的特殊成员函数，避免类层面的未定义行为。

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