make_shared vsvs new

Написав std::shared_ptr<Widget> p(new Widget());, происходит две отдельные аллокации в куче: одна — под сам Widget (сделанная явным new), другая — под control block (сделанная конструктором shared_ptr уже после того, как объект создан). Это два отдельных обращения к аллокатору, потенциально в совершенно разных, далёких друг от друга участках памяти.Writing std::shared_ptr<Widget> p(new Widget()); triggers two separate heap allocations: one for the Widget itself (done by the explicit new), another for the control block (done by shared_ptr's constructor after the object already exists). That's two separate calls to the allocator, potentially landing in entirely different, distant regions of memory.

std::make_shared<Widget>(args...) выделяет один непрерывный кусок памяти, в котором control block и сам объект Widget размещены рядом (обычно control block непосредственно перед объектом или объединены в одну структуру). Конструктор Widget вызывается через placement new прямо внутри уже выделенной памяти.std::make_shared<Widget>(args...) allocates a single contiguous chunk of memory, in which the control block and the Widget object itself sit next to each other (typically the control block immediately before the object, or merged into one structure). Widget's constructor runs via placement new right inside that already-allocated memory.

Практический выигрыш двойной: во-первых, одно обращение к аллокатору вместо двух — сама аллокация памяти не бесплатна (в многопоточной программе она может требовать внутренней блокировки в аллокаторе). Во-вторых, кэш-локальность: control block и данные объекта физически рядом, поэтому чтение счётчика ссылок и чтение полей объекта чаще попадают в одну и ту же кэш-линию процессора, а не требуют двух отдельных промахов кэша в двух разных, потенциально далёких участках памяти.The practical win is twofold: first, one allocator call instead of two — the allocation itself isn't free (in a multi-threaded program it may require an internal lock inside the allocator). Second, cache locality: the control block and the object's data sit physically next to each other, so reading the reference count and reading the object's fields more often land in the same CPU cache line, rather than requiring two separate cache misses in two different, potentially distant memory regions.

// хуже: два обращения к аллокатору, два потенциальных промаха кэша// worse: two allocator calls, two potential cache misses
std::shared_ptr<Widget> a(new Widget(42));

// лучше: одна аллокация, control block и Widget рядом в памяти// better: one allocation, control block and Widget adjacent in memory
auto b = std::make_shared<Widget>(42);

Поскольку control block и объект теперь занимают один и тот же блок памяти, вся эта память не может быть освобождена, пока не умрут оба — и объект (когда strong count дойдёт до нуля), и control block (когда weak count тоже дойдёт до нуля). При new+shared_ptr с раздельными аллокациями память самого объекта освобождается сразу при strong count == 0, а память control block-а (обычно намного меньшая) продолжает жить отдельно, пока жив хоть один weak_ptr.Because the control block and the object now share one single memory block, none of that memory can be freed until both die — the object (once the strong count hits zero) and the control block (once the weak count also hits zero). With separate new+shared_ptr allocations, the object's memory is freed immediately at strong count == 0, while the (usually much smaller) control block's memory keeps living separately for as long as any weak_ptr survives.

Практическое следствие: если объект большой (скажем, содержит буфер на несколько мегабайт), а какой-то долгоживущий weak_ptr на него держится намного дольше, чем сам объект, — с make_shared вся эта память объекта не будет освобождена всё это время, хотя сам объект давно логически уничтожен. Это редкий, но реальный случай, когда явный new с раздельной аллокацией предпочтительнее make_shared.The practical consequence: if the object is large (say, it holds a multi-megabyte buffer) and some long-lived weak_ptr to it outlives the object by a lot, then with make_shared all of that object's memory stays unreleased the whole time, even though the object itself was logically destroyed long ago. This is a rare but real case where an explicit new with a separate allocation beats make_shared.

make_shared не подходит, если нужен кастомный deleter (у него нет параметра для этого — только у самого конструктора shared_ptr есть перегрузка, принимающая deleter), или если конструктор класса приватный/защищённый, а доступ разрешён только через friend-объявленную фабричную функцию, которая не может напрямую вызвать make_shared изнутри (обходится через приватный тег-конструктор или std::allocate_shared).make_shared doesn't work if a custom deleter is needed (it has no parameter for one — only shared_ptr's own constructor has an overload taking a deleter), or if the class's constructor is private/protected and access is only granted through a friend-declared factory function that can't call make_shared directly from inside (worked around via a private tag constructor or std::allocate_shared).

• cppreference — std::make_shared
• cppreference — std::allocate_shared