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

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

Robben wrote:[color=blue]
> 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);[/color]

Don't:

int* i = new int;
[color=blue]
> *i = 10;
>
> cout << " *i++ " << *i++ << endl;[/color]

This is *(i++) : increment the pointer, return the old address and
dereference it.
[color=blue]
> cout << " *i " << *i << endl;
>
> *i = 10;[/color]

illegal, i does not point to valid memory anymore.
[color=blue]
> cout << " ++*i " << ++*i << endl;[/color]

and this is ++(*i) : dereference the pointer and increment the value.
[color=blue]
> cout << " *i " << *i << endl;[/color]

Don't forget to delete the int:

delete i;
[color=blue]
> return 0;
> }
>
>
> *i++ 10
> *i -33686019
> ++*i 11
> *i 11[/color]


Jonathan

> Don't forget to delete the int:[color=blue]
>
> delete i;[/color]

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

when you delete a pointer,

delete i;
i = null;

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

Regulus wrote:[color=blue]
> when you delete a pointer,
>
> delete i;
> i = null;
>
> it is a good habit, especially in very complex environment.[/color]

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.

W Marsh wrote:[color=blue]
> Regulus wrote:[color=green]
> > when you delete a pointer,
> >
> > delete i;
> > i = null;
> >
> > it is a good habit, especially in very complex environment.[/color]
>
> Is it? Not having dangling pointers* at all is a better habit, IMHO.[/color]

Not having pointers at all is still better, but some things are
inevitable.
[color=blue]
> Are
> you going to be checking that "i != NULL" each time you use it?[/color]

The point of setting a pointer to 0 is to prevent double deletion.
[color=blue]
> * 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.[/color]

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


Jonathan

"W Marsh" <wayneDOTmarshATgmailDOTcom@decipher> wrote in message
news:43af88ed$0$23288$db0fefd9@news.zen.co.uk...[color=blue]
> Regulus wrote:[color=green]
>> when you delete a pointer,
>>
>> delete i;
>> i = null;
>>
>> it is a good habit, especially in very complex environment.[/color]
>
> 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.[/color]

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

Jim Langston wrote:[color=blue]
> "W Marsh" <wayneDOTmarshATgmailDOTcom@decipher> wrote in message
> news:43af88ed$0$23288$db0fefd9@news.zen.co.uk...
>[color=green]
>>Regulus wrote:
>>[color=darkred]
>>>when you delete a pointer,
>>>
>>>delete i;
>>>i = null;
>>>
>>>it is a good habit, especially in very complex environment.[/color]
>>
>>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.[/color]
>
>
> Actually, for pointers it is the one case it does have a special meaning.
>
> It is legal to delete a null pointer.[/color]

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.
[color=blue]
>
> int* i = new int;
> delete i;
> delete i; // ERROR
>
> int* i = new int;
> delete i;
> i = NULL;
> delete i; // NO ERROR[/color]

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.

Luke Meyers wrote:[color=blue][color=green]
> > Don't forget to delete the int:
> >
> > delete i;[/color]
>
> 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[/color]


Thank you Luke and Jonathan for your feedback.

Luke Meyers wrote:[color=blue][color=green]
> > Don't forget to delete the int:
> >
> > delete i;[/color]
>
> 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[/color]


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

Jonathan Mcdougall wrote:[color=blue]
> Robben wrote:[color=green]
>> 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);[/color]
>
> Don't:
>
> int* i = new int;[/color]
new int() if he wants the same behavior as calloc (zero initialization).
[color=blue]
>[color=green]
>> *i = 10;
>>
>> cout << " *i++ " << *i++ << endl;[/color]
>
> This is *(i++) : increment the pointer, return the old address and
> dereference it.[/color]

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.

Ron Natalie wrote:[color=blue]
> Jonathan Mcdougall wrote:[color=green]
> > Robben wrote:[color=darkred]
> >> 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);[/color]
> >
> > Don't:
> >
> > int* i = new int;[/color]
> new int() if he wants the same behavior as calloc (zero initialization).
>[color=green]
> >[color=darkred]
> >> *i = 10;
> >>
> >> cout << " *i++ " << *i++ << endl;[/color]
> >
> > This is *(i++) : increment the pointer, return the old address and
> > dereference it.[/color]
>
> 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.[/color]

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:
[color=blue]
> cout << " *i " << *i << endl;[/color]

is more dangerous, but may still go unnoticed unfortunately.


Jonathan

Jonathan Mcdougall wrote:
[color=blue]
> I think you missed the double quotes around the first *i++.
>[/color]

Oops you'rre right.

[color=blue]
> 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:
>[color=green]
>> cout << " *i " << *i << endl;[/color][/color]

[color=blue]
>
> is more dangerous, but may still go unnoticed unfortunately.
>[/color]

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.

Jonathan Mcdougall wrote:[color=blue]
> Robben wrote:[color=green]
>> int *i = (int*) calloc(sizeof(int),1);[/color]
> Don't:
> int* i = new int;[/color]

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