[Issue 6581] Yet another dtor/postblit problem?

[d-bugmail at puremagic.com]

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


Dmitry Olshansky <dmitry.olsh at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


--- Comment #9 from Dmitry Olshansky <dmitry.olsh at gmail.com> 2011-09-20 14:05:32 PDT ---
(In reply to comment #8)
> Sorry, that was imcomplete.
> 
> (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.
> }
> 

This doesn't call constructor at all it copies B.init over mem, this one will
do:

void main()
{
    ubyte[B.sizeof] mem=void;
    emplace!B(cast(void[])mem[], 33);
    writefln("%s %s %s", A.ctor, A.post, A.dtor);//prints 1 0 2
    writefln("%s %s %s", B.ctor, B.post, B.dtor);//prints 1 0 1
}
The interesting moment is that emplace first does overwrite memory with T.init
so it seems like there is no way to call constructor on a raw memory. (at least
 not untill you use __ctor on your own risk)

> > 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 does
> something.
> e.g. reference counter == 0, class reference == null, ...)
> 
> Therefore, destructor calling with assignment against T.init like `a =
> A(dummy)` does not make problems usually.

Yes, but I was thinking about cases where destructor could be called on raw
memory causes things like: free(some_random_address); 
I just was investigating a crush and the cause looked like memory freed two
times in two calls to destructor, looks like I'm off on this one, though.
I'm closing it.

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