Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #13105 > unrolled thread

plz xplain behavior of const_cast

Back to article view | Back to comp.lang.c++

Contents

  plz xplain behavior of const_cast Heck <heckja_in@ordertostymieharvestersverizon.net> - 2012-01-05 02:01 -0500
    Re: plz xplain behavior of const_cast Christian Gollwitzer <auriocus@gmx.de> - 2012-01-05 08:53 +0100
    Re: plz xplain behavior of const_cast "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2012-01-05 08:57 +0100
      Re: plz xplain behavior of const_cast gwowen <gwowen@gmail.com> - 2012-01-05 04:00 -0800
        Re: plz xplain behavior of const_cast "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2012-01-05 23:17 +0100
          Re: plz xplain behavior of const_cast Ian Collins <ian-news@hotmail.com> - 2012-01-06 11:38 +1300
          Re: plz xplain behavior of const_cast Gareth Owen <gwowen@gmail.com> - 2012-01-06 06:33 +0000
          Re: plz xplain behavior of const_cast Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-06 00:46 -0800
            Re: plz xplain behavior of const_cast gwowen <gwowen@gmail.com> - 2012-01-06 03:19 -0800
          Re: plz xplain behavior of const_cast Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-07 06:38 +0000
            Re: plz xplain behavior of const_cast 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-07 03:53 -0800
        Re: plz xplain behavior of const_cast Juha Nieminen <nospam@thanks.invalid> - 2012-01-06 09:14 +0000
    Re: plz xplain behavior of const_cast Goran <goran.pusic@gmail.com> - 2012-01-04 23:55 -0800
    Re: plz xplain behavior of const_cast jt@toerring.de (Jens Thoms Toerring) - 2012-01-05 09:04 +0000
    Re: plz xplain behavior of const_cast Heck <heckja_in@ordertostymieharvestersverizon.net> - 2012-01-05 09:36 -0500

#13105 — plz xplain behavior of const_cast

 const int    NUM_UNIVS =  -1;

{
   // some block of code, and at the end of the block, 
   // I now have the value I need for NUM_UNIVS,
   // so I do the following to assign it the new value

   int * tmp;
   *(tmp = const_cast <int*> (& NUM_UNIVS)) = new_value;
}

Then, I begin the operations that require NUM_UNIVS, but, this first 
condition was failing upon its very first test and the loop was of
course being skipped:

