Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C++ (http://www.velocityreviews.com/forums/f39-c.html)
-   -   const_cast undefined results (http://www.velocityreviews.com/forums/t286190-const_cast-undefined-results.html)

Simon Bailey 10-12-2004 08:08 AM

const_cast undefined results
 
In the following code at the end of the program z = 20 & y = 99.

void doit(const int* x)
{
int* nonconst;
nonconst = const_cast<int*>(x);
*nonconst = 99;
}

int main(int argc, char* argv[])
{
const int y = 20;
int z;
doit(&y);
z = y; // Fails
return 0;
}

having looked at the generated assembler code I can see why this is
'failing' as the assembler uses a numeric literal to assign 20 to z on the
failing statement. This is logical & efficient in most cases as y is a
const which can be evaluated at compile time. However, since the facility
has been provided to un-const a const variable (bad programming practice?) I
would have thought that this code should work. I've tried it on Microsoft &
g++ compilers with the same result. I have seen a web site that said that
the result of const_cast in cases like this was undefined. I find the idea
of undefined results in programming utterly abhorrent. We might as well
accept 'nearly working' programs with such constructs as 'do sometimes'
loops etc. Can this 'undefined' result be correct or is it a bug in the
language specification / compilers?

Any comments?

Simon




Peter van Merkerk 10-12-2004 08:35 AM

Re: const_cast undefined results
 
Simon Bailey wrote:
> In the following code at the end of the program z = 20 & y = 99.
>
> void doit(const int* x)
> {
> int* nonconst;
> nonconst = const_cast<int*>(x);
> *nonconst = 99;
> }
>
> int main(int argc, char* argv[])
> {
> const int y = 20;
> int z;
> doit(&y);
> z = y; // Fails
> return 0;
> }
>
> having looked at the generated assembler code I can see why this is
> 'failing' as the assembler uses a numeric literal to assign 20 to z on the
> failing statement. This is logical & efficient in most cases as y is a
> const which can be evaluated at compile time. However, since the facility
> has been provided to un-const a const variable (bad programming practice?) I
> would have thought that this code should work. I've tried it on Microsoft &
> g++ compilers with the same result. I have seen a web site that said that
> the result of const_cast in cases like this was undefined. I find the idea
> of undefined results in programming utterly abhorrent. We might as well
> accept 'nearly working' programs with such constructs as 'do sometimes'
> loops etc. Can this 'undefined' result be correct or is it a bug in the
> language specification / compilers?


It is correct as far as the C++ standard is concerned, and it is a bug
in your program. When you are casting away constness you are telling the
compiler "I know better; this is really not a const object". If you are
lying to the compiler you can be sure it will find a way to get back at
you. When using casts it is *your* responsibility to make sure that the
cast is correct, because you are effectively disabling the safeguards of
the compiler. This is why casts are best avoided. Good C++ code has very
few, if any, casts.

--
Peter van Merkerk
peter.van.merkerk(at)dse.nl

JKop 10-12-2004 08:54 AM

Re: const_cast undefined results
 
Simon Bailey posted:

> In the following code at the end of the program z = 20 & y = 99.
>
> void doit(const int* x)
> {
> int* nonconst;
> nonconst = const_cast<int*>(x);
> *nonconst = 99;
> }


The above function's documentation would have to specify:

This function exhibits undefined behaviour if provided with a pointer to a
const object.

(. . . as ludacris as it may sound)


> int main(int argc, char* argv[])
> {
> const int y = 20;
> int z;
> doit(&y);



AAAAAAAaaahhhhhhh!


> z = y; // Fails
> return 0;
> }
>
> having looked at the generated assembler code I can see why this is
> 'failing' as the assembler uses a numeric literal to assign 20 to z on
> the failing statement.


Beautiful!


> This is logical & efficient in most cases as y
> is a const which can be evaluated at compile time. However, since the
> facility has been provided to un-const a const variable (bad
> programming practice?) I would have thought that this code should work.


Nope. It only works if the original object was non-const. Otherwise it's
undefined behaviour.

Consider if you have a "const" reference, but the reference refers to a non-
const object. Use of "const_cast" there would be grand.

> I've tried it on Microsoft & g++ compilers with the same result. I
> have seen a web site that said that the result of const_cast in cases
> like this was undefined. I find the idea of undefined results in
> programming utterly abhorrent.


int* const p = reinterpret_cast<int* const>(876755);

*p = 5;

> We might as well accept 'nearly
> working' programs with such constructs as 'do sometimes' loops etc.


Please speak English.

> Can this 'undefined' result be correct or is it a bug in the language
> specification / compilers?


The C++ Standard explicitly defines "undefined behaviour" and specifies in
what situations it arises. The following qualifies as undefined behaviour:

int main()
{
int const blah = 5;

const_cast<int&>(blah) = 4;
}

And why? Because the original object was const.


-JKop

John Harrison 10-12-2004 09:12 AM

Re: const_cast undefined results
 

"Simon Bailey" <trainersbuk@yahoo.co.uk> wrote in message
news:eiMad.504$cm4.291@newsfe1-win.ntli.net...
> In the following code at the end of the program z = 20 & y = 99.
>
> void doit(const int* x)
> {
> int* nonconst;
> nonconst = const_cast<int*>(x);
> *nonconst = 99;
> }
>
> int main(int argc, char* argv[])
> {
> const int y = 20;
> int z;
> doit(&y);
> z = y; // Fails
> return 0;
> }
>
> having looked at the generated assembler code I can see why this is
> 'failing' as the assembler uses a numeric literal to assign 20 to z on the
> failing statement. This is logical & efficient in most cases as y is a
> const which can be evaluated at compile time. However, since the facility
> has been provided to un-const a const variable (bad programming practice?)


That is not correct. The facility has been provided to allow you to remove
const in a circumstance when you know that would not result in a const being
modified. A typical situation would be when you have to call legacy or badly
written code that does not use const when it should. Modifying a const is
undefined behaviour however you manage it. Having this rule allows greater
flexibility for compiler writers, for instance in code optimization.

> I
> would have thought that this code should work. I've tried it on Microsoft

&
> g++ compilers with the same result. I have seen a web site that said that
> the result of const_cast in cases like this was undefined.


Correct.

> I find the idea
> of undefined results in programming utterly abhorrent.


Well then you should avoid the circumstances which give rise to undefined
behaviour like the above.

> We might as well
> accept 'nearly working' programs with such constructs as 'do sometimes'
> loops etc. Can this 'undefined' result be correct or is it a bug in the
> language specification / compilers?
>
> Any comments?
>


C and C++ have hundreds of circumstances that produce undefined behaviour.
If you don't like it then you should pick a different programming language.

john



Ron Natalie 10-12-2004 01:44 PM

Re: const_cast undefined results
 
JKop wrote:
>
> This function exhibits undefined behaviour if provided with a pointer to a
> const object.
>
> (. . . as ludacris as it may sound)
>
>

It's not quite as ludicrous as it sounds. There's a difference between
a const object and an expression of some const type that refers to a
non-const object.

rookkey 10-13-2004 01:38 AM

Re: const_cast undefined results
 
"Simon Bailey" <trainersbuk@yahoo.co.uk> wrote in
news:eiMad.504$cm4.291@newsfe1-win.ntli.net:

> I have seen a web site that said that the result of const_cast in cases
> like this was undefined. I find the idea of undefined results in
> programming utterly abhorrent. We might as well accept 'nearly
> working'programs with such constructs as 'do sometimes' loops etc. Can
> this 'undefined' result be correct or is it a bug in the language
> specification > / compilers?


Performing a const_cast to remove the constness of a constant object and
then modifying that object is undefined behavior. Period. The C++
standard makes this clear.

So, you're likely wondering: what good is const_cast then?

Think of badly written API's.

Suppose there is a function you would like to use that takes as an
argument a non-const reference to an object. Unfortunately, all you have
is a const object and you'd rather not go through the trouble of creating
a non-const copy of it to pass as an argument. You look at the code of
this function and you see that the reference is never modified or passed
anywhere else! The original author of that function either neglected to
declare the reference parameter as const or was a beginning programmer
who did not understand the benefits of declaring parameters const
whenever possible.

It is a function you know will not change what's passed to it. Yet, you
have that constant object. In this case, using const_cast is appropriate
to have your new code work with the old.

There are plenty of functions that take non-const references or pointers
but which never change those parameters. const_cast is very useful in
these cases because it promotes const correctness but allows flexibility
when interacting with the real-world code that ignores it.

Ron Natalie 10-13-2004 01:45 PM

Re: const_cast undefined results
 
rookkey wrote:

> Think of badly written API's.
>


Usually the problem. Either:

1. Something needs a non-const value and you KNOW it won't be modified.
2. You have a const value, but you know the object wasn't const to
begin with (more difficult, but not impossible).


All times are GMT. The time now is 12:00 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.