passing parameters by const& ... can it be overdone?

[christopher diggins]

I have heard it is considered good practice to pass function parameters as
const& as often as possible, is this true? Is it possible to go overboard?
And if so why? Thanks a lot in advance everyone!

Christopher Diggins
http://www.cdiggins.com

 

[Ron Natalie]

I have heard it is considered good practice to pass function parameters as
const& as often as possible, is this true? Is it possible to go overboard?
And if so why? Thanks a lot in advance everyone!

Certainly...it makes little sense to pass things that aren't very big
to begin with (pointers, ints, doubles, etc...) via const reference when
a copy would most likely be faster.

However when it comes to things where the copying is nontrivial: vectors,
strings, etc...and you know that it's not going to change in the caller,
then there's an advantage to not copying it.

 

[E. Robert Tisdale]

I have heard it is considered good practice
to pass function parameters as const& as often as possible.
Is this true?

Yes.
You can also pass small objects by value.

Is it possible to go overboard? And, if so, why?

You should pass by value, const* or const& and return by value.
Functions that return void are seldom justified.
A destructor is an example of an exception to this rule.

Sometimes, it is necessary to modify a large object *in-place*.
Examples are:
discrete finite Fourier transforms, matrix decompositions and
other operations on container objects.

Assignment:

X& Xperator=(const X&);

is an example of a function that modifies one of its arguments --
the hidden argument X* this.
Functions that modify one of their arguments
should return a reference or a pointer to the modified object
instead of void so that the function can be used in an expression.

But, generally, if you find yourself implementing a function
that modifies one or more of its arguments,
you should stop and think carefully about your design.
The argument that is modified must be declared as a [state] variable
in the calling program and this will complicate
the analysis of your program by you and other programmers
who must maintain your program.

 

[Larry Brasfield]

I have heard it is considered good practice to pass function parameters as const& as often as possible, is this true? Is it
possible to go overboard?

I have been known to say "The only rule of thumb worth a damn is
'Do not rely on rules of thumb without knowing when to break them.'".

The rule you suggest is not worth a damn, period. So applying it
would be quite likely to lead to overuse.

And if so why? Thanks a lot in advance everyone!

For objects that are expensive to copy, which includes large objects
or objects whose copy contructors must allocate dynamic memory,
passing via const reference would be good idea, unless there were
locking issues that would make even the copying a cheaper choice.
When considering the gain achieved by avoiding a copy, one must
consider the extra indirection that a reference will usually entail for
each access to the members or value of the object.

The easiest way to realize that the rule is bunk is to consider the
case of simple value objects that (may, on a particular machine)
fit in a machine word, such as int, float, or small structs. When
these can be copied to the parameter/call stack with a single
instruction, using a reference instead would likely be a loser.
But even that cannot be taken as a hard and fast rule. For
example, such a small object might be only rarely used in the
called routine and tend to reside in memory that has been
paged out so that passing its address and not using it would
be faster than pulling the value at the cost of a page fault.

Good practise is to understand what affects performance and
keep it in mind during design and coding, but finally measure
performance and, if lacking, discover why and correct. If
silly errors have not been made in the design, such fixes as
are needed at that point should be mostly localized changes.

And, in case I have not been clear about this: Good practise
is to avoid rules of thumb without knowing their limitations.

 

[christopher diggins]

Certainly...it makes little sense to pass things that aren't very big
to begin with (pointers, ints, doubles, etc...) via const reference when
a copy would most likely be faster.

However when it comes to things where the copying is nontrivial: vectors,
strings, etc...and you know that it's not going to change in the caller,
then there's an advantage to not copying it.

Thanks for the response. Do you think excessive copying of primitive types
lead to a significantly performance penalty given the optimizations
performed by most C++ compilers? Is there any reason an optimizer would not
make a copy of a superflous reference to a primitive type?

Christopher Diggins

 

[christopher diggins]

I have heard it is considered good practice to pass function parameters as

I have been known to say "The only rule of thumb worth a damn is
'Do not rely on rules of thumb without knowing when to break them.'".

The rule you suggest is not worth a damn, period. So applying it
would be quite likely to lead to overuse.


