TIP: Be Careful with Dummy Reference Arguments

How many times have you used functions that return results through reference parameters, such as this:

void func(int & ra1, int & ra2, int & ra3) ;

You would probably call this function this way:

func(a1, a2, a3) ;

Sometimes, if you do not want the outputs of ra1 and ra2 arguments, but only interested in ra3, you might be tempted to make a call to the function as follows:

int dummy, res ;
func(dummy, dummy, res) ;

This way, you might end up saving the space that is required for that one extra int argument by using dummy in place of arguments a1 and a2. The function may even work properly. But, what's important to note is that if the output argument ra3 is dependent on the values already computed in ra1 and ra2 by func, you might be looking at an entirely different scenario. Take the following example implementation of func:

# include <iostream.h>

func(int & ra1, int & ra2, int & ra3)
   ra1 = 1 ;
   ra2 = 2 ;
   ra3 = ra1 + ra2 ;

   int dummy, res ;
   func(dummy, dummy, res) ;

   cout << res ;

No points for guessing the output. It's not 3 (as expected), but 4. This is obviously due to ra1 and ra2 being allotted the same address, that of dummy. Disaster!! You would have successfully traded accuracy/correctness for a simple saving of 4 bytes in virtual space.

Therefore, in cases where you are not sure whether the values of one result parameter affects others, safely use different variables to hold output parameters, as in:

int  dummy1, dummy2, res ;
func(dummy1, dummy2, res) ;

About the Author

Ashwin Kumar

A mind that's ready to keep learning.


  • Seconded

    Posted by Pharap on 12/29/2014 12:27am

    I agree with prantif that in a case like this, the function should be using its own locals anyway. However, that's not to say such an eventuality where this sort of thing would be a problem would not occur, this example is just far to simplistic to show why it could be a problem. It shows how problems could occur, but not with a meaningful enough example.

  • Is it not the other way round?

    Posted by prantlf on 02/24/2009 04:30pm

    A method implementation should not make assumptions how the parameters must be entered. Otherwise the implementation will be difficult to maintain and a cause of many difficult to find troubles. In this case, local variables should be used and the output parameters filled at the end. Don't let yourself discouraged and keep learning :-) Cheers, Ferda Prantl

Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • Moving from an on-premises environment to Office 365 does not remove the need to plan for disruptions or reduce the business risk requirements for protecting email services. If anything, some risks increase with a move to the cloud. Read how to ease the transition every business faces if considering or already migrating to cloud email. This white paper discusses: Setting expectations when migrating to Office 365 Understanding the implications of relying solely on Exchange Online security Necessary archiving …

  • Enterprises are increasingly looking to platform as a service (PaaS) to lower their costs and speed their time to market for new applications. Developing, deploying, and managing applications in the cloud eliminates the time and expense of managing a physical infrastructure to support them. PaaS offerings must deliver additional long-term benefits, such as a lower total cost of ownership (TCO), rapid scalability, and ease of integration, all while providing robust security and availability. This report …

Most Popular Programming Stories

More for Developers

RSS Feeds

Thanks for your registration, follow us on our social networks to keep up-to-date