Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Yes, you are absolutely correct. You should make your objects follow these guidelines, and therefore access to them will potentially be slower in C++11. If <strong><em>and only if</em></strong>:</p> <ol> <li><p>The class has <code>mutable</code> members which <code>const</code> member functions modify.</p></li> <li><p>The object is being accessed from multiple threads.</p></li> </ol> <p>If you ensure that at least one of these is untrue, then nothing changes. The number of objects that are being accessed from multiple threads should always be as minimal as possible. And the number of classes that have mutable members should be minimal. So you're talking about a minimal set of a minimal set of objects.</p> <p>And even then... all that is required is that data races will not be broken. Depending on what the mutable data even is, this could simply be an atomic access.</p> <p>I fail to see the problem here. Few of the standard library objects will have mutable members. I defy you to find a reasonable implementation of <code>basic_string</code>, <code>vector</code>, <code>map</code>, etc that need mutable members.</p> <blockquote> <p>It seems that in C++11, you cannot use a class with the standard library unless its const member functions are internally synchronized (or do not perform any writes).</p> </blockquote> <p>This is incorrect. You most certainly can. What you <em>cannot</em> do is attempt to access that class across multiple threads in a way that would "perform any writes" on those mutable members. If you never access that object through that C++11 class across threads in that particular way, you're fine.</p> <p>So yes, you can use them. But you only get the guarantees that your own class provides. If you use your class <em>through</em> a standard library class in an unreasonable way (like your <code>const</code> member functions not being <em><code>const</code></em> or properly synchronized), then that's <em>your fault</em>, not the library's.</p> <blockquote> <p>So, in C++98 you can get away with not doing any internal synchronization for mutable members, but in C++11 you can't.</p> </blockquote> <p>That's like saying you can get away with computer crime back in the Roman Empire. Of course you can. They didn't have <em>computers</em> back then; so they didn't know what computer crime <em>was</em>.</p> <p>C++98/03 did not have the concept of "threading". Thus, the standard has no concept of "internal synchronization", so what you could or could not "get away with" was neither defined nor undefined. It made no more sense to ask that question of the standard than to ask what the hacking laws were during Ceaser's day.</p> <p>Now that C++11 actually defines this concept and the idea of a race condition, C++11 is able to say when you can "get away with not doing any internal synchronization".</p> <p>Or, to put it another way, here is how the two standards answer your question: What is the result of a potential data race on a <code>mutable</code> member when accessed via a member function declared <code>const</code> in the standard library?</p> <p>C++11: There will be no data races on any internal members when accessed by a <code>const</code> function. All standard library implementations of such functions must be implemented in such a way that a data race cannot occur.</p> <p>C++98/03: What's a data race?</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload