将std :: unique_ptr类成员标记为const

Question

A lot of the examples for using std::unique_ptr to manage ownership of class dependencies look like the following:

class Parent
{
public:
    Parent(Child&& child) :
    _child(std::make_unique<Child>(std::move(child))){}
private:
    std::unique_ptr<Child> _child;
};

My question is whether marking the _child member as const have any unexpected side effects? (Aside from being ensuring that reset() , release() etc. cannot be called on _child ).

I ask since I have not yet seen it in an example and don't whether that is intentional or just for brevity/generality.

Answer 1

Because of the nature of a std::unique_ptr (sole ownership of an object) it's required to have no copy constructor whatsoever. The move constructor (6) only takes non-const rvalue-references which means that if you'd try to make your _child const and move it you'd get a nice compilation error :)

Even if a custom unique_ptr would take a const rvalue-reference it would be impossible to implement.

Answer 2

The downsides are like with any const member: That the assignment and move-assignment operators don't work right (they would require you to overwrite _child ) and that moving from the parent would not steal the _child (performance bug). Also it is uncommon to write code like this, possibly confusing people.

The gain is marginal because _child is private and therefore can only be accessed from inside the Parent , so the amount of code that can break invariants revolving around changing _child is limited to member functions and friends which need to be able to maintain invariants anyways.

I cannot imagine a situation where the gain would outweigh the downsides, but if you do you can certainly do it your way without breakage of other parts of the program.

Answer 3

Yes, you can do this, and it's what I regularly do when implementing UI classes in Qt:

namespace Ui {
    class MyWidget
}

class MyWidget : public QWidget
{
    Q_OBJECT  

    const std::unique_ptr<Ui::MyWidget> ui;

public:
    explicit MyWidgetQWidget *parent = 0)
        : ui(new Ui::MyWidget{})
    {
    }

    ~MyWidgetQWidget();
    // destructor defined as = default in implementation file,
    // where Ui::MyWidget is complete
}

It's exactly comparable to writing Ui::MyWidget *const ui in C++03 code.

The above code creates a new object, but there's no reason not to pass one in using std::move() as in the question.