const_cast versus compiler optimization

[Alexander Stippler]

Hello,

I wonder if and in what cases casting const away by a const_cast can be
dangerous. In one place the only way I can imagine to realize a pretty
nice feature is casting away const. Now I wonder if this is dangerous. I
have something like that:

const Object &
Object::dummy(const AType &a) const
{
Object &refThis = const_cast<Object &>(*this);
AType &refA = const_cast<AType &>(rhs);
refThis.member = a.member();
...
}

Are there situations, where these constructs are dangerous?
I know, this code is ugly. But the realized feature is worth it.

regards,
Alex

 

[Victor Bazarov]

I wonder if and in what cases casting const away by a const_cast can be
dangerous. In one place the only way I can imagine to realize a pretty
nice feature is casting away const. Now I wonder if this is dangerous.

It is no more (and no less) dangerous than any other undefined behaviour.

> I
have something like that:

const Object &
Object::dummy(const AType &a) const
{
Object &refThis = const_cast<Object &>(*this);
AType &refA = const_cast<AType &>(rhs);
refThis.member = a.member();
...
}

Are there situations, where these constructs are dangerous?
I know, this code is ugly. But the realized feature is worth it.

It's not just ugly. It's simply wrong. You should at least be consistent
with your names. Did you mean

const Object &
Object::dummy(const AType &a) const
{
Object &refThis = const_cast<Object &>(*this);
AType &refA = const_cast<AType &>(a);
refThis.member = refA.member();
...
}

?

To answer your question, it's dangerous where 'a' or 'this' were _created_
as 'const'. The compiler is allowed to place any parts of the object in
read-only part of program memory when the object is declared 'const'.
Assigning to 'refThis.member' causes undefined behaviour.

V

 

[Howard]

Hello,

I wonder if and in what cases casting const away by a const_cast can be
dangerous. In one place the only way I can imagine to realize a pretty
nice feature is casting away const. Now I wonder if this is dangerous. I
have something like that:

const Object &
Object::dummy(const AType &a) const
{
Object &refThis = const_cast<Object &>(*this);
AType &refA = const_cast<AType &>(rhs);
refThis.member = a.member();
...
}

Are there situations, where these constructs are dangerous?
I know, this code is ugly. But the realized feature is worth it.

Why would you make the function const if it's going to modify the object
it's called on? And why use the local references at all? It looks like all
you're doing is this:

const Object & Object::dummy(const AType &a)
{
member = a.member();
...
}

-Howard

 

[Howard]

Why would you make the function const if it's going to modify the object
it's called on? And why use the local references at all? It looks like
all you're doing is this:

const Object & Object::dummy(const AType &a)
{
member = a.member();
...
}

I should have said, "it looks like all you're TRYING to do is this:"

-Howard

 

[red floyd]

Why would you make the function const if it's going to modify the object
it's called on? And why use the local references at all? It looks like all
you're doing is this:

const Object & Object::dummy(const AType &a)
{
member = a.member();
...
}

Possibly he's creating a functor. Of course, the correct way to do that
is to make the particular item to be updated mutable.

 

[Alexander Stippler]

I should have said, "it looks like all you're TRYING to do is this:"

-Howard

Not really. It's hard to desribe in a few lines. So I use an example:
I want objects, which refer to other objects of the same type, like the
following by a member function:

Object &
referTo(Object &rhs);

Object oneO, otherO;
oneO.referTo(otherO);

At that point, oneO is a "pointer into" otherO. No problem, as long as
otherO is not const. But if otherO were const, I would like to have oneO
refer to otherO, but oneO should not be able to change otherO. So I make
oneO const, but then I need the const_cast ...
An abuse of const, one might say and he would probably be right. What I
want to implement is a reference, where the referenced object is const (
not modifiable through the reference), not the reference object. Why not
a type of its own for the references? Because all classes are template
classes and there would be plenty of complications, because the
reference shall be used just like the original object and type
conversions for templates together with instantiation ...
Tried to explain my motivation, but must sounds strange and like bad
design, or?
But I have now found a standard conform solution .

regards,
Alex

 

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

Are there situations, where these constructs are dangerous?

Yes: if you have any doubt, is dangerous. You must use a cast only when you
are sure that is safe. The casts tell the compiler: "I really know what I'm
doing".

The key is: don't cast away constness to modify an object that is const.