[Issue 6581] Yet another dtor/postblit problem?

[d-bugmail at puremagic.com]

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



--- Comment #7 from Kenji Hara <k.hara.pg at gmail.com> 2011-09-20 13:39:38 PDT ---
(In reply to comment #6)
> Example:
> ubyte[B.sizeof] mem=void;
> emplace!B(mem.ptr);//Does this call to B's constructor call A's dtor on some
> kind of trash then?

void main()
{
    ubyte[B.sizeof] mem=void;
    emplace!B(cast(void[])mem[]);
    writefln("%s %s %s", A.ctor, A.post, A.dtor);//prints 0 0 1
    writefln("%s %s %s", B.ctor, B.post, B.dtor);//prints 0 0 1
    // emplace calls A's ctor through calling B's ctor.
}

> And that's a problem. I mean even when emplace is working and all. Do we really
> want everybody to write emplace(&a, dummy); to do initialization in
> constructor?
> Seems very backwards.
> I'd hate it if this will be some kind of rule #22 of how to do things correctly
> in D.

I think the cases that actually needs emplace is rare.
In most cases, it is rare that T.init has a meaningful state. (In this context,
'meaningful' means calling destructor against T.init occurs something.)


> 
> 
> > 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.
> 
> Ok, glad it works this way.

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