DConf 2013 Day 1 Talk 2 (Copy and Move Semantics)

[Ali Çehreli]

On 05/10/2013 10:03 PM, H. S. Teoh wrote:

 > I have to thank Ali

Thank you, it's very kind of you.

 > - The bit about swapping of structs when assigning a function's return
 >    value. Makes a lot of sense semantically! Though it does bear looking
 >    into for further optimizations.

deadalnix mentioned the same thing: Instead of bit-swapping, it is 
possible to destroy the old state first and then bit-move from the 
rvalue. I am pretty sure that is how it is done by the compiler. Still, 
I find it easier to think about in terms of bit-swapping.

 > What about in-place construction if a
 >    struct is known to be returned to the caller, so that even the move is
 >    elided?

I think that is the RVO and the NRVO optimization, which is not possible 
in every case. For example, if I am not mistaken, it is not possible if 
the fonction returns one of two possible values conditionally (e.g. by 
the ternary operator).

 > - The bit about exception-safe ctors: awesome!! Yet another thing D gets
 >    right, that blows up in C++.

(Correction: exception-safe _assignment_).

As far as I know, I am one of the few who point out the glaring 
exception-unsafe behavior of the assignment operator of C++.

Every C++ programmer knows about "the rule of the big three" (ctor, 
dtor, assignment) but nobody talks about "the rule of the big one". 
(assignment) :) For strongly exception-safe assignment, one must always 
define the assignment operator. (Well, for types that have multiple 
members and that the ones after the first one may throw. (It is ok if 
the first one throws; then there would be no partial assignment.))

 > - The idiom of using this(S that) vs. this(ref const(S) that) for
 >    move/copy: another awesome idiom that should be documented in a
 >    prominent place so that more people are aware of it.

Actually that one is well documented in TDPL.

Ali