Overloaded functions by its return type, cast rules

G

Grizlyk

1. Can abybody explain me why C++ function can not be overloaded by its
return type? Return type can has priority higher than casting rules.
For example:

char input(); //can be compiled to name "input$char$void"
int input(); //can be compiled to name "input$int$void"
....

int i= 3+'0'+input(); //can be compiled to:
int(3)+int('0')+input$int$void()
char ch= 3+'0'+input(); //can be compiled to:
char(3)+char('0')+input$char$void()

Are any understandable obstacles exist? There is some profit for such
overloading, for example, we would may not write:
char input_char();
int input_int();

2. Cast is only by return type. Am i right? For example:

A a;
struct B{ static B& operator+ (const A&, const B&); };
B b;
struct B{ static C& operator+ (const B&, const C&); };
C c;
struct D{
static D& operator+ (const D&, const D&);
D(const C&);
};

D d=a+b+c; //give me

d.operator=( D::eek:perator+( D::eek:perator+( D(a)+D(b) ), D(c) ) );
or declared "class_name::eek:perator+" change cast
d.operator=( D( C::eek:perator+ ( B::eek:perator+(a,b), c ) ) );

Or is it FAQ question?
 
J

Jim Langston

Grizlyk said:
1. Can abybody explain me why C++ function can not be overloaded by its
return type? Return type can has priority higher than casting rules.
For example:

char input(); //can be compiled to name "input$char$void"
int input(); //can be compiled to name "input$int$void"
...

int i= 3+'0'+input(); //can be compiled to:
int(3)+int('0')+input$int$void()
char ch= 3+'0'+input(); //can be compiled to:
char(3)+char('0')+input$char$void()

Are any understandable obstacles exist? There is some profit for such
overloading, for example, we would may not write:
char input_char();
int input_int();

2. Cast is only by return type. Am i right? For example:

A a;
struct B{ static B& operator+ (const A&, const B&); };
B b;
struct B{ static C& operator+ (const B&, const C&); };
C c;
struct D{
static D& operator+ (const D&, const D&);
D(const C&);
};

D d=a+b+c; //give me

d.operator=( D::eek:perator+( D::eek:perator+( D(a)+D(b) ), D(c) ) );
or declared "class_name::eek:perator+" change cast
d.operator=( D( C::eek:perator+ ( B::eek:perator+(a,b), c ) ) );

Or is it FAQ question?

int foo( std::string& bar )
{
bar = "Hello";
}

bool foo( std::string& bar )
{
bar = "Goodbye";
}

int main()
{
std::string Text;
foo( Text );

std::cout << Text << std::endl;
}

Would that program print "Hello" or "Goodbye"? I believe that's why
functions can't be overloaded by return type alone.
 
G

Grizlyk

Jim said:
int foo( std::string& bar )
{
bar = "Hello";
}

bool foo( std::string& bar )
{
bar = "Goodbye";
}

int main()
{
std::string Text;
foo( Text );

std::cout << Text << std::endl;
}

Would that program print "Hello" or "Goodbye"? I believe that's why
functions can't be overloaded by return type alone.

Maybe, but we always have ambiguouses for overloading
void foo(const int);
void foo(const char);

foo(0); //what calls?
 
G

Grizlyk

Grizlyk ÐÉÓÁÌ(Á):
void foo(const int);
void foo(const char);

foo(0); //what calls?

No.
void foo(const long);
void foo(const double);
foo(0); //what calls?

It is ambiguous.
 
G

Greg

Grizlyk said:
Grizlyk ÐÉÓÁÌ(Á):

No.
void foo(const long);
void foo(const double);
foo(0); //what calls?

It is ambiguous.

True, but with the following foo() overloads:

void foo(int);
void foo(short);

there would be no ambiguity. foo(int) would be called.

Greg
 
G

Gary Wessle

Grizlyk said:
1. Can abybody explain me why C++ function can not be overloaded by its
return type? k

according to Stroustrup p.151
The reason is to keep resolution for an individual operator or
function call context-independent.
 
P

Pete Becker

Grizlyk said:
Grizlyk ÐÉÓÁÌ(Á):

No.
void foo(const long);
void foo(const double);
foo(0); //what calls?

It is ambiguous.

Yes, but that ambiguity is easy to resolve by being more explicit about
the type of the argument:

foo(0L); // calls foo(long)
foo(0.0); // calls foo(double)

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)
 
G

Grizlyk

Gary said:
according to Stroustrup p.151
The reason is to keep resolution for an individual operator or
function call context-independent.

Yes, but the reason is compiler's reason or human's reason? Maybe there
is dangers in overloaded by return type?

For overloaded functions ambiguouses is always exist, these or those.
Disabling of function overloaded by return type decreases flexibility,
exactly as disabling of function overloaded by parameter type.
 
J

Jack Klein

1. Can abybody explain me why C++ function can not be overloaded by its
return type? Return type can has priority higher than casting rules.
For example:

char input(); //can be compiled to name "input$char$void"
int input(); //can be compiled to name "input$int$void"
...

int i= 3+'0'+input(); //can be compiled to:
int(3)+int('0')+input$int$void()
char ch= 3+'0'+input(); //can be compiled to:
char(3)+char('0')+input$char$void()

No, it can't, because the types of the expression:

char ch = 3 + '0' + input();

Which are: char = int + char + function return. The rules of C++
require that '0' undergoes the usual arithmetic conversion and
promotes to int.

The fact that you are assigning the value of the expression to a char
has nothing at all to do with the types and conversions in the
expression itself, it never has, and it never will.
 
G

Grizlyk

Jack Klein ÐÉÓÁÌ(Á):
No, it can't, because the types of the expression:

char ch = 3 + '0' + input();

Which are: char = int + char + function return. The rules of C++
require that '0' undergoes the usual arithmetic conversion and
promotes to int.

The fact that you are assigning the value of the expression to a char
has nothing at all to do with the types and conversions in the
expression itself, it never has, and it never will.

Mm? Is any type of destination not used? It looks as wrong, for there
is no other way to avoid ambiguouse conversions.

Or std types char and short have a special meaning and promotes to int?
Let's consider double instead of char.
 
B

bjarne

Grizlyk said:
Yes, but the reason is compiler's reason or human's reason? Maybe there
is dangers in overloaded by return type?

It was for the humans. I knew how to get the computer to resolve based
on the return type also - the algorithm was well known at the time. See
"The Design and Evolution of C++" for answers to this kind of questions
- you don't have to guess.

-- Bjarne Stroustrup; http://www.research.att.com/~bs
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,537
Members
45,021
Latest member
AkilahJaim

Latest Threads

Top