[Issue 6581] Yet another dtor/postblit problem?

d-bugmail at puremagic.com d-bugmail at puremagic.com
Tue Sep 20 08:07:49 PDT 2011


http://d.puremagic.com/issues/show_bug.cgi?id=6581



--- Comment #5 from Kenji Hara <k.hara.pg at gmail.com> 2011-09-20 08:07:19 PDT ---
(In reply to comment #4)
> > Please note this line:
> > >         a = A(dummy); // a(dummy) was a typo, thought it changes nothing
> > 
> > This is "assignment", not initializing.
> > The assignment of an object that has postblit (like A) is implemented *swap and
> > destroy*. 
> 
> Note this line was in constructor. No way to initialize member of a struct?
> That's something I'd call unacceptable.
> 
> I should point out that move == swap & destroy, iff left side of assigment
> _was_ initialized. A constructor may be called on chunk of uninitialized memory
> e.g. in Phobos std.typecons.emplace.

In B's constructor, the member a is already intialized by A.init. So `a =
A(dummy);` is always assignment.

And, yes, I think using emplace is right way to *initialize* member a.

emplace(&a, dummy);  // a is treated as an uninitialized memory

But, unfortunately, emplace has a bug. This does not work as our expected.


> why do we copying the original value in the first place? 
> It should be moved with e.g. memmov

Ah... my explanation had a bit misleading. When opAssign receives rvalue, rhs
is just moved. Otherwise, rhs is coped. In this case, A(dummy) is treated as
rvalue, so it is moved.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------


More information about the Digitalmars-d-bugs mailing list