Question

Implementation 1:

foo(const Bar x);

Implementation 2:

foo(const Bar & x);

If the object will not be changed within the function, why would you ever copy it(implementation 1).

Will this be automatically optimized by the compiler?

Summary: Even though the object is declared as const in the function declaration, it is still possible that the object be edited via some other alias &.

If you are the person writing the library and know that your functions don’t do that or that the object is big enough to justify the dereferencing cost on every operation, than
foo(const Bar & x); is the way to go.

Part 2:

Will this be automatically optimized by the compiler?

Since we established that they are not always equivalent, and the conditions for equivalence is non-trivial, it would generally be very hard for the compiler to ensure them, so almost certainly no

Answer 1

you ask,

“If the object will not be changed within the function, why would you ever copy it(implementation 1).”

well there are some bizarre situations where an object passed by reference might be changed by other code, e.g.

namespace g { int x = 666; }

void bar( int ) { g::x = 0; }

int foo( int const& a ) { assert( a != 0 );  bar( a );  return 1000/a; }  // Oops

int main() { foo( g::x ); }

this has never happened to me though, since the mid 1990s.

so, this aliasing is a theoretical problem for the single argument of that type.

with two arguments of the same type it gets more of a real possibility. for example, an assignment operator might get passed the object that it’s called on. when the argument is passed by value (as in the minimal form of the swap idiom) it’s no problem, but if not then self-assignment generally needs to be avoided.

you further ask,

“Will this be automatically optimized by the compiler?”

no, not in general, for the above mentioned reason

the compiler can generally not guarantee that there will be no aliasing for a reference argument (one exception, though, is where the machine code of a call is inlined)

however, on the third hand, the language could conceivably have supported the compiler in this, e.g. by providing the programmer with a way to explicitly accept any such optimization, like, a way to say ”this code is safe to optimize by replacing pass by value with pass by reference, go ahead as you please, compiler”