Destructor semantics
foobar
foo at bar.com
Tue Aug 10 14:23:39 PDT 2010
Steven Schveighoffer Wrote:
> On Tue, 10 Aug 2010 16:33:08 -0400, foo <foo at bar.com> wrote:
>
> > In light on recent discussions of clear() and the distructor it seems to
> > me that we are going backwards from one of D's great improvements over
> > C++ - the difference in semantics between structs and classes.
> >
> > IMO, instead of enhancing class desteructors they should be completely
> > removed and only allowed on structs with deterministic semantics and all
> > uses cases of class desteructors should be replaced with structs.
> > Examples:
> > class SocketConnection : Connection {
> > // struct instance allocated inline
> > SocketHandle handle;
> > ...
> > }
> >
> > OR:
> >
> > class SocketConnection : Connection {
> > struct {
> > this() { acquireHandle(); }
> > ~this() { releaseHandle(); }
> > } handle;
> > ...
> > }
> >
> > The suggested semantics of the above code would be that creating a
> > SocketConnection object would also construct a SocketHandle as part of
> > the object's memory and in turn that would call the struct's ctor.
> > On destruction of the object, the struct member would be also destructed
> > and it's d-tor is called. This is safe since the struct is part of the
> > same memory as the object.
> >
> > in short, struct instances should be treated just like built-in types.
> >
>
> That doesn't help. deterministic destruction is not a struct-vs-class
> problem, its a GC-vs-manual-memory problem. A struct on the heap that is
> finalized by the GC has the same issues as a class destructor. In fact,
> struct destructors are not currently called when they are heap-allocated
> because the GC has no idea what is stored in those memory locations.
>
> -Steve
Let me add to the above, that the GC should NOT manage structs allocated on the heap. structs should only provide deterministic semantics.
More information about the Digitalmars-d
mailing list