Почему 'std::make_shared' всегда использует выделение глобальной памяти даже с перегруженными операторами new/delete класса?

Итак, в чем рациональность поведения?

Причина, по которой это делается, заключается в том, что make_shared не просто выделяет ваш объект, но также выделяет блок управления shared_ptr. Чтобы сделать это максимально эффективным, он вызывает new один раз и выделяет достаточно памяти для блока управления и объекта за один раз. В противном случае ему пришлось бы вызывать new дважды, что удваивает накладные расходы на выделение.

Если вы хотите использовать собственный распределитель, вам нужно использовать std::allocate_shared. и он будет использовать ваш пользовательский распределитель, чтобы сделать одно выделение памяти для создания файла shared_ptr.

Другой вариант — использовать std::make_unique для создания unique_ptr, а затем использовать его для инициализации shared_ptr. Это работает, потому что unique_ptr не имеет управляющего блока, поэтому std::make_unique выделяет в виде

unique_ptr<T>(new T(std::forward<Args>(args)...))

Это даст вам

std::shared_ptr<C> ptr = std::make_unique<C>();

который выводит

C::new() -> 0xf34c20
C::delete() -> 0xf34c20

Непосредственной причиной такого поведения является тот факт, что std::make_shared выполняет однократное выделение для выделения как управляющего блока, так и объекта. У него нет другого выбора, кроме как использовать для этого глобальный оператор new.

Также хочу отметить, что лично я считаю возможность перегружать операторы new/delete для класса одной из самых непродуманных фич C++. Класс не должен предписывать методы распределения своей памяти. Скорее, выделение класса должно быть делегировано конкретной задаче, а хорошо спроектированный класс должен вести себя одинаково хорошо, независимо от того, размещен ли он в динамическом хранилище, в автоматическом хранилище, в файле с отображением памяти или на флэш-карте.

Другие ответы объясняют, почему std::make_shared не использует специфичные для вашего класса operator new и operator delete. Это просто примечание.

Если вы хотите использовать ссылочные указатели счетчиков с вашим объектом и использовать выделение/освобождение вашего класса, другим вариантом является использование boost::intrusive_ptr.

#include <iostream>
#include <boost/intrusive_ptr.hpp>
#include <boost/smart_ptr/intrusive_ref_counter.hpp>

class C : public boost::intrusive_ref_counter<C, boost::thread_safe_counter> {
public:
    static void* operator new(size_t size) {
        void* p = ::operator new(size);
        std::cout << "C::new() -> " << p << "\n";
        return p;
    }

    static void operator delete(void* p) {
        std::cout << "C::delete() -> " << p << "\n";
        ::operator delete(p);
    }
};

int main() {
    boost::intrusive_ptr<C> c(new C);
}

Недостатки boost::intrusive_ptr:

• Это навязчиво. Класс должен иметь счетчик ссылок в качестве одного из своих членов или быть производным от boost::intrusive_ref_counter. Вам не обязательно менять определение класса, можно использовать класс-оболочку со счетчиком, производным от вашего класса (но при этом снова теряются функции распределения/освобождения класса).
• Нет слабых указателей.

Преимущества:

• sizeof(boost::intrusive_ptr<T>) == sizeof(T*), тогда как sizeof(std::shared_ptr<T>) == 2 * sizeof(T*).
• У вас есть выбор потокобезопасного или небезопасного счетчика ссылок. Для объектов, которые никогда не пересекают границы потоков, использование безопасного для потоков счетчика расточительно: атомарные приращения и декременты являются наиболее затратными (как и все атомарные операции чтения-модификации-записи). std::shared_ptr<T> всегда использует 2 (два) потокобезопасных счетчика в многопоточных приложениях. В хорошо разработанных приложениях только объекты нескольких классов сообщений пересекают границы потоков.
• Счетчик ссылок хранится внутри вашего объекта, что является лучшим случаем с точки зрения локальности ссылки / наиболее удобного для кэширования. std::make_shared делает это и за вас, но вы теряете функции выделения/освобождения своего класса.
• Может быть назначен и заменен атомарным способом без ожидания.