title: C++11's "const==mutable", How to implement copy? efficiently?
body: <p>As I introduced in this <a href="https://stackoverflow.com/questions/67143468/c11-saga-of-const-mutable-provide-two-classes-for-efficiency">question</a> and this <a href="https://stackoverflow.com/questions/67143433/c11-saga-of-const-mutable-non-const-unprotected-efficient-when-you-need">question</a> , it seem that the modern way to implement a thread safe class with hidden state is this:</p>
  <pre><code>struct Widget {
    int getValue() const{
      std::lock_guard&lt;std::mutex&gt; guard{m}; // lock mutex
      if (cacheValid) return cachedValue;
      else {
        cachedValue = expensiveQuery(); // write data mem
        cacheValid = true;                    // write data mem
        return cachedValue;
      }
    }                                      // unlock mutex
  ...
    private:
    mutable std::mutex m;
    mutable int cachedValue;
    mutable bool cacheValid;
  ...
  };
  </code></pre>
  <p>The logic seems solids and explained here: <a href="https://herbsutter.com/2013/01/01/video-you-dont-know-const-and-mutable/" rel="nofollow noreferrer">https://herbsutter.com/2013/01/01/video-you-dont-know-const-and-mutable/</a></p>
  <p>The question is how do I implement the <em>rest</em> of the class?
  In particular the copy constructor.</p>
  <p>One option is not to implement copy and that's it. (<code>=delete</code>).
  But <code>Widget</code> can have bonafide state (in <code>...</code>) and that state should be copyable or one might want to make copies precisely to alleviate the usage of a <em>single</em> mutex and balance it with the expense of <code>expensiveQuery</code>.</p>
  <p>So lets assume we want to make <code>Widget</code> copyable: one cannot make it default-copyable because the mutex is not copyable so something needs to be implemented manually.</p>
  <p>This is already complicated because one needs to protect the source instance <code>other</code> <em>before</em> copying and for that one seems to need a body for the function.</p>
  <pre class="lang-cpp prettyprint-override"><code>struct Widget {
    Widget(Widget const&amp; other){
      std::lock_guard&lt;std::mutex&gt; guard{other.m}; // lock mutex
       cachedValue = other.cachedValue;
       cachedValid = other.cachedValid;
    }
    ...
  };
  </code></pre>
  <p>This is getting very ugly.
  Maybe one needs to implement a <code>lock()</code> function that RAII-lock and return the unprotected <code>Widget_nonmt</code>, this is possible but you can see how the problem diverges.</p>
  <p><strong>Is this the right way to make the C++11 <code>Widget</code> copyable?</strong></p>
  <p>Finally, we can have a user complaining that now he/she is being forced  me to use the mutex for copies even in context that I know they are unnecessary.</p>
  <p>And this is where it gets crazy, continuing with this logic (same as for the member function) one might think of introducing a non-const copy constructor.</p>
  <pre class="lang-cpp prettyprint-override"><code>struct Widget{
    Widget(Widget&amp; other) : cachedValid{other.cachedValid}, cachedValue{other.cachecValue}{}
    Widget(Widget const&amp; other) ... // same as above
  };
  </code></pre>
  <p>Note that this is not a move constructor, it is something more strange.
  (something like the doomed <code>std::auto_ptr</code>)</p>
  <p>It is not unusable, but is very non-standard and for example the STL containers for example will never use when copying containers of <code>Widget</code>.</p>
  <p>Logic took me to this ugly place, starting from something solid.
  Is this a problem that still waits for a more elegant and general solution?</p>
  <p><strong>Is this the real end of C++98 to C++11 transition saga of a class with protected internal state?</strong></p>