Hacker News Reader

Comment by aydwi | Hacker News Reader

> IMO the use of `new` in modern C++ (as is the case in the writer queue) is often a code smell

As a naive practitioner of modern C++, I'd love it if you could elaborate on this.

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().

Exactly as usefulcat points out: with modern C++, the bulk of object lifetimes should be handled with unique_ptr and/or directly on the stack, so your destructors are automatically called for you (reducing the risk of double frees or memory leaks).

unique_ptr forces you to think about your dependencies and when objects can / should be cleaned up.

It's widely accepted you should almost always use some smart pointer like unique_ptr or shared_ptr, and even sometimes the the unpopular weak_ptr depending on your use case.

Reply on news.ycombinator.com