move and returning string

[Christopher J. Pisz]

I am playing catchup on C++11 and 14 still.

Once upon a time it was preferred to write a function in which you were
returning a string, in form:

void GetString(std::string & out);

and it was argued that we did not want to write form:

std::string GetString();

in order to prevent the extra copy of the temporary that is the return
value.

With the introduction of Move Semantics, is this still the case?

[Alf P. Steinbach]

On 08.11.2016 04:12, Christopher J. Pisz wrote:
> I am playing catchup on C++11 and 14 still.
>
> Once upon a time it was preferred to write a function in which you were
> returning a string, in form:
>
> void GetString(std::string & out);
>
> and it was argued that we did not want to write form:
>
> std::string GetString();
>
> in order to prevent the extra copy of the temporary that is the return
> value.

No, that was just some incompetent's advice.

Before optimizing, MEASURE.

Determine if any optimization is needed.

For optimization nearly always comes at some cost, such as the added
complexity of the purely procedural notation (it requires extra
variables, more statements, otherwise needless initializations, and so
on, and on).

After optimization, MEASURE: check if it actually improved things.

In C++03, where this advice could be made to sound plausible, you would
probably have found that the advice was plain wrong, due to factors such
as Return Value Optimization (in general) and COW strings (in g++).

> With the introduction of Move Semantics, is this still the case?

It was never the case, and it's even less the case now; all the standard
library containers are movable. :)


Cheers & hth.,

- Alf

[Daniel]

Copy elision - a compiler optimization that eliminates unnecessary copying of objects - took care of that long before C++11.

Daniel

[Christopher J. Pisz]

Well, sure, I have argued that the compiler will optimize it away, but
then there has been at least one peer who would argue to the death that
we should not depend on compiler optimizations in the way we code any
more than one would argue to not release memory "because Windows will
clean it up after the process exits"

Seemed like a good enough argument, at least a time. Better safe then
sorry after all.

When do you reckon we could say that all compilers optimized it away?
somewhere around 2000?

[Juha Nieminen]

Christopher J. Pisz <cp...@austin.rr.com> wrote:
> and it was argued that we did not want to write form:
>
> std::string GetString();
>
> in order to prevent the extra copy of the temporary that is the return
> value.

AFAIK C++17 will enforce return value optimization for this (something
that most/all compilers have been doing anyway, for like forever).

Return value optimization works even for classes without move semantics.