Yeah. const_cast (and C-style casts) and mutable existing in the language make const pretty useless to the optimizer. But at least they are trying to get some benefit from it in some cases.
A C++ variant (compiler flag) that would remove const_cast, mutable and the cast-const-away parts of C-style casts from the language and allow the optimizer to put more value into 'const' could be interresting.
const_cast<> isn't the root of the problem. If someone passes you a pointer to a const pointer to a non-const thing, they can still just mutate the non-const thing without any casts. You'd have to forbid non-const to const pointer conversions entirely (which would imply removing const_cast<>, as there would no longer be any situations in which it was legal to use).
Right. There are lots of corner cases that would need to be identified and considered in the case of a "strong const" C++ variant (like what you point out) - I still think it could be an interresting experiment.
I've never actually seen a union used in a C++ codebase. What's the usecase? I know people use them in C for bitfields, but outside of embedded (which is almost always just pure C) that just doesn't seem to come up
Embedded can be almost anything, C/C++/java and so on. I've seen microcontrollers with 8K of program space, written in C++. Why? Because it optimizes better than the 'C' programmer does.
Unions are used for interpreting any kind of record stream. Reading serialized binary objects from a file? Use a union. Network packets? A union.
When reading from a binary source, I've seen that, instead of unions, the char pointer will be cast to a pointer to the appropriate data structure. What is the advantage of using a union instead of casting?
Well, for one, unions have defined behavior in C, while passing pointers around and casting them randomly doesn't.
I don't know if this is the best example. Generally you see unions in C to cover "tagged unions", I.e. Those things that would be subsumed by algebraic data types in other languages.
The usual way to do this via memcpy, rather than either a union (requires some non-portable extension like "packed") or pointer casting (invokes undefined behavior if alignment isn't satisfied).
ISO Core C++ is trying to do something like this. They have to, in order to count on the properties of "const" for their static safety analysis.
(I have my reservations about whether ISO Core C++ with the lifetime profile really qualifies as C++ anymore due the massively backwards incompatible nature of the changes, but it'll be interesting nonetheless.)
Can you link to more information about this? Googling for "c++ core lifetime profile" just takes me to the Core Guidelines.
Is the idea that they'll codify a bunch of static analysis that disallows problematic constructs & patterns? Could implementers then add something like Rust's ownership checks (assuming full source visibility)?
My sibling commentators have given you good links, but it's worth noting that these systems and Rust have a lot of differences. For example, they're explicitly not trying to tackle data races, and the way that they work is different.
Which, to be fair, is all register buys you also: the compiler isn't supposed to allow you to take the address of a register variable (although the Plan 9 compiler didn't enforce the rule).
What useful meaning is there for optimization purpuses?
As far as I know, there is no meaning in pointer-to-const other than it must not be used directly to modify the stored value (if it is you get a compile error). It is always valid from the perspective of language semantics to cast-away the const and modify the pointed-to object, as long as the object is not itself read-only. So, to my knowledge, they could not make any additional assumptions based on pointer-to-const, though they could use it as a hint to look for a possible optimization.
29 comments
[ 1.7 ms ] story [ 93.2 ms ] threadUnions are used for interpreting any kind of record stream. Reading serialized binary objects from a file? Use a union. Network packets? A union.
I don't know if this is the best example. Generally you see unions in C to cover "tagged unions", I.e. Those things that would be subsumed by algebraic data types in other languages.
(I have my reservations about whether ISO Core C++ with the lifetime profile really qualifies as C++ anymore due the massively backwards incompatible nature of the changes, but it'll be interesting nonetheless.)
Is the idea that they'll codify a bunch of static analysis that disallows problematic constructs & patterns? Could implementers then add something like Rust's ownership checks (assuming full source visibility)?
Microsoft has delivered a beta version of it with VS 2015 Update 1.
Clang guys are improving clang-tidy for similar errors.
Check Herb Sutter's talk at CppCon 2015.
https://youtu.be/hEx5DNLWGgA
Sutter comments on const_cast around 11m15s.
I'm excited to see this all play out though!
'inline' would be a better example of another "ignored" keyword.
As far as I know, there is no meaning in pointer-to-const other than it must not be used directly to modify the stored value (if it is you get a compile error). It is always valid from the perspective of language semantics to cast-away the const and modify the pointed-to object, as long as the object is not itself read-only. So, to my knowledge, they could not make any additional assumptions based on pointer-to-const, though they could use it as a hint to look for a possible optimization.