1.3.10 signature [defns.signature]
the information about a function that participates in overload resolution (13.3): the types of its parameters and, if the function is a class member, the cv- qualifiers (if any) on the function itself and the class in which the member function is declared.2) The signature of a function template specialization includes the types of its template arguments (14.5.5.1).

Footnote 2 says: "2) Function signatures do not include return type, because that does not participate in overload resolution."

OK, so I can overload a function by defining one with the same signature but a different return type.

Another related question (to avoid starting a new thread): If I have a base class with two overloaded functions and I have a derived class which redefines one of those functions, why then is the second overloaded function unavailable to the derived class?

It could be based on how it's derived, but I am fairly certain that overloading and overriding are mutually exclusive. That is to say Base::Foo (overloaded) is never invoked by calls to Derived::Foo (overriden) because the class it is a member of is part of the signature. So be very explicit when you mean one of the Base::Foos.

OK, so I can overload a function by defining one with the same signature but a different return type.

Another related question (to avoid starting a new thread): If I have a base class with two overloaded functions and I have a derived class which redefines one of those functions, why then is the second overloaded function unavailable to the derived class?

Read it again: return types do not play a part in overload resolution. Two different functions must differ in something other than return type. (Unless you don't mean what I seem to think you mean, which is possible.) But the class name does play a part.

Read it again: return types do not play a part in overload resolution. Two different functions must differ in something other than return type. (Unless you don't mean what I seem to think you mean, which is possible.)

I think that's actually the case! What I meant was that I can overload a function with another that has a different return type, not that changing the return type is actually necessary for the overload. I guess it was just a clumsy way of rephrasing the fact that the return type has nothing to do with it.

If I have a base class with two overloaded functions and I have a derived class which redefines one of those functions, why then is the second overloaded function unavailable to the derived class?

Because member names in the derived class hide corresponding member names in the base class, so you should use a using declaration to bring back the member names from the base class as necessary.

Originally Posted by Bjarne Stroustrup (2000-10-14)

I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.

I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.

Yes, but strictly speaking that is not so. The conversion functions have different names, so by definition there is no overloading (at least not in the context of the same class).

Originally Posted by Sebastiani

So both the implicit operator and bar require overload resolution.

However, for conversion functions is not overload resolution; it is conversion resolution (or whatever name is more appropriate).

Originally Posted by Bjarne Stroustrup (2000-10-14)

I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.

Ah, I see what you mean. So they serve a similar purpose, but are actually governed by different rules. Correct?

Yes, that is how I see it.

Originally Posted by Bjarne Stroustrup (2000-10-14)

I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.

I think that's actually the case! What I meant was that I can overload a function with another that has a different return type, not that changing the return type is actually necessary for the overload. I guess it was just a clumsy way of rephrasing the fact that the return type has nothing to do with it.

Are you overloading or overriding the function? You can override a function (in a derived class) with a different return type (although this would be a very bad idea), but you can't overload two functions in the same class with the same name & parameters but different return types.

"I am probably the laziest programmer on the planet, a fact with which anyone who has ever seen my code will agree." - esbo, 11/15/2008

"the internet is a scary place to be thats why i dont use it much." - billet, 03/17/2010

You can override a function (in a derived class) with a different return type (although this would be a very bad idea)

That is not true. The virtual function override cannot have a different return type specified, unless that return type is a subtype. In such cases, it can actually be a good idea to make use of such covariant return types.

Last edited by laserlight; 07-01-2009 at 10:57 AM.

Originally Posted by Bjarne Stroustrup (2000-10-14)

I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.