On 20/06/2019 17.48, Ville Voutilainen wrote:
> Ideas like these pop up from material like More Effective C++. Do
> tell, what in this attempt to make sure that your type is never
> created in any other way than you choose is worth a language change?
> Is the hypothetical guarantee that the creation always happens just
> the way you intended really worth the cost?
I think you think I'm using a pattern that is not what I'm using.

Let me give a different example:

  class foo
  {
    foo();
    // maybe other ctors
    foo(foo const& other) : foo{other.d_ptr} {}

  protected:
    foo(QSharedDataPointer<FooData> const& d) : d_ptr{d} {}

    QSharedDataPointer<FooData> d_ptr;
  }

Derived classes *need* to be able to call the protected constructor, but
users of the type should absolutely never, ever call it, hence it is
protected.

In my real code, I have a constructor "like" this (i.e. one that exposes
implementation details and "should be" protected), that my class's
implementation needs to be able to invoke through make_shared.

Are you essentially saying that the "correct" solution is to not make
the constructor protected? (But then why bother with access protection
at all? Obviously, someone, at some time, thought that access protection
was a useful idea...)

-- 
Matthew