View mode: basic / threaded / horizontal-split · Log in · Help
September 14, 2005
Re: dcouple [was: Another event handling module]
"Bastiaan Veelo" <Bastiaan.N.Veelo@ntnu.no> wrote in message 
news:dg8nsc$f9l$1@digitaldaemon.com...
> Ben Hinkle wrote:
>>>#  ~this()
>>>#  {
>>>#    deleteSignals();
>>>#    deleteSlots();
>>>#  }
>>
>>
>> Does deleteSignals and deleteSlots reference other GC-managed objects or 
>> arrays?
>
> Yes, but only to objects (Signals and Slots) that know about each other 
> and about their managers (the ones calling deleteSignals and/or 
> deleteSlots). In their destructor they deregister themselves with these 
> referencing objects. So at the time of destruction, only references exist 
> to objects that have not been destructed yet. Therefore, the order of 
> destruction does not matter.

Ok, though note the dynamic array used to store the data is also GC-managed 
and has no destructor.

>
> Bastiaan.
September 14, 2005
Re: dcouple [was: Another event handling module]
"Bastiaan Veelo" <Bastiaan.N.Veelo@ntnu.no> wrote in message 
news:dg8nsc$f9l$1@digitaldaemon.com...
> Ben Hinkle wrote:
>>>#  ~this()
>>>#  {
>>>#    deleteSignals();
>>>#    deleteSlots();
>>>#  }
>>
>>
>> Does deleteSignals and deleteSlots reference other GC-managed objects or 
>> arrays?
>
> Yes, but only to objects (Signals and Slots) that know about each other 
> and about their managers (the ones calling deleteSignals and/or 
> deleteSlots). In their destructor they deregister themselves with these 
> referencing objects. So at the time of destruction, only references exist 
> to objects that have not been destructed yet. Therefore, the order of 
> destruction does not matter.
>
> Bastiaan.

I should add that if all the objects have references to one another then if 
one of the objects is garbage they are all. So having destructors that 
remove the connection is only useful when someone explicitly calls delete on 
an object still connected.
September 15, 2005
Re: dcouple [was: Another event handling module]
Ben Hinkle wrote:

> Ok, though note the dynamic array used to store the data is also GC-managed 
> and has no destructor.

Hm. Thanks for pointing that out. I have not been bitten by that fact 
yet, could it be that objects do get collected before arrays in the 
current implementation of the garbage collector?

What do you think would be the best defence, a linked list using malloc 
and free?

Dcouple is kind of a study for me, I am not sure yet whether it is 
better/nicer to explicitly delete an object or to disconnect all its 
connections (e.g. by means of a "discard" method) and let the GC take 
care of it. I am mainly thinking GUI programming here.
September 15, 2005
Re: dcouple [was: Another event handling module]
Ben Hinkle wrote:

>>Yes, but only to objects (Signals and Slots) that know about each other 
>>and about their managers (the ones calling deleteSignals and/or 
>>deleteSlots). In their destructor they deregister themselves with these 
>>referencing objects. So at the time of destruction, only references exist 
>>to objects that have not been destructed yet. Therefore, the order of 
>>destruction does not matter.
>>
>>Bastiaan.
> 
> 
> I should add that if all the objects have references to one another then if 
> one of the objects is garbage they are all. So having destructors that 
> remove the connection is only useful when someone explicitly calls delete on 
> an object still connected. 

Yes. So in this case calling delete Object or Object.discard() is 
somewhat equivalent (where discard() is a method that disconnects all 
signals and slots of Object). The former is immediate and familiar to 
C++ programmers, the latter is delayed and a bit special.

Bastiaan.
September 15, 2005
Re: dcouple [was: Another event handling module]
On Thu, 15 Sep 2005 17:12:06 +0200, Bastiaan Veelo  
<Bastiaan.N.Veelo@ntnu.no> wrote:

> Dcouple is kind of a study for me, I am not sure yet whether it is  
> better/nicer to explicitly delete an object or to disconnect all its  
> connections (e.g. by means of a "discard" method) and let the GC take  
> care of it. I am mainly thinking GUI programming here.


Very good question. I often consider this problem by myself. "Dereference  
and forget" vs. "explicity delete". Any thoughts about this matter, anyone?
-- 
Dawid Ciężarkiewicz
September 16, 2005
Re: dcouple [was: Another event handling module]
Indigo also contains a signals&slots implementation. It is partly  
malloc-based to avoid GC problems, and very simple to use (without signal  
managers and other complexity classes). You can have a look at it at:

http://www.uwesalomon.de/code/indigo/files/core/cmdtarget-d.html#Signals_and_slots

Ciao
uwe
September 16, 2005
Indogo [was: dcouple [was: Another event handling module]]
Uwe Salomon wrote:
> Indigo also contains a signals&slots implementation. It is partly  
> malloc-based to avoid GC problems, and very simple to use (without 
> signal  managers and other complexity classes). You can have a look at 
> it at:
> 
> http://www.uwesalomon.de/code/indigo/files/core/cmdtarget-d.html#Signals_and_slots 
> 
> 
> Ciao
> uwe

Nice work. I like the ability to connect partly compatible signals and 
slots.

From the documentation:
> Connections between objects will not detain the garbage collector from
> recycling them if they are not referenced otherwise.

Cool! I will have a closer look.

Bastiaan.
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home