Looking around on Google for a definitive definition of function signatures, it seems that some people say one thing and some say another.
Some say it's everything in the prototype, others say it's just the name and the argument types and names. So who is right? Is the return type part of the signature or not?
When all else fails, ask ISO.
Footnote 2 says: "2) Function signatures do not include return type, because that does not participate in overload resolution."Originally Posted by The C++ Standard
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.
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.
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.
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.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
But what about:
Code:struct base { virtual operator string ( void ) const; virtual operator int ( void ) const; };
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
How are you going to overload a conversion function?
Look up a C++ Reference and learn How To Ask Questions The Smart Way
>> How are you going to overload a conversion function?
Well, that's essentially what you're doing. For example:
So both the implicit operator and bar require overload resolution.Code:struct foo { operator float ( void ) const { return 0.0f; } operator double ( void ) const { return 1.0; } void bar( float ) { } void bar( double ) { } }; int main( void ) { foo f; int //b1 = f, // error, ambiguous b2 = ( int )( ( float )f ), // fine b3 = ( int )( ( double )f ); // fine //f.bar( 0 ); // error, ambiguous f.bar( ( float )0 ); // fine f.bar( ( double )0 ); // fine return 0; }
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
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).
However, for conversion functions is not overload resolution; it is conversion resolution (or whatever name is more appropriate).
Look up a C++ Reference and learn How To Ask Questions The Smart Way
>> Yes, but strictly speaking that is not so. The conversion functions have different names, so by definition there is no overloading.
Ah, I see what you mean. So they serve a similar purpose, but are actually governed by different rules. Correct?
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
Yes, that is how I see it.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
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
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.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
