Const Problem

[venkatarao0]

Hi Friends,
I got problem hear,

C++ File:

const int val=0;
int *ptr = (int *)&val;
*ptr = 55;
cout<<val<<endl; // out put 0
cout<<*ptr<<endl; // out put 55

in debugging val & *ptr are showing 55 only,
but while printing val it is showing '0' as out put
while printing *ptr it is showing '55' as out put

what is the problem, i am unable to get could u pls help me out.

 

[Alf P. Steinbach]

* (e-mail address removed):

Hi Friends,
I got problem hear,

C++ File:

const int val=0;
int *ptr = (int *)&val;
*ptr = 55;
cout<<val<<endl; // out put 0
cout<<*ptr<<endl; // out put 55

in debugging val & *ptr are showing 55 only,
but while printing val it is showing '0' as out put
while printing *ptr it is showing '55' as out put

what is the problem, i am unable to get could u pls help me out.

It's undefined behavior to cast away original const (and use it).

Anyway, as a beginner just say No to raw pointers, and don't use C style casts.

That way you avoid such "problems".


Cheers & hth.,

- Alf

 

[Vaclav Haisman]

Hi Friends,
I got problem hear,

C++ File:

const int val=0;
int *ptr = (int *)&val;
*ptr = 55;

You are trying to assign to a constant object through a non-const pointer.
That is not allowed, it is undefined behaviour.

cout<<val<<endl; // out put 0
cout<<*ptr<<endl; // out put 55

in debugging val & *ptr are showing 55 only,
but while printing val it is showing '0' as out put
while printing *ptr it is showing '55' as out put

what is the problem, i am unable to get could u pls help me out.

Those are all manifestation of the undefined behaviour. Once your code has
undefined behaviour, it can do pretty much anything, including what you see.
Try reading <http://en.wikipedia.org/wiki/Undefined_behaviour>.

 

[Michael Tsang]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anyway, as a beginner just say No to raw pointers, and don't use C style
casts.

How can you write a useful program without using raw pointers? Even as
simple as a link list needs raw pointers. If i is an object., &i is already
a raw pointer which can be used in the way you want
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAktLOsgACgkQm4klUUKw07AqtQCfQGEL9smSyqY5ZLhT1GzSq9mv
1LAAnA41AEUOtXoyJZiMTVhu+VrKR8Tl
=hlnM
-----END PGP SIGNATURE-----

 

[Paul N]

To more or less repeat a post I made back in June...

Hi Friends,
               I got problem hear,

As someone used to put it, "If you lie to the compiler, it will get
its revenge".

C++ File:

        const int val=0;

Here you are promising that val is const. It has the value 0. This
will not change. No siree!

         int *ptr = (int *)&val;
        *ptr = 55;

And here you change it. Have you considered a career as a politician?

        cout<<val<<endl;                   // out put 0
        cout<<*ptr<<endl;                   // out put 55

in debugging val & *ptr are showing 55 only,

ptr is pointing to val, which you changed, via ptr, to 55. What did
you expect?

but while printing val it is showing '0' as out put

You said val was 0, and that you weren't going to change it. val had
the value of 0, and is not (you said) going to change, so it must (the
compiler may presume) still be 0. There's no need to look it up, so
the computer doesn't spot that it has, in fact, changed. What did you
expect?

while printing *ptr it is showing '55' as out put

You changed the thing ptr points to to 55. What did you expect?

what is the problem, i am unable to get could u pls help me out.

As others have said, it is undefined behaviour, which means anything
could happen. But the results you have got are both perfectly sensible
results considering what you asked for. Ask for something more
sensible next time.

Hope that helps.
Paul.

 

[Alf P. Steinbach]

* Michael Tsang:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

How can you write a useful program without using raw pointers? Even as
simple as a link list needs raw pointers.

Only internally.

The standard library offers 'std::list'.

So in short, use containers and you can write a great many useful programs with
no pointers in sight anywhere.

If i is an object., &i is already
a raw pointer which can be used in the way you want

As a beginner, avoid also the address operator.

E.g.

#include <iostream>
int main()
{
std::cout << "uh" << std::endl;
}

