by value or by reference?

[James.Yu.Tin]

Anybody can kindly explain the confusion below?
generally, would there be any problem for C++?



void magic(int& a) {

/* expect side-effect */
// change the value of the input

printf("by reference.");
return;
}

void magic(int a){
/* any side-effect is not allowed*/

printf("by value.");
return;
}

//each with a unique signature, so it is ok to have both magic(int& )
and magic(int), though they are overloaded;

//now comes the problem. when both magics are defined as above,
//none of them can be called without ambiguity. For example,

void main(){

int x = 10000;
magic(x);

}

 

[Gianni Mariani]

Anybody can kindly explain the confusion below?
generally, would there be any problem for C++?



void magic(int& a) {

/* expect side-effect */
// change the value of the input

printf("by reference.");
return;
}

void magic(int a){
/* any side-effect is not allowed*/

printf("by value.");
return;
}

//each with a unique signature, so it is ok to have both magic(int& )
and magic(int), though they are overloaded;

//now comes the problem. when both magics are defined as above,
//none of them can be called without ambiguity. For example,

void main(){

void is wrong here. Must be "int main()".

int x = 10000;
magic(x);

}

Right ... and the compiler complains. So what's the problem ?

xxx_ambigfunc.cpp:28: error: call of overloaded `magic(int&)' is ambiguous
xxx_ambigfunc.cpp:4: note: candidates are: void magic(int&)
xxx_ambigfunc.cpp:13: note: void magic(int)

 

[James.Yu.Tin]

The problem is:

The two functions magic(int &) and magic(int ) are valid
(according to both C++ grammar and semantics);

However, it turns absurd if both of them exist.

The absurdity is that no body can invoke either of them (for a calling
is inevitably ambiguous).

I am afraid if this phenonmenon would be general in C++, i.e., it is
possible
for people to find more and more embarrasing cases just like this
simple example. ..... I hope I am wrong here....


Could you help me and point out what is wrong with my reasoning?

 

[Neelesh Bodas]

The problem is:

please donot Top-post in this group.

The two functions magic(int &) and magic(int ) are valid
(according to both C++ grammar and semantics);

However, it turns absurd if both of them exist.

The absurdity is that no body can invoke either of them (for a calling
is inevitably ambiguous).

It is not "inevitably ambiguous". It is ambiguous in the example that
you quoted.

int main()
{
const int x = 10000;
magic(x); // value semantics. Resolved without ambiguity

int r = foo();
int s = bar();
magic(r+s); // value sematics. Resolved without ambiguity
}

I am afraid if this phenonmenon would be general in C++, i.e., it is
possible
for people to find more and more embarrasing cases just like this
simple example. ..... I hope I am wrong here....

The pass-by-value and pass-by-nonconst-reference have altogether
different semantics. Rhese two cases could turn out to be
semantically equivalent only when there are no side-effects.

Also note that a function taking a non-const reference as its argument
is an indication of the fact that the function would like to change
the argument's value. If the function doesnot intend to do that, a
pass-by-const-reference be used instead. Pass by value should be
preferred only when you want to send a copy of the variable to the
called function.

-Neelesh

 

[Gianni Mariani]

The problem is:

The two functions magic(int &) and magic(int ) are valid
(according to both C++ grammar and semantics);

However, it turns absurd if both of them exist.

It's invalid code. I can write all kinds of invalid code, what's the
point ?

The absurdity is that no body can invoke either of them (for a calling
is inevitably ambiguous).

I am afraid if this phenonmenon would be general in C++, i.e., it is
possible
for people to find more and more embarrasing cases just like this
simple example. ..... I hope I am wrong here....


Could you help me and point out what is wrong with my reasoning?

The standard places constraints and forces seemingly innocuous
constructs to be invalid. There is usually (not always) good reason.

It just is.

If you'd like it to be different, make a good reason for an alternative.

BTW if you really had to, you can discriminate between either method.

#include <cstdio>
using namespace std;

void magic(int& a) {

/* expect side-effect */
// change the value of the input

printf("by reference.");
return;
}

void magic(int a){
/* any side-effect is not allowed*/

printf("by value.");
return;
}

//each with a unique signature, so it is ok to have both magic(int& )
and magic(
int), though they are overloaded;

//now comes the problem. when both magics are defined as above,
//none of them can be called without ambiguity. For example,

typedef void ( * f1 )( int );
f1 getmagic1( f1 v )
{
return v;
}

typedef void ( * f2 )( int & );
f2 getmagic2( f2 v )
{
return v;
}

int main(){

int x = 10000;
getmagic1(magic)(x);
getmagic2(magic)(x);

}

 

[cplusplus]

THE PROBLEM IS THAT YOU ARE A GEEK