Reply to Robert,

> BCS wrote:
> 
>> that only works in most cases where the object only owns memory
>> resources. If it owns files, mutexes, database connections, stock
>> options or Corvettes, your sunk.
>> 
> Really? I have yet to write a finalize() method in Java. IMO, using
> close() methods for non-memory resources and letting the GC clean up
> the memory makes for less cognitive load than worrying about the order
> of destruction, etc., etc.
> 

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().

"Robert Fraser" <fraserofthenight@gmail.com> wrote in message news:fthlbc$1fro$2@digitalmars.com...
> Lionello Lunesu wrote:
>>  It's a good thing I avoid inheritance like
>> the plague lately.
>
> Wouldn't it be better to avoid destructors like the plague instead?

I think there are more problems with inheritance than these "virtual calls in ctor/dtor" : )

I used to be so fond of OOP and its inheritance, but lately I find myself preferring composition and free-functions to "class frameworks".

L. 

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.

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

"Jason House" <jason.james.house@gmail.com> wrote in message news:fthbok$vs8$1@digitalmars.com...
> It should always be considered an error to call a virtual member function in a destructor. Someone should make a bug report for this. I would if I was at a computer and not typing with my thumb...
>

I agree, but this would mean that only final, static and global functions are allowed in ctors/dtors? Would be interesting to add a warning for this, to see how many times it occurs in existing code.

L. 

It's also safe to call private and templated functions.

Private functions, by definition, can't be overloaded. Templated functions are defined to be non-virtual.

Does D have final functions?

Lionello Lunesu Wrote:

> 
> "Jason House" <jason.james.house@gmail.com> wrote in message news:fthbok$vs8$1@digitalmars.com...
> > It should always be considered an error to call a virtual member function in a destructor. Someone should make a bug report for this. I would if I was at a computer and not typing with my thumb...
> >
> 
> I agree, but this would mean that only final, static and global functions are allowed in ctors/dtors? Would be interesting to add a warning for this, to see how many times it occurs in existing code.
> 
> L.
> 

On 10/04/2008, Jason House <jason.james.house@gmail.com> wrote:
>  Private functions, by definition, can't be overloaded.

I suspect you mean "overridden".

Janice Caron Wrote:

> On 10/04/2008, Jason House <jason.james.house@gmail.com> wrote:
> >  Private functions, by definition, can't be overloaded.
> 
> I suspect you mean "overridden".

Yes, sorry.

Jason House wrote:
> Does D have final functions?

Indeed. Using the "final" storage class.