Is this undefined behaviour?

[n.aggel]

This question goes out to everyone who knows the latest c++ standard by heart:P.
We have the following program:

#include <iostream>

using namespace std;

void wow(int& x, int& y, int&z)
{
	x=x+1;
	y=z;
	z=z+1;
}

int main()
{
	int i=0;
	int A[2]={10,11};

	wow(i, A[i], i);

	cout<<i<<endl;
              cout<<A[0]<<endl;
              cout<<A[1]<<endl;
}

So we have parameter passing by reference and in the function wow we give 2 times the same variable...

This was one of the questions they gave us in the exam of the course "Compilers and language principals..."

The gave us the above code...and told us to say what it will print if we had parameter passing
by reference,
call by value,
call by name,
call by value result...

The gave us the above code in pascal so i "translated it" in c++....{i know that c++ doesn't support all the possible parameter passing techniques}

Comments?

PS:: why the gave us the code in Pascal {pascal isn't in our curricula}...did pascal support all the above methods in parameter passing {or the gave us the code in pascal in order to look like pseudocode}?

PS2::if i compile the program i get an answer, but i am still asking if this is undefined behaviour because i read in the book Concepts.of.Programming.Languages.7th.Edition{0321330250- Addison.Wesley} that it is a no-no to give the same argument to function that utilizes parameter passing by reference....

[Ancient Dragon]

I don't think its undefined behavior, just bad coding. In function wow() x and z both are references to the same object, so any changes to x is also reflected in z. After line 7 is executed the value of both x and z is 1. After line 9 is executed they the value is 2. In line 20 the value of A[1] is unchanged and the value of A[2] is undefined because array A does not have 3 elements. At line 19 the value of i will be 2 (from line 9).

[n.aggel]

sorry i wanted to write::

cout<<i<<endl;
cout<<A[0]<<endl;
cout<<A[1]<<endl;

i also edited the original post

[Ancient Dragon]

that's better. The value of A[0] will be 1, from lines 7 and 8.

[n.aggel]

if y is A-->(A+i)* when in line 7 i changes from 0 to 1, shouldn't this affect A?

In other words why the change isn't A[1]=1???

[Salem]

The reference to A[i] is made with the value of i known in main at the time of the call.

With the reference to an element of the array made, that reference remains constant for the duration of the call.

[n.aggel]

The reference to A[i] is made with the value of i known in main at the time of the call.

With the reference to an element of the array made, that reference remains constant for the duration of the call.

Ah i see, i didn't know that... and this is true for all languages or just for c and c-based....I mean in case of pseudocode {or pascal..sic..} this rule applies?

[Ancient Dragon]

Ah i see, i didn't know that... and this is true for all languages or just for c and c-based....I mean in case of pseudocode {or pascal..sic..} this rule applies?

No, just C and C++. Other languages may or may not follow the same rules. I don't know about pascal, you'd have to read the docs.

[Salem]

> and this is true for all languages or just for c and c-based
It's certainly not true of all languages.

Since Pascal allows nested function definitions, you might be able to construct something which does it the other way.

Here are some other terms which deal with evaluation for further study.
http://en.wikipedia.org/wiki/Closure_%28computer_science%29
http://en.wikipedia.org/wiki/Late_binding
http://en.wikipedia.org/wiki/Lazy_evaluation
Languages which implement these features may be able to demonstrate the effect which you describe.

[n.aggel]

thanks for the links, i will check them.