C++ 的五个普遍误解(2):垃圾回收
2014-12-25 21:16
351 查看
C++ 的五个普遍误解(2):垃圾回收
2014/12/22 | 分类: C/C++, 开发 | 2条评论 | 标签: BJARNE STROUSTRUP, C++, 垃圾回收
分享到:13
Java
Socket应用---通信是这样练成的
洪大师带你解读Symfony2框架
用字体在网页中画ICON图标
快速入门ThinkPHP框架—理论篇
本文由 伯乐在线 - Sheng
Gordon 翻译,黄利民 校稿。未经许可,禁止转载!
英文出处:Bjarne Stroustrup。欢迎加入翻译小组。
[编注:为了增加您冬天阅读的乐趣,我们很荣幸的奉上Bjarne Stroustrup大神的这个包含3个部分的系列文章。第一部分在这里;第三部分将在下个周一发布,即在圣诞节之前完成这个系列。请欣赏。]
1. 简介
本系列包括 3 篇文章,我将向大家展示并澄清关于C++的五个普遍的误解:
1. “要理解C++,你必须先学习C”
2. “C++是一门面向对象的语言”
3. “为了软件可靠性,你需要垃圾回收”
4. “为了效率,你必须编写底层代码”
5. “C++只适用于大型、复杂的程序”
如果你深信上述误解中的任何一个,或者有同事深信不疑,那么这篇短文正是为你而写。对某些人,某些任务,在某些时间,其中一些误解曾经只是正确的。然而,在如今的C++,应用广泛使用的最先进的ISO C++ 2011编译器和工具,它们只是误解。
我认为这些误解是“普遍的”,是因为我经常听到。偶尔,它们有原因来支持,但是它们经常地被作为明显的、不需要理由的支持地表达出来。有时,它们成为某些场景下不考虑使用C++的理由。
每一个误解,都需要一大篇文章,甚至一本书来澄清,但是这里我的目标很简单,就是抛出问题,并简明地陈述我的原因。
前两个误解在我的第一篇文中呈现。
4. 误解3:“对可靠的软件,你需要垃圾回收”
在回收不再使用的内存上,垃圾回收做的很好,但是并不完美。它并非灵丹妙药。因为内存可以被间接地引用,并且很多资源并不是普通内存。考虑:
对于依赖垃圾回收的语言和系统,常规的解决方法是消除delete(它很容易被遗忘,导致泄漏)和析构函数(因为支持垃圾回收的语言很少有析构函数,而最好避免使用“finalizers”,因为它在逻辑上容易被取巧,并经常损坏性能)。内存回收器能够回收所有内存,但是我们需要用户手动(代码)关闭文件,以及释放与流相关的非内存资源(如锁)。因此,内存是自动(此例中很完美)回收的,但是需要手动管理其他资源,从而存在错误和泄露的可能性。
C++中常用和推荐的方法是使用析构函数,来保证资源被回收。典型的,在此例和通用技术中,这类资源在构造器中申请,并遵循有着笨拙名字的“资源申请即初始化”(RAII)原则。在user()中,flt的析构函数隐式地调用了流is和os的析构函数。这些析构函数依次关闭文件并释放流相关的资源。delete对*p做同样的操作。
有经验的现代C++11用户会注意到,user()相当笨拙并容易出错。这样会更好一些:
然而,我们仍然可以看到new,这个解决方案有点啰嗦(Filter类型重复了两次),并且将普通指针构造(通过new)和智能指针(这里是unique_ptr)分离开阻止了一些有效的优化。我们可以使用C++14中的辅助函数make_unique来改进,它构造一个指定类型的对象,并返回一个unique_ptr:
除非我们在语法上真正地需要第二个Filter指针(这不太可能),否则这样会更好:
但是Filter的析构函数做什么?它释放Filter拥有的资源;即,它关闭文件(通过触发它们的析构函数)。实际上,这是隐式完成的,因此除非有其他需要,我们可以忽略Filter析构函数的显式声明,让编译器来处理它。因此,我需要编写的只有:
这是我理想的资源管理方式。它不单单处理内存,同时也处理通用(非内存)资源,例如文件句柄,线程句柄和锁。但是这就够了吗?怎么处理需要从一个函数传递到另一个函数的对象?那些没有明显单独拥有者的对象呢?
4.1传递拥有关系:move
让我们先来看一看把对象从一个代码块传递到另一个代码块的问题。关键问题是,在不复制或者错误使用指针导致严重性能问题的前提下,如何从一个代码块中得到大量信息。使用指针的传统方式是:
我可能会使用一个shared_ptr或者unique_ptr,来明确表明对创建对象的拥有关系。例如:
老练的C++用户指出,一个好的编译器能够完全消除返回值复制操作(这个例子中是,消除掉4个字的赋值和析构函数调用)。然而,这是依赖于实现的,我不喜欢我的基本编程技术的性能依赖于独立编译器的聪明程度。更进一步,一个能够消除复制的编译器,也能够轻易的消除move。这里我们所拥有的,是一个简单、可靠和通用的方式,能够消除从一个代码块移动大量信息到另一个块的复杂度和代价。
通常,我们甚至不需要定义所有这些赋值和移动操作。如果一个类由拥有特定表现的成员组成,我们可以简单地依赖编译器自动生成的默认操作。考虑:
不是句柄的对象怎么处理呢?如果它们很小,像int,或者complex,不用担心。否则,把它们改成句柄,或者使用“智能”指针返回,如unique_ptr和shared_ptr。不要和“裸”操作new和delete混用。
不幸的是,类似我上面例子中的Matrix类不是ISO C++标准库的一部分,但是还是可以找到的(开源或者商业)。例如,在网上搜索“Origin Matrix Sutton”,阅读我The C++ Programming Language (Fourth Edition)的第29章,里面有如何设计类似矩阵类的讨论。
4.2 共享拥有关系:shared_ptr
在关于垃圾回收的讨论中,通常会注意到一个现象,即不是每一个对象都有唯一的拥有者。这意味着,我们必须确保当最后一个引用消除后,才能销毁/释放这个对象。在这个模型中,我们必须有一个机制,来保证当对象的最后一个拥有者销毁时,销毁这个对象。即,我们需要一种共享的拥有关系形式。假设我们有一个同步的队列,sync_queue,用作任务之间的通信。生产者和消费者都拥有一个指向sync_queue的指针:
它很简单并高效。它并不包含需要复杂运行时系统的垃圾回收器。更重要的是,它不仅仅回收sync_queue关联的内存资源,它同时回收内置在sync_queue中管理两个任务线程同步的对象(互斥,锁,或其他)。我们这里做到的,仍然不仅仅是内存管理,而是通用资源管理。“隐藏的”同步对象也被处理了,和前面例子中处理文件句柄和流缓冲区一样。
在围绕任务的某些范围内,我们可以尝试引入一个唯一的拥有者,从而不使用shared_ptr;但是这样做通常不简单。因此C++11同时提供了unique_ptr(对唯一拥有关系)和shared_ptr(对共享拥有关系)。
4.3 类型安全
我刚刚只提到了和资源管理有关联的垃圾回收。它还在类型安全中扮演一个角色。只要我们有显式的delete操作,它就可能被错误使用。例如:
4.4 总结:资源管理理念
对于资源管理,我认为垃圾回收是最后的选择,而不是“解决方案”或者理念:
1. 运用适当的抽象,递归和显式地处理自己拥有的资源。限定对象的作用域会更好。
2. 当你需要使用指针/引用语义时,使用诸如unique_ptr和shared_ptr的“智能指针”,来表明拥有关系。
3. 如果其他都行不通(如,你的代码是一个程序的一部分,而程序中使用了大量不满足语言资源管理和错误处理策略的指针),尝试“手动”处理非内存资源,并内嵌一个保守的垃圾回收器,用它来处理那些几乎不可避免的内存泄露。
这个策略完美吗?不,但它是通用的,并且简单。传统的基于垃圾回收的策略也不完美,并且它们不能直接处理非内存资源。
附言
系列的第一篇在这里误解1:“要理解C++,你必须先学习C”
误解2:“C++是一门面向对象的语言”
在下一篇中我将讲解
误解4:“为了效率,你必须编写底层代码”
误解5:“C++只适用于大型、复杂的程序”
相关文章推荐
- C++之父:C++ 的五个普遍误解(3)
- C++之父:C++ 的五个普遍误解(1)
- C++之父:C++ 的五个普遍误解(1)
- C++之父:C++ 的五个普遍误解
- 简单的c++垃圾回收站
- C++的垃圾回收——以对象管理内存
- 再论C++之垃圾回收(GC)
- 再论C++之垃圾回收(GC)
- 再论C++之垃圾回收(GC)
- [置顶]C/C++中几种经典的垃圾回收算法
- C++的垃圾回收机制
- 极品C/C++内存资源垃圾回收库注释源码
- Herbert Schildt对C++垃圾回收机制的实现
- C/C++中几种经典的垃圾回收算法
- C/C++中几种经典的垃圾回收算法
- c++垃圾自动回收类
- 再论C++之垃圾回收(GC)
- 再论C++之垃圾回收(GC)
- 再论C++之垃圾回收(GC)
- C++为什么不加入垃圾回收机制