6 ms·

C++11 breaking changes in const-correctness guarantees

31 points by cdmh 13y ago

okamiueru 13y 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 13y ago
Related: http://isocpp.org/blog/2012/12/you-dont-know-const-and-mutable-herb-sutter http://isocpp.org/blog/2012/12/you-dont-know-const-and-mutab...
eatitraw 13y 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-You-dont-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 13y 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.
- eatitraw 13y 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.
foobarbazqux 13y 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 13y ago
  I've updated the text to emphasize that. Thanks for pointing it out
  - foobarbazqux 13y ago
    Looks good!
obiterdictum 13y 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 13y 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 13y ago
    Also if a function doesn't have _ANY_ side effect how can it be thread unsafe ?
    - BudVVeezer 13y ago
      It could rely on another variable for computation, and that other variable could be accessed outside of the function. Eg) class c { int m1; public: void set_m1( int i ) { m1 = i; } int calc( int i ) const { return m1 * 10; } }; calc is properly const, but it's not threadsafe.
      - dbcfd 13y ago
        The only time I could see that not being threadsafe is with something like a double on a system without native support, such that bits could change during operation. Even then I think the information gets pulled out. On most systems, the value of calc will still be a race condition dependent on what thread gets there first, even if you lock around m1 or make it atomic. Calc will pull the value from m1 into a register, perform the operation, then return the newly calculated value. Another thread changing m1 will not matter.
      - eatitraw 13y ago
        calc is bitwise const function and therefore is perfectly threadsafe: http://herbsutter.com/2013/05/24/gotw-6a-const-correctness-part-1-3/ http://herbsutter.com/2013/05/24/gotw-6a-const-correctness-p... Threadsafety(in this context) means that any sequence of calls of const-functions from any number of threads will have the same result. In your case there is a single const function, and you may call calc(0) from several threads and it always will return the same value. So it is pretty threadsafe.
ambrop7 13y 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 ;)
- dbcfd 13y 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.
  - ambrop7 13y 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)
    - dbcfd 13y ago
      And that's where functional programming languages are gaining over imperative/oo languages for multi-threaded behavior. Because you have the ability to break the contract, it produces code that is harder to follow, harder to learn for beginners, and harder to debug in parallel/concurrent contexts. It's a shame that this is more best practice. Hopefully the specification will address this in the future that you can only call const from const, and cast from const to non-const can't be used.
- coliveira 13y 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.
cheez 13y 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.
trup 13y 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.
ubos 13y 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.

31 points by cdmh 13y 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 13y ago

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

eatitraw 13y 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-You-dont-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 13y 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.

eatitraw 13y 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.

foobarbazqux 13y 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 13y ago
I've updated the text to emphasize that. Thanks for pointing it out
- foobarbazqux 13y ago
  Looks good!

obiterdictum 13y 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 13y 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 13y ago
  Also if a function doesn't have _ANY_ side effect how can it be thread unsafe ?
  - BudVVeezer 13y ago
    It could rely on another variable for computation, and that other variable could be accessed outside of the function. Eg) class c { int m1; public: void set_m1( int i ) { m1 = i; } int calc( int i ) const { return m1 * 10; } }; calc is properly const, but it's not threadsafe.
    - dbcfd 13y ago
      The only time I could see that not being threadsafe is with something like a double on a system without native support, such that bits could change during operation. Even then I think the information gets pulled out. On most systems, the value of calc will still be a race condition dependent on what thread gets there first, even if you lock around m1 or make it atomic. Calc will pull the value from m1 into a register, perform the operation, then return the newly calculated value. Another thread changing m1 will not matter.
    - eatitraw 13y ago
      calc is bitwise const function and therefore is perfectly threadsafe: http://herbsutter.com/2013/05/24/gotw-6a-const-correctness-part-1-3/ http://herbsutter.com/2013/05/24/gotw-6a-const-correctness-p... Threadsafety(in this context) means that any sequence of calls of const-functions from any number of threads will have the same result. In your case there is a single const function, and you may call calc(0) from several threads and it always will return the same value. So it is pretty threadsafe.

ambrop7 13y 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 ;)

dbcfd 13y 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.
- ambrop7 13y 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)
  - dbcfd 13y ago
    And that's where functional programming languages are gaining over imperative/oo languages for multi-threaded behavior. Because you have the ability to break the contract, it produces code that is harder to follow, harder to learn for beginners, and harder to debug in parallel/concurrent contexts. It's a shame that this is more best practice. Hopefully the specification will address this in the future that you can only call const from const, and cast from const to non-const can't be used.
coliveira 13y 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.

cheez 13y 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.

trup 13y 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.

ubos 13y ago