31–40 of 58 posts
Earlier quoted context omitted.
const_cast is undefined behavior? Can you cite the spec?
const_cast is undefined behavior if the actual object is const. If it's a mutable object that just happened to be passed as a reference you can const_cast it. Or that's how I understand it.
Earlier quoted context omitted.
That code isn't valid C++. Modifying a const object is undefined behavior. You would have to remove the const on your string in main to make the program well-defined.
const_cast is undefined behavior? Can you cite the spec?
7.1.5.1/4: Except that any class member declared mutable (7.1.1) can be modified, any attempt to modify a const object during its lifetime (3.8) results in undefined behavior.
const_cast is not undefined behavior, but modifying a const object is.
The main question I have is, why? The author also has a rather [confusing article][1] about immutable vs const, that I would discredit personally. He claims that objects accessed via reference to const can modify themselves, which is not true, as you can only access const functions through a const reference. [1]: http://blog.reliablecpp.com/2013/09/immutable-vs-const/
The main question I have is, why? The author also has a rather [confusing article][1] about immutable vs const, that I would discredit personally. He claims that objects accessed via reference to const can modify themselves, which is not true, as you can only access const functions through a const reference. [1]: http://blog.reliablecpp.com/2013/09/immutable-vs-const/
The example is misleading because there isn't any reason why you would be concerned with such a distinction in this case.
The main question I have is, why? The author also has a rather [confusing article][1] about immutable vs const, that I would discredit personally. He claims that objects accessed via reference to const can modify themselves, which is not true, as you can only access const functions through a const reference. [1]: http://blog.reliablecpp.com/2013/09/immutable-vs-const/
Hi Alex, you say I "claim[s] that objects accessed via reference to const can modify themselves". Which paragraph are you referring to? It don't see that? I'm happy to update the article to make it clearer. Thanks, Craig
The main question I have is, why? The author also has a rather [confusing article][1] about immutable vs const, that I would discredit personally. He claims that objects accessed via reference to const can modify themselves, which is not true, as you can only access const functions through a const reference. [1]: http://blog.reliablecpp.com/2013/09/immutable-vs-const/
I think the implication is that since void output(std::string const &msg); takes a const reference, that function cannot change the value of msg. What the function does not know is whether or not anyone else outside of the function could change that value. It doesn't know if the original creation of the object was const or not const. The example is misleading because there isn't any reason why you would be concerned…
Earlier quoted context omitted.
const_cast is undefined behavior if the actual object is const. If it's a mutable object that just happened to be passed as a reference you can const_cast it. Or that's how I understand it.
The funny thing is - it doesn't even show a warning compiled with -Wall.
Earlier quoted context omitted.
Hi Alex, you say I "claim[s] that objects accessed via reference to const can modify themselves". Which paragraph are you referring to? It don't see that? I'm happy to update the article to make it clearer. Thanks, Craig
"However, the object to which it is a reference is not const and can change its value, and msg is not immutable."
Earlier quoted context omitted.
"However, the object to which it is a reference is not const and can change its value, and msg is not immutable."
That is accurate. The object reference by immutable msg is hello_world which is mutable. If the value of hello_world changes, then the value of msg changes too. In the simple example, it won't happen, but the point is that it could , especially when multi-threaded.