How to abandon a function when changing C ++ return type

Question

What strategies exist for legacy functions when their return type needs to change? For example, I have:

BadObject foo(int); // Old function: BadObject is being removed. Object foo(int); // New function. 

Object and BadObject very different from each other, and replacing their return types will violate the code for current users of my library. I try to avoid this.

I can mark BadObject foo(int) deprecated and give users time to modify the affected code.
However, I cannot overload foo based on the return type . foo very well named, and it does not need to accept additional parameters. How to add a new function to my library while keeping the old version, at least for a while?

What is the strategy to abandon the old function without breaking too heavily dependent code, giving users time to upgrade to the new version? Ideally, I would keep the current function name and parameter list, because now it is pretty well named. It seems that this should be a fairly common problem: what is a decent way to solve it?

Answer 1

Although the decision will force you to change function names, it will be a compromise between your old users and your new ones.

So - rename the old foo to deprecatedFoo and your new foo to foo2 (or whatever). Then, in the header file that you include in your library, you can simply:

 #define deprecatedFoo foo 

and inside the do function itself:

 #warning ("This function is deprecated. Use 'foo2' or change the #define in LINE in file HEADER.") 

Users of older versions will not have to change their code and a warning will be issued, and new users will probably listen and modify #define to use the new foo .

In the next version, you just delete the old foo and define .

Answer 2

I think the classic example of Boost Spirit .

From the FAQ :

During the introduction of Spirit V2, we restructured the directory structure in order to host two versions at the same time. All Spirit.Classic now lives in a directory

boost / spirit / home / classic

where the above directories contain forwarding headers to new ones allowing you to maintain application compatibility. forwarding headers give a warning (starting with Boost V1.38), informing the user can change their included paths. Please expect directories / forwarding headers to leave soon.

This explains the need for a directory.

boost / spirit / include

which also contains forwarding headers. But this time, the headlines will not disappear. We encourage authors of applications to use only includes this directory. This allows us to restructure the directories under it, if necessary, without worrying about compatibility. Use these files only in your application. If it is that some forwarding files are missing, report it as an error.

You can facilitate migration by storing the new and old versions in separate directories and using forwarding headers to ensure compatibility. Ultimately, users will be forced to use new headers.

SDL 2.0 has a different approach. They do not provide a level of compatibility, but instead the migration guide takes users through the most dramatic changes. In this case, you can help users understand how they need to restructure their code.

Answer 3

What if your class Object inherits from BadObject (which you will temporarily store)? Then the old user code will not know about it, so it will not be interrupted provided that your new "foo" function still returns your objects correctly.