0

I know that "best" is relative and varies with different situations, but why would one choose to implement say a getter by passing in a variable rather than a pointer to a variable. Since passing pointers is generally faster/less overhead, why not just use pointers/references all the time instead of passing variables? I can only see issues if the original variable is deleted, then you'll be left with null pointers, but in the case of class level variables that shouldn't be an issue right?

Example:

int getNum() {return num}
vs
void getNum(int* toGet) {toGet = num}
floatfil
  • 407
  • 2
  • 10
  • 17
  • 8
    "Since passing pointers is generally faster/less overhead" - why do you think that? They add the overhead of indirection, and only reduce the overhead of copying the object if the object is larger or more complex than a pointer. (Except in this case, where the object is copied anyway, so all you achieve is obfuscation.) – Mike Seymour Oct 24 '14 at 12:32
  • 3
    Your second example is completely broken. So's your first if we consider syntax! Anyway, this is a general question about the most efficient way to get a value out of a function and it's been asked before. – Lightness Races in Orbit Oct 24 '14 at 12:36
  • 1
    Please consider http://stackoverflow.com/questions/3647438/conventions-for-accessor-methods-getters-and-setters-in-c – sfrehse Oct 24 '14 at 12:38
  • 1
    Out-parameters make side-effects harder to spot, prevent you from declaring variables as `const`, and require prior construction. On the other hand, modifying an already existing variable in-place can be more efficient (e.g., reusing allocated memory). Note that there is Return Value Optimization, which makes returning more efficient than just copying. There are up- and downsides for either approach. – dyp Oct 24 '14 at 12:38
  • Just to plainly reiterate what Mike said, the very example you show (assuming it's corrected), is actually almost guaranteed to be slower for the "reference-style" return. – luk32 Oct 24 '14 at 12:39
  • 4
    Rules of thumb: http://stackoverflow.com/a/2139254/1938163 and there must be a duplicate of this somewhere.. I can't find it yet.. – Marco A. Oct 24 '14 at 12:41
  • 1
    I honestly don't think you would ever use pointers for this purpose in C++. This is where you would almost always use a reference: `void get(int& i);`, not that I would recommend out-parameters for a getter. – Galik Oct 24 '14 at 12:48
  • Yeah, what would an old Dane know about C++ programming, amirite? – molbdnilo Oct 24 '14 at 12:54
  • `boost::call_traits < T >::param_type` determines "best" way to pass parameters to functions. – sfrehse Oct 24 '14 at 12:59
  • Don't use getters and setters at all. Tell, Don't Ask (https://pragprog.com/articles/tell-dont-ask). – Rob K Oct 24 '14 at 13:42

1 Answers1

1

Use T getter() or T getter() const unless there is no copy/move constructor for return value. The only exception - significant performance issues. As about pointer, I think, the only reason to use void getter(T* pointer) is writing POD-data to pre-allocated buffer.

When you about to choose void getter(T& value) due to performance reasons, look if compiler performs Return Value Optimization to help you. In most cases, it does, so just let your compiler work for you.

When you're sure that RVO is not applicable in your case, check if this code is called often (may be performance doesn't matter in caller function)?

And when you're can provide proof that reference or pointer is needed in your getter to anyone concerning - use reference/pointer alternative. As has been suggested above, pointer and reference are much more less obvious and hard to support than "returning by-value". Don't add potential error places to your code just because you can.

Victor Istomin
  • 1,107
  • 8
  • 14
  • As about performance, it's very easy to optimize returned POD-type value for compiler. Even easier, than optimizing pointer usage. Just create simple test project, write test code, compile in several modes, (Debug, Release, play with optimization) and look at results. – Victor Istomin Oct 24 '14 at 13:14