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

I think using the auto keyword gives it to you.

C

On Mon, 29 Mar 2004 18:08:18 +0000 (UTC), <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
>
>



-- 
D Newsgroup.

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

I think he means knowing when the destructor will get called, in which case if you

auto MyClass x = new MyClass;

it will allocate it on the stack and your destructor is guaranteed to called when leaving scope.

C

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.

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.

> Current garbage collection doesn't return the space to the OS

Nor do C/C++, http://wwwcgi.rdg.ac.uk:8081/cgi-bin/cgiwrap/wsi14/poplog/man/3C/realloc , or non GC systems.

> and even with
> "auto" it waits until the next GC cycle

Hmm , this goes against my understanding, does auto not allocate room on the stack ?  Does anyone have the PDF link for the D manual, i cant find things on the docs without searching every page.


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

Yes, i think the GC is replaceable, so shouldn't be a problem i dont think.

C



On Tue, 30 Mar 2004 00:03:21 +0000 (UTC), larry cowan <larry_member@pathlink.com> wrote:

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



-- 
D Newsgroup.

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

resistor@mac.com wrote:

> 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?
<snip top of upside-down reply>

Of course it destructs there and then.  What else would delete do?

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.

Mark it as destruct-able and wait for the next GC sweep...

Owen

In article <c4c9h8$153b$1@digitaldaemon.com>, Stewart Gordon says...
>
>resistor@mac.com wrote:
>
>> 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?
><snip top of upside-down reply>
>
>Of course it destructs there and then.  What else would delete do?
>
>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.

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.