> 
> It's not *that* bad!
> To me, 99% of the time I do not really care exactly when
> the destructor on an object is called, as long as it does
> get called eventually. For the 1 percent of the situations
> where a timely call of the destructor really is necessary,
> you can call delete manually (as you already are forced to
> do in Delphi).
> 
> But how about this for a solution. COM uses a kind of
> reference counting. IUnknown already has methods AddRef()
> and Release() to accomodate this. Delphi implements a
> kind of syntax sugar where these functions get called for
> you automatically, whenever an object enters or exits
> scope. Combining these you could make stack-like objects
> that free themselves automatically whenever the last
> reference to it exits scope. It has the price of a
> function call when the objects enters or exits scope,
> but that is a small price to pay and should be a
> consideration. I don't know how difficult this kind
> of syntax sugar is to implement, but it could solve
> at least part of the problem.
> 

but then you're tied to a platform.

> 
> --
> Stijn
> OddesE_XYZ@hotmail.com
> http://OddesE.cjb.net
> _________________________________________________
> Remove _XYZ from my address when replying by mail
> 
> 
> 

"andy" <acoliver@apache.org> wrote in message news:3CF52268.3040008@apache.org...

> > But how about this for a solution. COM uses a kind of
> > reference counting. IUnknown already has methods AddRef()
> > and Release() to accomodate this. Delphi implements a
> > kind of syntax sugar where these functions get called for
> > you automatically, whenever an object enters or exits
> > scope. Combining these you could make stack-like objects
> > that free themselves automatically whenever the last
> > reference to it exits scope. It has the price of a
> > function call when the objects enters or exits scope,
> > but that is a small price to pay and should be a
> > consideration. I don't know how difficult this kind
> > of syntax sugar is to implement, but it could solve
> > at least part of the problem.
> >
>
> but then you're tied to a platform.

Not really. AddRef() and Release() are easily implemented anywhere...

... but then you get a reference-counting based garbage collector, as seen in VB, with all its problems like cyclic interdependencies...

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CF4E83B.80BDA02E@deming-os.org...
> Matthew Wilson wrote:

<snip>

> I agree that this is unfortunate.  How would you suggest we fix it?

<snip>


I'd suggest being able to turn the garbage collector on and off. When it is off, it would be in a danger mode and all removal would have to be done manaually. Debug mode could still use the GC to detect memory leaks (though that should also be able to be turned off). Ie it could be turn off during unnecessary GC's reads between a frame loop, or if part of the program definately doesn't need it.

It also be good if it had to modes,  deterministic and non-dertimistic (default). Deterministic would be for advanced programmers and implemented in the optimisation programming cycle.

Also you should be able to give the GC an estimate of aprox howmuch memory is needed to be freed at any one time or how long it is to run for. The GC would stop when goes past this amount.  Programmers could then tweek this to the applications needs.

"anderson" <anderson@firestar.com.au> wrote in message news:ad5bo2$1i9q$1@digitaldaemon.com...

> I'd suggest being able to turn the garbage collector on and off. When it
is
> off, it would be in a danger mode and all removal would have to be done

It is possible to turn off garbage collector. I don't remember the exact function, just look for it in gc.d.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:ad5kch$etn$1@digitaldaemon.com...
> "anderson" <anderson@firestar.com.au> wrote in message news:ad5bo2$1i9q$1@digitaldaemon.com...


> It is possible to turn off garbage collector. I don't remember the exact function, just look for it in gc.d.

I guess most of my suggestions are more like questions.

Then why do they say that it's a turn off for C++ programmers. They don't get a GC (deterministic or not) at all and they can program the same way in D.

"anderson" <anderson@firestar.com.au> wrote in message news:ad6sbm$19e4$1@digitaldaemon.com...

> Then why do they say that it's a turn off for C++ programmers. They don't get a GC (deterministic or not) at all and they can program the same way
in
> D.

The problem is, you still don't get automated clean-up. You have to delete all objects yourself. It is deterministic, but it's quite a lot to type.

Me, I don't care much. Just got used to Delphi, I suppose, so, when I need
it,
I don't mind calling "delete"...

Some good thoughts. -Walter

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:ad32t5$11mr$1@digitaldaemon.com...
> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CF4E83B.80BDA02E@deming-os.org...
> > Matthew Wilson wrote:
> >
> > > Agree with the compliments, apart from D's choice to follow Java/.NET
> down
> > > the non-deterministic destructor (or finalize) model. I think this
will
> kill
> > > a lot of interest from C++ people, who's use of "resource aquisition
is
> > > initialisation" is second nature (not to mention being about the most powerful bang-for-buck object-oriented concept).
> >
> > I agree that this is unfortunate.  How would you suggest we fix it?
>
> I also find this to be a large drawback of D.  Unpredictability of finalization sucks.
>
> > The problem, as I see it, is not actually the destructor model, but the
> garbage
> > collector.  It would be horribly inefficient to require the GC to run
> whenever
> > any object or array reference goes out of scope.
>
> some objects the compiler could in theory know are going away at the end
of
> a scope (because their references were never sent anywhere "outside" the
> scope)
>
> > That means that we need some way to signal to the compiler that objects
> need to
> > be cleaned up immediately.  Walter gives us a manual way to do it, by
> calling
> > 'delete' on the object, but we do not yet have a way to do it
> automatically.
>
> Maybe the difference between:
>
> Object x;
>
> and
>
> new Object x;
>
> or
>
> Object x = null;
>
> > As I see it, we have 2 types of class objects that get created:
> >     1) Temporary objects that should be destroyed when the reference
goes
> out of
> > scope.  Essentially, these are stack objects - even if they are not
> actually
> > created on the stack.  We don't have these in D right now.
>
> This is exactly how structs behave though, provided you don't allocate
them
> with new.
> I noticed you can put member functions in a struct, but not ctors/dtors.
If
> we could put ctors/dtors in a struct, we could use struct for these types
of
> "resource acquisition" objects and class for objects we don't care about
as
> much, but that seems like a bandaid not a real fix.
>
> >     2) Longer term objects that will last an arbitrary length of time.
> These
> > are heap objects, and are all objects right now.
>
> Maybe we need an auto keyword.  ;)  auto objects can't have their address taken.
>
> Sean
>
>