On Wed, Jul 24, 2013 at 8:40 PM, Thiago Macieira <[email protected]>wrote:
> On quarta-feira, 24 de julho de 2013 12:59:31, Mandeep Sandhu wrote: > > > > http://channel9.msdn.com/posts/C-and-Beyond-2012-Herb-Sutter-You-dont-know > > > -blank-and-blank > > Thanks for sharing this link. It was very informative. (BTW, this applies > > only to C++11) > > It does not apply to anything. > What I meant with "it applies to C++11", is that the C++11 standard library now follows/respects the correct meaning of "const", i.e all std lib's const functions are thread safe and in turn they expect "user" defined const functions to be thread-safe as well. Though as you mentioned, is not enforced by the language. The only thing thats tying it up with C++11 is that the correct "interpretation" of const is being followed in the new C++11 std lib, isn't this what he meant in the talk? CMIIW. > > This is an idea by Herb Sutter and, to be honest, I agree with him that > const > *should* mean that. > > But it doesn't. The language does not enforce anything. There's no way to > guarantee that the user code in a const function is actually thread-safe. > It's > very easy to break out of the safety: > > const_cast > mutable > But having a mutable in a const function is (logiaclly) right. Rather thats how, Herb explains, one would implement a thread-safe const function. On the other hand doing a const_cast, in a const function, looked more of a work-around to make the compiler happy. -mandeep > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Interest mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/interest > >
_______________________________________________ Interest mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/interest
