Почему нет такого шотката для std::make_shared?

Потому что это не java, в C++ методы не в почёте (до сих пор каются, что надобавляли кучу в basic_string).

Потому что интерфейсы в STL — merdeболь

Потому что слово «шоткат» не существует.

Потому что почти всегда shared_ptr указывает на базовый класс, а ресетится тем, что пришло из фабрики.

Потому что этот шорткат ничего не сокращает.

Да, похоже this.

Это не shortcut, а функция, позволяющая сэкономить 1 вызов аллокатора памяти.

Тем не менее, вот такое реализуемо:

std::unique_ptr<Base> ptr;
ptr.emplace<Derived>(arg1, arg2);

Хотя ИМХО, = std::make_unique<Derived>(arg1, arg2) как-то нагляднее.

позволяющая сэкономить 1 вызов аллокатора памяти.

... в сознании программиста.

в какой современной реализации это не так?

emplace

Оно должно создавать объект в сторадже старого объекта?

Оно должно создавать объект в сторадже старого объекта?

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

в какой современной реализации это не так?

Реализации метода я не нашел (даже в расширениях). Хотя с другой стороны, clang 6.0 на amd64 порешал все через constant propagation: https://godbolt.org/z/SQMa0E

#include <memory>

struct Foo {int bar;};

int f(std::unique_ptr<Foo> &ptr) {
    ptr = std::make_unique<Foo>(Foo{4});
    return ptr->bar;
}

int main() {
    auto a = std::make_unique<Foo>(Foo{3});
    return f(a) - 4;
}

/*
main:                                   # @main
        xor     eax, eax
        ret
*/

А GCC 8 таки не смог (даже с -O3): https://godbolt.org/z/0rsT0s

C другой стороны, я все же посыпаю голову пеплом, ибо f() таки остался как и был (if (ptr) delete ptr; ptr = new). Что, впрочем, не значит, что других оптимизаций не будет.

мы, вообще-то, про shared_ptr

ничего, что это называется reset()?

ничего, что это называется reset()?

Так я это и имел ввиду, только другими словами: Почему нет такого шотката для std::make_shared? (комментарий)

мы, вообще-то, про shared_ptr

Он создает много лишнего шума в ассемблере своим подсчетом ссылок и его guard-ами. Я себе подумал, что суть в unique_ptr останется той же относительно действий с владеемой памятью (обьектом).

Хотя да, оптимизациям сложно через барьеры прыгать.

Если новый обьект влазит в аллоцированную память, то как оптимизация может быть.

Создаст проблемы с объектами с ссылочными и константными мемберами.

Создаст проблемы с объектами с ссылочными и константными мемберами.

Не должно, если вызвать деструктор а потом конструктор (in-place).

std::shared_ptr<A> a = new A(...);

два выделения: одно под A, второе — под счётчик ссылок.

std::shared_ptr<A> a = std::make_shared<A>(...);

одно выделение. функция делает всю магию сама.

Не должно, если вызвать деструктор а потом конструктор (in-place).

Ты хотел сказать «не должно, если использовать std::launder»?

Ты хотел сказать «не должно, если использовать std::launder»?

Я таки слышал о std::launder ;) Но спасибо за напоминание. В смысле да.