Function Overloading

[Pramod]

I have one question. Can I catch exception in function overloading.In
my programm i want to create two function with same signature and same
return type. I know its not possible...can i use try.catch .block to
hand this exception.

 

[Amal P]

I have one question. Can I catch exception in function overloading.In
my programm i want to create two function with same signature and same
return type. I know its not possible...can i use try.catch .block to
hand this exception.

Dear Pramod,

Function overloading happens in compile time.
Exception handling is during runtime.
So you can mix these thing together.
I think I answered your question. If not can you just make your
question more clear?

Thanks and regards,
Amal P

 

[Pramod]

Dear Pramod,

Function overloading happens in compile time.
Exception handling is during runtime.
So you can mix these thing together.
I think I answered your question. If not can you just make your
question more clear?

Thanks and regards,
Amal P

ya amal

can i write my code like this

void sum(int,int)throw;// 1st function
void sum(float,float)throw;//2nd function

 

[=?iso-8859-1?q?Erik_Wikstr=F6m?=]

ya amal

can i write my code like this

void sum(int,int)throw;// 1st function
void sum(float,float)throw;//2nd function

Sure, but what are the exceptions for? If the types of the parameters
are different then the compiler will choose the function to call based
on the arguments provided.

 

[Pramod]

Sure, but what are the exceptions for? If the types of the parameters
are different then the compiler will choose the function to call based
on the arguments provided.

ya you are write basically i wrote wrong ....right question is

int sum(int,int)throw;// 1st function
void sum(int,int)throw;//2nd function

 

[Victor Bazarov]

ya you are write basically i wrote wrong ....right question is

int sum(int,int)throw;// 1st function
void sum(int,int)throw;//2nd function

Uh... Sorry, I must be dumb or something... What is the *question*?
You just repeated the declarations you showed above with a very slight
variation. What do exceptions have to do with it? From your original
post:

What does that mean? What's "exception in function overloading"? Or
what does it mean to "catch" something in "function overloading"?

Please elaborate. Perhaps use less fancy words...

V

 

[Amal P]

ya you are write basically i wrote wrong ....right question is

int sum(int,int)throw;// 1st function
void sum(int,int)throw;//2nd function

Hi,

I am sorry. There is a correction in my previous post. I wrote "So
you CAN mix these thing together." instead of "So you CANNOT mix these
thing together."

And you cannot compile the above code. The return type difference
cannot do the function overloading.

Thanks,
Amal P

 

[Gavin Deane]

Uh... Sorry, I must be dumb or something... What is the *question*?
You just repeated the declarations you showed above with a very slight
variation.

I don't know what the question is either, but the variation between
the two sets of declarations might be significant.

To the OP: You can't overload solely on return type. So while

void sum(int,int); and
void sum(float,float);

are legal overloads of sum,

int sum(int,int); and
void sum(int,int);

are not because the only difference is the return type. Note that this
has nothing whatsoever to do with exceptions or exception
specifications. Adding exception specifications doesn't change this
rule. The correct syntax by the way needs parentheses:

int sum(int,int) throw();

What do exceptions have to do with it? From your original
post:


What does that mean? What's "exception in function overloading"? Or
what does it mean to "catch" something in "function overloading"?

Please elaborate. Perhaps use less fancy words...

Indeed.

Gavin Deane

 

[Bharath]

I don't know what the question is either, but the variation between
the two sets of declarations might be significant.

To the OP: You can't overload solely on return type. So while

void sum(int,int); and
void sum(float,float);

are legal overloads of sum,

int sum(int,int); and
void sum(int,int);

are not because the only difference is the return type. Note that this
has nothing whatsoever to do with exceptions or exception
specifications. Adding exception specifications doesn't change this
rule. The correct syntax by the way needs parentheses:

int sum(int,int) throw();




Indeed.

Gavin Deane

See "7.4.1 Overloading and Return Type [fct.return]" in C++
programming language by Bjarne Stroustrup: Return types are not
considered in overload resolution.

 

[Diego Martins]

See "7.4.1 Overloading and Return Type [fct.return]" in C++
programming language by Bjarne Stroustrup: Return types are not
considered in overload resolution.

will it appear in the new std?

 

[Marcus Kwok]

See "7.4.1 Overloading and Return Type [fct.return]" in C++
programming language by Bjarne Stroustrup: Return types are not
considered in overload resolution.

will it appear in the new std?

I don't think so, as it is too ambiguous.


int foo() { return 0; }
double foo() { return 42.0; }

int main()
{
foo(); // which foo() to call here?
}

 

[Bharath]

See "7.4.1 Overloading and Return Type [fct.return]" in C++
programming language by Bjarne Stroustrup: Return types are not
considered in overload resolution.

will it appear in the new std?

I don't know.

 

[James Kanze]

See "7.4.1 Overloading and Return Type [fct.return]" in C++
programming language by Bjarne Stroustrup: Return types are not
considered in overload resolution.

will it appear in the new std?

