-3

Why is it showing the values of p as incremented twice even if according to the code it should be incremented later on

#include "iostream.h"
#include "conio.h"

using namespace std;

int main()
{
  int i;
  cin>>i;
  int *p;         // p is a pointer to int
  int *&r = p;   // r is a reference to the pointer p

  r = &i;        // r refers to a pointer; assigning &i to r makes p point to i
  cout<<*p<<*r<<(*p)++<<*p<<*r<<(*r)++<<endl;

  getch();
  return 0;
}
  • 9
    Why do people insist on doing silly things and then wondering why it doesn't work as they expect? :-) – paxdiablo Jun 16 '13 at 10:10
  • dats rude...but go and run the code you will find that it shows weird behaviour...i m curious to know .. WHY –  Jun 16 '13 at 10:18
  • This code doesn't refer to pointers, nor references at all. Rollbacked to the second revision. – awesoon Jun 16 '13 at 10:31
  • i think u dnt get my code..accordng to me it does reference and points to i as well... –  Jun 16 '13 at 10:37
  • @paxdiablo - Also why do people write code that is unmaintainable - lacks narrative - speaks volumes of their job insecurity - ... Just write reasonable code and then anybody can read it. – Ed Heal Jun 16 '13 at 10:37
  • @Cpluspluslover, I did. You should enable all warnings. Really, there is no differences between your code and [this](http://coliru.stacked-crooked.com/view?id=92b1527a6aad0c8ee0192270bbbc7551-86b2e6efcfbc8c9ef8046e90e83130d8) code. As you can see, I don't use pointers nor references there. – awesoon Jun 16 '13 at 10:42
  • @mbratch if the evaluation of "<<" is right to left then also the values of the order are not coming in the way they should be....I was shocked to see dat the answer was not even coming the same if the order is left to right or right to left...dat d reason I asked to you people –  Jun 16 '13 at 10:47
  • @EdHeal I hope the code is much narrative and easy to understand now...you can now see if we give a value of 2 to 'i'...then y the answer is coming to be 4 4 3 4 4 2 –  Jun 16 '13 at 10:50
  • @Cpluspluslover - It is not. If it was easy to understand then (as a C++ lover) you do not require to ask a question. – Ed Heal Jun 16 '13 at 10:54
  • possible duplicate of [Order of evaluation of arguments using std::cout](http://stackoverflow.com/questions/7718508/order-of-evaluation-of-arguments-using-stdcout) – awesoon Jun 16 '13 at 11:12
  • @mbratch are you sure that the order of evaluation for `<<` is right to left? http://stackoverflow.com/questions/7718508/order-of-evaluation-of-arguments-using-stdcout – Wayne Uroda Jun 16 '13 at 11:16
  • 1
    My comment wasn't meant to be rude, just an observation that code clarity more often than not correlates with code quality . But, to be brutally honest, if someone wrote crud like that for me, I'd send them away to do it properly. And, if they couldn't, I'd just send them away. – paxdiablo Jun 16 '13 at 11:48
  • @WayneUroda, lol I reckon not. Thanks for the great link. :) – lurker Jun 16 '13 at 18:00

1 Answers1

1

I think the weird behaviour you are wondering about is because of the order in which the redirected arguments are parsed and executed.

#include <iostream>

using namespace std;

int main()
{
  int i = 1;
  cout << i << i << i++ << i << i << i++ << endl;
  return 0;
}

In this particular case, on the particular compiler I am using... (i.e. this is all undefined or unspecified behaviour - I am just trying to interpret the results. You should always avoid writing code which triggers undefined behavour).

Arguments 3 and 6 are evaluated first (Because they have the ++ operators attached? thanks rodrigo).

So the rightmost i++ evaluates to 1 and leaves i as 2.

Next the 3rd argument i++ is evaluated, giving 2 and leaving i as 3.

All other arguments evaluate to 3. That is how you get the output

332331.

Note that the order of evaluation for redirected elements is not specified, that is, it could change from compiler to compiler etc, you can't know what it will be.

See also Order of evaluation of arguments using std::cout

As @rodrigo points out to me, since i is incremented twice in the same expression the results are undefined.

So there are many gremlins at play, this is one possibly-correct, possibly-incorrect interpretation of how the output is generated.

Community
  • 1
  • 1
Wayne Uroda
  • 5,025
  • 4
  • 30
  • 35
  • At last! Your last two paragraphs explains the problem fully. +1, this is the answer. – awesoon Jun 16 '13 at 11:10
  • 2
    `i` is modified twice, so the result is actually _undefined behavior_. And the parenthesis here means absolutely nothing. – rodrigo Jun 16 '13 at 11:17
  • atlast some relevant explaination..thanx @wayne uroda –  Jun 16 '13 at 19:06
  • @rodrigo I have edited my answer to be less incorrect now, thanks. – Wayne Uroda Jun 17 '13 at 01:16
  • @Cpluspluslover I'm glad I could help. These guys are correct when they say you should avoid writing code like this, but I understand you might just be experimenting. There's nothing wrong with that in my books. – Wayne Uroda Jun 17 '13 at 01:22