modifying a const object

[Eric]

I have read that using const_cast to modify an object that was originally
declared const can lead to undefined behavior.
Would this be true in the case of a user defined object containing a const
data member as in the example below, and if so, why?
In what cases can modification of an originally declared const object be
problematic?

I would appreciate any comments.

struct TestClass
{
TestClass() : m_s("123") {}
const string m_s;
};

TestClass b;
const_cast<string&>(b.m_s) = "456"; // works fine but is this acceptable ?



[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 

[Rob]

I have read that using const_cast to modify an object that was
originally declared const can lead to undefined behavior.

Not precisely. Using const_cast does not, in itself, lead to
undefined behaviour. However, any process that involves (directly or
not) modifying something that is constant yields undefined behaviour.

Would this be true in the case of a user defined object containing a
const data member as in the example below, and if so, why?

Yes. The short answer is "because the standard says so".

In practice, the reason is that something which is const (whether a
class member or not) might receive special treatment from the compiler
or even from the linker. For example, the object might be physically
located in read-only memory, which makes any attempt to modify it
rather problematical.

In what cases can modification of an originally declared const object
be problematic?

As I said above, it will be problematical if the const attribute is
somehow enforced. In my example above, with a const object placed into
read-only memory, the system might elect to terminate the program if an
attempt is made to modify a const object. Or an attempt to change the
object may have no effect. Or .... the list goes on.


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 

[Karl Heinz Buchegger]

I have read that using const_cast to modify an object that was originally
declared const can lead to undefined behavior.

Not only 'can'. It has undefined behaviour.

Would this be true in the case of a user defined object containing a const
data member as in the example below, and if so, why?

Sure it would.

Imagine the situation:
You: This wall outlet emits 110 Volts. This voltage will never change, you can count
on it.
I: Ok. Then I will design my electrical engine for 110 volts.
You: He, he. I am going to change the 110 volts to 230 volts.
My engine: smokes

(Actually, somthing similar happend to Apollo 13)

In what cases can modification of an originally declared const object be
problematic?

Because the compiler trusts you. With const you tell the compiler:
This is the value and it is never going to change.
Thus the compiler can use the value directly instead of fetching
it from the variable in certain situations.

I would appreciate any comments.

Don't lie to your compiler.


The main usage of const_cast is when you have to interface to an external
(older) library. There might be functions, from which you know that they
want change arguments you pass to them but for some reasons those parameters
are not declared const. You have a const and with the knowledge that the
function will not attempt to change what you pass to it, you can cast the
const away in order to be able to call that function.

--
Karl Heinz Buchegger
(e-mail address removed)

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 

[Torsten Mueller]

I have read that using const_cast to modify an object that was
originally declared const can lead to undefined behavior. Would this
be true in the case of a user defined object containing a const data
member as in the example below, and if so, why? In what cases can
modification of an originally declared const object be problematic?

Rob and Karl Heinz said it right.

const_cast<> is thought to be used in the following situation: you
want to call a non-const method on a const object and you know that
the method does not modify the object. Many people forget to declare
such methods as const and so they get even into large frameworks.
Look at this:

class MyClass {
int m_i;
public:
MyClass (int i) : m_i(i) {}
int get () {return m_i;}
};

The get-method does nothing with m_i. However, it is not const. That's
why the following code will fail to compile:

int func (const MyClass& c)
{
return c.get();
}

Here you can use const_cast<>:

int func (const MyClass& c)
{
return const_cast<MyClass>(c).get();
}

You should never modify an object using const_cast<> - this will
result in dependencies on compilers and their options.

T.M.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 

[Dave Harris]

I have read that using const_cast to modify an object that was
originally declared const can lead to undefined behavior.
Would this be true in the case of a user defined object containing a
const data member as in the example below, and if so, why?

Yes. Because the standard says so. The main reason is consistency. Some
const objects can be placed in read-only memory. That is unlikely for
member variables but the language is simpler if the same rules apply to
all, and we don't limit how clever the compiler can be.

One practical consequence is that the compiler is allowed to assume the
const object won't change after it has been constructed. In your string
example, the compiler could turn an expression like b.m_s[0] into the
constant '1', even after the assignment.

struct TestClass {
TestClass() : m_s("123") {}
const string m_s;
};

TestClass b;
if (true)
const_cast<string&>(b.m_s) = "456"; // Undefined behaviour.
assert( b.m_s[0] == '1' ); // May pass.


-- Dave Harris, Nottingham, UK.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]