Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles / Languages / C++

Function Overload by Return

4.40/5 (30 votes)
5 Apr 2007CPOL2 min read 1   441  
Choosing the right function based on the return type

Introduction

This code shows one way to use the C++ overload rule using the function return type instead of its signature. Of course, nothing is changed in the language, and the result just looks like a return type overload.

Background

The function overload, in other words, reusing an existent function name but with different parameters, is something more or less known by the C++, Java and .NET community. As a sine qua non condition, we know that the overloaded function signature must be always different from its homonyms colleagues. The code below illustrates this:

C++
GUID guid;
wstring guidS;

CreateNewGUID(guidS); // calls void CreateNewGUID(wstring&)
CreateNewGUID(guid);  // calls void CreateNewGUID(GUID&) (the compiler knows that)

It's a pretty common way to accept different input formats. But what about the output? How to extract different information or the same information in different format using the overload feature (e.g. the above example) without passing the result variable as a output argument? Giving ourselves some imagination and thinking how a valid construction would be, we can think of something like this:

C++
GUID guid;
wstring guidS;

guidS = CreateNewGUID(); // calls wstring CreateNewGUID()
guid = CreateNewGUID();  // calls GUID CreateNewGUID() (the compiler knows that?)

Opening again our old and hurt C++ theories book, we can see the above code DOES NOT work. Or, at least, should not be. Just defining a couple of functions like that causes the following error:

error C2556: 'GUID CreateNewGUID(void)' : overloaded function differs 
	only by return type from 'std::wstring CreateNewGUID(void)'

That's right. Well, the error is right. The return type is not a function property that identifies it uniquely. Only the signature can do that (the parameters received by the function). AFAIK, this "limitation" is hack proof. Anyway, nothing disallows us to use another feature besides ordinary functions:

C++
struct CreateNewGUID
{
   // what is supposed to be here?
};

We got it! Now we can "call" our "function" creating a new instance of the struct and attributing the "return" to a wstring or to our GUID struct:

C++
guidS = CreateNewGUID(); 	// instantiates a CreateNewGUID
guid = CreateNewGUID(); 	// instantiates a CreateNewGUID. 
			// The difference is in the "return"

Using the Code

Since we create a new type, and knowing that this new type is different from the already known wstring and GUID types, we should simply convert our new type into every desirable return type:

C++
struct CreateNewGUID
{
   operator wstring () { ... } 	// the conversion is the "function call"

   operator GUID () { ... } 	// as there's a couple of conversions... 
				// over... underload!
};

This concludes our somewhat odd solution to overload a "function" by the return type:

C++
// instantiates a CreateNewGUID e calls CreateNewGUID::operator wstring()
guidS = CreateNewGUID();

// instantiates a CreateNewGUID e calls CreateNewGUID::operator GUID()
guid = CreateNewGUID();

There's the entire source.

C++
/** @file underload.cpp
@brief A way to make overload using just the return type.
@author Wanderley Caloni
*/
#include <windows.h>
#include <objbase.h>

#include <iostream />
#include <string>

using namespace std;

struct CreateNewGUID
{
   operator wstring () // the first function...
   {
      GUID guid = operator GUID();
      OLECHAR buf[40] = { };
      ::StringFromGUID2(guid, buf, sizeof(buf));
      return wstring(buf);
   }

   operator GUID () // ... and its "underload"
   {
      GUID guid = { };
      ::CoCreateGuid(&guid);
      return guid;
   }
};

Points of Interest

This code was developed a long time ago as an answer to a friend's doubt. I learnt while coding that C++ is even more powerful than we think it is. In one form or another, we can always get what we want.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)