For objects that are expensive to copy, which includes large objects
or objects whose copy contructors must allocate dynamic memory,
passing via const reference would be good idea, unless there were
locking issues that would make even the copying a cheaper choice.
When considering the gain achieved by avoiding a copy, one must
consider the extra indirection that a reference will usually entail for
each access to the members or value of the object.

The easiest way to realize that the rule is bunk is to consider the
case of simple value objects that (may, on a particular machine)
fit in a machine word, such as int, float, or small structs. When
these can be copied to the parameter/call stack with a single
instruction, using a reference instead would likely be a loser.
But even that cannot be taken as a hard and fast rule. For
example, such a small object might be only rarely used in the
called routine and tend to reside in memory that has been
paged out so that passing its address and not using it would
be faster than pulling the value at the cost of a page fault.

Could modern C++ optimizing compilers compensate for superflous usage of
const& with small value types?

Good practise is to understand what affects performance and
keep it in mind during design and coding, but finally measure
performance and, if lacking, discover why and correct. If
silly errors have not been made in the design, such fixes as
are needed at that point should be mostly localized changes.

And, in case I have not been clear about this: Good practise
is to avoid rules of thumb without knowing their limitations.

You are preaching to the choir here, I am asking in order to have a better
understanding of how superflous const& operations on small value types could
adversely affect the performance. To this end I significantly appreciate
your input.

Christopher Diggins

 

[christopher diggins]

Yes.
You can also pass small objects by value.


You should pass by value, const* or const& and return by value.
Functions that return void are seldom justified.
A destructor is an example of an exception to this rule.
...

Thanks for the response, but I think we have crossed wires. I am pondering
the negative effects that would arise if I implemented a large library with
every single argument being passed as a const&. Clearly there is some
measure of performance penalty, but I am trying to gauge how much.

Christopher Diggins

 

[E. Robert Tisdale]

Could modern C++ optimizing compilers compensate
for superflous usage of const& with small value types?

Yes.

But it isn't practical.
You can't measure the difference between
pass by value and pass by const reference
for small objects in any function call.
Try it for yourself.

Pass built-in types by value
and pass User Defined Types (UDTs) by const reference
and your code won't be far from optimal wherever you port it.

 

[E. Robert Tisdale]

Thanks for the response, but I think we have crossed wires.
I am pondering the negative effects that would arise
if I implemented a large library
with every single argument being passed as a const&.
Clearly there is some measure of performance penalty,
but I am trying to gauge how much.

The performance penalty is so slight that
you won't be able to measure it.

 

[Method Man]

Pass built-in types by value

and pass User Defined Types (UDTs) by const reference
and your code won't be far from optimal wherever you port it.

Again, you can not make general statements like that without knowing the
implementation details. Consider a device controller programmer who has the
following UDT:

struct DISK_REGISTER {
unsigned ready:1;
unsigned error_occured:1;
unsigned disk_spinning:1;
unsigned write_protect:1;
unsigned head_loaded:1;
unsigned error_code:8;
unsigned track:9;
unsigned sector:5;
unsigned command:5;
};

For sake of argument, assume: sizeof(DISK_REGISTER) == sizeof(int).

Now, say we needed to pass this struct into a function and modify all its
members. The extra level of indirection required by a const reference to
access the members would be much more inefficient than simply passing in the
struct by value.

 

[christopher diggins]

Again, you can not make general statements like that without knowing the
implementation details. Consider a device controller programmer who has
the
following UDT:

struct DISK_REGISTER {
unsigned ready:1;
unsigned error_occured:1;
unsigned disk_spinning:1;
unsigned write_protect:1;
unsigned head_loaded:1;
unsigned error_code:8;
unsigned track:9;
unsigned sector:5;
unsigned command:5;
};

For sake of argument, assume: sizeof(DISK_REGISTER) == sizeof(int).

Now, say we needed to pass this struct into a function and modify all its
members. The extra level of indirection required by a const reference to
access the members would be much more inefficient than simply passing in
the
struct by value.

If I am not confused then this is not a good example because you simply
wouldn't be able to modify the members if you passed it by const reference.

