Effective STL 条款8:不要把auto_ptrs放入容器

最新推荐文章于 2025-12-04 17:39:28 发布

原创最新推荐文章于 2025-12-04 17:39:28 发布 · 2k 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#编译器 #工作 #网络

作者原本不想翻译Effective STL，因部分条款网上缺失才动手。文中提到包含auto_ptr的容器（COAPs）在STL中被禁止，编译器不会编译此类代码，且标准委员会未解释原因，编译器应处理好相关工作。

本来没有打算自己翻译Effective STL的，怕影响大家情绪:)，只是发现有些条款在网络上找不到，只好自己翻译了。--Winter

坦白的讲,这个条款不应加入本书，因为包含atuo_ptr的容器(COAPs)本来在STL中就是禁止的。就算你这么用了，编译器也不会编译你的代码。而标准委员会也没有解释为什么不能这样。对于COAPs我应该什么都不用说的，因为你的编译器应该替你做好了一切工作，所有这种类似的代码都不应该被编译。

详细阅读 "Effective STL 条款8:不要把auto_ptrs放入容器"

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

WinterTree

关注关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
1
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

条款8:不要把auto_ptr放入容器

Black_Man的专栏

07-08

1102

条款8:不要把auto_ptr放入容器作者： winter 本来没有打算自己翻译Effective STL的，怕影响大家情绪:)，只是发现有些条款在网络上找不到，只好自己翻译了。--Winter坦白的讲,这个条款不应加入本书，因为包含atuo_ptr的容器(COAPs)本来在STL中就是禁止的。就算你这么用了，编译器也不会编译你的代码。而标准委员会也没有解释为什么不能这样。对于COAP

C++规范编码引涉语法点之（5）不要在STL容器中存储 auto_ptr 对象 & auto_ptr的缺陷

qfturauyls的博客

07-09

440

【导入】使用auto_ptr类的限制（auto_ptr的缺陷） 1）不要使用auto_ptr对象保存指向静态分配对象的指针，否则，当auto_ptr对象本身被撤销的时候，它将试图删除指向非动态分配对象的指针，导致未定义的行为。 2）永远不要使用两个 auto_ptrs 对象指向同一对象，导致这个错误的一种明显方式是，使用同一指针来初始化或者 reset 两个不同的 auto_ptr对象。另一种导致这个错误的微妙方式可能是，使用一个 auto_ptr 对象的 get 函数的结果来初始化或者 reset另一个

1 条评论您还未登录，请先登录后发表或查看评论

std::auto_ptr和tr1::shared_ptr的用法

mniwc的专栏

03-21

3406

