By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,302 Members | 1,453 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,302 IT Pros & Developers. It's quick & easy.

integer int i; *i++ and ++*i have a different integer value after the increment

P: n/a
Hi All,

I have an integer pointer with value 10, but it returns a different
return value after the preincrement and post increment.

I will be very thankful if somebody can give an explanation for this
behavior.

Listed below is the program and output - executed in vc++6.

int main(int argc, char* argv[])
{
int *i = (int*) calloc(sizeof(int),1);
*i = 10;

cout << " *i++ " << *i++ << endl;
cout << " *i " << *i << endl;

*i = 10;
cout << " ++*i " << ++*i << endl;
cout << " *i " << *i << endl;

return 0;
}
*i++ 10
*i -33686019
++*i 11
*i 11
Press any key to continue

Dec 26 '05 #1
Share this Question
Share on Google+
14 Replies


P: n/a
Review operator precedence. operator++ has higher precedence than
unary operator*, so
*i++
is equivalent to
*(i++)
and not equivalent to
(*i)++
which is what your presumably wanted. When you dereference a pointer
and find an unexpected, large-magnitude value, it generally means that
the pointer isn't pointing where you thought it was.

Luke

Dec 26 '05 #2

P: n/a

Robben wrote:
Hi All,

I have an integer pointer with value 10, but it returns a different
return value after the preincrement and post increment.

I will be very thankful if somebody can give an explanation for this
behavior.

Listed below is the program and output - executed in vc++6.

int main(int argc, char* argv[])
{
int *i = (int*) calloc(sizeof(int),1);
Don't:

int* i = new int;
*i = 10;

cout << " *i++ " << *i++ << endl;
This is *(i++) : increment the pointer, return the old address and
dereference it.
cout << " *i " << *i << endl;

*i = 10;
illegal, i does not point to valid memory anymore.
cout << " ++*i " << ++*i << endl;
and this is ++(*i) : dereference the pointer and increment the value.
cout << " *i " << *i << endl;
Don't forget to delete the int:

delete i;
return 0;
}
*i++ 10
*i -33686019
++*i 11
*i 11

Jonathan

Dec 26 '05 #3

P: n/a
> Don't forget to delete the int:

delete i;


Remembering, of course, not to mix "new" or "delete" in isolation with
C-style (de)allocation. But since I agree with your recommendation to
use new rather than calloc, no problem.

Luke

Dec 26 '05 #4

P: n/a
when you delete a pointer,

delete i;
i = null;

it is a good habit, especially in very complex environment.

Dec 26 '05 #5

P: n/a
Regulus wrote:
when you delete a pointer,

delete i;
i = null;

it is a good habit, especially in very complex environment.


Is it? Not having dangling pointers* at all is a better habit, IMHO. Are
you going to be checking that "i != NULL" each time you use it?

* Okay, it's "NULL" rather than dangling, which would be fine if C++
were a language where null has a special meaning rather than just being 0.
Dec 26 '05 #6

P: n/a

W Marsh wrote:
Regulus wrote:
when you delete a pointer,

delete i;
i = null;

it is a good habit, especially in very complex environment.
Is it? Not having dangling pointers* at all is a better habit, IMHO.


Not having pointers at all is still better, but some things are
inevitable.
Are
you going to be checking that "i != NULL" each time you use it?
The point of setting a pointer to 0 is to prevent double deletion.
* Okay, it's "NULL" rather than dangling, which would be fine if C++
were a language where null has a special meaning rather than just being 0.


Well a valid address cannot be 0 so yes, 0 has a special meaning for
pointers in C++.
Jonathan

Dec 26 '05 #7

P: n/a

"W Marsh" <wayneDOTmarshATgmailDOTcom@decipher> wrote in message
news:43***********************@news.zen.co.uk...
Regulus wrote:
when you delete a pointer,

delete i;
i = null;

it is a good habit, especially in very complex environment.


Is it? Not having dangling pointers* at all is a better habit, IMHO. Are
you going to be checking that "i != NULL" each time you use it?

* Okay, it's "NULL" rather than dangling, which would be fine if C++ were
a language where null has a special meaning rather than just being 0.


Actually, for pointers it is the one case it does have a special meaning.

It is legal to delete a null pointer.

int* i = new int;
delete i;
delete i; // ERROR

int* i = new int;
delete i;
i = NULL;
delete i; // NO ERROR
Dec 26 '05 #8

P: n/a
Jim Langston wrote:
"W Marsh" <wayneDOTmarshATgmailDOTcom@decipher> wrote in message
news:43***********************@news.zen.co.uk...
Regulus wrote:
when you delete a pointer,

delete i;
i = null;

