Re: References vs variables - speed impacts?
Rune Allnor wrote:
In the code I am working with now, references appear to behave
as if they were actual variable assignments.
[...]
{// Unconditional evaluation
const size_t& i = v1[v2[n]];
const size_t& j = v2[v1[n]];
if (someTest(i))
{
// Use j
}
}
{// Lazy evaluation
const size_t& i = v1[v2[n]];
if (someTest(i))
{
size_t& j = v2[v1[n]];
// Use j
}
}
I initially used the reference expressions to save some typing
(the actual names used in the code is quite a bit longer than here),
expecting reference expressions to have no impact on run-time.
However, I saw hints of improved performance when I used the
lazy evaluation code, where the reference j is initialized only if
the test on i succeeds.
This would suggest that there is an actual variable assignment taking
place, and not merely a code synonym.
Stop: A reference refers to an object, not to code! That means that if e.g.
someTest() changed v1, v2 or n, you would even get different results!
Anyhow, others already pointed out that it is the evaluation of the
expression that costs time, not binding the reference to the result of that
expression.
One more thing, since you seem to be interested in speed: Assign the result
of the expression to a const object, not to a reference. Two reasons for
that:
1. You document clearly that it doesn't change, i.e. that even though you
can not change it (as the reference to const also say), nobody else can
either.
2. The compiler also doesn't have to make alias analysis in order to
determine that nobody will change it, which is much easier when it doesn't
have to try to determine all twisted ways the object a reference refers to
could be changed.
3. Storing it in a local makes it much easier to just use a register. Even
if an actual object is created in RAM, typically it is easier to access
than through a reference, which adds another pointer dereference including
the impact on the memory/cache etc. IOW, avoiding to copy the object by
using a reference is more expensive than copying it! Obviously, that
depends on the (size/complexity of the) object.
Uli
--
Sator Laser GmbH
Gesch??ftsf??hrer: Thorsten F??cking, Amtsgericht Hamburg HR B62 932
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]