I
Ian Collins
I all depends how expensive a foo is to copy. The idiomatic form wouldPrzemyslaw said:
be cost&. If foo is small, it may be cheaper to pass by value, but that
would change if ever foo changed.
be cost&. If foo is small, it may be cheaper to pass by value, but that
would change if ever foo changed.
V
Victor Bazarov
Przemyslaw said:
I think a common implementation of references for the purposes of
passing them as arguments is a pointer. IOW, behind the scenes the
compiler generates the code that passes the address of the object
when you write pass by reference. Unless the function is inlined,
passing an address requires for the item to be in memory. For some
cases it would actually be better to pass the argument itself if it
can be kept in a processor register (instead of storing it in memory
even if it's just in the stack). A long time ago, in a different
life, I timed calling an empty function that takes a double as its
argument, another that takes a reference to a double, and yet
another that takes a pointer to a double. With certain optimization
options the compiler generated the fastest code when the double was
passed by value. With other options the difference was not serious
enough to mention. YMMV
V
I
Ian Collins
Przemyslaw said:
I didn't spot the copy.
In addition to Victors comments, on some machines (notably RISC machines
with register wheels) several registers are used to pass parameters. One
example is Sun CC on Sparc, where it is faster to pass a std::string by
value than by reference.
A
Andrey Tarasevich
Przemyslaw said:
Semantically, there's a difference. When you pass by reference, the
compiler has to preserve the lvalue identity of the argument. For example:
1) Built-in unary '&' applied to the parameter has to return the address
of the actual argument
void foo(const int& a, const int& b) {
assert(&a == &b);
}
// The above 'assert' has to hold if called as
int i;
foo(i, i);
2) A non-constant argument can be legally modified through const
reference by using 'const_cast'
void foo(const int& a) {
const_cast<int&>(a) = 42;
}
// The above modification is legal if called as
int i;
foo(i);
assert(i == 42);
// i.e. this assertion has to hold
3) Possible aliasing
int x = 0;
void foo(const int& a) {
x = 42;
assert(a == 42);
}
// The above 'assert' has to hold if called as
foo(x);
Which means that the compiler can't simply treat const reference
parameters as being equivalent to value parameters. They are not.
Of course, a very smart compiler can recognize these situations and
stick to the strict semantics when they occur, while using const
references and copied values interchangeably in all other cases. This is
not simple though in general case.
In situations when you can use either, it might be more optimal to pass
small objects by value and large objects by reference.
P
Przemyslaw Koprowski
Hi all,
Is there any difference between the following:
foo someFunction(const foo& A)
{
foo B(A);
// do sth. to B
return B;
}
and
foo someFunction(foo A)
{
// do sth. to A
return A;
}
I think there is none (a short test on gcc, with all
optimalizations on, seems to support this), but if
there is any I would like to know.
Is any of these two forms preferable? Why?
TIA,
Przemek
P.S.
The context for the question (if is of any importance here)
is mostly operator overloading. Say:
qForm operator + (qForm A, const qForm &B)
{
return A += B;
}
Assuming that qForm:
perator += is already defined.
Is there any difference between the following:
foo someFunction(const foo& A)
{
foo B(A);
// do sth. to B
return B;
}
and
foo someFunction(foo A)
{
// do sth. to A
return A;
}
I think there is none (a short test on gcc, with all
optimalizations on, seems to support this), but if
there is any I would like to know.
Is any of these two forms preferable? Why?
TIA,
Przemek
P.S.
The context for the question (if is of any importance here)
is mostly operator overloading. Say:
qForm operator + (qForm A, const qForm &B)
{
return A += B;
}
Assuming that qForm:
perator += is already defined.
A
acehreli
A number of years ago, Andrei Alexandrescu was arguing on comp.lang.c+
+.moderated that pass-by-value would give the compiler more
oportunities for optimizations. He was recommending this form of
operator=:
Foo & Foo:
perator= (Foo temp){
this->swap(temp);
return *this;
}
But you haven't seen any differences in your testing...
Ali
P
Przemyslaw Koprowski
Why? After all, the foo object is being copied in both cases.
Either explicitely when constructing B:
or implicitely when passing an argument by value:
That's why I don't expect any difference. Could you ellaborate
why size of foo shall matter here?
Przemek
H
Hans Bos
Przemyslaw Koprowski said:
I think the second form can be more efficient.
If you don't pass directly a foo object but something that can be converted
in a foo the first form will create two foo objects.
E.g.
If someFunction(const std::string &A) is called as someFunction("..."), the
literal string is converted to a std::string. When you make the copy, the
string is created twice.
In std::string someFunction(std::string A), there will be only one string.
So I would recommend the second option. It is a more general solution and
doesn't hurt performance.
Hans.