5 ms·
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 th
by alexchamberlain 13y ago
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/ http://blog.reliablecpp.com/2013/09/immutable-vs-const/
- cdmh 13y agoHi 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
- alexchamberlain 13y ago"However, the object to which it is a reference is not const and can change its value, and msg is not immutable."
- cdmh 13y agoThat 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.
- alexchamberlain 13y agoI don't buy it, by calling that function, the caller is saying the value won't change underneath you (because you are being called in multithreaded code). The object itself cannot change itself, though of course there can be mutable members, which tend to be syncronisation mechanisms (mutexes) anyway.
- to3m 13y agoNo, the caller is saying that the callee isn't permitted to change the value! That's what const means. No promise is made about the actual object itself. There's no general way to specify that in C++. This isn't so much an issue for functions, where the caller is stopped while the callee runs, but it needs to be borne in mind for longer-lived objects that take const references - or, indeed, const pointers - to objects that have longer lifetimes again. (I don't think multithreading need be introduced for this to be an issue.) There's quite a difference between an object that could change and one that won't, if you're considering caching values across method calls, or setting up the referring object based on the referred object's current state, etc.
- dllthomas 13y agoRight, multithreading is needed for it to be an issue with functions, not with containers.
- alexchamberlain 13y agoOk, I know what the spec says, but it is utterly rediculous to expect people to write code in which parameters are allowed to change in an undefined way.
- haberman 13y ago> I don't buy it, by calling that function, the caller is saying the value won't change underneath you You really do not understand what "const" means in C++. If what you said were true, a whole class of optimizations would be possible that are not currently possible. For example, consider this silly function: void f(const int *x) { int y = *x; g(); if (y == *x) h(); } If what you said were true, this would be able to optimize away the call to h() completely, but if you compile the function with maximum optimization you will see that this is not the case. Why not? Because the caller could look like this: int val = 0; void g() { val = 1; } int main() { f(&val); }
- Deregibus 13y agoI 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 with such a distinction in this case.
- alexchamberlain 13y agoAgreed, it is completely irrelevant that it could be modified before or after.