Function Overloading

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.

re: Function Overloading

On Jun 14, 9:05 pm, Pramod <sahgalpram...@gmail.comwrote: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

re: Function Overloading

On Jun 14, 5:10 pm, Amal P <enjoyam...@gmail.comwrote:ya amal

can i write my code like this

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

re: Function Overloading

On 14 Juni, 14:24, Pramod <sahgalpram...@gmail.comwrote: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.

--
Erik Wikström

re: Function Overloading

On Jun 14, 5:32 pm, Erik Wikström <eri...@student.chalmers.sewrote: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

re: Function Overloading

Pramod wrote: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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

re: Function Overloading

On Jun 14, 9:43 pm, Pramod <sahgalpram...@gmail.comwrote: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

re: Function Overloading

On 14 Jun, 13:56, "Victor Bazarov" <v.Abaza...@comAcast.netwrote:<snip>
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

re: Function Overloading

On Jun 14, 8:25 am, Gavin Deane <deane_ga...@hotmail.comwrote: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.

re: Function Overloading

On Jun 14, 11:05 pm, Bharath <bharath.donni...@gmail.comwrote:will it appear in the new std?

re: Function Overloading

Diego Martins <jose.diego@gmail.comwrote: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?
}

--
Marcus Kwok
Replace 'invalid' with 'net' to reply

re: Function Overloading

On Jun 15, 12:43 pm, Diego Martins <jose.di...@gmail.comwrote:I don't know.

re: Function Overloading

On Jun 15, 7:43 pm, Diego Martins <jose.di...@gmail.comwrote: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.)

--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

re: Function Overloading

On Jun 16, 8:17 am, James Kanze <james.ka...@gmail.comwrote:But normal function overloading also causes ambiguity due to implicit
conversions:

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

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

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

re: Function Overloading

Diego Martins wrote: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.
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.

[...]How often do you need it?
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?
Complexity.
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.)

--
James Kanze (GABI Software, from CAI) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34