{"id":107300,"date":"2022-10-19T07:00:00","date_gmt":"2022-10-19T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=107300"},"modified":"2022-10-19T07:35:39","modified_gmt":"2022-10-19T14:35:39","slug":"20221019-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20221019-00\/?p=107300","title":{"rendered":"Why is there a make_unique<\/CODE>? Why not just overload the unique_ptr<\/CODE> constructor?"},"content":{"rendered":"

At first, there was no make_unique<\/code>. Only unique_ptr<\/code>. And for expository simplicity, let’s focus just on the non-array version of unique_ptr<\/code>.<\/p>\n

There’s the proposal for make_unique<\/code><\/a>, written by our pal Stephan T. Lavavej<\/a>. It cites a few motivating issues for the make_unique<\/code> function:<\/p>\n

    \n
  1. Parallel construction with make_shared<\/code>.<\/li>\n
  2. Avoiding the need to use the new<\/code> operator explicitly, thereby permitting the simple rule: “Don’t write new<\/code>.” Prior to make_unique<\/code>, the rule was “Don’t write new<\/code>, except to construct a unique_ptr<\/code>.”<\/li>\n
  3. Avoiding having to say the type name twice: std::unique_ptr<T>(new T(args))<\/code>.<\/li>\n
  4. Avoid a memory leak due to unspecified order of evaluation if a std::unique_ptr<\/code> is constructed from a newly new<\/code>‘d pointer as part of a larger expression which could throw. More details here<\/a>.<\/li>\n<\/ol>\n

    But couldn’t we have solved this problem by adding a new constructor to unique_ptr<\/code>?<\/p>\n

    template<typename T>\r\nstruct unique_ptr\r\n{\r\n    ...\r\n\r\n    template<typename... Args>\r\n    unique_ptr(Args&&... args) :\r\n        unique_ptr(new T(std::forward<Args>(args)...)) {}\r\n};\r\n<\/pre>\n
    With this new overload, you can write<\/p>\n
    \/\/ was p = std::make_unique<Thing>(arg1, arg2, arg3);\r\nauto p = std::unique_ptr<Thing>(arg1, arg2, arg3);\r\n<\/pre>\n
    This seems convenient (avoids introducing a new name), but it still has problems. For example, consider this:<\/p>\n
    struct Node\r\n{\r\n    Node(Node* parent = nullptr);\r\n};\r\n\r\nauto create_child(Node* parent)\r\n{\r\n    \/\/ was return std::make_unique<Node>(parent);\r\n    return std::unique_ptr<Node>(parent);\r\n}\r\n<\/pre>\n
    This version looks like it’s create a new child node with the specified parent, but since the constructor parameter is a pointer to the same type, what this really does is create a unique_ptr<\/code> that manages the parent pointer. Everything will compile, and it may even run for a while, inadvertently updating the wrong node, and eventually leading to a double-free bug.<\/p>\n
    And then there’s the converse problem:<\/p>\n
    struct NodeSource\r\n{\r\n    operator Node*();\r\n};\r\n\r\nauto wrap_proxy(NodeSource const& source)\r\n{\r\n    \/\/ was return std::make_unique<Node>(source);\r\n    return std::unique_ptr<Node>(source);\r\n}\r\n<\/pre>\n
    This time, we want to create a unique_ptr<\/code> that manages the object produced by the Node\u00adSource<\/code>‘s conversion operator. A common case where you encounter this is if the Node\u00adSource<\/code> is some sort of proxy object. But since the parameter is not literally a Node*<\/code>, this gets picked up by the new overload and is interpreted as<\/p>\n
        return std::unique_ptr<Node>(new Node(source));\r\n<\/pre>\n
    For backward compatibility, both of these cases must resolve to the constructor that takes a raw pointer to a Node<\/code>. That can probably be accomplished via a special overload that takes exactly one universal reference, and a little SFINAE, but it’s starting to get complicated.<\/p>\n
    The default constructor has entered the chat<\/i>:<\/p>\n
    auto make_something()\r\n{\r\n    \/\/ was return std::make_unique<Node>();\r\n    return std::unique_ptr<Node>();\r\n}\r\n<\/pre>\n
    Does this create an empty unique_ptr<\/code>? Or does it create a new default-constructed Node<\/code> and then create a unique_ptr<\/code> that manages it?<\/p>\n
    For backward compatibility, this must create an empty unique_ptr<\/code>, so now you have a third special case where passing Node<\/code> constructor parameters to unique_ptr<\/code> doesn’t actually construct a Node<\/code>.<\/p>\n
    The move and copy constructors have entered the chat<\/i>:<\/p>\n
    struct ListNode\r\n{\r\n    ListNode(std::unique_ptr<ListNode> rest);\r\n};\r\n\r\nauto prepend_node(std::unique_ptr<ListNode> rest)\r\n{\r\n    \/\/ was return std::unique_ptr<ListNode>(\r\n    \/\/    new ListNode(std::move(rest));\r\n    return std::unique_ptr<ListNode>(std::move(rest));\r\n}\r\n<\/pre>\n
    Does this create a new ListNode<\/code> object, using rest<\/code> as the constructor parameter? Or does this move-construct an existing std::unique_ptr<\/code>? Again, for backward compatibility, this must move-construct the std::unique_ptr<\/code>.<\/p>\n
    Okay, so if you do some SFINAE magic and carve out the special cases for backward compatibility, you’ve resolved the technical<\/i> ambiguity. But you’ve done nothing to address the semantic<\/i> ambiguity.<\/p>\n
    contoso::table<Node*> nodes;\r\n...\r\nauto p = std::unique_ptr<Node>(nodes.get(i));\r\n<\/pre>\n
    Does this get a Node*<\/code> from the table and transfer ownership of it to a unique_ptr<\/code>? Or does this get a Node*<\/code> from the table and create a new Node<\/code> from it?<\/p>\n
    As we noted earlier, compatibility requires that we interpret this as an ownership transfer, and if you want to create a new node, you have to do so explicitly:<\/p>\n
    auto p = std::unique_ptr<Node>(new Node(nodes.get(i));\r\n<\/pre>\n
    What makes this even more confusing is that similar expressions represent the creation of a new Node<\/code> without having to write out the new<\/code>:<\/p>\n
    \/\/ new Node(Node*, bool)\r\nauto p = std::unique_ptr<Node>(nodes.get(i), true);\r\n\r\n\/\/ new Node(42)\r\nauto p = std::unique_ptr<Node>(42);\r\n\r\n\/\/ does not create a new Node (!)\r\nauto p = std::unique_ptr<Node>(nodes.get(i));\r\n<\/pre>\n
    In addition to the confusion over whether this is an ownership transfer or a creation, it is unforgiving of typos like<\/p>\n
    Node* n;\r\n\r\n\/\/ This takes ownership of n\r\nauto p = std::unique_ptr<Node>(n);\r\n\r\n\/\/ This creates a new Node that is a copy of *n\r\nauto p = std::unique_ptr<Node>(*n);\r\n<\/pre>\n
    To avoid this pit of failure, we probably should use a tag type to indicate whether we are taking ownership or making a new object.<\/p>\n
    template<typename T>\r\nstruct unique_ptr\r\n{\r\n    ...\r\n\r\n    template<typename... Args>\r\n    unique_ptr(in_place_t, Args&&... args) :\r\n        unique_ptr(new T(std::forward<Args>(args)...)) {}\r\n};\r\n\r\nNode* n;\r\n\r\n\/\/ Take ownership of n\r\nauto p = std::unique_ptr<Node>(n);\r\n\r\n\/\/ Create a new Node with n as its parent\r\nauto p = std::unique_ptr<Node>(std::in_place, n);\r\n\r\n\/\/ Create an empty unique_ptr\r\nauto p = std::unique_ptr<Node>();\r\n\r\n\/\/ Create a new default Node and wrap it in a unique_ptr\r\nauto p = std::unique_ptr<Node>(std::in_place);\r\n\r\n\/\/ Move-construct a new unique_ptr from an existing one\r\nstd::unique_ptr<ListNode> rest = \/* ... *\/;\r\nauto q = std::unique_ptr<ListNode>(std::move(rest));\r\n\r\n\/\/ Move-construct a new unique_ptr from an existing one\r\nauto q = std::unique_ptr<ListNode>(std::in_place, std::move(rest));\r\n<\/pre>\n
    At this point, the new overload seems much more hassle than it’s worth. You may as well just factor the “make a new Node” feature into a separate function make_unique<\/code>. This is more explicit that it makes a new Node, and it’s less typing anyway.<\/p>\n
    \/\/ Take ownership of n\r\nstd::unique_ptr<Node> p(n);\r\n\r\n\/\/ Create a new Node with n as its parent\r\nauto p = std::make_unique<Node>(n);\r\n\r\n\/\/ Create an empty unique_ptr\r\nauto p = std::unique_ptr<Node>();\r\n\r\n\/\/ Create a new default Node and wrap it in a unique_ptr\r\nauto p = std::make_unique<Node>();\r\n\r\n\/\/ Move-construct a new unique_ptr from an existing one\r\nstd::unique_ptr<ListNode> rest = \/* ... *\/;\r\nauto q = std::unique_ptr<ListNode>(std::move(rest));\r\n\r\n\/\/ Move-construct a new unique_ptr from an existing one\r\nauto q = std::make_unique<ListNode>(std::move(rest));\r\n<\/pre>\n
    If you want to make a new object, use the make_unique<\/code> function.<\/p>\n","protected":false},"excerpt":{"rendered":"
    You’ll have to resolve the ambiguity, so you’re still typing a lot.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-107300","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
    You’ll have to resolve the ambiguity, so you’re still typing a lot.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/107300","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=107300"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/107300\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=107300"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=107300"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=107300"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}