D classes inherane. How it works.

[Kevin Bealer]

Robert Fraser Wrote:

> BCS wrote:
> > My comment was in light of "let the GC handle it". Your suggestion 
> > amounts to manual memory management (s/memory/resource/). That is fine 
> > but to make it work you need to keep track of lifetimes which isn't 
> > letting the GC do it. Personally I'd think the way to handle this kind 
> > of thing would be to try really hard to make order of destruction 
> > irrelevant and let the GC call ~this().
> 
> Fair enough, but designing classes such that the order of destruction is 
> irrelevant is no trivial task.

If the relationship from A to B is clear, then one approach is to use a static
map to store the B objects.  This insures that the ordering is preserved.

class B {
};

class A {
    this()
    {
        data = new B;
        safety_[data] = 1;
    }

    ~this()
    {
        data.close();
        data.cleanup();
        data.flush();
        data.etc();
        safety_.remove(data);
    }

private:
    B data;
    int[B] safety_;
};

This delays the destruction of B for another GC cycle, but maybe
that's not a big deal.  If you know that only A uses B, then you can
probably also delete B from A.~this if you like.

Beware of cycles, this code wasn't compiled, always ski in control, etc.

Kevin