It's not a problem of references to the Object, but to resources the object
might acquire.  Suppose for a
moment that the object is being used for database connections.  Databases only
support a limited
number of connections at a time, so it's important for me to know for certain
that the connection held
by the first object has been released by the time the second object is created.
Provided I release the
connection in the destructor, I need to know if it is guaranteed to be run
before the second object is
created.  It sounds like this is true, but it was also a possibility that the
object was just marked as
delete-able and then it waited for the next GC sweep, and in my example this
would not be equivalent.

Owen

In article <c4e5m3$13nb$1@digitaldaemon.com>, Stewart Gordon says...
>
>resistor@mac.com wrote:
>
>> Mark it as destruct-able and wait for the next GC sweep...
><snip top of upside-down reply>
>
>That's done by removing all references to it.  If delete merely did that, then in your example it would have no effect at all, assuming of course that your constructor and doStuffAndAcquireUniqueResources don't create references to the object that may still be reachable from elsewhere.
>
>The purpose of GC is to determine what's reachable and what isn't, and destruct and deallocate what isn't.  If it also served as somewhere to postpone explicit destruction, it would be a pointless complexity IMO.
>
>If you use delete, you're supposed to know what you're doing, i.e. that there are definitely no further references to the object elsewhere.  In which case it will be picked up by the GC anyway.  That's the whole point of GC.
>
>Stewart.
>
>-- 
>My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

The garbage collector is simply a memory management tool - it doesn't do things like actively break connections (though if open, they probably will crash after the GC has been by if there were no external memory references).  If you need to do so, write your own delete and do your other resource disconnects there - if called explicitly the delete will be run when called (doing its thing) and then the associated memory is marked for the GC to pick up on its next pass. "Garbage collection kicks in only when memory gets tight. When memory is not tight, the program runs at full speed and does not spend any time freeing memory."(Dspec)  If not called explicitly, the GC will eventually do it when appropriate, or if you make the class auto, the delete will run when the instance is goes out of scope.

Enough?

In article <c4f06s$2dvk$1@digitaldaemon.com>, resistor@mac.com says...
>
>It's not a problem of references to the Object, but to resources the object
>might acquire.  Suppose for a
>moment that the object is being used for database connections.  Databases only
>support a limited
>number of connections at a time, so it's important for me to know for certain
>that the connection held
>by the first object has been released by the time the second object is created.
>Provided I release the
>connection in the destructor, I need to know if it is guaranteed to be run
>before the second object is
>created.  It sounds like this is true, but it was also a possibility that the
>object was just marked as
>delete-able and then it waited for the next GC sweep, and in my example this
>would not be equivalent.
>
>Owen
>
>In article <c4e5m3$13nb$1@digitaldaemon.com>, Stewart Gordon says...
>>
>>resistor@mac.com wrote:
>>
>>> Mark it as destruct-able and wait for the next GC sweep...
>><snip top of upside-down reply>
>>
>>That's done by removing all references to it.  If delete merely did that, then in your example it would have no effect at all, assuming of course that your constructor and doStuffAndAcquireUniqueResources don't create references to the object that may still be reachable from elsewhere.
>>
>>The purpose of GC is to determine what's reachable and what isn't, and destruct and deallocate what isn't.  If it also served as somewhere to postpone explicit destruction, it would be a pointless complexity IMO.
>>
>>If you use delete, you're supposed to know what you're doing, i.e. that there are definitely no further references to the object elsewhere.  In which case it will be picked up by the GC anyway.  That's the whole point of GC.
>>
>>Stewart.
>>
>>-- 
>>My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.
>
>

It'd be easier just to try it out <g>

Explicitly invoking delete on an object does indeed invoke the destructor at that point in time.

On a related note; some languages (including Java) do not guarantee the destructor will *ever* be invoked. D is not like that, and the tradeoff is this: if you have several million live objects when your program exits, there will be several million destructor calls. I don't think this is optimized in any way (for classes without an explicit destructor) ... but is it even worth bothering about?

- Kris


