In article <cin1og$2tuj$1@digitaldaemon.com>, Ben Hinkle says... <snip>
>> It has a remove method, which calls the WinAPI to remove the item from the tree and then deletes this.
> 
> ok.  though I wonder what deleting this does.  Is it needed?

As I said, removes it from the SDWF-side index and recursively does the same to the children.

> Why not just have remove call the Windows API to remove the item?

Because that wouldn't remove it from the SDWF-side index.  OK, so there are other possibilities, and they aren't really doing anything but taking up space in there....

<snip>
> I'm a little lost without more context so I'll try getting your library and poking around sometime.  I can see your point about worrying about efficiency and also trying to use destructors to guarantee removal.

This whole feature is as yet unreleased, but I'd be happy to send you a prototype when I've got one ready.

<snip>
>> I mean, if you have something like
>> 
>>     Qwert yuiop = new Qwert;
>>     delete yuiop;
>>     delete yuiop;
>> 
>> will there necessarily be only one destructor call?
> 
> I'm not sure - or maybe the answer is "it depends".  There might be a problem if another thread jumps in between the two delete calls and allocates a new object right exactly where yuiop is pointing and then the second delete would actually end up deleting that new object (ick!).

Only if delete immediately frees the memory.  But you'd want to think about thread-safety here anyway.

> I don't really know the GC well enough to know if this is possible but off the top of my head I would assume it could happen.  If such threading behavior can't happen in your app then yes the destructor is only called once because the first delete clears a flag that the GC uses to keep track of what needs destroying.
<snip>

Of course, that would depend on how it keeps track of which object is which.  Having memory freed only during GC passes simplifies this considerably.

Stewart.

Ben Hinkle wrote:
<snip>
>>It looks like a discard() method is necessary on objects containing
>>signals and slots, which users must call when they have no use for an
>>object anymore. In C++, they would delete the object at this time. This
>>will be a confusing aspect of my library.
> 
> 
> Why is that confusing? Writing
>  delete foo;
> is not much different than
>  foo.disconnect();
> or
>  foo.discard();
> or whatever the API happens to be.

It is not much different, but when explicitly deleting an object with signals and/or slots can give you problems, I think that is a discomfort and a potential source of frustration.

Anyway, the repository now contains a working approach to delete, I think. Signals, slots and their owning classes (that inherit SignalSlotManager) know about each others health and clean up references to each other in their destructors. Owners delete their signals and slots, but only if not destructed already.

<snip>
> I looked at the module dcouple.signal on dsource and noticed that
> SignalGenericCore's destructor calls disconnect() which loops over the slots
> in _slots and disconnects each one. I would be careful about looping over
> _slots from a destructor since _slots might already have been cleaned up -
> or partially cleaned up.

Ah, somehow I assumed that the non-deterministic finalisation only applied to objects, not for example a D AA, which _slots is. Because an AA does not need to be newed, I thought it would be alive as long as it is in scope, including the destructor. But you are probably right.

It might be possible to use a specially implemented doubly linked list as the container of slots. Elements would remove themselves from the list from within their destructor, pulling the same trick as Signals and Slots do, which mutually disconnect each other when they are destructed. I will end up with densely packed cross-references...


Thanks for the guidance, this is very valuable to me.

Bastiaan.