Hacker Read

cmma · 2015-08-23 10:02:53

The reason why that code fails is explained by gcc's unique_ptr implementation:

    /// Primary template of default_delete, used by unique_ptr
    template<typename _Tp>
      struct default_delete
      {
    ...
        void
        operator()(_Tp* __ptr) const
        {
          static_assert(!is_void<_Tp>::value,
                        "can't delete pointer to incomplete type");
          static_assert(sizeof(_Tp)>0,
                        "can't delete pointer to incomplete type");
          delete __ptr;
        }
      };

Basically, invoking "operator delete" on a pointer to an incomplete type (aka opaque pointer) is usually undefined. Calling "operator new" on an incomplete type is not possible (because its size is 0). Since unique_ptr deals with allocation/deallocation, and doesn't just copy pointer values around, it's not fully comparable to a plain pointer.

nice_byte proposed a good solution: if you can, abstract the new/delete logic to another file, in which the complete type of "Gadget" is known.

reply

wuch | karma 166 | avg karma 2.05 · | 2015-08-23 08:45:06

This is required by the standard. unique_ptr<Gadget> in your example uses default_delete<Gadget> deleter, which in turn requires that type Gadget is complete at the point where this deleter is used, otherwise program is ill-formed.

Intention is to avoid undefined behaviour in situation where you delete an object with incomplete class type at the point of deletion, that has a non-trivial destructor or a deallocation function.

Edit: An deleter is used because of default generated copy constructor.

reply

blt | karma 4916 | avg karma 2.99 · | 2019-01-08 07:32:06

Totally agree. Recently used unique_ptr with a custom deleter is to consume a C library that requires heap allocation with its own alloc/free functions. No destructor!

mort96 | karma 11266 | avg karma 3.8 · | 2022-08-09 07:38:06

There's nothing more complicated about using unique_ptr than a raw pointer, it just expresses who's responsible for calling `delete` explicitly in code rather than implicitly through program flow.

onedognight | karma 2215 | avg karma 3.92 · | 2014-04-18 18:36:53

This article starts with a flawed premise, that the right way to create a managed pointer is something like this[1].

    std::unique_ptr<void,void(*)(void*)> big_ptr(malloc(1), free);

The wasteful thing about this is that you have to store the deleter (free() in this case) right next to your void* for every pointer you manage, so the unique_ptr is twice as large as it needs to be. What you'd like to do is store the deleter in the type of the pointer rather than the pointer itself. It turns out unique_ptr can handle this. If the second template parameter is a type with an overloaded function call operator, then unique_ptr will use that to delete. We can wrap it up like so.

    template <class T, void F(T *)> struct unique {
        struct deleter { void operator()(T *p) { F(p); }; };
        typedef std::unique_ptr<T, deleter> ptr;
    };

With this helper type you can now declare a similar managed pointer

    unique<void, free>::ptr small_ptr(malloc(1));

but this time notice that the deleter function is the second template parameter and not an argument to the constructor and the following holds.

    assert(2 * sizeof(small_ptr) == sizeof(big_ptr));

[1] I used malloc() and free() so those of you following along at home can easily try this out for yourselves.

mavam | karma 164 | avg karma 1.73 · | 2016-04-28 14:22:59+00:00

I understand that your point is that unique_ptr facilitates resource management. But the example you provide is a misleading. How is this supposed to compile? The deleter type is part of the unique_ptr. So you need something along these lines:

     auto scope_guard = [](void*) { };
     unique_ptr<void, decltype(scope_guard)> finally{nullptr, scope_guard};

This is not very idiomatic. Something like toth mentioned makes more sense. If you want it to be efficient, use this:

    template <class Fun>
    class scope_guard {
      scope_guard() = delete;
      scope_guard(const scope_guard&) = delete;
      scope_guard& operator=(const scope_guard&) = delete;

    public:
      scope_guard(Fun f) : fun_(std::move(f)) {}

      ~scope_guard() {
        fun_();
      }

    private:
      Fun fun_;
    };

    template <class Fun>
    scope_guard<Fun> make_scope_guard(Fun f) {
      return {std::move(f)};
    }

    auto guard = make_scope_guard([] { cleanup(); });

The difference is: there's no indirection through std::function, so you save yourself a (potential) heap allocation.

nyanpasu64 | karma 3595 | avg karma 2.14 · | 2022-02-23 17:14:21

Using a function pointer as a unique_ptr's deleter type, and passing it in at runtime, makes the unique_ptr fat (two pointers large). The "idiomatic solution for the past decade" is a lot more complicated than you make it sound.