<resistor@mac.com> wrote in message news:c4c3o8$rg4$1@digitaldaemon.com...
> Actually, I meant is it possible to guarantee the destruction of an object
at a
> specific time.  Example
>
> Thing t = new Thing();
> t.doStuffAndAcquireUniqueResources();
> delete t;
> t = new Thing();
>
> Is there any way to guarantee that t has been destructed by the time the
new t
> is created, or does the delete not take effect until the next GC sweep
comes
> around?
>
> Owen
>
> In article <c4adg9$14g1$1@digitaldaemon.com>, larry cowan says...
> >
> >In article <opr5nagnd5ehmtou@localhost>, C says...
> >>
> >>I think he means knowing when the destructor will get called, in which =
> >>
> >>case if you
> >>
> >>auto MyClass x =3D new MyClass;
> >>
> >>it will allocate it on the stack and your destructor is guaranteed to =
> >>
> >>called when leaving scope.
> >>
> >>C
> >>
> >.. But if he means that he wants to force a destruct to return the space immediately, then he will have to use C's malloc/calloc/free as "extern
C", and
> >even then it will not go back to the system at large until the program terminates - it stays as part of the process space.  We have discussed
this
> >before.
> >Current garbage collection doesn't return the space to the OS, and even
with
> >"auto" it waits until the next GC cycle - partly an operating system
thing, but
> >if the pages stay unreferenced they will page out and no real memory will
be in
> >use - only page file size is required.  For small real operating systems
without
> >virtual memory, the problem has not yet been dealt with, but there the
operating
> >system should support a different garbage collector and deal with
malloc/free
> >differently.
> >
> >>On Mon, 29 Mar 2004 22:06:09 +0100, Lars Ivar Igesund =
> >>
> >><larsivar@igesund.net> wrote:
> >>
> >>> resistor@mac.com wrote:
> >>>
> >>>> Do I remember hearing something around here about D supporting =
> >>
> >>>> deterministic
> >>>> destruction?  If so, could someone point me somewhere to find more =
> >>
> >>>> information
> >>>> about it?
> >>>>
> >>>> Thanks, Owen
> >>>>
> >>>>
> >>>
> >>> Do you mean 'Explicit Class Instance Allocation'?
> >>> Look at the Memory Management page of the docs. You can make your
> >>> own new and delete functions.
> >>>
> >>> Lars Ivar Igesund
> >>
> >>
> >>
> >>-- =
> >>
> >>D Newsgroup.
> >
> >
>
>

>Explicitly invoking delete on an object does indeed invoke the destructor at that point in time.
>
>On a related note; some languages (including Java) do not guarantee the destructor will *ever* be invoked. D is not like that, and the tradeoff is this: if you have several million live objects when your program exits, there will be several million destructor calls. I don't think this is optimized in any way (for classes without an explicit destructor) ... but is it even worth bothering about?

That's exactly what I was asking.  Thanks.

I am aware that both Java and C# cannot make that guarantee, but I am pleased to
know that D does.
Like I said, when the object is holding a critical resource (like a database
connection), it is important to
be able to guarantee that the destructor is being called when I think it is.
You're right that I could just
make an example for it, but that would not have told me if it was a language
feature or an
implementation detail.

Owen

If you need deterministic release of resources, make the class an auto class, and D will RAII it for you.

"larry cowan" <larry_member@pathlink.com> wrote in message news:c4f1lv$2gap$1@digitaldaemon.com...
> The garbage collector is simply a memory management tool - it doesn't do
things
> like actively break connections (though if open, they probably will crash
after
> the GC has been by if there were no external memory references).  If you
need to
> do so, write your own delete and do your other resource disconnects
there - if
> called explicitly the delete will be run when called (doing its thing) and
then
> the associated memory is marked for the GC to pick up on its next pass. "Garbage collection kicks in only when memory gets tight. When memory is
not
> tight, the program runs at full speed and does not spend any time freeing memory."(Dspec)  If not called explicitly, the GC will eventually do it
when
> appropriate, or if you make the class auto, the delete will run when the instance is goes out of scope.
>
> Enough?
>
> In article <c4f06s$2dvk$1@digitaldaemon.com>, resistor@mac.com says...
> >
> >It's not a problem of references to the Object, but to resources the
object
> >might acquire.  Suppose for a
> >moment that the object is being used for database connections.  Databases
only
> >support a limited
> >number of connections at a time, so it's important for me to know for
certain
> >that the connection held
> >by the first object has been released by the time the second object is
created.
> >Provided I release the
> >connection in the destructor, I need to know if it is guaranteed to be
run
> >before the second object is
> >created.  It sounds like this is true, but it was also a possibility that
the
> >object was just marked as
> >delete-able and then it waited for the next GC sweep, and in my example
this
> >would not be equivalent.
> >
> >Owen
> >
> >In article <c4e5m3$13nb$1@digitaldaemon.com>, Stewart Gordon says...
> >>
> >>resistor@mac.com wrote:
> >>
> >>> Mark it as destruct-able and wait for the next GC sweep...
> >><snip top of upside-down reply>
> >>
> >>That's done by removing all references to it.  If delete merely did that, then in your example it would have no effect at all, assuming of course that your constructor and doStuffAndAcquireUniqueResources don't create references to the object that may still be reachable from
elsewhere.
> >>
> >>The purpose of GC is to determine what's reachable and what isn't, and destruct and deallocate what isn't.  If it also served as somewhere to postpone explicit destruction, it would be a pointless complexity IMO.
> >>
> >>If you use delete, you're supposed to know what you're doing, i.e. that there are definitely no further references to the object elsewhere.  In which case it will be picked up by the GC anyway.  That's the whole point of GC.
> >>
> >>Stewart.
> >>
> >>-- 
> >>My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.
> >
> >
>
>

Matthew wrote:
> If you need deterministic release of resources, make the class an auto
> class, and D will RAII it for you.
<snip>

You don't need to make the class auto.  You just need to declare object references as auto.  Which you'll need to do anyway if you make the class auto.

Of course, if you want to make sure that the class uses RAII wherever it's used, _then_ you'd declare the class auto.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on on the 'group where everyone may benefit.