Passing return as reference to another function

[Ryan Mitchley]

Hi all

I have the functions
friend CComplexMatrixT emp eye(const size_t nN);

and
friend CComplexMatrixT emp & chol(CComplexMa trixTemp &z);

I would like create expressions of the form CComplexMatrixT emp x =
chol(eye(6)), similar to MATLAB syntax.

GCC doesn't seem like the fact that chol(...) wants to take a reference to a
returned temporary. Is there anyway around this without losing the nice
notation? I could obviously do something like:
CComplexMatrixT emp temp = eye(80);
CComplexMatrixT emp x = chol(temp);
but this is definitely not as pretty!

Copying a matrix object is an expensive operation, hence the desire to use
references. The CComplexMatrixT emp class is formed in intermediate
expressions where storage space may be reused (I also have a CComplexMatrix
class which is used directly by the application programmer).

Thanks for any help!

Ryan

[Victor Bazarov]

"Ryan Mitchley" <rm******@remov ethis.worldonli ne.co.za> wrote...

I have the functions
friend CComplexMatrixT emp eye(const size_t nN);

and
friend CComplexMatrixT emp & chol(CComplexMa trixTemp &z);

I would like create expressions of the form CComplexMatrixT emp x =
chol(eye(6)), similar to MATLAB syntax.

GCC doesn't seem like the fact that chol(...) wants to take a reference to a returned temporary. Is there anyway around this without losing the nice
notation? I could obviously do something like:
CComplexMatrixT emp temp = eye(80);
CComplexMatrixT emp x = chol(temp);
but this is definitely not as pretty!

Copying a matrix object is an expensive operation, hence the desire to use
references. The CComplexMatrixT emp class is formed in intermediate
expressions where storage space may be reused (I also have a CComplexMatrix class which is used directly by the application programmer).

There is no way around the rule that a non-const reference cannot be
bound to a temporary. That said, there is no way for you to return
even a const reference to a local object (I assume 'eye' returns some
kind of automatic object it creates).

I think there are two solutions for you. Either return an object (as
you already do), make 'chol' accept a reference to a _constant_ object

CComplexMatrixT emp chol(CComplexMa trixTemp const &);

(and, apparently make it create another object too), _or_ you look over
the "MOJO" technique proposed by Andrei Alexandrescu and discussed in
several places, comp.lang.c++.m oderated being probably the most
accessible to you.

Essentially, you might get away with inventing your own ref-counting
mechanism for matrix contents. Instead of the calculation data make
your matrix object store a pointer to them. Only when an matrix is
to change should it produce another calculation data and point to it.
This is called "copy on write". That way when you just return objects
from a function, the calculation data don't have to be reallocated.

All in all, you really shouldn't concern yourself with copying a matrix
object _until_ you see that you compiler cannot optimise it for you and
until you discover that it really slows everything down too much. There
is a significant optimisation allowed by the C++ Standard: return value
optimisation (RVO), which should be performed by most if not all modern
compilers.

Victor

[Ryan Mitchley]

VB> I think there are two solutions for you. Either return an object (as
VB> you already do), make 'chol' accept a reference to a _constant_ object

VB> CComplexMatrixT emp chol(CComplexMa trixTemp const &);

VB> (and, apparently make it create another object too), _or_ you look over
VB> the "MOJO" technique proposed by Andrei Alexandrescu and discussed in
VB> several places, comp.lang.c++.m oderated being probably the most
VB> accessible to you.

Thanks for the detailed reply, Victor. I've actually come across an article
on the MOJO thing before. Unfortunately, I ran out of concentration about
half way through :-) Maybe it's time to look at it again . . .

VB> All in all, you really shouldn't concern yourself with copying a matrix
VB> object _until_ you see that you compiler cannot optimise it for you and
VB> until you discover that it really slows everything down too much.
VB> There is a significant optimisation allowed by the C++ Standard: return
VB> value optimisation (RVO), which should be performed by most if not all
VB> modern compilers.

Okay. I'm just not too sure how I'll tell when it's being done, and when
not.

Thanks again!

Ryan