Solution with std::variant, no default constructibility, and no redundant `std::get<XY>(x)` calls

[cgraeser]

    // Using a factory functions avoids default constructibility of the variant
    auto factory = [](auto i)
    {
      using VX = std::variant<X0,X1,X2>;
      if (i == 0)
        return VX(std::in_place_type_t<X0>());
      else if (i == 1)
        return VX(std::in_place_type_t<X1>());
      else
        return VX(std::in_place_type_t<X2>());
    };
    // Cast reference to variant<T0,...> to common
    // polymorphic base class T of T0, ... . T should
    // be a template parameter, but since we're at block
    // level T=X is hardwired.
    auto commonBaseCast = [](auto& x) -> decltype(auto) {
      return std::visit([](auto& x) -> decltype(auto){
        return dynamic_cast<X&>(x);
      }, x);
    };
    auto x = factory(i);
    pX = &commonBaseCast(x);

The commonBaseCast could also be replace by single line

    pX = std::visit([](auto& x){ return dynamic_cast<X*>(&x);}, x);

but using a named function for the cast nicely documents the intend.

[amarmer]

in_place_type_t uses placement new.

[cgraeser]

Ah, I missed the 'no placement new' part, because https://isocpp.org/blog/2018/09/stack-factory-puzzle only mentions that it's about construction on the stack.

However I cannot see any feature in C++ that allows to achieve this despite placement new or union. std::variant simply hides this from the user code in a clean and safe way. Hence it's IMHO the best and most idiomatic solution that should be preferred to a union.

[amarmer]

Solution links are in the puzzle description (at the bottom) and since initially description doesn't exclude union, it is considered as a solution as well.

[isc30]

I like this approach with in_place_type_t, it's more clean than using the placement new directly.
+1 for that