Здравствуйте, andrey.desman, Вы писали:

M>>В классе окна есть функция создания
M>>

M>>    virtual WindowTimer createTimer(timeout_t timeoutMs) const override
M>>    {
M>>        auto pSharedImpl = std::make_shared<WindowTimerImpl>(WindowTimerImpl::create(getHwnd(), curTimerId++, timeoutMs));

M>>//...
M>>

AD>Тыж явно зовешь конструктор копирования/перемещения через make_shared.

Боюсь, здесь не так все просто. Ведь create возвращает rvalue, соответственно, shared_ptr конструирует WindowTimerImpl через конструктор перемещения, а не копирования.

Вот дистиллированный пример, который показывает, что если в базовых классах с операторами/конструкторами перемещения все OK, то и с make_shared должно быть OK:

#include <memory>

struct base
{
    virtual ~base() = default;

    base() = default;

    base(const base &) = delete;
    base & operator=(const base &) = delete;

    base(base &&) = default;
    base & operator=(base &&) = default;
};

struct derived : public base
{
    int a_;
    int b_;

    derived(int a, int b) : a_{a}, b_{b} {}

    [[nodiscard]] static derived create(int a, int b)
    {
        return { a, b };
    }
};

int main()
{
    auto d = std::make_shared<derived>(derived::create(0, 1));
    return d->a_ + d->b_;
}

В режиме C++17 нормально компилируется и VS2022, и VS2019.

У меня была когда-то похожая проблема, но там в одном из базовых классов затесался член класса с задизейбленными операторами копирования/перемещения. Поэтому компилятор и для наследника их не мог вывести.

Полагаю, у ТС-а что-то похожее. Но уже в самом WindowTimerImpl.