Re: Why is there no input value optimization?
On 2012-04-10 11:18, rossmpublic@gmail.com wrote:
I have a very simple question that I have been unable to find a
satisfactory answer. The question is why do I need to manually
optimize my functions using const references?
For example:
// Optimized passing of string parameter
Widget(std::string const& name);
SetName(std::string const& name);
// Non-optimized passing of string parameter
Widget(std::string name);
SetName(std::string name);
I understand that with the latter notation there is an additional
copy involved on most compilers, but why is that exactly?
Why is it that the compiler (as smart as it is today) is unable to
optimize away the additional copy?
Why should I be writing optimization code into my interfaces?? This
seems very wrong to me.
Everyone is familiar with the Return Value Optimization that the
compiler performs to save extraneous copies of return values. I don't
understand why the same logic cannot be applied to input values.
Because the situation is quite different: When a function returns a
value this means that there will be a to-be-constructed object on the
caller side. RVO just recognizes that fact that the called function
itself has no further use for the return value, so it can construct the
object directly on the caller-side.
For function parameters, the compiler cannot apply this logic: When the
function is called, the compiler must assume that the actual parameters
are still in use (If we have a C++11 compiler and the an rvalue
argument, this argument value can be moved. But it seems to me that your
concern is not related to move semantics). It would require that the
compiler performs tracking of each argument *within* the function (This
is different from RVO, where the compiler can ignore the different
views) to recognice whether they are modified or not. Only if not, the
compiler could elide the copy. Except for very simple examples this is
generally not feasible.
If I write a constructor that simply initializes a member variable or a
setter function that sets a member variable. Wouldn't it be easy for the
compiler to treat that function as if it were declared as pass by
reference instead of pass by value?
Maybe, but that is a very special case. If you want to extend the
copy-elision rules in C++, I suggest to specify the rules for this. It
is easy to demand this by hand-waving examples, but the world is no
longer nice and sweet once you are supposed to *specify* the constraints
upon which compilers would be allowed to do that.
HTH & Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]