C++11 breaking changes in const-correctness guarantees

by cdmh • 13 years ago

31 35 13 years ago

okamiueru• 13 years ago

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.

ashishb4u• 13 years ago

eatitraw5• 13 years ago

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...

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

dkhenry• 13 years ago

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.

eatitraw5• 13 years ago

> 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.

foobarbazqux2• 13 years ago

> 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• 13 years ago

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

foobarbazqux2• 13 years ago

Looks good!

obiterdictum• 13 years ago

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• 13 years ago

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.

JacobiX• 13 years ago

Also if a function doesn't have _ANY_ side effect how can it be thread unsafe ?

stingraycharles2• 13 years ago

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.

ithkuil• 13 years ago

indeed, this article sounds overly alarming. It is true though that it's possible that future code written with the c++11 spec in mind will incorrectly assume some properties of a library which was written as c++98.

In this case the user of the library should be aware of which assumptions the library guarantees, not only what the current compiler does

jhdevos• 13 years ago

There are two different considerations:

* what the compiler will enforce: this has nothing to do with thread safety, and will allow what you mention.

* what guarantees the standard library will give:

[17.6.5.9/3] A C++ standard library function shall not directly or indirectly modify objects (1.10) accessible by threads other than the current thread unless the objects are accessed directly or indirectly via the function’s non-const arguments, including this.

This means that the standard library assumes that your const objects will be thread safe in order to guarantee thread-safety itself. Updating a global without synchronization is not thread-safe.

ambrop73• 13 years ago

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

dbcfd7• 13 years ago

No.

If you used const correctly, you couldn't change anything about the class, therefore it was also thread-safe. If your class had mutable members or got around the const guarantee through backdoors (e.g. pointer passed in that modified another object, or member pointers that called non-const methods), it wasn't correctly const and shouldn't have been marked as such.

There is nothing wrong with the const keyword, just with programmers who marked things const that broke the const contract. There is no language ambiguity on this.

ambrop73• 13 years ago

The language doesn't define "correct const usage" the way you see it. It only specifies what is defined and undefined behavior. Casting a pointer-to-const to a pointer-to-non-const and modifying an object via that is defined behavior as long as the original object is not declared const. (see my comment above)

coliveira2• 13 years ago

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.

ambrop73• 13 years ago

I've actually just looked at the standard and there is a clear example something like this:

  int x;
  int const *cpx = &x;
  int *px = const_cast<int *>(cpx);
  *px = 1; // defined behavior, modifying non-const object through non-const pointer

While this may seem ok here, consider that the same applies to functions taking pointers to const. While this usually means the function won't modify the pointed-to objects, there is no guarantee from the language about that.

dbcfd7• 13 years ago

const_cast = code smell mutable = code smell

Pretty much anything that breaks the contract is readily apparent when reading/searching the code, and indicates that something needs to be rewritten.

Just because you can break the contract doesn't mean you should break the contract. Const correctness produces more readable/easily understood code.

Don't be lazy, and make life better for anyone that has to maintain and use the code after you.

dbaupp• 13 years ago

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.)

cheez• 13 years ago

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.

ubos• 13 years ago

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.

C++11 breaking changes in const-correctness guarantees

Related Stories