Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Confused by C++ Primer's discusion of const_cast

50 views
Skip to first unread message

Paul

unread,
Apr 25, 2015, 2:29:02 PM4/25/15
to
Code from C++ Primer is:

const char* pc;
char * p = const_cast<char*>(pc); // Ok but writing through p is undefined.

Why is writing through p undefined? I thought this was an archetypal use of const_cast -- create a non-const object from a low-level const object.

Why is this use of const_cast wrong?

Paul

Victor Bazarov

unread,
Apr 25, 2015, 2:44:15 PM4/25/15
to
The "Code from C++ Primer" is incomplete to be right or wrong. The
pointer named 'pc' is uninitialized. Writing through 'p' or even
reading through 'pc' yields undefined behavior.

V
--
I do not respond to top-posted replies, please don't ask

Jorgen Grahn

unread,
Apr 25, 2015, 2:56:51 PM4/25/15
to
On Sat, 2015-04-25, Victor Bazarov wrote:
> On 4/25/2015 2:28 PM, Paul wrote:
>> Code from C++ Primer is:
>>
>> const char* pc;
>> char * p = const_cast<char*>(pc); // Ok but writing through p is undefined.
>>
>> Why is writing through p undefined? I thought this was an archetypal
>> use of const_cast -- create a non-const object from a low-level const
>> object.
>>
>> Why is this use of const_cast wrong?
>
> The "Code from C++ Primer" is incomplete to be right or wrong. The
> pointer named 'pc' is uninitialized. Writing through 'p' or even
> reading through 'pc' yields undefined behavior.

Yes. Such an example needs to have an actual object to be useful:

char foo = 'a';
const char* pc = &foo;
char* p = const_cast<char*>(pc); // Ok

const char foo = 'a';
const char* pc = &foo;
char* p = const_cast<char*>(pc); // "Ok but" according to the book

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

Dombo

unread,
Apr 25, 2015, 4:03:16 PM4/25/15
to
Op 25-Apr-15 20:28, Paul schreef:
> Code from C++ Primer is:
>
> const char* pc;
> char * p = const_cast<char*>(pc); // Ok but writing through p is undefined.
>
> Why is writing through p undefined? I thought this was an archetypal
> use of const_cast -- create a non-const object from a low-level const
> object.

Nope, const_cast does not create a new non-const object, it only tells
the compiler: "you may think this is a pointer to a const object, but
take my word for it: it really points to a non-const object". You'd
better be right, or the compiler will have its revenge.

> Why is this use of const_cast wrong?

pc is not initialized in the example; the effects of reading or writing
through an uninitialized pointer is undefined.

But even if it were initialized writing to it is still undefined if pc
is pointing to a const object (this is probably the point C++ Primer is
trying to make). const objects may have been been placed in read-only
memory, making it impossible to modify them.

const_cast<> should only be used to cast away constness if you are
absolutely sure that the object being referred to really is non-const.
For example:

int main()
{
char[1] data; // non-const object
foo(data);
return 0;
}

void foo(const char* pc)
{
bar(pc);
}

void bar(const char* pc)
{
char* p= const_cast<char*>(pc);

p[0] = '!'; // Ok, because pc is really pointing to a non-const object
}

Normally you should never have to use const_cast unless there is some
code you cannot change that passes pointers it got from your code back
to your code. If you need to cast it often indicates there a design issue.

peter koch

unread,
Apr 26, 2015, 7:34:54 PM4/26/15
to
You can not modify a const object. So if you are to modify p you need to be sure that pc - despite the declaration - points to non-constant data.
One use of const_cast is to implement non-const member functions via the const function. Another use is to cast to const, and finally you may use const_cast - carefully - when interfacing to legacy code that is not const aware.

Juha Nieminen

unread,
Apr 27, 2015, 3:38:41 AM4/27/15
to
Because 'pc' may be pointing to something that literally can't be modified
or, if it's modified, might break something. (String literals are a typical
example: They might be unmodifiable depending on the compiler/architecture,
or they might be modifiable but if you do, you'll break something, eg. if
the compiler merges identical string literals, or if the literal resides
in a segment of memory that can't be written to, in which case bad things
usually happen.)

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
0 new messages