Click here to Skip to main content
15,868,016 members
Please Sign up or sign in to vote.
1.00/5 (1 vote)
See more:
The const_cast can be used to remove volatile qualifier:
Quote:
In particular, only const_cast may be used to cast away (remove) constness or volatility
const_cast conversion - cppreference.com[^]

But the volatile object should NOT be accessed that way:
Quote:
Any attempt to refer to a volatile object through a non-volatile glvalue (e.g. through a reference or pointer to non-volatile type) results in undefined behavior
cv (const and volatile) type qualifiers - cppreference.com[^]

So, what the point?

Also, as i see it, removing the const cv from an actual const object (stored in the memory page marked as const) leads to the segmentation fault.

What I have tried:

I confirm that, when i was trying to access the volatile object by none volatile ref (using the const_cast) in MS VS 2013 it works fine, through compiled in MS VS 2015 it just crushed, so yep this is clearly UB.
Posted
Updated 10-Jun-16 4:21am

It's a kludge, to let you call non-const legacy code that you know won't modify the value but that insists on a non-const parameter.

Basically, if you use it, it's at your own risk!
 
Share this answer
 
Comments
Shvetsov Evgeniy 10-Jun-16 17:01pm    
Thanks for your answer! A kludge naturally built-in in the programming language is a very interesting phenomenon by itself :) Through C++ has more such a things: mutable AND friend, which breaks constness AND encapsulation.
OriginalGriff 10-Jun-16 17:14pm    
C++ is getting a bit old now, and like all elderly things it's had a few transplants that perhaps it shouldn't have needed...:laugh:
Doesn't mean it's a bad language, but ... it has things that it needed to get round a problem here, a difficulty there, that a newer language has designed not to need. Yet. See "var" and "dynamic" in C# and the way they are becoming abused.
Shvetsov Evgeniy 10-Jun-16 19:26pm    
Well, as we say in Russia: "the old mule ploughs a straight urrow" :) ANY programming language which continues to evolve is affected by this problem. The Java language, i think, is the most famous example here. The problem is you can NOT foresee all, so the problem is strictly human based AND so it is insoluble, as the mankind, in opposite to the technology, is NOT evolving (OR at least NOT so fast).
There is no reason to remove volatility using const_cast and there are very rare situations where removing constness makes sense.

The warnings are quite clear and that it does work sometimes with a specific compiler does not mean that it will work always (it may fail during run-time even with such a compiler).

Removing constness should be used only when really necessary and you are sure that there will be no side effects and the real data is not constant (e.g. you have a non const array referenced by a const pointer).
 
Share this answer
 
Comments
Shvetsov Evgeniy 10-Jun-16 17:06pm    
Thanks for your reply! "There is no reason to remove volatility using const_cast" - if there were NO reason, i guess C++ standardization committee would NOT allow to do that. "If stars are lit it means - there is someone who needs it".
Jochen Arndt 11-Jun-16 4:31am    
I can only guess why it is allowed:
const and volatile are type qualifiers defined and handled in a similar way and the committee decided to provide only one conversion operator.

Casting away the qualifier for a const or volatile object results in undefined behaviour. So it should be used only for pointers and references that access non-const/-volatile objects but are declared itself as const/volatile.

While this is used frequently with const (e.g. with function parameters to indicate that the function will not change the referenced object), I have never seen the usage of volatile in such a context. If you find a situation where using it makes sense, you have disproved my statement.

To nail it down:
The conversion operator is there for volatile too because it is allowed to use the volatile qualifier with references. What does not make sense from my point of view is using volatile for references to non-volatile objects.

However, using it does not harm. The only side effect is that the compiler will not optimise the code using the reference.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900