for( univ_num = 0; univ_num <= NUM_UNIVS; ++univ_num)
{
  ...

The assembly language showed that, indeed, where I expected there to
be a reference to the new value of NUM_UNIVS from the stack, there was
no such.  Instead the cmp was made with a -1 literal.

01151906  mov        dword ptr [ebp-0B74h],0  ; num_univ = 0  
01151910  jmp         main+3D1h (1151921h)  
01151912  mov        eax,dword ptr [ebp-0B74h] 
01151918  add         eax,1                            ; ++num_univ
0115191B  mov       dword ptr [ebp-0B74h],eax  
01151921  cmp        dword ptr [ebp-0B74h],0FFFFFFFFh  
01151928  jg            01151AD6 
 
The debugger (VS 2010) showed the value of NUM_UNIVS to have been
changed, but the code generator, written by people who consider
themselves far more serious than mere writers of debuggers, saw that
initialization of the const int to -1 and wrote that value in
everywhere NUM_UNIVS appears, many other locations.  Isn't this the
way to change the value of a const?  If it can't be changed like this,
why did the compiler allow it and why  does the debugger respect it?

(I have the variable defined prior to the block which calculates its
proper value for neatness' and readability's sake.  I can simply move
the definition of NUM_UNIVS to where it works, but, when I saw this
after fretting over what had wrecked my already-debugged code, I
wanted to find out what I was thinking or doing wrong.)  TIA

[toc] | [next] | [standalone]

#13107

Am 05.01.12 08:01, schrieb Heck:
>   const int    NUM_UNIVS =  -1;
>
> {
>     // some block of code, and at the end of the block,
>     // I now have the value I need for NUM_UNIVS,
>     // so I do the following to assign it the new value
>
>     int * tmp;
>     *(tmp = const_cast<int*>  (&  NUM_UNIVS)) = new_value;
> }
>

This is undefined behaviour. You cannot assign to a real const, 
const_cast's purpose is to help in situations where you need to join 
const-correct and const-incorrect code. The compiler assumes that a 
const is const and optimizes the code in tht way.

	Christian

[toc] | [prev] | [next] | [standalone]

#13108

On 05.01.2012 08:01, Heck wrote:
>   const int    NUM_UNIVS =  -1;

Don't use all uppercase for constants. That's a Java convention. Java 
does not have a preprocessor. C++ does have a preprocessor. In C++, all 
uppercase is conventionally used for and reserved for macros names, 
primarily to reduce the probability of name collisions.

>
> {
>     // some block of code, and at the end of the block,
>     // I now have the value I need for NUM_UNIVS,
>     // so I do the following to assign it the new value
>
>     int * tmp;
>     *(tmp = const_cast<int*>  (&  NUM_UNIVS)) = new_value;

To cast away constness of an object, just cast to a non-const reference; 
there's no need for the pointer stuff.

However, if you cast away constness of and then attempt to modify an 
/originally const/ object, then you have Undefined Behavior.

That's because you have told the compiler that it's originally const and 
will never be changed, so the compiler is free to substitute the 
(presumed) known value anywhere the object is used.

Short advice: don't cast.


Cheers & hth.,

- Alf

[toc] | [prev] | [next] | [standalone]

#13119

On Jan 5, 7:57 am, "Alf P. Steinbach" <alf.p.steinbach
+use...@gmail.com> wrote:
> On 05.01.2012 08:01, Heck wrote:
>
> >   const int    NUM_UNIVS =  -1;
>
> Don't use all uppercase for constants. That's a Java convention.

Not really. It's a logical extension of the C rules/conventions that
say:
(i) Macros are conventially capitals.
(ii) In C, const variables of integer type cannot be used as compile
time constants, and, prior to C99's VLAs, if you want non-dynamic
array, you need a compile time constants.

So integer constants tend to #define'd, instead of just defined.

So compile-time constants tend to be capitals. Then that convention
tends to leak across to C++ due to the similarity of the languages and
the identical use cases.

[toc] | [prev] | [next] | [standalone]

#13140

On 05.01.2012 13:00, gwowen wrote:
> On Jan 5, 7:57 am, "Alf P. Steinbach"<alf.p.steinbach
> +use...@gmail.com>  wrote:
>> On 05.01.2012 08:01, Heck wrote:
>>
>>>    const int    NUM_UNIVS =  -1;
>>
>> Don't use all uppercase for constants. That's a Java convention.
>
> Not really. It's a logical extension of the C rules/conventions that
> say:
> (i) Macros are conventially capitals.
> (ii) In C, const variables of integer type cannot be used as compile
> time constants, and, prior to C99's VLAs, if you want non-dynamic
> array, you need a compile time constants.

That's just bad programmers.

C has had 'enum' since C89.

'enum' works nicely for expressing whatever integer real constants.


> So integer constants tend to #define'd, instead of just defined.

It's true that the convention probably originated with C, although the 
early C practitioners used all kinds of weird conventions, including 
none. They were programming in-the-small. So it didn't matter so much.

However, as you write, in C and C++ all uppercase is a convention for 
macros.

Arguing that it is a convention for constants just because constants are 
sometimes expressed as macros, is just like arguing that it is for 
functions, or whatever that can be expressed as a macro.

The convention does IMO not serve a useful purpose for constants, in 
particular in light of "one man's constant is another man's variable".

The convention does serve a useful purpose for macros.


> So compile-time constants tend to be capitals. Then that convention
> tends to leak across to C++ due to the similarity of the languages and
> the identical use cases.

Hm, I don't think there are really many who start out with C and migrate 
up. Rather they migrate sideways/down from Java and C#. They don't pick 
up all these weird inheritance patterns and singletons and abstract 
factories and managers and whatnot in C, I think.

Cheers,

- Alf

[toc] | [prev] | [next] | [standalone]

#13141

On 01/ 6/12 11:17 AM, Alf P. Steinbach wrote:
> On 05.01.2012 13:00, gwowen wrote:
>
>> So compile-time constants tend to be capitals. Then that convention
>> tends to leak across to C++ due to the similarity of the languages and
>> the identical use cases.
>
> Hm, I don't think there are really many who start out with C and migrate
> up. Rather they migrate sideways/down from Java and C#. They don't pick
> up all these weird inheritance patterns and singletons and abstract
> factories and managers and whatnot in C, I think.

I think you would be surprised Alf.  Most of the aspirational C++ 
programmers I work with or coach are embedded C programmers looking to 
make the next step.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#13145

"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:

> That's just bad programmers.
>
> C has had 'enum' since C89.
>
> 'enum' works nicely for expressing whatever integer real constants.

I didn't say it was right, I said that where it came from.  In any case
I'd be willing bet

#define NUM_OBJ 100 

is much more prevalent than

enum {
 num_obj = 100
};

even in C code written in the last five years.  Idioms are hard to
kill. (I'll admit that I'm among them - type safety concerns means I
tend to set compiler switches so that I get warned about int-to-enum
comparisons and enum-to-other-enum comparisons, so this technique
doesn't even *work* for me)

Either way, the convention did not cross from Java to C++, it went
entered C++ and Java from the common ancestor, C.

[toc] | [prev] | [next] | [standalone]

#13149

On Jan 5, 10:17 pm, "Alf P. Steinbach" <alf.p.steinbach
+use...@gmail.com> wrote:
> On 05.01.2012 13:00, gwowen wrote:
> > On Jan 5, 7:57 am, "Alf P. Steinbach"<alf.p.steinbach
> > +use...@gmail.com>  wrote:
> >> On 05.01.2012 08:01, Heck wrote:
>
> >>>    const int    NUM_UNIVS =  -1;
>
> >> Don't use all uppercase for constants. That's a Java convention.
>
> > Not really. It's a logical extension of the C rules/conventions that
> > say:
> > (i) Macros are conventially capitals.
> > (ii) In C, const variables of integer type cannot be used as compile
> > time constants, and, prior to C99's VLAs, if you want non-dynamic
> > array, you need a compile time constants.
>
> That's just bad programmers.
>
> C has had 'enum' since C89.
>
> 'enum' works nicely for expressing whatever integer real constants.
>
> > So integer constants tend to #define'd, instead of just defined.
>
> It's true that the convention probably originated with C, although the
> early C practitioners used all kinds of weird conventions, including
> none. They were programming in-the-small. So it didn't matter so much.

small. Like Unix...

> However, as you write, in C and C++ all uppercase is a convention for
> macros.
>
> Arguing that it is a convention for constants just because constants are
> sometimes expressed as macros, is just like arguing that it is for
> functions, or whatever that can be expressed as a macro.
>
> The convention does IMO not serve a useful purpose for constants, in
> particular in light of "one man's constant is another man's variable".
>
> The convention does serve a useful purpose for macros.
>
> > So compile-time constants tend to be capitals. Then that convention
> > tends to leak across to C++ due to the similarity of the languages and
> > the identical use cases.
>
> Hm, I don't think there are really many who start out with C and migrate
> up.

seriously? I'd have thought there were loads. I'm one. Weren't all the
initial C++ programmers originally C programmers?

> Rather they migrate sideways/down from Java and C#. They don't pick
> up all these weird inheritance patterns and singletons and abstract
> factories and managers and whatnot in C, I think.

don't singletons and abstract factory come from GoF?

[toc] | [prev] | [next] | [standalone]

#13153

On Jan 6, 8:46 am, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:

> > Hm, I don't think there are really many who start out with C and migrate
> > up.
>
> seriously? I'd have thought there were loads. I'm one.

Me too

> Weren't all the initial C++ programmers originally C programmers?

Even if its true of the latest crop of programmers, its probably not
true of their teachers, or their teachers's teachers, and the people
who wrote their textbooks.  Its easy to pick habits up from that.
Besides, K&R2 uses #define where Alf says "only bad programmers" do
that.

[toc] | [prev] | [next] | [standalone]

#13161

On Thu, 2012-01-05, Alf P. Steinbach wrote:
...
> Hm, I don't think there are really many who start out with C and migrate 
> up. Rather they migrate sideways/down from Java and C#. They don't pick 
> up all these weird inheritance patterns and singletons and abstract 
> factories and managers and whatnot in C, I think.

I happen to dislike much of that stuff too, but I think it's unfair to
describe it as a virus from the Java world. When people come to their
first language which supports object-oriented programming, they will
want to learn about that OOP stuff, and they will find those things
there.

/Jorgen

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

[toc] | [prev] | [next] | [standalone]

#13162

Jorgen Grahn於 2012年1月7日星期六UTC+8下午2時38分32秒寫道：
> On Thu, 2012-01-05, Alf P. Steinbach wrote:
> ...
> > Hm, I don't think there are really many who start out with C and migrate 
> > up. Rather they migrate sideways/down from Java and C#. They don't pick 
> > up all these weird inheritance patterns and singletons and abstract 
> > factories and managers and whatnot in C, I think.
> 
> I happen to dislike much of that stuff too, but I think it's unfair to
> describe it as a virus from the Java world. When people come to their
> first language which supports object-oriented programming, they will
> want to learn about that OOP stuff, and they will find those things
> there.
> 
> /Jorgen

The object programming in C++ can be summarized as follows:

1. class inheritance and object properties set up 
  by the compiler for all static parts and a bunch of static functors with 
  *this as the hidden parameter

2. one vtable in a class and  one vpointer in an object to be used to  
invoke the right function pointer as a virtual function  at the run-time

3. the operator reloading part similar to   smalltalk only in syntax but not very helpful  in developing cad tools or code generators
  

 


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

[toc] | [prev] | [next] | [standalone]

#13150

gwowen <gwowen@gmail.com> wrote:
> Not really. It's a logical extension of the C rules/conventions that
> say:
> (i) Macros are conventially capitals.
> (ii) In C, const variables of integer type cannot be used as compile
> time constants, and, prior to C99's VLAs, if you want non-dynamic
> array, you need a compile time constants.
> 
> So integer constants tend to #define'd, instead of just defined.
> 
> So compile-time constants tend to be capitals. Then that convention
> tends to leak across to C++ due to the similarity of the languages and
> the identical use cases.

  There's a difference between a compile-time constant in C++ and a
#define macro. For one, you can take the address of the former (ie.
create a pointer that points to the const) but not the latter.

[toc] | [prev] | [next] | [standalone]

#13109

On Jan 5, 8:01 am, Heck <heckja...@ordertostymieharvestersverizon.net>
wrote:
>  const int    NUM_UNIVS =  -1;
>
> {
>    // some block of code, and at the end of the block,
>    // I now have the value I need for NUM_UNIVS,
>    // so I do the following to assign it the new value
>
>    int * tmp;
>    *(tmp = const_cast <int*> (& NUM_UNIVS)) = new_value;

This is where your code is broken. It is undefined behavior to use
const_cast to cast the const away from a const object, and &NUM_UNIVS
is const int*. Everything else stems from there, see below.

You can only use const_cast on variables that were __initially__
defined as non const. So for example, this is OK:

int i=1;
const int& r = i;
const_cast<int&>(r) = 2;

(Note the use of int&, not int*, to lower syntactical gibberish.)

> }
>
> Then, I begin the operations that require NUM_UNIVS, but, this first
> condition was failing upon its very first test and the loop was of
> course being skipped:
>
> for( univ_num = 0; univ_num <= NUM_UNIVS; ++univ_num)
> {
>   ...
>
> The assembly language showed that, indeed, where I expected there to
> be a reference to the new value of NUM_UNIVS from the stack, there was
> no such.  Instead the cmp was made with a -1 literal.

Yes. You said that NUM_UNIVS is const, and equals -1. So compiler took
the freedom to replace it with -1, which is a common optimization.
This, again, is a consequence of language rule that const_cast is
legal only if done on an object (or a reference to it) that was
defined as non-const.

The rule is good, and you broke it ;-). Further, in C++, there's no
reason for the contortion you tried. I am guessing that you want
NUM_UNIVS to be seen as const to a (significant) part of your code,
but you want to change it in some other parts. You can solve that
problem in a different way. For example:

file1.cpp

namespace { int NUM_UNIVS=-1; }
const int& NumUnivs = NUM_UNIVS;
int NumUnivs() { return NUM_UNIVS; }

void ChangesNumUnivs()
{
 workworkwork;
 NUM_UNIVS=9;
}

file1.h
extern const int& NumUnivs; // Use this to access a read-only variant
of NUM_UNIVS.

file2.cpp
#include file1.h
void f()
{
 for (int i=0; i<NumUnivs; i++)
  workworkwork;
}

Goran.

[toc] | [prev] | [next] | [standalone]

#13113

Heck <heckja_in@ordertostymieharvestersverizon.net> wrote:
>  const int    NUM_UNIVS =  -1;

> {
>    // some block of code, and at the end of the block, 
>    // I now have the value I need for NUM_UNIVS,
>    // so I do the following to assign it the new value

>    int * tmp;
>    *(tmp = const_cast <int*> (& NUM_UNIVS)) = new_value;
> }

> Then, I begin the operations that require NUM_UNIVS, but, this first 
> condition was failing upon its very first test and the loop was of
> course being skipped:

> for( univ_num = 0; univ_num <= NUM_UNIVS; ++univ_num)
> {
>   ...

> The assembly language showed that, indeed, where I expected there to
> be a reference to the new value of NUM_UNIVS from the stack, there was
> no such.  Instead the cmp was made with a -1 literal.

> 01151906  mov        dword ptr [ebp-0B74h],0  ; num_univ = 0  
> 01151910  jmp         main+3D1h (1151921h)  
> 01151912  mov        eax,dword ptr [ebp-0B74h] 
> 01151918  add         eax,1                            ; ++num_univ
> 0115191B  mov       dword ptr [ebp-0B74h],eax  
> 01151921  cmp        dword ptr [ebp-0B74h],0FFFFFFFFh  
> 01151928  jg            01151AD6 
>  
> The debugger (VS 2010) showed the value of NUM_UNIVS to have been
> changed, but the code generator, written by people who consider
> themselves far more serious than mere writers of debuggers, saw that
> initialization of the const int to -1 and wrote that value in
> everywhere NUM_UNIVS appears, many other locations.  Isn't this the
> way to change the value of a const?  If it can't be changed like this,
> why did the compiler allow it and why  does the debugger respect it?

You can't change a const variable, trying to do so results
in undefined behaviour. And you did your very best to con-
fuse the compiler and you now suffer the consequences;-)

A const cast can be only used reasonably on pointers (or
references) to variables that actually aren't const. An
example would be a function that receives a const pointer
to something that isn't a constant in the caller. Then you
may use the const cast to change the value of what's poin-
ted to anyway (admittedly that's ugly but there can be
circumstances were this can't be avoided). But when what
is pointed to is constant then this won't work. So a const
cast is not for circumventing a variable being constant -
and that seems to be your main misunderstanding. When its
constant it stays constant and nothing can be done about
that afterwards. All you can do is assign the value to a
non-constant variable and then change that.

By qualifying 'NUM_UNIVS' as constant you thus allow the
compiler to reasonably assume that the value of this va-
riable will never change - and it does use this bit of
information to optimize your program. That's completely
legal for the compiler since you're not allowed to change
its value and attempting to do it anyway results in unde-
fined behaviour, i.e. everything can happen and you can't
know what that will be (unless, may be, if you know exact-
ly how the compiler does its job and don't care if this
program will still work when compiled with a different
compiler). The optimization in this case consists of re-
placing 'NUM_UNIVS' in the loop condition by the constant
value of that variable, -1.

To avoid the compiler noticing you don't try to change
'NUM_UNIVS' directly - in that case the compiler would
have told you that you're doing something illegal. You
had to resort to using a pointer and, by using the const
cast, you also basically told the compiler "I know better
than you, don't complain if this looks wrong". So the
compiler really isn't to blame here. You entered a
marked minefield, i.e. attempt to do something for which
the language doesn't define what will be the results (and
thus the compiler may create whatever code it likes),
and got blown up.

Rather likely 'NUM_UNIVS' here is a variable with block
scope and not a global. Otherwise the compiler may have
put it into memory flagged as read-only. And in that case
already the attempt to alter its value via a const cast
pointer might have resulted in a different outcome, a
segmentation fault due to a write access to memory you
are not allowed to modify. That would have been a dif-
ferent symptom of invoking undefined behaviour.

                          Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#13121

Thanks to you all for your explanations and alternatives and advice.

Thank you, gwowen, for defending or at least, explaining, the all-caps
to alf.p.steinbach.  I was programming in C probably before Alf was
born, and gwowen accurately recounts the bit of history.

My history of habits in C also sheds light on why I readily use the
pointer, rather than the reference form.  I didn't consider <int &>,
it didn't even cross my mind, but I'll change it in my code, to
develop new approaches and alternatives.

Thanks, Jens, for describing another symptom my code could possibly
trigger, a write exception.  As long as I remained ignorant of doing
something that resulted in undefined behavior, I would have been
stumped and it would have caused me great frustration.  It's hard
feeling less competent than I used to feel, whether or not it's the
case.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web