Christopher Diggins
http://www.cdiggins.com

 

[Markus Elfring]

I have heard it is considered good practice to pass function parameters as

const& as often as possible, is this true? Is it possible to go overboard?
And if so why? Thanks a lot in advance everyone!

Please read this:
1. Book "Effective C++" by Scott Meyers
Item 22: Prefer pass-by-reference to pass-by-value
http://www.ncpod.org:16080/shared/EffectiveC++/EC/EI22_FR.HTM

2. Free electronic book "Thinking in C++" by Bruce Eckel
References in C++
http://www.savinov.spb.ru/think/tic0120.html#Heading311

 

[christopher diggins]

Please read this:
1. Book "Effective C++" by Scott Meyers
Item 22: Prefer pass-by-reference to pass-by-value
http://www.ncpod.org:16080/shared/EffectiveC++/EC/EI22_FR.HTM

2. Free electronic book "Thinking in C++" by Bruce Eckel
References in C++
http://www.savinov.spb.ru/think/tic0120.html#Heading311

Thank you for the links.

Christopher Diggins
http://www.heron-language.com

 

[Method Man]

If I am not confused then this is not a good example because you simply
wouldn't be able to modify the members if you passed it by const reference.

Sorry, I should not have said "modified", but simply "accessed".

 

[E. Robert Tisdale]

Again, you can not make general statements like that without knowing the
implementation details. Consider a device controller programmer who has the
following UDT:

struct DISK_REGISTER {
unsigned ready:1;
unsigned error_occured:1;
unsigned disk_spinning:1;
unsigned write_protect:1;
unsigned head_loaded:1;
unsigned error_code:8;
unsigned track:9;
unsigned sector:5;
unsigned command:5;
};

For sake of argument, assume: sizeof(DISK_REGISTER) == sizeof(int).

Now, say we needed to pass this struct into a function and modify all its
members. The extra level of indirection required by a const reference to
access the members would be much more inefficient than simply passing in the
struct by value.

Please construct a pair of benchmark programs:
one that passes a DISK_REGISTER by const reference and
another that passes a DISK_REGISTER by value.
Show us that you can measure a significant difference
in the time required to execute each program.

 

[Andre Dajd]

I have heard it is considered good practice to pass function parameters as
const& as often as possible, is this true? Is it possible to go overboard?
And if so why? Thanks a lot in advance everyone!

Christopher Diggins
http://www.cdiggins.com

Functors are to be designed to be passed by value.

See Effective STL.

d

 

[Richard Herring]

Functors are to be designed to be passed by value.

That's a requirement imposed on the *functor*, not the function to which
it's passed, and it's not there to address this particular question.

Forbidding functors to have mutable internal state (which is effectively
what it does) allows the library implementor more freedom in designing
algorithms which can use multiple copies of the functor if they need to.

 

[Peteris Krumins]

Please construct a pair of benchmark programs:
one that passes a DISK_REGISTER by const reference and
another that passes a DISK_REGISTER by value.
Show us that you can measure a significant difference
in the time required to execute each program.

The simplest benchmark program.

#include <iostream>
#include <string>

struct DISK_REGISTER {
unsigned ready:1;
unsigned error_occured:1;
unsigned disk_spinning:1;
unsigned write_protect:1;
unsigned head_loaded:1;
unsigned error_code:8;
unsigned track:9;
unsigned sector:5;
unsigned command:5;
};

void f(const DISK_REGISTER &r) {
(void) r;
}

void g(DISK_REGISTER r) {
(void) r;
}

int
main(int argc, char **argv)
{
if (argc > 1) {
const std::string arg = argv[1];
DISK_REGISTER r;
if (arg == "f") for (unsigned i = 0; i < 1000000000; i++) f(r);
else if (arg == "g") for (unsigned i = 0; i < 1000000000; i++) g(r);
else std::cerr << argv[0] << ": <f|g>" << std::endl; return 1;
}
return 0;
}

4 second difference in favor of pass by value for 1 billion iterations.
Compiled with gcc 3.3.4 without optimizations (run on 400Mhz box in case
you wonder why it took so long)

pkrumins$ time ./test g

