From: Alf P. Steinbach on
* Ben Voigt [C++ MVP]:
>> As already shown else-thread, no, writing = for == can be detected at
>> compile time in other ways, the most effective and (IMHO) least ugly
>> to make '=' for assignment invalid. That it's possible does not mean
>> it's a good idea, because the problem it means to avoid is
>> insignificant and will be detected anyway if it occurs, and the
>> solution has associated costs, namely non-conventional notation,
>> reducing readability and clarity. Just as it isn't a good idea, in
>> general, to make rvalues const, because the problem is insignificant
>> and will be detected anyway, e.g. through testing or via compiler
>> warnings, and the solution has associated costs, in particular
>> prohibiting an important possible optimization.
>
> I'm still going to trust Scott Meyers on this one, especially because he
> recommends the const r-values *in a discussion on RVO*:
> http://groups.google.com/group/comp.lang.c++.moderated/msg/e60d78d50da3f841

RVO is just loosely associated with the earlier discussion in this thread.

const result or not has, as far as I know, no impact on RVO.

Happily Scott Meyers did not advocate const r-values on the basis of efficiency.
He advocated it on the basis of what felt most natural to him. He's made
some fundamental errors in his books (e.g., as I recall, stating that the
compiler would generate operator& for you if you didn't define it), but
confusion about const impact on RVO is, as far as I know, not one of them.


Cheers, & hth.,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
From: Ben Voigt [C++ MVP] on
Alf P. Steinbach wrote:
> * Ben Voigt [C++ MVP]:
>>> As already shown else-thread, no, writing = for == can be detected
>>> at compile time in other ways, the most effective and (IMHO) least
>>> ugly to make '=' for assignment invalid. That it's possible does
>>> not mean it's a good idea, because the problem it means to avoid is
>>> insignificant and will be detected anyway if it occurs, and the
>>> solution has associated costs, namely non-conventional notation,
>>> reducing readability and clarity. Just as it isn't a good idea, in
>>> general, to make rvalues const, because the problem is insignificant
>>> and will be detected anyway, e.g. through testing or via compiler
>>> warnings, and the solution has associated costs, in particular
>>> prohibiting an important possible optimization.
>>
>> I'm still going to trust Scott Meyers on this one, especially
>> because he recommends the const r-values *in a discussion on RVO*:
>> http://groups.google.com/group/comp.lang.c++.moderated/msg/e60d78d50da3f841
>
> RVO is just loosely associated with the earlier discussion in this
> thread.
> const result or not has, as far as I know, no impact on RVO.

Then what "important possible optimization" were you referring to? I'm
lost.

>
> Happily Scott Meyers did not advocate const r-values on the basis of
> efficiency. He advocated it on the basis of what felt most natural
> to him. He's made some fundamental errors in his books (e.g., as I
> recall, stating that
> the compiler would generate operator& for you if you didn't define
> it), but confusion about const impact on RVO is, as far as I know,
> not one of them.
>
> Cheers, & hth.,
>
> - Alf


From: Alf P. Steinbach on
* Ben Voigt [C++ MVP]:
> Alf P. Steinbach wrote:
>> const result or not has, as far as I know, no impact on RVO.
>
> Then what "important possible optimization" were you referring to? I'm
> lost.

Earlier in this thread, then giving URL to yet earlier reference, <url:
http://groups.google.com/group/microsoft.public.vc.language/msg/7209f10e7eece7d4>.

Just for clarity, this refers to what you the programmer can do, confined by the
rules of the language wrt. const and other things, whereas RVO is an
optimization applied by the compiler, which can do just about anything as long
as it's within the "as if" rule (and the standard explicitly gives it permission
to e.g. remove side-effects from copy constructors in some optimizations).

For the compiler, a little const on a temporary in the middle of a copy chain
that it's going to optimize away, doesn't matter: hey, it's optimized away,
anyway. It's not there, as far as the compiler's optimization circuits are
concerned. For the programmer doing similar optimization where the language
rules apply and must be followed at each step, the const is a showstopper.


Cheers, & hth.,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?