5 ms·
> 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
by aydwi 5y ago
> 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.
- ddlutz 5y agoIt'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.
- usefulcat 5y agoWhenever 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().
- vitus 5y agoExactly 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.