If only std::unique_ptr and std::variant were introduced in C++ it would be possible to use the default destructor, copy and move constructor…
Your comment doesn’t seem to be right at all. I mean, to start off by design std::unique_ptr disallows copying, and std::variant is completely wrong for the job. From thereon, it seems you’re commenting on a problem you didn’t understood.
The problem is not how to point to the Impl instance, but to get the pimpl-ed class to support copying, moving, etc while not leaking implementation details. This article adds another constraint to the problem, which is explore ways to mitigate the performance penalty caused by dereferencing a pointer each time it’s necessary to access data members. Using std::unique_ptr with a pimpl is already well established, and covered in books like Effective Modern C++, but so is the performance penalty involved.
If only
std::unique_ptrandstd::variantwere introduced in C++ it would be possible to use the default destructor, copy and move constructor…That article would have been useful 15 years ago, but not anymore.
Your comment doesn’t seem to be right at all. I mean, to start off by design
std::unique_ptrdisallows copying, andstd::variantis completely wrong for the job. From thereon, it seems you’re commenting on a problem you didn’t understood.The problem is not how to point to the
Implinstance, but to get the pimpl-ed class to support copying, moving, etc while not leaking implementation details. This article adds another constraint to the problem, which is explore ways to mitigate the performance penalty caused by dereferencing a pointer each time it’s necessary to access data members. Usingstd::unique_ptrwith a pimpl is already well established, and covered in books like Effective Modern C++, but so is the performance penalty involved.