Unique_ptr, it's pants, i don't like it!

[pflugshaupt]

@MBO

But if something goes wrong, for example vector is too small, it will cause problems.

No - if the vector is “too small” it’ll be enlarged. If there’s not enough memory, you’ll get an exception but then you’re likely in much deeper trouble. Trouble that could maybe be avoided by calling vec.reserve() before constructing new elements in place.

I use std::make_unique<> and then vec.back() after adding a new element. That makes ownership clear.

Switching everything from ScopedPointer to std::unique_ptr has been painful in the beginning, but overall the design is better and if you plan to ever code c++ outside Juce it’s something you better get used to anyway. Once you also start using juce:: prefixes everywhere, the extra verbosity doesn’t look out of place anymore ;).

[MBO]

@MBO

Yes, therefore this will fail:

std::vector<std::unique_ptr<MyClass>> vec;
auto& obj = vec.emplace_back (std::make_unique<MyClass>());

Instead it should be:

std::vector<std::unique_ptr<MyClass>> vec;
auto& obj = vec.emplace_back (new MyClass());

Oh, sorry, I pasted it wrong obviously, you are right It should be vice versa. std::make_unique should be used!

[MBO]

@sebk

That’s an interesting point I haven’t thought about

Is it still a problem when using make_unique like this?

std::vector<std::unique_ptr<MyClass>> vec;
auto& obj = vec.emplace_back(std::make_unique<MyClass>());

As far as I understand it this implicitly moves the newly created unique_ptr into the vector and if it fails the unique_ptr is getting destroyed because it get’s out of scope.

Of course you are right, I wanted just to warn that because emplace_back can create an object, so instead of using make_unique it could be tempting to use raw pointer instead with emplace_back. But then it can leak. In C++14 things are simpler with std::make_unique as you stated.

[jimc]

If your vector can’t expand enough to add one more pointer I think the leak is the least of your worries …?

[MBO]

Exactly This discussion is kind of fun. I tell you that for storing components I still use OwnedArray.

[jimc]

OwnedArray is my best friend most of the time.

[adamwilson]

Arriving a bit late to the discussion here, but having battled with the Rust compiler last year, I now appreciate that it will prevent mistakes such as use after move/delete (as well as not allow things that to a C/C++ programmer seem perfectly OK). I wonder if the C++ compiler will ever get clever enough to prevent mistakes like this?

@jimc

void setSomething(unique_ptr<Component> b)
{
   b->doSomething();
   container.push_back(std::move(b));

  /// many lines of code

  if (someRareCondition())
   b->doSomethingElse();
}

[danielrudrich]

At least code analyzers will catch it, like Xcode Analyze: