View mode: basic / threaded / horizontal-split · Log in · Help
April 09, 2008
Re: D classes inherane. How it works.
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().
April 09, 2008
Re: D classes inherane. How it works.
"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.
April 09, 2008
Re: D classes inherane. How it works.
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.
April 09, 2008
Re: D classes inherane. How it works.
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
April 10, 2008
Re: D classes inherane. How it works.
"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.
April 10, 2008
Re: D classes inherane. How it works.
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. 
>
April 10, 2008
Re: D classes inherane. How it works.
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".
April 10, 2008
Re: D classes inherane. How it works.
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.
April 10, 2008
Re: D classes inherane. How it works.
Jason House wrote:
> Does D have final functions?

Indeed. Using the "final" storage class.
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home