对象的共享所有权是不良设计的标志吗？

Question

背景:在阅读Stroustrup博士的论文和常见问题解答时,我注意到传奇的CS科学家和程序员提出了一些强烈的"意见"和很好的建议.其中一个是关于shared_ptrC++ 0x.他开始解释shared_ptr它以及它如何代表指向对象的共享所有权.在最后一行,他说,我引用:

.A shared_ptr代表共享所有权,但共享所有权不是我的理想:如果一个对象具有明确的所有者和明确的,可预测的寿命,那就更好了.

我的问题:RAII在多大程度上取代了垃圾收集等其他设计模式？我假设手动内存管理不用于表示系统中的共享所有权.

Answer 1

RAII在多大程度上取代了垃圾收集等其他设计模式？我假设手动内存管理不用于表示系统中的共享所有权

嗯,有了GC,你真的不必考虑所有权.只要有人需要,物体就会停留在周围.共享所有权是默认选择.

当然,一切都可以通过共享所有权来完成.但它有时会导致非常笨拙的代码,因为您无法控制或限制对象的生命周期.您必须在finally子句中使用C#的using块或try/ finallyclose/dispose调用,以确保在超出范围时清除对象.

在这些情况下,RAII更适合:当对象超出范围时,所有清理都应该自动进行.

RAII在很大程度上取代了GC.99%的时间,共享所有权并不是您想要的理想选择.这是一个可接受的妥协,以换取通过获取垃圾收集器来节省许多麻烦,但它并不真正符合您的要求.您希望资源在某个时刻死亡.不是之前,而是之后.当RAII是一个选项时,它会在这些情况下产生更优雅,简洁和健壮的代码.

但RAII并不完美.主要是因为它不能很好地处理你不知道对象的生命周期的偶然情况.只要有人使用它,它必须保持很长一段时间.但是你不想永远保持它(或者只要围绕所有客户端的范围,这可能只是整个主要功能).

在这些情况下,C++用户必须"降级"为共享所有权语义,通常通过引用计数来实现shared_ptr.在这种情况下,GC胜出.它可以更加强大地实现共享所有权(例如,能够处理周期),并且更有效(与正常的GC相比,重新计算的摊销成本是巨大的)

理想情况下,我希望用一种语言来看待它们.大多数时候,我想要RAII,但有时候,我有一种资源,我只想抛到空中而不用担心它何时何地着陆,并且相信它会在它被清理时被清理干净.这样做是安全的.

Answer 2

程序员的工作就是用他选择的语言优雅地表达事物.

C++具有非常好的语义,可用于构建和销毁堆栈中的对象.如果可以在范围块的持续时间内分配资源,那么优秀的程序员可能会采用阻力最小的路径.对象的生命周期由大括号分隔,而大括号可能已存在.

如果没有好的方法将对象直接放在堆栈上,也许它可以作为成员放在另一个对象中.现在它的生命周期要长一点,但C++仍然可以自动运行.对象的生命周期由父对象分隔 - 问题已委派.

但是,可能没有一个父母.接下来最好的事情是一系列养父母.这auto_ptr是为了什么.仍然相当不错,因为程序员应该知道什么是特定的父母是所有者.对象的生命周期由其所有者序列的生命周期分隔.决定论和本身优雅的一步一步是shared_ptr:由一群业主联盟划定的一生.

但是,此资源可能不与系统中的任何其他对象,对象集或控制流并发.它是在某些事件发生时创建的,并在另一个事件中被破坏.尽管有很多工具可以用来限定代表团和其他生命周期的生命周期,但它们还不足以计算任何任意函数.因此程序员可能决定编写几个变量的函数来确定一个对象是否存在或消失,并且调用new和delete.

最后,编写函数可能很难.也许管理对象的规则会花费太多时间和内存来实际计算!它可能只是非常难以优雅地表达它们,回到我原来的观点.因此,我们有垃圾收集:对象生命周期由您希望的时间和不需要的时间分隔.

对于咆哮很抱歉,但我认为回答问题的最佳方式是上下文:shared_ptr它只是计算对象生命周期的工具,适用于广泛的替代方案.它工作时有效.它应该在它优雅的时候使用.如果您拥有的所有者少于一个池,或者您正在尝试使用它作为一种复杂的递增/递减方式来计算某些复杂函数,则不应该使用它.