• [译]GotW #89 Smart Pointers


    There’s a lot to love about standard smart pointers in general, and unique_ptr in particular.

    Problem

    JG Question

    1.什么时候你应该使用shared_ptr vs unique_ptr?尽可能列出你所想到的注意事项。

    Guru Question

    2.为什么你应该总是使用make_shared来创建一个被shared_ptr(s)拥有的对象?请解释。

    3.为什么你应该总是使用make_unique来创建一个被unique_ptr拥有的对象?请解释。

    4.怎么处理auto_ptr?

    Solution

    1.什么时候你应该使用shared_ptr vs unique_ptr?尽可能列出你所想到的注意事项。

         当存在疑问时,默认情况下优先使用unique_ptr。如果有需要的话可以以后再改为shared_ptr。如果你从一开始就知道你所需要的共享所有权类型指针,那么可以直接通过make_shared来声明shared_ptr类型(查看下面的#2)。

         有三个理由解释为什么“当存在疑问时,默认情况下优先使用unique_ptr”。

         首先,使用最简单的语义应该是足够的:选择正确的智能指针来最直接表达你的意图和你(现在)所需要的。如果你创建了一个新类型,但是不知道最终是否需要共享对象所有权,使用unique_ptr来表达唯一的所有权。或者你可以将它放入容器中(例如:vector<unique_ptr<widget>>),然后做你想要用原始指针(raw pointer)做的事情,不会有问题,除了很安全。如果之后需要共享所有权,你可以直接将unique_ptr改变为shared_ptr。

         其次,unique_ptr比shared_ptr更高效。unique_ptr不需要去维护引用计数信息和底层的控制块。它设计的目的就是尽可能简单便宜地像原始指针一样移动和使用。当你没有要求比你需要的多,那么你就没有必要去承受不使用那部分带来的开销。

         最后,使用unique_ptr更加灵活且有保持选择的权利。如果一开始就使用unique_ptr,你之后可以总是转换到shared_ptr或者通过.get()或.release()来使用其他自定义的智能指针(甚至是原始指针)。

       

               Guideline:优先使用标准的智能指针。默认情况下使用unique_ptr,如果需要共享则使用shared_ptr。它们在C++标准库中属于常见类型。只有在和其他库进行交互的必要前提下才使用其他智能指针类型,或使用标准的智能指针的deleters和allocators达不到你的需求的自定义行为。

     

    2.为什么你应该总是使用make_shared来创建一个被shared_ptr(s)拥有的对象?请解释。
         注意:如果你需要是同自定的allocator来创建一个对象,你可以使用allocate_shared,这几乎很少见。尽管它的名字稍微有点不一样,但allocate_shared应该被视为“可以让你指定一个allocator风味的make_shared”。所以在这主要讨论make_shared而并不会去区分它们之间的区别。

         有两种主要情况你不能使用make_shared去创建一个被shared_ptr(s)拥有的对象:(a)你需要使用自定义的deleter,这种情况下因为使用shared_ptr来管理非内存资源或在非标准内存区分配一个对象,你不能使用make_shared因为它不支持指定的deleter;(b)如果你采取一个原始指针(raw pointer)指向一个来需要处理的自其他(通常是legacy code)代码的对象,你可以直接用原始指针去构建shared_ptr。

      

                  Guideline:使用make_shared(或需要自定义allocator的allocate_shared)去创建你知道需要使用shared_ptr类型的对象,除非你需要一个自定义的deleter或从采用一个来自其他地方的原始指针(raw pointer)。

         那么,为什么几乎总是尽可能地使用make_shared(或需要自定义allocator的allocate_shared)?这里有两个主要的原因:简单和高效。
    第一,使用make_shared的代码更简单,书写清晰和正确的代码是第一位。
    第二,使用make_shared更高效。shared_ptr需要在控制块维护一个被所有share_ptr(s)和weak_ptr(s)引用的指定对象的内务信息(housekeeping information)。这个内务信息包含了不止一个引用计数,而是两个。

        · 一个“强引用”来跟踪当前保持活动的shared_ptr(s)的个数。当最后一个强引用消失时这个共享对象就会被销毁(可能会被回收)。
        · 一个“弱引用”来跟踪当前观察对象的weak_ptr(s)的个数。当最后一个弱引用消失时,这个共享的内务控制块会被销毁和回收(如果还没有被回收话)。

         如果你分配对象分别通过原始的new表达式,然后再传给shared_ptr,那么shared_ptr会没有选择只能分别去分配控制块,如下面代码和图所示。

    // Example 2(a): Separate allocation
    auto sp1 = shared_ptr<widget>{ new widget{} };
    auto sp2 = sp1;

    053013_2139_gotw89solut1


         我们想要避免两次分别的分配动作。如果选择使用make_ptr去分配对象,那么shared_ptr所有的只会有一个。然后它的实现可能将他们折叠在一起到一个分配当中。如下面代码和图所示。

    // Example 2(b): Single allocation
    auto sp1 = make_shared<widget>();
    auto sp2 = sp1;

    053013_2139_gotw89solut2

    组合分配有两个主要好处:
         · 减少了分配开销,包括内存碎片。首先,这个最明显的方式是通过减少分配请求的次数,分配一般是属于昂贵的操作。这同时也减少了在allocators上的竞争;其次,只使用一块内存而不是两块可以减少每次分配的开销。当向系统要求一块内存时,系统一般至少会给出一些字节,通常还会给出更多一些,因为里面维护其他的信息需要一定的空间。因此通过使用单个内存块,
    倾向于减少额外的开销,最终减少因为零碎的内存区而导致的内存碎片。
         · 改善了区域(locality)。引用计数经常会被对象使用,对于小的对象很可能是处在相同的内存线(cache line)上,这个可以提高缓存性能(只要当中没有一些线程将智能指针拷贝到一个紧密的循环中,不要那么做)。

         像往常一样,如果能试图通过一个简单的函数调用来表达更多的意图,那么系统会找到一个更高效的方式来完成任务。这个可以通过往vector中填充元素可以看出,因为使用v.inser(first,last)填充100个元素远比调用100次v.inser(value)更高效。所以使用单个make_shared调用比分别调用new widget()和shared_ptr(widget*)更好。

         此外还有两个好处是:使用make_shared避免了显示使用new和避免了一些异常安全问题。上述这些同样适用于make_unique。

    3.为什么你应该总是使用make_unique来创建一个被unique_ptr拥有的对象?请解释。

         和make_shared一样。存在两个主要情况不能使用make_unique分配一个unique_ptr所有权类型的对象:如果需要一个deleter,或采用一个原始指针(raw pointer)。

    否则,尽可能地优先使用make_unique。
       


             Guideline: 使用make_unique创建一个非共享的对象,除非需要一个自定义的deleter或采用一个来自于其他地方的原始指针。

    因为make_shared和make_unique有对称性,所以和上述一样。首先,优先使用make_unique<T>()而不是繁琐的unique_ptr<T>{ new T{}},因为通常情况下应该避免显示使用new

       

               Guideline:不要显示使用new,delete,和*指针。除非需要实现一些底层的数据结构这种罕见的情况。

    其次,它避免了使用原始new的一些异常安全问题。下面是个例子:

    void sink( unique_ptr<widget>, unique_ptr<gadget> );
    
    sink( unique_ptr<widget>{new widget{}},
          unique_ptr<gadget>{new gadget{}} ); // Q1: do you see the problem?

         简单说就是,如果首先分配和构建new widget,然后再分配或构建new gadget时发生了异常,那么widget则会泄露。有人可能会像:“这样的话,那么可以调整new widget{}到make_unique<widget>()这样就没问题了对吧?”也就是:

    sink( make_unique<widget>(),
          unique_ptr<gadget>{new gadget{}} );         // Q2: is this better?

         答案是否定的。因为C++在评估函数参数的序列是未指定的,因此new widget或new gadget都可能先执行。

         因此,只是改变参数中的一个都没有堵上这个漏洞,只有两者都使用make_unique才真正完全消除了这个问题:

    sink( make_unique<widget>(), make_unique<gadget>() );  // exception-safe

    关于异常安全的问题会在GotW #56更多的讨论。

                 Guideline:分配对象时,默认情况下优先选择使用make_unique。当知道一个对象的生命期需要通过shared_ptr(s)进行管理,那么使用make_shared。

    4.怎么处理auto_ptr?

         auto_ptr在C++有移动语义前有很多特性是作为去创建一个和unique_ptr的意思。auto_ptr现在是废弃了的。不应该在新写的代码中使用它。

    如果在既存代码中使用了auto_ptr,那么可以进行全局搜索然后用unique_ptr去替换它。绝大多数的使用都会工作的一样,可能会暴露一些问题(编译错误)或修复了(轻微)一些bug或者两个你都不知道有。

  • 相关阅读:
    k8s的基本概念与基本功能
    STM32F030看门狗
    STM32F030低功耗
    STM32开发脱坑记
    ubuntu下安装wine并运行source insight
    Linux下使用Eclipse搭建ARM开发环境
    linux下的find文件查找命令与grep文件内容查找命令(转)
    STM32F030 BootLoader与应用程序的跳转设置
    MCU开发之MDK-ARM总结
    IIC协议总结
  • 原文地址:https://www.cnblogs.com/navono007/p/3440117.html
Copyright © 2020-2023  润新知