involves some pointers, but there's no need to deal with them explicitly.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAktLOsgACgkQm4klUUKw07AqtQCfQGEL9smSyqY5ZLhT1GzSq9mv
1LAAnA41AEUOtXoyJZiMTVhu+VrKR8Tl
=hlnM
-----END PGP SIGNATURE-----

This means that people using Microsoft newsreaders will not be able to easily
read your message, plus that it annoys many other people; AFAIK there's no
positive effect...


Cheers & hth.,

- Alf

 

[Brian Wood]

You can't, really.  But you generally need a lot less pointers
in C++ than in some other languages I could name.
OK.

Favor local
variables (with deep copy) whenever possible.

What about in a marshalling/sending context? Say it is
possible to make a deep copy of at least some of the
values being sent. I don't think its a good idea to make
a deep copy just because you could do it. It seems
advantageous to use references in situations where you
have potentially a lot of data involved.


Brian Wood
http://webEbenezer.net
(651) 251-93854

 

[James Kanze]

* Michael Tsang:

Only internally.

That's true. Pointers are only good within the C++ program
itself. You can't expect them to work outside of the program.

The standard library offers 'std::list'.

So in short, use containers and you can write a great many
useful programs with no pointers in sight anywhere.

Certainly. That's more or less what I said, in the part you
cut. You don't need that many pointers.

There are still two cases that you can't avoid. Within an
object, this is a pointer. Even if it doesn't behave like one:
it can't be null and it can't be reseated. But it does mean
that you have to deal with "raw" pointers at least here. And
for navigating between entity objects; I've yet to see any
alternative that worked.

As a beginner, avoid also the address operator.

Totally agreed; pointers should, with few exceptions, limited to
dynamically allocated objects. (Of course, references are sort
of pointers too. So you should probably avoid them as well.)

 

[Alf P. Steinbach]

* James Kanze:

That's true. Pointers are only good within the C++ program
itself. You can't expect them to work outside of the program.

First of all, I'm absolutely not sure I'm replying to James Kanze here.

It looks like someone impersonating him.

But anyway, "internally" does not refer to the program versus its running
environment, but to the implementation of a container such as std::list.

Certainly. That's more or less what I said, in the part you
cut.

I have not replied to or quoted anything from James Kanze in this thread.

And so I have certainly not cut anything from quotes of him.



Cheers & hth., (whoever this is),

- Alf

 

[frank]

Hi Friends,
I got problem hear,

C++ File:

const int val=0;
int *ptr = (int *)&val;
*ptr = 55;
cout<<val<<endl; // out put 0
cout<<*ptr<<endl; // out put 55

in debugging val & *ptr are showing 55 only,
but while printing val it is showing '0' as out put
while printing *ptr it is showing '55' as out put

what is the problem, i am unable to get could u pls help me out.

repeat with me:
const very ugly;
private protected friend template, ugly;
pass by references for one function or operator good;
references like alias ugly;
pointers good;
classes good;
constructor/distrctor very good;
malloc/free good;
C++ library seems ugly;
C library seems ugly;
C and C++ (operator, overloading too) languages very good;
assembly languge [or base language] very good;

I used to program "somewhere between" C and C++, starting with Microsoft
development products. I think it was MVC++ 4.

One thing I liked about the Gemisch was that I could calculate a value
with C syntax, and just cout<< once I found it. The conversion
specifiers for printf are a huge pain in the ass until you stack up
enough references that you've got a decent chance of getting it right.

I think I ended up on the C side because of the pull from unix.

 

[red floyd]

As in "Oh I do like to be beside the C side"? I knew Unix was
attractive, but I didn't realise it was tidal.

I think he just gravitated towards it...

 

[Michael Tsang]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This means that people using Microsoft newsreaders will not be able to
easily read your message, plus that it annoys many other people; AFAIK
there's no positive effect...

The positive effect is the news readers (except Microsoft ones) can
automatically validate the post with the signature. I've written a web site
and I can't make it shown correctly in Microsoft browsers ONLY because it is
not standards-compliant.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAktVwJQACgkQm4klUUKw07Cs9ACfY1eXr5BiC5+WhWjkkZhQLOjY
xnQAn0ygcQ6f01DhSkQbergiwss+Qwoh
=BPz2
-----END PGP SIGNATURE-----

 

