

C++11 breaking changes in const-correctness guarantees - cdmh
http://cdmh.co/16rCL82

======
eatitraw
Awesome talk by Herb Sutter in "C++ and Beyond" "You don't know [blank] and
[blank]": [http://channel9.msdn.com/posts/C-and-Beyond-2012-Herb-
Sutter...](http://channel9.msdn.com/posts/C-and-Beyond-2012-Herb-Sutter-You-
dont-know-blank-and-blank)

As you can guess it is about const and mutable, and Herb speaks about this
feature(or problem -- depending on how you see it).

C++98: const == logically const

C++11: const == thread-safe

------
obiterdictum
C++98 "const" code still works exactly the same in single-threaded
environment, so this change is not breaking, because no _existing_ code is
broken.

~~~
Someone
100% correct; before this standard, there was no standard for how C++ code
should behave when run by multiple threads.

Also, I do not think the claim that const member functions cannot have side
effects is correct.

For example, it is OK, but very bad practice to have a const member function
update a global integer counter.

~~~
stingraycharles
Also, you can declare member variables as mutable which allows you to modify
it from a const function. An example legitimate application for this is
acquiring a read lock on a mutex from a const function.

~~~
dbcfd
C++11 is finally saying that this is not ok, as it really breaks the const
contract, and can produce varying behavior in a threaded situation.

You could also argue that read/write locks aren't legitimate applications
(starvation, increased contention, alternate solutions).

~~~
stingraycharles
But the const function could still accept a non-const reference to a mutex,
and still produce varying behavior in a threaded situation. In other words,
what you're describing as the const contract sounds a lot like a pure
function, which it definitely is not.

~~~
dbcfd
I'm not sure how it would produce varying behavior if it satisfies the const
contract, in regards to the object itself.

You're passing in a non-const reference, so wherever that came from would be
expected to change. However the object itself would not change. Your object
would be at StateA regardless of who gets the mutex first.

------
ashishb4u
Related: [http://isocpp.org/blog/2012/12/you-dont-know-const-and-
mutab...](http://isocpp.org/blog/2012/12/you-dont-know-const-and-mutable-herb-
sutter)

------
dkhenry
I dont see that as being a breaking change. In both cases its wrong to mutate
the object in the const member, Its just in C++98 no one _explicitly_ told you
that. Maybe we should spell other good programming practices out for you so
you can start following them before they are stated by the standards commitee

1\. Don't use global state 2\. Don't use goto 3\. Don't, for the love of all
things good in this world, use exceptions to do control flow 4\. Don't just
pass strings around in your functions and deserialise them in your function
5\. Make your data members private with public accessors and mutators.

~~~
eatitraw
> In both cases its wrong to mutate the object in the const member, Its just
> in C++98 no one _explicitly_ told you that.

How so? You cannot mutate a data member(without placing mutable before it) in
const member function. It is a compiler error. Pretty explicit IMO.

The point of the article is that you should ensure thread-safety when you
mutate mutable(sounds funny, I know) members in const methods.

------
ubos
The author is a total idiot.

The C++ language is totally unsafe, so when you call third-party code,
literally anything can happen.

Just because there might be a convention for "const" methods to be thread-safe
doesn't mean that they are actually implemented this way, regardless of what
the language spec says.

It's alarming that this guy apparently writes books, hopefully no one reads
them.

------
foobarbazqux
> The most common use of mutable data, and I would argue that the only
> reasonable use of mutable data is for caching.

This was confusing to read in the context of C++, because I typically
associate that view with functional programming. Don't the majority of C++
classes require mutable data to work properly, even the ones in the STL? How
do you write std::vector<> without mutable data?

Ok, so I looked a bit more, and it turns out there's a "mutable" keyword...

~~~
cdmh
I've updated the text to emphasize that. Thanks for pointing it out

~~~
foobarbazqux
Looks good!

------
ambrop7
I've always suspected not using const all around my OO code is going to save
me some trouble sometime. Looks I was right ;)

~~~
coliveira
Completely agree. Despite what gurus say, there is hardly an advantage in
writing const correct code, other than complying with existing libraries.
Const is a nice concept in theory, but it doesn't provide any guarantees,
since it is so easy to cast const away from any pointer. As a result,
compilers can't do anything in practice with const, other than give an endless
stream of compilation errors.

~~~
dbaupp
Often, the point of stuff like 'const' is exactly to give a stream of
compilation errors, because they presumably mean the programmer is doing
something wrong (either using the const keyword wrong, or using the things
marked const incorrectly)

Even if things like 'const' are useless to the compiler in optimisation terms,
they provide (weak) contracts for the humans writing the code, and obvious
flags when these contracts are broken, by having to be explicit about, in this
instance, const_cast's. ('git grep const_cast' => places to examine closely
for bugs.)

~~~
coliveira
The problem is that const is also flawed as a contract. Whenever you're using
const, you're trying to design a class that behaves as a mutable or as an
immutable object, depending on how the pointer/reference is declared. A class
that behaves in two different ways depending on the situation is a recipe for
disaster, and that's exactly what const asks us to do.

I only noticed this problem when I learned how languages such as
Smalltalk/objective-c deal with the same issue: they create different classes
for each situation, so if you want a mutable array you have to say so.

------
okamiueru
Completely unrelated to the content, but it annoys me when sites put 'design'
in front of readability. Darkening the background, lightening the text color
and reducing the font size is a sure way to make it hard to see.

------
cheez
I always wrote const member functions assuming they had to be threadsafe. I
guess that's the "advantage" of always having worked with multi-threaded code.

