A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N3588

Date: 2013-03-15

make_unique

by Stephan T. Lavavej

Excerpt:

I. Introduction

This is a proposal to add make_unique for symmetry, simplicity, and safety.

II. Motivation And Scope

C++11 provided make_shared for shared_ptr, but not make_unique for unique_ptr. This is widely viewed as an oversight. While it isn't absolutely necessary for the Standard to provide make_unique (because skilled users can implement it with perfect efficiency), it's still important. The implementation of make_unique<T>(args...), a perfectly forwarding variadic template, is difficult for beginners to understand. make_unique<T[]> involves even more subtleties. Because make_unique is commonly desired, adding it to the Standard Library will put an end to the proliferation of user implementations.

make_unique's presence in the Standard Library will have several wonderful consequences. It will be possible to teach users "never say new/delete /new[]/delete[]" without disclaimers. Additionally, make_unique shares two advantages with make_shared (excluding the third advantage, increased efficiency). First, unique_ptr<LongTypeName> up(new LongTypeName(args)) must mention LongTypeName twice, while auto up = make_unique<LongTypeName>(args) mentions it once. Second, make_unique prevents the unspecified-evaluation-order leak triggered by expressions like foo(unique_ptr<X>(new X), unique_ptr<Y>(new Y)). (Following the advice "never say new" is simpler than "never say new, unless you immediately give it to a named unique_ptr".)