Оглядываясь назад, учитываяmake_shared, было быshared_ptr есть конструктор, который принимает необработанный указатель, если он был введен в C ++ 11?

Есть ли веские аргументы или варианты использования в пользу этого конструктора?

Это позволило бы избежать хорошо документированной ловушкиИсключение-безопасности ираспределение памяти / производительность использованияmake_shared.

Я считаю, что еще одно преимущество требуетshared_ptr строительство черезmake_shared было бы то, что это может быть один указатель под капотом, уменьшая использование памяти и делая такие вещи, какatomic_compare_exchange намного проще (и, возможно, более эффективно). (увидетьпрезентация из C ++ сейчас)

РЕДАКТИРОВАТЬ

Я понимаю, что shared_ptr, который в основном является intrusive_ptr (с объединенным объектом и блоком управления), не будет иметь возможностей, которые есть у текущего std :: shared_ptr. Подобно:

возможность освободить объект отдельно от контрольного блока (что хорошо, если вы долго жили слабо)

совместимость с библиотеками, которые передают вам сырые указатели и ответственность за их освобождение

возможность хранить произвольные ресурсы с пользовательскими удалителями (или без них, для не владеющих указателями)

способность указывать на подобъект (например, член), сохраняя при этом родительский объект живым.

Я предлагаю, чтобы эти функции не использовались достаточно часто (или в случае использования их в качестве raii-обертки), возможно, не подходят лучше всего, чтобы оправдать дополнительные расходы:

отдельный указатель на блок управления(потенциально) более сложная логика atomic_compare_exchange, возможно, не стоит того.

В мире C ++ 98 (где был представлен shared_ptr) make_shared менее практичен и менее удобен для пользователя (отсутствие идеальной пересылки требует использования упаковщиков ссылок, а отсутствие шаблонов с переменным числом элементов делает реализацию неуклюжей).