http://d.puremagic.com/issues/show_bug.cgi?id=6581
--- Comment #7 from Kenji Hara <[email protected]> 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: -------