real 0m27.953s
user 0m27.370s
sys 0m0.100s

pkrumins$ time ./test f

real 0m31.652s
user 0m31.060s
sys 0m0.130s


P.Krumins

 

[E. Robert Tisdale]

Please construct a pair of benchmark programs:
one that passes a DISK_REGISTER by const reference and
another that passes a DISK_REGISTER by value.
Show us that you can measure a significant difference
in the time required to execute each program.

The simplest benchmark program.

#include <iostream>
#include <string>

struct DISK_REGISTER {
unsigned ready:1;
unsigned error_occured:1;
unsigned disk_spinning:1;
unsigned write_protect:1;
unsigned head_loaded:1;
unsigned error_code:8;
unsigned track:9;
unsigned sector:5;
unsigned command:5;
};

void f(const DISK_REGISTER &r) {
(void) r;
}

void g(DISK_REGISTER r) {
(void) r;
}

int
main(int argc, char **argv)
{
if (argc > 1) {
const std::string arg = argv[1];
DISK_REGISTER r;
if (arg == "f") for (unsigned i = 0; i < 1000000000; i++) f(r);
else if (arg == "g") for (unsigned i = 0; i < 1000000000; i++) g(r);
else std::cerr << argv[0] << ": <f|g>" << std::endl; return 1;
}
return 0;
}

4 second difference in favor of pass by value for 1 billion iterations.
Compiled with gcc 3.3.4 without optimizations (run on 400Mhz box in case
you wonder why it took so long)

pkrumins$ time ./test g

real 0m27.953s
user 0m27.370s
sys 0m0.100s

pkrumins$ time ./test f

real 0m31.652s
user 0m31.060s
sys 0m0.130s

That's a good start.

First,
convince us that your compiler did *not* simply inline
f(const DISK_REGISTER&) and/or g(DISK_REGISTER).
Show us the compiler version and options that you used.

Second,
convince us that your results are *significant*.
Run each case several times
and calculate the average time and standard deviation.
The difference in average times must be at least as large
as the standard deviation(s).

 

[Peteris Krumins]

That's a good start.

First,
convince us that your compiler did *not* simply inline
f(const DISK_REGISTER&) and/or g(DISK_REGISTER).
Show us the compiler version and options that you used.

pkrumins$ g++ test.cpp -o test -W -Wall
pkrumins$ g++ -v
gcc version 3.3.4

Since I am was optimizing, no functions were inlined.

Second,
convince us that your results are *significant*.
Run each case several times
and calculate the average time and standard deviation.
The difference in average times must be at least as large
as the standard deviation(s).

I changed the number of iterations for each test to 200 million, so
the tests took less time.
I did 10 observations.

Here are the results (sorted by time):

1. f(const DISK_REGISTER&)

N time (s) delta time (s) (delta time)^2 (s^2)
1 6,324 0,0195 0,00038025
2 6,326 0,0175 0,00030625
3 6,327 0,0165 0,00027225
4 6,334 0,0095 0,00009025
5 6,336 0,0075 0,00005625
6 6,350 0,0065 0,00004225
7 6,353 0,0095 0,00009025
8 6,354 0,0105 0,00011025
9 6,363 0,0195 0,00038025
10 6,368 0,0245 0,00060025
----- ----------
avg: 6,3435 sum: 0,00232850

standard deviation:
sqrt(sum / (n - 1)) = 0,016084844 (s)

2. g(DISK_REGISTER)
N time (s) delta time (s) (delta time)^2 (s^2)
1 5,596 0,0048 0,00002304
2 5,597 0,0038 0,00001444
3 5,599 0,0018 0,00000324
4 5,599 0,0018 0,00000324
5 5,600 0,0008 0,00000064
6 5,600 0,0008 0,00000064
7 5,601 0,0002 0,00000004
8 5,603 0,0022 0,00000484
9 5,604 0,0032 0,00001024
10 5,609 0,0082 0,00006724
----- ----------
avg: 5,601 sum: 0,00012760

standard deviation: 0,003765339 (s)


Now the results are significant and we see that pass by value is
faster than pass by const reference.


P.Krumins