shared_ptr 到数组:应该使用它吗?

shared_ptr to an array : should it be used?(shared_ptr 到数组:应该使用它吗?)

问题描述

只是关于 shared_ptr 的一个小问题.

使用 shared_ptr 指向数组是一个好习惯吗?例如，

shared_ptrsp(new int[10]);

如果没有，那为什么不呢?我已经知道的一个原因是不能增加/减少 shared_ptr.因此它不能像普通的数组指针一样使用.

使用 C++17，shared_ptr 可用于管理动态分配的数组.在这种情况下，shared_ptr 模板参数必须是 T[N] 或 T[].所以你可以写

shared_ptrsp(new int[10]);

从 n4659，[util.smartptr.shared.const]

 模板显式 shared_ptr(Y* p);

using element_type = remove_extent_t;

 element_type&运算符 [](ptrdiff_t i) 常量；

模板<类型名称 T >struct array_deleter{void 运算符 ()( T const * p){删除[] p;}};

std::shared_ptrsp(new int[10], array_deleter());

std::unique_ptr向上(新的 int[10])；//这将正确调用 delete[]

库提供了另一种 C++17 之前的替代方案基础技术规范，增强了 shared_ptr 以允许它在拥有一组对象的情况下开箱即用.可以在 shared_ptr 更改的当前草案/n4082.pdf" rel="noreferrer">N4082.这些更改可通过 std::experimental 命名空间访问，并包含在 标头中.为数组支持 shared_ptr 的一些相关更改是:

—成员类型定义element_type变化

typedef T element_type;

 typedef typename remove_extent::type element_type;

—正在添加成员operator[]

 element_type&运算符[](ptrdiff_t i) const noexcept;

—与数组的 unique_ptr 部分特化不同，shared_ptr 和 shared_ptr 都将有效并且两者都将导致在托管对象数组上调用 delete[].

 模板显式 shared_ptr(Y* p);

要求:Y 应该是一个完整的类型.表达式 delete[] p，当 T 是数组类型时，或 delete p，当 T 不是数组类型时一个数组类型，应该是格式良好的，应该有明确定义的行为，并且不应该抛出异常.当T为U[N]时，Y(*)[N]可转换为T*；当T为U[]时，Y(*)[]可转换为T*；否则，Y* 应可转换为 T*.

Just a small query regarding shared_ptr.

Is it a good practice to use shared_ptr pointing to an array? For example,

shared_ptr<int> sp(new int[10]);

If not, then why not? One reason I am already aware of is one can not increment/decrement the shared_ptr. Hence it can not be used like a normal pointer to an array.

With C++17, shared_ptr can be used to manage a dynamically allocated array. The shared_ptr template argument in this case must be T[N] or T[]. So you may write

shared_ptr<int[]> sp(new int[10]);

From n4659, [util.smartptr.shared.const]

  template<class Y> explicit shared_ptr(Y* p);

Requires: Y shall be a complete type. The expression delete[] p, when T is an array type, or delete p, when T is not an array type, shall have well-defined behavior, and shall not throw exceptions.
...
Remarks: When T is an array type, this constructor shall not participate in overload resolution unless the expression delete[] p is well-formed and either T is U[N] and Y(*)[N] is convertible to T*, or T is U[] and Y(*)[] is convertible to T*. ...

To support this, the member type element_type is now defined as

using element_type = remove_extent_t<T>;

Array elements can be access using operator[]

  element_type& operator[](ptrdiff_t i) const;

Requires: get() != 0 && i >= 0. If T is U[N], i < N. ...
Remarks: When T is not an array type, it is unspecified whether this member function is declared. If it is declared, it is unspecified what its return type is, except that the declaration (although not necessarily the definition) of the function shall be well formed.

Prior to C++17, shared_ptr could not be used to manage dynamically allocated arrays. By default, shared_ptr will call delete on the managed object when no more references remain to it. However, when you allocate using new[] you need to call delete[], and not delete, to free the resource.

In order to correctly use shared_ptr with an array, you must supply a custom deleter.

template< typename T >
struct array_deleter
{
  void operator ()( T const * p)
  { 
    delete[] p; 
  }
};

Create the shared_ptr as follows:

std::shared_ptr<int> sp(new int[10], array_deleter<int>());

Now shared_ptr will correctly call delete[] when destroying the managed object.

The custom deleter above may be replaced by

• the std::default_delete partial specialization for array types

  std::shared_ptr<int> sp(new int[10], std::default_delete<int[]>());
  

• a lambda expression

  std::shared_ptr<int> sp(new int[10], [](int *p) { delete[] p; });
  

Also, unless you actually need share onwership of the managed object, a unique_ptr is better suited for this task, since it has a partial specialization for array types.

std::unique_ptr<int[]> up(new int[10]); // this will correctly call delete[]

Changes introduced by the C++ Extensions for Library Fundamentals

Another pre-C++17 alternative to the ones listed above was provided by the Library Fundamentals Technical Specification, which augmented shared_ptr to allow it to work out of the box for the cases when it owns an array of objects. The current draft of the shared_ptr changes slated for this TS can be found in N4082. These changes will be accessible via the std::experimental namespace, and included in the <experimental/memory> header. A few of the relevant changes to support shared_ptr for arrays are:

— The definition of the member type element_type changes

typedef T element_type;

 typedef typename remove_extent<T>::type element_type;

— Member operator[] is being added

 element_type& operator[](ptrdiff_t i) const noexcept;

— Unlike the unique_ptr partial specialization for arrays, both shared_ptr<T[]> and shared_ptr<T[N]> will be valid and both will result in delete[] being called on the managed array of objects.

 template<class Y> explicit shared_ptr(Y* p);

Requires: Y shall be a complete type. The expression delete[] p, when T is an array type, or delete p, when T is not an array type, shall be well-formed, shall have well defined behavior, and shall not throw exceptions. When T is U[N], Y(*)[N] shall be convertible to T*; when T is U[], Y(*)[] shall be convertible to T*; otherwise, Y* shall be convertible to T*.

这篇关于shared_ptr 到数组:应该使用它吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！