By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,197 Members | 1,205 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,197 IT Pros & Developers. It's quick & easy.

Overloading based on return type

P: n/a
Hi All,
Very recently I had one iteresting question about
overloading. The guy was arguing why we dont have overloading based on
return type. I told him about the reason mentioned in "Thinking in C+
+", which is what if the return type is ignored by the caller.

He then said that the regular overloading places
restrictions - such as same fucntion names, different type or number
of arguments. If the language creators wanted to implement
overloading, they could have forced the restriction of specifiying the
return type each time the caller ignores that function.

I request everyone to comment on this. I really want to find
out why overloading is not supported on the basis of return type of
the function.

Regards,
Madhav.

Aug 13 '07 #1
Share this Question
Share on Google+
1 Reply


P: n/a
On Aug 13, 3:48 pm, Madhav <madhav.kel...@gmail.comwrote:
I really want to find
out why overloading is not supported on the basis of return type of
the function.
Google's a wonderful thing - from Stroustrup himself:

The reason that C++ doesn't allow overload resolution based on a
return
type (so that you need to use explicit qualification in the examples
below) is that I wanted overload resolution to be bottom up. For
example, you can determine the meaning of a subexpression a+b without
considering the complete expression that a+b is part of. Overload
resolution can be subtle so even though I knew how to use return types
as part of resolution (Ada showed how), I decided not to. As a result
of this decision, a+b means the same in a+b+c as in a+b+d. See
Stroustrup: The Design and Evolution of C++ for more details of the
design of C++.

Aug 13 '07 #2

This discussion thread is closed

Replies have been disabled for this discussion.