Re: How to return a reference, when I really need it

In article <h4ur7t$1o5b$1@news.ett.com.ua>, Balog Pal <pasa@lib.hu> wrote:


Please, this is incorrect !

Returning vector by value is not "way inefficient" in the general case.
It may even be faster and more efficient than returning by reference
in the majority of usage scenario because of the capability of the
compiler to optimise away any superflous copy and allocation via RVO.

So the following is probably the fastest in a large set of very common
usage scenario.
---------------------------------------------------
std::vector<double> iReturnALargeVector();

int main()
{
  std::vector<double> v = iReturnALargeVector();
}
---------------------------------------------------
In addition to the speed benefits, the above is very simple to write,
very simple to maintain and is far least likely to hide a subtle bugs
than returning a reference to internal data.

The following is probably slower due to the (possibly) unecessary call
to the default constructor and maybe additional indirection.
---------------------------------------------------
void iUseReferenceArg(std::vector<double> & v);

int main()
{
  std::vector<double> v;
  iUseReferenceArg(v);
}
----------------------------------------------------
It also is more verbose, less obvious, and forces the creation of a
vector that for a period of time has not been initialised with any
relevant data. Although it is a valid vector that has been correctly
constructed, it contains "invalid" data for a time.

This will probably be slower in the common case when a const ref is
not sufficient
---------------------------------------------------
std::vector<double> const & iReturnAConstRefToALocalTemp();

int main()
{
  // OK fast enough (but still maybe a bit slower)
  std::vector<double> & crv = iReturnAConstRefToALocalTemp();

  // slower
  std::vector<double> constRefNotSufficient =
    iReturnAConstRefToALocalTemp();
}
----------------------------------------------------

Returning a reference to internal data to a class (possibly using a
proxy) may in some circumstances have speed benefits. But is has very
significant drawbacks because of the risk it introduce in the code.
--------------------------------------------------------
class Matrix
{
public:
   std::vector<double> const & getRow(size_t index) const;
   // I'll not even consider a non-const non-const ref version of this...

   void modifier(Data data);
private:
  std::vector< std::vector<double> > m_matrix;
}

Matrix aMatrix;
// ...
// ...
std::vector<double> const & rv = aMatrix.getRow(12);
// OK
double d = rv.at(4); // OK
// ...
// ...
// inline or even worse, in a difference thread
aMatrix.modifier(data); // OK
// ...
// But now?
double d2 = rv.at(6); // Euh... Is it safe now?

// Or even better
Matrix * pMatrix = new Matrix;
std::vector<double> const & rv = pMatrix->getRow(12);
delete pMatrix;
double d = rv.at(10) // !!!!!!!!!

Note: usually, the above sequence is quite a bit less obvious than
that. It is obfuscated through indirect calling and existence of
multiple classes that return data by reference. It all start with
good intention... the assumption that returing a reference will be
faster... and then we have a database proxy class, that caches the
database data, that for performance returns a reference to its
internal cache but then one adds support for updating or refreshing
the cache somewhere, and then...

Yannick