Since C++17 supports shared_ptr of array, does this mean that an explicit deleter for T[] is no longer required in both ctor and reset?

Question

When create shared_ptr using a separated allocation, an explicit delete function must be provided in C++14 ctor and reset member function.

using std::string;
using std::shared_ptr;
using std::default_delete;
int arr_size{};
...


auto string_arr_sptr_cpp14 = 
         shared_ptr<string[]>(new string[arr_size], default_delete<string[]>() );
string_arr_sptr_cpp14.reset(new string[arr_size], default_delete<string[]>() );
// define an explicit deleter, 
// or otherwise, "delete ptr;" will internally be used incorrectly!

By supporting shared_ptr of array feature in C++17, would those be no longer required in both ctor and reset?

auto string_arr_sptr_cpp17 = shared_ptr<string[]>(new string[arr_size]);
string_arr_sptr_cpp14.reset(new string[arr_size]);
// deduced delete function calls "delete[] ptr;" correctly now?

score 5 · Accepted Answer · 2017-08-03T06:04:15.730

5

You are correct, shared_ptr<T[]> now naturally handles calling delete[] properly.

http://eel.is/c++draft/util.smartptr.shared#const-5

Effects: When T is not an array type, constructs a shared_ptr object that owns the pointer p. Otherwise, constructs a shared_ptr that owns p and a deleter of an unspecified type that calls delete[] p.

And as far as reset() goes:

http://eel.is/c++draft/util.smartptr.shared#mod-3

Equivalent to shared_ptr(p).swap(*this).

Which will transfer the specification-required custom deleter.

edited Aug 03 '17 at 06:04

answered Aug 03 '17 at 05:58

Does this mean that the major role of std::default_delete<>() is also gone? – sandthorn Aug 03 '17 at 16:10
1

`std::default_delete<>()` is related to `unique_ptr<>`, which is a different matter. – Aug 03 '17 at 16:39

Since C++17 supports shared_ptr of array, does this mean that an explicit deleter for T[] is no longer required in both ctor and reset?

1 Answers1