On Thu, Jul 25, 2013 at 12:59 PM, Till Oliver Knoll < [email protected]> wrote:
> I think the answer has already been given with regards to "mutable" and > "const_cast", but at least I seem to have missed at least one reply (sent > in private?) in this > No, no private replies to me at least! :) > discussion. So here are my thoughts :) > > Am 24.07.2013 um 09:29 schrieb Mandeep Sandhu <[email protected] > >: > > > Microsoft is giving a "mutable" example with an access counter: > > http://msdn.microsoft.com/en-us/library/4h2h0ktk(v=vs.80).aspx > > If that increment was not atomically implemented (and to be honest, right > now I don't know whether a "foo++" is atomic - I don't think it is, is it?) > and again two threads > Atomicity of foo++ would depend on the data type of foo, right? Maybe if it's a short, the increment will be atomic. Thought the correct way would be to use atomic types (or maybe use the gcc atomic extensions). > Bottom line: you walk on a very thin line when breaking the "const" with > "mutable" (or "const_cast"). You can totally mis-use it and render the > "const" completely meaningless, you can now rant about C++ letting you > shoot into your foot (once again) and how "const" does not give you /any/ > guarantee about thread-safety (as long as only "readers" are involved... > (even though I understand that "reader-thread-safety" is now the > *intention* of the C++ 11 standard library...) > > > But think about it: having a loophole such as "mutable" is actually > (ironically?) the only way(1) to make a class thread-safe while still > offering const methods! (Java for instance does not even have the lan > > guage concept of "const methods"). > Yes, the irony is unescapable! :) Thanks, -mandeep
_______________________________________________ Interest mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/interest