No. It leads to too many ambiguities. It is present in
languages that don't have any implicit conversions. But in C++,
the fact that every type can convert implicitly to void makes it
more or less unmanageable.

In specific cases, you can simulate it by means of a proxy.
Something like:

class Data
{
class GetXProxy
{
public:
GetXProxy( Data const* owner )
: myOwner( owner )
{
}

operator int() const
{
return myOwner->getXAsInt() ;
}

operator double() const
{
return myOwner->getXAsDouble() ;
}

operator std::string() const
{
return myOwner->getXAsString() ;
}

private:
Data const* myOwner ;
} ;

GetXProxy getX() const
{
return GetXProxy( this ) ;
}

int getXAsInt() const ;
double getXAsDouble() const ;
std::string getXAsString() const ;
} ;

With this, doing something like:

int i = data.getX() ;

will end up calling getXAsInt, for example. (And just
"data.getX()", without using the return value, will not call any
of the real getters.)

 

[Diego Martins]

See "7.4.1 Overloading and Return Type [fct.return]" in C++
programming language by Bjarne Stroustrup: Return types are not
considered in overload resolution.

will it appear in the new std?

No. It leads to too many ambiguities. It is present in
languages that don't have any implicit conversions.

But normal function overloading also causes ambiguity due to implicit
conversions:

void foo(unsigned);
void foo(float);
....
foo(10); // error! ambiguous call

But in C++,
the fact that every type can convert implicitly to void makes it
more or less unmanageable.

A possible workaround is disallowing converting to void when using
overload by return-type.

In specific cases, you can simulate it by means of a proxy.
Something like:

class Data
{
class GetXProxy
{
public:
GetXProxy( Data const* owner )
: myOwner( owner )
{
}

operator int() const
{
return myOwner->getXAsInt() ;
}

operator double() const
{
return myOwner->getXAsDouble() ;
}

operator std::string() const
{
return myOwner->getXAsString() ;
}

private:
Data const* myOwner ;
} ;

GetXProxy getX() const
{
return GetXProxy( this ) ;
}

int getXAsInt() const ;
double getXAsDouble() const ;
std::string getXAsString() const ;
} ;

With this, doing something like:

int i = data.getX() ;

will end up calling getXAsInt, for example. (And just
"data.getX()", without using the return value, will not call any
of the real getters.)

Your example is correct and works pretty well, but is too boilerplate
code for me.

I am sure a compiler could implement overload by return type in a
similar way:

int get();
float get();
....

float x = get(); // ok
int y = get(); // ok
double z = get(); // error. ambiguous call
get(); // error. "overloading by return type must have a 'void get();'
when the return value is discarded" (or a similar message)

I see no reason to not having overload by return type in the language.
Normal overloading issues (ambiguous call) will also apply in a
similar manner.

-- Perhaps we should forward this discussion to comp.std.c++ --

Diego
HP

 

[James Kanze]

See "7.4.1 Overloading and Return Type [fct.return]" in C++
programming language by Bjarne Stroustrup: Return types are not
considered in overload resolution.
will it appear in the new std?

No. It leads to too many ambiguities. It is present in
languages that don't have any implicit conversions.

But normal function overloading also causes ambiguity due to implicit
conversions:

void foo(unsigned);
void foo(float);
...
foo(10); // error! ambiguous call

Not as systematically. You have to supply an argument, so that
the type can be deduced. (There are also certain rules of thumb
which help avoid the problem. For example, any time you provide
an overload for any numeric type, you also provide one for int,
to avoid this sort of ambiguity.) The problem is that you can
ignore the return value, *every* type is convertible to void,
and you can't play games with the number of return types,
either. You've got a lot less possibilities for limiting the
problem.

A possible workaround is disallowing converting to void when using
overload by return-type.

There are numerous possible workarounds. The current situation
is a compromize, avoiding the worst problems without breaking C
compatibility. (The ideal solution would be to do away with
most implicit conversions.) It as a few rough edges, especially
when taking the address of a function, but while the actual
rules are so complex that almost no one understands them, the
results in practice are almost always what one would intuitively
expect, at least for real code.

[...]

Your example [of a proxy] is correct and works pretty well,
but is too boilerplate code for me.

How often do you need it?

I am sure a compiler could implement overload by return type in a
similar way:

int get();
float get();
...

float x = get(); // ok
int y = get(); // ok
double z = get(); // error. ambiguous call
get(); // error. "overloading by return type must have a 'void get();'
when the return value is discarded" (or a similar message)

And what happens when you start mixing, with differences in both
the return type and the parameter types? Or are the current
rules for function overload resolution too simple for your
taste?

Obviously, it could be done. The question is just, at what
price in terms of additional complexity, and is it worth it?

I see no reason to not having overload by return type in the language.
Complexity.

Normal overloading issues (ambiguous call) will also apply in a
similar manner.

-- Perhaps we should forward this discussion to comp.std.c++ --

You can try, but I doubt you'll find much interest in the
committee. (But that's just my feeling---I could be wrong about
it.)