[Richard Herring]

The positive effect is the news readers (except Microsoft ones) can
automatically validate the post with the signature.

"Validate"? All it means is that some entity calling itself "Michael
Tsang" signed the post. How is that of any interest to the overwhelming
majority of people reading that post? Even for the few who might be
actually be interested, it's doesn't mean anything significant unless
(a) there's a so-called "web of trust" linking your public key to
somebody they actually trust, and (b) they (probably foolishly) trust
all the unknown signers between that person and your public key.

 

[jl_post]

C++ File:

const int val=0;
int *ptr = (int *)&val;
*ptr = 55;
cout<<val<<endl; // out put 0
cout<<*ptr<<endl; // out put 55

in debugging val & *ptr are showing 55 only,
but while printing val it is showing '0' as out put
while printing *ptr it is showing '55' as out put

I remember learning that the "const" keyword in C++ is like a
contract between the compiler and the programmer that a variable will
never be changed. If the programmer tries to change a const variable,
the compiler should prevent it. In addition, the programmer should be
confident that a const variable will never change after its
initialization.

However, in casting away val's "const-ness" you created a
contradiction: first you told the compiler that val's value will
never change, then you changed it. So when you print out the value of
val, the compiler may see val as an unchangeable variable, and print
out its original value (which is reasonable since you told it that val
would never change) or it may print out the value pointed at by ptr
(which is somewhat reasonable, since that is what is held in val).

... or it could do/print something completely unexpected, since you
wrote code that produced undefined behavior.

In the end, it's important to respect the fact that if you declare
a variable as const, you should never attempt to change it. Doing so
(even if the compiler doesn't complain) produces undefined behavior
and confuses both the compiler and the programmer/maintainer.

I hope this helps,

-- Jean-Luc

 

[Miles Bader]

I remember learning that the "const" keyword in C++ is like a
contract between the compiler and the programmer that a variable will
never be changed. If the programmer tries to change a const variable,
the compiler should prevent it. In addition, the programmer should be
confident that a const variable will never change after its
initialization.

The last sentence is not correct -- const is only a restriction on what
you can do, not a guarantee about what can or can't happen.

-Miles

 

[venkatarao0]

   I remember learning that the "const" keyword in C++ is like a
contract between the compiler and the programmer that a variable will
never be changed.  If the programmer tries to change aconstvariable,
the compiler should prevent it.  In addition, the programmer should be
confident that aconstvariable will never change after its
initialization.

   However, in casting away val's "const-ness" you created a
contradiction:  first you told the compiler that val's value will
never change, then you changed it.  So when you print out the value of
val, the compiler may see val as an unchangeable variable, and print
out its original value (which is reasonable since you told it that val
would never change) or it may print out the value pointed at by ptr
(which is somewhat reasonable, since that is what is held in val).

   ... or it could do/print something completely unexpected, since you
wrote code that produced undefined behavior.

   In the end, it's important to respect the fact that if you declare
a variable asconst, you should never attempt to change it.  Doing so
(even if the compiler doesn't complain) produces undefined behavior
and confuses both the compiler and the programmer/maintainer.

   I hope this helps,

   -- Jean-Luc

Thanks for giving reply,

*ptr = 55; this statement got executed ( ptr and val memory locations
are same)

cout<<val<<endl; // out put 0
cout<<*ptr<<endl; // out put 55

from witch memory location val and *ptr trying to reading, if both
memory locations are same means it should read the same data why it is
not happening.

pls give me a reply.

 

[Bart van Ingen Schenau]

Thanks for giving reply,

*ptr = 55; this statement got executed ( ptr and val memory locations
are same)

 cout<<val<<endl;                   // out put 0
 cout<<*ptr<<endl;                   // out put 55

from witch memory location val and *ptr trying to reading, if both
memory locations are same means it should read the same data why it is
not happening.

It is not happening, because the compiler took you promise not to
change 'val' at face-value and replaced 'val' in 'cout<<val<<endl;'
with the value of 'val', which according to your promiss would always
be 0.

As coming back on your promiss results in Undefined Behaviour, the
compiler can just do as if you never went back on your promiss.

pls give me a reply.

Bart v Ingen Schenau