1>为防止资源泄漏,请使用RAII对象,它们在构造函数中获得资源并在析构函数中释放资源.如下:void Func(){ Investment* pInv = createInvestment();//createInvestment是工厂方法.返回一个堆上的对象指针 ...; delete pInv;}这时当在...区域一个过早的return,continue,goto语句退出.这样在区域内的语句抛出异常,这样delete就被忽略过去,这时就发生了内存泄漏,我们泄漏的不只是内含对象的那块内存,还

《Effective STL》条款解读

zhuikefeng的博客

08-22

1062

条款01：慎重选择容器类型 vector、list和deque有着不同的复杂度，vector是默认使用的序列类型。当需要频繁在序列中间做插入和删除操作时，应使用list。当大多数插入和删除操作发生在序列的头部和尾部时，应使用deque。可以将容器分为连续内存容器和基于节点的容器两类。连续内存容器把元素存放在一块或多块（动态分配的）内存中，当有新元素插入或已有的元素被删除时，同一块内存中的其他元素要向前或向后移动，以便为新元素让出空间，或者是填充被删除元素所留下的空隙。这种移动会影响到效率和异常安全性。

effective stl(容器部分总结)

xietingcandice的专栏

08-01

1114

还是很喜欢effective部分的书，看了好几遍，这里把stl中和容器相关的一些基本的注意的点进行介绍总结，之后对迭代器等进行总结 1 对序列容器中需要逐个删除的时候，不能像关联容器那样事先对迭代器进行＋＋操作，因为删除一个迭代器，会使他自己无效，后面的迭代器也无效，所以应该保存删除erase返回的下一个指针的值。而关联容器中并不会导致后面的迭代器无效的情况 2 在stl中如果对容器内对象

「经典研读」Effective STL

士全的优快云，用心连载，欢迎关注

02-19

437

研读 Effective STL 时的一些心得和记录，不一定正确，请酌情参考，从容器、迭代器和算法等几个方面展开

【绝版C++书籍】《Effective STL》读书笔记

Elias_Liu的博客

09-21

1657

《Effective STL》读书笔记写在前面《Effective STL》中可能过时的内容1 容器第1条：慎重选择容器类型。第2条：不要试图编写独立于容器类型的代码。第3条：确保容器中的对象拷贝正确而高效。第4条：调用empty而不是检查size()是否为0。第5条：区间成员函数优先于与之对应的单元素成员函数。第6条：当心C++编译器最烦人的分析机制。第7条：如果入容器中包含了通过new操作创建的指针，切记在容器对象析构前将delete掉。第8条：切勿创建包含auto_ptr的容器对象。第9条：慎重选择删

Effective Modern C++42招独家技巧助你改善C++11和C++14的高效用法笔记

最新发布

weixin_50606255的博客

12-04

182

我们在看视频时经常会看到黑客入侵别人电脑会在屏幕上显示一串代码，并且代码不断插入自动滚动，看起来很厉害的样子，现在就在此纪录实现此功能：

TCP，UDP使用socket编程流程

weixin_46855342的博客

12-01

163

UDP socket编程流；

多厂商配置对齐器：AI 如何在 Cisco / Huawei / Juniper 间做语义映射

oQianYuan的博客

12-03

740

这些模型上的差异，使得简单的“语法级模板替换”永远会失败。“给我一个能阻止外网 SSH 进入财务内网的安全策略，并在所有出口设备上同步生效（Cisco/Huawei/Juniper 各一套）。需特别注意 mask 类型的标准化，AI 内部统一用 CIDR (/24) 或 Wildcard 存储，渲染时再转换。/* 假设 Gi0/0 属于 untrust，内网为 trust */在过去十几年里，不同厂商 CLI 的“语法差异”从来不是最难的问题。AI 在多厂商对齐中的真正价值，是负责把。

【Android逆向工程】第19章：协议分析与接口还原

w987333120的博客

12-03

378

本文介绍了网络协议分析的关键技术与工具。主要内容包括HTTP/HTTPS协议分析流程、常用抓包工具配置（Charles/Burp Suite）、协议格式解析方法以及签名算法还原技术。通过示例展示了完整的请求/响应分析过程，涵盖请求行、请求头、请求体的解析方法，特别关注签名相关字段的识别。文章还提供了Python代码示例演示如何自动分析HTTP请求结构，帮助逆向工程师理解业务逻辑、还原接口签名算法并实现自动化脚本。

网络安全（黑客技术）—2025自学手册

2401_84760527的博客

11-24

1630

网络安全可以基于攻击和防御视角来分类，我们经常听到的 “红队”、“渗透测试” 等就是研究攻击技术，而“蓝队”、“安全运营”、“安全运维”则研究防御技术。走安全行业的工程方向的，技术上面其实有很大的重叠性，抛开甲乙方、岗位名称、岗位职责等因素来看，作为学技术的，也根据以往我们给学员推荐就业和入职情况来看，只要好好掌握以下几种技术（网络协议与安全设备、Linux操作系统、Web服务部署/开发、主流渗透测试/安全工具、一门及以上的编程语言）中的2到3个，都可以较好的胜任工作需求。

std::auto_ptr<Graphics::TBitmap> TheImage(new Graphics::TBitmap()); std::auto_ptr<TMy_BltBitmap> OverlayImage(new TMy_BltBitmap()); 编译时产生错误[bcc64x Error] mycgauges.cpp(84): no member named 'auto_ptr' in namespace 'std'

07-22

<think>我们被要求解决用户关于std::auto_ptr编译错误的问题。根据用户描述，错误是“no member named 'auto_ptr' in namespace 'std'”。根据引用[1]，我们知道auto_ptr在C++11中被弃用，并在C++17中被移除。因此，如果用户使用的编译器支持C++17或更高版本，并且没有指定使用旧的标准，那么std::auto_ptr将不可用。解决方案： 1. 如果用户不需要使用C++17或更高版本，可以尝试将编译标准设置为C++11之前的标准（如C++98）或C++11（但注意C++11中auto_ptr已被弃用，但仍然可用）。但是，这种做法不推荐，因为auto_ptr有已知的设计缺陷。 2. 推荐的做法是使用C++11引入的替代智能指针：std::unique_ptr、std::shared_ptr和std::weak_ptr。根据引用[1]中的对比，我们可以知道： - std::unique_ptr：独占所有权的智能指针，是auto_ptr的替代品，但更安全，不支持拷贝，只支持移动。 - std::shared_ptr：共享所有权，通过引用计数管理。 - std::weak_ptr：配合shared_ptr使用，解决循环引用。因此，我们应该建议用户将auto_ptr替换为unique_ptr（如果场景是独占所有权）或其他合适的智能指针。具体步骤： a. 检查代码中auto_ptr的使用场景，确定所有权语义。 b. 将std::auto_ptr替换为std::unique_ptr（注意：需要包含头文件<memory>）。 c. 注意unique_ptr与auto_ptr在拷贝语义上的区别：unique_ptr禁止拷贝，只能移动。因此，如果原有代码中有拷贝auto_ptr的操作，需要修改为移动（使用std::move）。示例：原auto_ptr代码： std::auto_ptr<int> p1(new int(10)); std::auto_ptr<int> p2 = p1; // 此时p1变为空，p2拥有资源替换为unique_ptr： std::unique_ptr<int> p1(new int(10)); std::unique_ptr<int> p2 = std::move(p1); // 需要显式使用std::move d. 如果用户使用的是较新的编译器（如gcc/clang高版本或MSVC），并且指定了C++17或更高标准，那么std::auto_ptr确实不可用，所以替换是必须的。另外，引用[2]中提到，在VS2015中使用unique_ptr时，如果提示“'unique_ptr' is not a member of 'std'”，可能是因为没有包含头文件<memory>或者没有启用C++11及以上标准。因此，我们也需要提醒用户包含头文件并设置正确的编译标准。总结步骤： 1. 包含头文件：`#include <memory>` 2. 将`std::auto_ptr`替换为`std::unique_ptr`（或根据所有权需求选择其他智能指针） 3. 调整拷贝操作：使用std::move进行所有权的转移 4. 确保编译器支持C++11或更高标准，并在编译时指定标准（例如：-std=c++11）注意：如果用户使用的是旧代码，并且有多个地方使用auto_ptr，替换可能需要仔细检查所有权转移的地方，因为auto_ptr的拷贝构造函数会转移所有权，而unique_ptr的拷贝构造函数被删除，只能通过移动构造或移动赋值来转移所有权。最后，我们还可以提醒用户，auto_ptr已经被弃用并移除，使用unique_ptr是更安全、更现代的做法。生成相关问题： 1. 如何将std::auto_ptr替换为std::unique_ptr？ 2. std::unique_ptr和std::auto_ptr的主要区别是什么？ 3. 在C++17中，为什么不能使用std::auto_ptr？</think>### std::auto_ptr 编译错误解决方法当遇到 `no member named 'auto_ptr' in namespace 'std'` 编译错误时，根本原因是 `std::auto_ptr` 已在 C++17 标准中被**正式移除**（C++11 起已被弃用）[^1]。以下是具体解决方案： --- ### 解决方案分步说明 1. **确认编译器标准** 检查编译选项是否指定了 **C++17 或更高版本**（如 `-std=c++17`）。若必须使用旧标准，可降级至 C++14 或 C++11（不推荐长期使用）。 2. **替换为现代智能指针**（推荐方案）根据所有权需求选择替代方案： - **独占所有权** → 使用 `std::unique_ptr` ```cpp // 替换前 std::auto_ptr<MyClass> ptr(new MyClass); // 替换后 std::unique_ptr<MyClass> ptr(new MyClass); // C++11 auto ptr = std::make_unique<MyClass>(); // C++14 更安全 ``` **注意**：`unique_ptr` **禁止隐式拷贝**，转移所有权需显式使用 `std::move`[^1]： ```cpp std::unique_ptr<MyClass> ptr2 = std::move(ptr); // 正确 ``` - **共享所有权** → 使用 `std::shared_ptr` ```cpp std::shared_ptr<MyClass> ptr = std::make_shared<MyClass>(); ``` 3. **包含必要头文件** 确保在代码中包含智能指针头文件： ```cpp #include <memory> // 所有智能指针均在此头文件 ``` 4. **处理特殊场景** - **数组类型**：`auto_ptr` 不支持数组，而 `unique_ptr` 可直接支持： ```cpp std::unique_ptr<int[]> arr(new int[10]); // 正确 ``` - **标准容器**：`auto_ptr` 与容器结合会引发未定义行为，`unique_ptr` 和 `shared_ptr` 可安全用于容器[^1]。 --- ### 关键差异总结 | 特性 | `std::auto_ptr` | `std::unique_ptr` | |---------------------|----------------------|-------------------------| | **拷贝语义** | 隐式转移所有权（危险） | 显式移动（`std::move`） | | **数组支持** | ❌ 不支持 | ✅ 支持 | | **标准容器兼容性** | ❌ 危险 | ✅ 安全 | | **标准状态** | C++17 移除 | C++11 引入 | --- ### 示例代码修正 ```cpp #include <memory> // 必须包含 int main() { // 错误：C++17 中 auto_ptr 已移除 // std::auto_ptr<int> old_ptr(new int(10)); // 正确：使用 unique_ptr 替代 std::unique_ptr<int> ptr(new int(10)); auto ptr2 = std::move(ptr); // 显式转移所有权 return 0; } ``` > **为何被移除？** > `auto_ptr` 的隐式所有权转移会导致代码逻辑错误（如意外悬空指针），且无法安全用于 STL 容器或异常处理场景。现代智能指针通过编译期安全检查解决了这些问题[^1][^4]。 --- ### 相关问题 1. 如何选择 `std::unique_ptr` 和 `std::shared_ptr`？ 2. 在 C++17 及以上版本中，如何处理遗留代码中的 `auto_ptr`？ 3. `std::unique_ptr` 如何避免内存泄漏？ [^1]: C++11 正式弃用 `auto_ptr`，推荐使用更安全的智能指针替代，如 `std::unique_ptr` 和 `std::shared_ptr`。 [^2]: 使用智能指针时需确保编译器支持 C++11 及以上标准并包含 `<memory>` 头文件。 [^4]: 智能指针的所有权转移机制直接影响资源释放时机，需显式处理所有权转移。