为什么std :: make_unique而不是std :: unique_ptr :: make？

Question

Why did C++ adopt free functions for:

std::make_unique(...);
std::make_shared(...);

instead of using static member functions:

std::unique_ptr::make(...); // static
std::shared_ptr::make(...); // static

?

Answer 1

TL;DR: Static member functions always have access to private data but free functions only have access to private data when explicitly marked as friend . The choice to implement these functions as free functions (with a small number being implemented as friend functions) isn't a random historical artifact, but is a deliberate decision to improve encapsulation while having a consistent naming scheme for all of the std::make_x functions.

---

There are many standard factory functions in C++:

std::make_pair
std::make_tuple
std::make_unique
std::make_shared //efficiency
std::make_exception_ptr //efficiency
std::make_move_iterator
std::make_reverse_iterator
std::make_error_code
std::make_error_condition
//And several more are proposed for C++17

For all of the above, the make_x function can be implemented correctly using only the public interface of x . In the case of make_shared and make_exception_ptr , the most efficient implementation would require access to the internal data of the std::shared_ptr or std::exception_ptr . All the others can be implemented using just the public interface with zero performance penalty.

Implementing these functions as non-friend free-functions reduces the amount of code that has access to the private internals of the object ( a desirable property , since when less code has access to private data, there are fewer places that have to be audited for operations that violate the invariants of the object, and fewer places that potentially need to be changed if the internals of the object change).

If make_shared were the only similar factory function, it might make sense for it to be a member function, but since the majority of such functions are not required to be friend functions to operate efficiently, make_shared is also implemented as a free-function, for the sake of consistency.

This is the correct design, as if static member make functions were consistently used, then in every case apart from make_shared and make_exception_ptr , the member function would unavoidably have excessive access to the private data of the x object. With the standardised design, the small number of make_x functions that need access to private data can be marked as friend , and the rest respect encapsulation correctly by default. If a non-member make_x were used in some cases and a static member make in others, the standard library would become inconsistent and more difficult to learn.

Answer 2

Consistency .

I don't think that there is any compelling reason to have the ::make syntax instead of the current one. I assume that make_unique and make_shared were preferred to a static ::make function to stay consistent with the existing std::make_pair and std::make_heap functions, that existed pre-C++11.

---

Note that std::make_pair has a big advantage: it automatically deduces the types of the resultant pair from the function call:

auto p0 = std::make_pair(1, 1.f); // pair<int, float>

If we had std::pair::make , then we would have to write:

auto p1 = std::pair<int, float>::make(1, 1.f);

which defeats the purpose of make_pair .

---

• I therefore assume that make_unique and make_shared were chosen because developers were already used to make_pair and similar functions.

• make_pair was chosen instead of pair::make for the aforementioned benefits.

Answer 3

There is not a concrete reason other than convention alone - a static-class function can do everything a global function can do (functionality wise).
C++ prefers global functions (for utility functions) which contained inside a defined namespace.
Other programming languages (such as Java) prefer static public functions, as global functions are not supported.

this is not new to make_*** , other examples exists:

std::this_thread::XXXX instead of std::thread::XXXX_current
although it might had sense to put function which relates to the current thread of execution as static functions inside thread class, they are made global inside this_thread namespace.

also, we could have something like std::container::sort which std::container is a helper class for containers, but we have std::sort instead.