call by value / (const) reference

[Alexander Stippler]

Hi,

I've several methods which get large objects as parameters like:

qr_decompositio n(const DenseMatrix &A)

My question is simple: Should the line above be the preferred way or
should the parameter be given like

qr_decompositio n(DoubleDenseMa trix A)

I know the difference in semantics. But does it make some essential
difference
for the compiler? Is it better to have the compiler do the copy or to do it
by oneself inside the method? Any performance differences?

regards,
alex

[White Wolf]

Alexander Stippler wrote:

Hi,

I've several methods which get large objects as parameters like:

qr_decompositio n(const DenseMatrix &A)

My question is simple: Should the line above be the preferred way or
should the parameter be given like

qr_decompositio n(DoubleDenseMa trix A)

I know the difference in semantics. But does it make some essential
difference
for the compiler? Is it better to have the compiler do the copy or to do
it by oneself inside the method? Any performance differences?

regards,
alex

If you have to copy the object, it does not really matter. If you do not
need to copy it inside the function use the const-ref form.

--
WW aka Attila
:::
There are wo kinds of people: Those who finish what they start

[Mike Wahler]

"Alexander Stippler" <st**@mathemati k.uni-ulm.de> wrote in message
news:40******@n ews.uni-ulm.de...

Hi,

I've several methods which get large objects as parameters like:

qr_decompositio n(const DenseMatrix &A)

My question is simple: Should the line above be the preferred way or
should the parameter be given like

qr_decompositio n(DoubleDenseMa trix A)

I know the difference in semantics. But does it make some essential
difference
for the compiler?
Typically yes, the generated code for the two forms will be different.
Is it better to have the compiler do the copy or to do it
by oneself inside the method? Any performance differences?

If the object is 'large', (as you state above), then imo pass
by reference should be preferred. But the only conclusive way
to find out about performance is to measure.

-Mike

[Jonathan Turkanis]

"White Wolf" <wo***@freemail .hu> wrote in message
news:bv******** **@phys-news1.kolumbus. fi...

Alexander Stippler wrote:

Hi,

I've several methods which get large objects as parameters like:

qr_decompositio n(const DenseMatrix &A)

My question is simple: Should the line above be the preferred way or should the parameter be given like

qr_decompositio n(DoubleDenseMa trix A)

I know the difference in semantics. But does it make some essential difference
for the compiler? Is it better to have the compiler do the copy or to do it by oneself inside the method? Any performance differences?

regards,
alex
If you have to copy the object, it does not really matter. If you

do not need to copy it inside the function use the const-ref form.

Andrei Alexandrescu (of "Modern C++ Design") has argued that passing
by const ref when you need to make a copy internally is less efficient
than passing by value. See
http://lists.boost.org/MailArchives/boost/msg10536.php.

Jonathan

[Donovan Rebbechi]

In article <40******@news. uni-ulm.de>, Alexander Stippler wrote:

Hi,

I've several methods which get large objects as parameters like:

qr_decompositio n(const DenseMatrix &A)

My question is simple: Should the line above be the preferred way or
should the parameter be given like

qr_decompositio n(DoubleDenseMa trix A)

I know the difference in semantics. But does it make some essential
difference
for the compiler? Is it better to have the compiler do the copy or to do it
by oneself inside the method? Any performance differences?

I think it's better to use const reference, because otherwise, you are
"disclosing " the fact that you deep-copy in the interface, but this should
be an implementation detail. The client code should not know whether or not
you deep-copy.

It's actually not hard to see how one could "implement" this without a deep
copy. For example, you could further down the road use a third party library
to do it instead, in which case the "copying" would involve glue code that
converted your matrix into a data structure the other library could use.

The example may seem contrived or non-applicable, but it also illustrates that
one signature imposes more constraints on implementation than the other.

Cheers,
--
Donovan Rebbechi
http://pegasus.rutgers.edu/~elflord/

[E. Robert Tisdale]

Alexander Stippler wrote:

I've several methods which get large objects as parameters like:

QRDecomposition qr_decompositio n(const DoubleDenseMatr ix &A);

My question is simple:
Should the line above be the preferred way?
Or should the parameter be given like

QRDecomposition qr_decompositio n(DoubleDenseMa trix A);

I know the difference in semantics.
But does it make some essential difference for the compiler?
These two definitions are equivalent
as far as the calling program is concerned.
Is it better to have the compiler do the copy
Or to do it by oneself inside the method?
It doesn't matter if you implementation calls for a copy to be made.
Any performance differences?

No.

Take a look at
The C++ Scalar, Vector, Matrix and Tensor class Library (SVMTL)

http://www.netwood.net/~edwin/svmtl/

(svmtl/src/matrix/Matrix.ccP: line #481-517)

Most implementations [in any computer programming language]
provide a method to perform the decomposition *in-place*:

DoubleDenseMatr ix& qr_decompositio n(DoubleDenseMa trix &A);

The QR decomposition is "packed" back into DoubleDenseMatr ix A
in a format defined be the implementation
(and, in this case, a reference to A is returned).
This isn't a very good Application Program Interface (API)
because a DoubleDenseMatr ix object has effectively
been converted into a QRDecomposition object
and is no longer a meaningful DoubleDenseMatr ix object.
Obviously, this will certainly lead some unwary application programmer
to grief.

[E. Robert Tisdale]

Donovan Rebbechi wrote:

I think it's better to use const reference because, otherwise,
you are "disclosing " the fact that you deep-copy in the interface
but this should be an implementation detail.
The client code should not know whether or not you deep-copy.
Please show us an example of a "client" program
that can tell whether the function was declared

int f(int);

or

int f(const int&);
It's actually not hard to see how one could "implement" this
without a deep copy. For example, you could, further down the road,
use a third party library to do it instead,
in which case the "copying" would involve glue code that converted
your matrix into a data structure the other library could use.

The example may seem contrived or non-applicable
but it also illustrates that one signature imposes more constraints
on implementation than the other.

You can simply substitute an f(const int&) declaration
for the f(int) declaration in your header file.
The only "constraint " is that
you would need to recompile the application.

[Donovan Rebbechi]

In article <40************ @jpl.nasa.gov>, E. Robert Tisdale wrote:

Donovan Rebbechi wrote:
Please show us an example of a "client" program
that can tell whether the function was declared

int f(int);

or

int f(const int&); [snip] The only "constraint " is that
you would need to recompile the application.

You're right, but some people actually think binary compatibility is important.

Even if this is only a small advantage, the pass-by-const reference doesn't
have any disadvantages (or did I miss something)

Cheers,
--
Donovan Rebbechi
http://pegasus.rutgers.edu/~elflord/

[Jonathan Turkanis]

"Donovan Rebbechi" <ab***@aol.co m> wrote in message:

Even if this is only a small advantage, the pass-by-const reference doesn't have any disadvantages (or did I miss something)

Supposedly, it may inhibit some optimizations. See
http://lists.boost.org/MailArchives/boost/msg10536.php.

Jonathan

[E. Robert Tisdale]

Donovan Rebbechi wrote:

Even if this is only a small advantage,
the pass-by-const reference doesn't have any disadvantages
(or did I miss something)

int f(const int&);

It's probably best to pass small objects by value
instead of by const reference.