To avoid this overhead, I prefer passing in a default-constructible type with an operator() deleter function, and not passing in a value into the unique_ptr constructor. A neat party trick is to use the decltype of a lambda as such a type (https://old.reddit.com/r/cpp/comments/rlvsq0/does_anybody_re...).

reply

torstenvl | karma 7330 | avg karma 2.85 · | 2023-02-05 16:35:32

By default, unique_ptr calls delete.

It therefore still calls the destructor.

So this has literally no bearing on the problem. It doesn't help at all.

reply

nyanpasu64 | karma 3595 | avg karma 2.14 · | 2022-02-23 15:31:29

Using a function pointer as a unique_ptr's deleter type, and passing it in at runtime, makes the unique_ptr fat (two pointers large). To avoid this overhead, I prefer passing in a default-constructible type with an operator() deleter function, and not passing in a value into the unique_ptr constructor (https://github.com/nyanpasu64/qvgmsplit/blob/edcce6df391c15b...). A neat party trick is to use the decltype of a lambda (https://old.reddit.com/r/cpp/comments/rlvsq0/does_anybody_re...).

pingyong | karma 631 | avg karma 2.59 · | 2019-09-23 13:00:50+00:00

It's pretty stupid to compare a unique_ptr with a deleter that contains state to a pointer - obviously those two things are completely different and the unique_ptr contains way more information.

ridiculous_fish | karma 6729 | avg karma 5.37 · | 2021-08-30 20:51:59

You can use a custom deleter, e.g.

    struct deleter_t { void operator()(impl_t *); };
    using impl_unique_ptr_t = std::unique_ptr<impl_t, deleter_t>;

You can place the implementation of the deleter alongside the impl.

planede | karma 2063 | avg karma 2.91 · | 2022-12-09 07:58:01

Ah, right, so `out_ptr` works with any unique_ptr and shared_ptr, doesn't have to hold the `default_deleter`. `default_deleter` would call `delete` down the line, which does not match up with `malloc`.

coralkashri | karma 1 | avg karma 0.09 · | 2023-04-17 15:55:47

Well, this article was written using a phone, so it might be possible to read it using one :P

And yes, it's completely true for cases that your custom deleter (pay attention that there is no custom allocator in std::unique_ptr, but it also true to allocators in other structures) doesn't contain any data members :)

And thanks!

reply

Pombal | karma 5 | avg karma 0.62 · | 2019-09-22 12:10:00

Yes, really. It's fine for simple types but for more complex types in more complex situations, you pay the price.

Unique pointers carry around not just the type but also a default deleter, if you provide one. That deleter has to be copied around, checked for nullptr before execution and set to nullptr when ownership changes.

For even more examples of this have a look at this talk when it comes out: https://cppcon2019.sched.com/event/Sfq4/there-are-no-zero-co...

reply

Too | karma 4126 | avg karma 1.55 · | 2017-10-22 05:27:36+00:00

std::unique_ptr has a widely unknown second template argument called deleter. It is designed exactly for this purpose. You just do roughly like this(written from a phone):

    typedef fdwrapper = unique_ptr<int, close>;
    fdwrapper fdhandle(open(filename));

vortico | karma 5453 | avg karma 3.42 · | 2018-03-26 15:07:25

This is a reasonable suggestion since the code isn't too bad.

    std::unique_ptr<Foo, std::function<void(Foo*)>> p(new Foo, [](Foo* p) {
        if (p) destroyFoo(p);
    });
    // initialize Foo and set to NULL if failed

It increases complexity a bit because you no longer have a simple pointer, and you can't allocate on the stack anymore (my example should have declared `Foo foo;` with `destroyFoo(&foo)`, sorry for typo.)

kllrnohj | karma 11052 | avg karma 3.34 · | 2021-10-18 09:34:08

Eh? '=delete' is a bad example of "footgun" or "arcane knowledge". There are those in C++, sure, but this isn't one of them.

You can happily never know the existence of '=delete' and nothing about your code changes. And if you ever hit a libraries usage of it, like the standard library, you get a pretty clear error message at compile time instead of an actual footgun in C++98 like memory corruption or runtime crashes.

'=delete' is basically the entire reason why std::unique_ptr is safe and std::auto_ptr is a footgun. It reduces the ammo aimed at yourself & the amount of knowledge you need to know (like the knowledge to never put auto_ptr in a vector)

reply

vitus | karma 2057 | avg karma 2.99 · | 2022-08-09 18:20:00

To be clear: I'm not advocating for the use of `new` / `delete` over unique_ptr. But if you're creating a local object that never has to leave the current scope (or a member variable that's never moved in or out), there's no benefit to using a unique_ptr instead of creating the object directly on the stack or inline as part of your class, where the object's lifetime is bound to the scope, and your destructor is automatically run when its containing scope is cleaned up.

As an added bonus, you don't actually have to do a separate heap allocation.

reply

ridiculous_fish | karma 6729 | avg karma 5.37 · | 2015-08-23 23:20:28+00:00

That doesn't sound right. unique_ptr does not have a copy constructor so there should not be an implicit copy ctor (am I right?) Exception handling in the default ctor I think is right.

usefulcat | karma 3745 | avg karma 2.73 · | 2021-10-26 14:21:49

Whenever you use 'new', you have to decide what is going to 'own' the newly allocated thing. You'll also have to remember to call 'delete' somewhere.

Using unique_ptr/make_unique() or shared_ptr/make_shared() automates lifetime management (obviates the need for a manual 'delete') and makes the ownership policy explicit. They also have appropriately defined copying behavior. For example:

    struct Foo {
        // lots of stuff here ...
    };

    struct A {
        Foo* f = new Foo;
        ~A() { delete f; }
    };
    
    struct B {
        std::unique_ptr<Foo> f = std::make_unique<Foo>();
        // no need to define a dtor; the default dtor is fine
    };

For the destructor and the default constructor, compilers will generate basically identical code for both A and B above. If you try to copy a B, the compiler won't let you because unique_ptr isn't copyable. However it won't stop you from copying an A, even though as written (using the default copy ctor) that's almost certainly a mistake and will likely result in a double free in ~A().