it is a good habit, especially in very complex environment.
Is it? Not having dangling pointers* at all is a better habit, IMHO. Are
you going to be checking that "i != NULL" each time you use it?

* Okay, it's "NULL" rather than dangling, which would be fine if C++ were
a language where null has a special meaning rather than just being 0.

Actually, for pointers it is the one case it does have a special meaning.

It is legal to delete a null pointer.


Sure, but you could just as well say "it is legal to delete a pointer
with the value 0". It's different to having a null pointer (or
reference) in a language such as C#, where deferencing it would throw an
exception rather than causing some nasty undefined behaviour.

int* i = new int;
delete i;
delete i; // ERROR

int* i = new int;
delete i;
i = NULL;
delete i; // NO ERROR


It's just my personal philosophy to design around potential errors like
this so that they don't have the chance to occur, rather than just
making them harmless if they do. I'm sure there are plenty of
programmers far more skilled than me who would disagree, though.
Dec 26 '05 #9

P: n/a

Luke Meyers wrote:
Don't forget to delete the int:

delete i;


Remembering, of course, not to mix "new" or "delete" in isolation with
C-style (de)allocation. But since I agree with your recommendation to
use new rather than calloc, no problem.

Luke

Thank you Luke and Jonathan for your feedback.

Dec 26 '05 #10

P: n/a

Luke Meyers wrote:
Don't forget to delete the int:

delete i;


Remembering, of course, not to mix "new" or "delete" in isolation with
C-style (de)allocation. But since I agree with your recommendation to
use new rather than calloc, no problem.

Luke

Thank you Luke and Jonathan and others who had given there valuable
suggestions and feedback.

Dec 26 '05 #11

P: n/a
Jonathan Mcdougall wrote:
Robben wrote:
Hi All,

I have an integer pointer with value 10, but it returns a different
return value after the preincrement and post increment.

I will be very thankful if somebody can give an explanation for this
behavior.

Listed below is the program and output - executed in vc++6.

int main(int argc, char* argv[])
{
int *i = (int*) calloc(sizeof(int),1);
Don't:

int* i = new int;

new int() if he wants the same behavior as calloc (zero initialization).
*i = 10;

cout << " *i++ " << *i++ << endl;


This is *(i++) : increment the pointer, return the old address and
dereference it.


No, it is return the address of the pointer before the increment and
make sure it is incremented before the next sequence point. In fact,
the above has undefined behavior. The increments could both be applied
before the sequence point in an allowable ordering.

Further, even without violating that rule, you don't know which
of the *i++ subexpressions is evaluated first.
Dec 26 '05 #12

P: n/a

Ron Natalie wrote:
Jonathan Mcdougall wrote:
Robben wrote:
Hi All,

I have an integer pointer with value 10, but it returns a different
return value after the preincrement and post increment.

I will be very thankful if somebody can give an explanation for this
behavior.

Listed below is the program and output - executed in vc++6.

int main(int argc, char* argv[])
{
int *i = (int*) calloc(sizeof(int),1);
Don't:

int* i = new int;

new int() if he wants the same behavior as calloc (zero initialization).
*i = 10;

cout << " *i++ " << *i++ << endl;


This is *(i++) : increment the pointer, return the old address and
dereference it.


No, it is return the address of the pointer before the increment and
make sure it is incremented before the next sequence point.
In fact, the above has undefined behavior.

The increments could both be applied
before the sequence point in an allowable ordering.

Further, even without violating that rule, you don't know which
of the *i++ subexpressions is evaluated first.


I think you missed the double quotes around the first *i++.

However, this is still undefined behavior because i now points to an
invalid address, though, on most platforms, the first cout statement
should work correctly because what is dereferenced is the old address.
The second cout:
cout << " *i " << *i << endl;


is more dangerous, but may still go unnoticed unfortunately.
Jonathan

Dec 26 '05 #13

P: n/a
Jonathan Mcdougall wrote:
I think you missed the double quotes around the first *i++.

Oops you'rre right.

However, this is still undefined behavior because i now points to an
invalid address, though, on most platforms, the first cout statement
should work correctly because what is dereferenced is the old address.
The second cout:
cout << " *i " << *i << endl;


is more dangerous, but may still go unnoticed unfortunately.


Incrementing is OK, the pointer is guaranteed to have a valid
value one past the end. However, dereferencing the pointer
is invalid as you note.
Dec 26 '05 #14

P: n/a
Jonathan Mcdougall wrote:
Robben wrote:
int *i = (int*) calloc(sizeof(int),1);

Don't:
int* i = new int;


Even better:
int j;
int *i = &j;

Dec 27 '05 #15

This discussion thread is closed

Replies have been disabled for this discussion.