Signals and Slots

[Sean Kelly]

Walter Bright wrote:
> Sean Kelly wrote:
>> Walter Bright wrote:
>>> http://www.digitalmars.com/d/std_signals.html
>>>
>>> And that, hopefully, is that.
>>
>> Nice work!  In skimming the code, one thing jumped out at me:
>>
>> signals.d:171: len += len + 4;
>>
>> I think this should be: len += 4;
>>
>> Or actually: len += (void*).sizeof;
> 
> No, that is as intended. It's using a power of 2 allocation method.

Okay, now I'm confused.  Here's the pertinent bit of code, edited for 
clarity:

     auto len = slots.length;
     auto startlen = len;

     len += len + 4;
     auto p = std.c.stdlib.realloc(slots.ptr, slot_t.sizeof * len);
     slots = (cast(slot_t*)p)[0 .. len];
     slots[startlen] = slot;

This looks like the allocated buffer will never be more than half full, 
because a reallocation of size len * 2 occurs every time connect is 
called.  This should give buffer sizes of: 4, 8, 20, 44, 92, etc, with 
the new element added at 0, 4, 8, 20, and 44, respectively.  In fact, it 
seems the buffer density will decrease over time because the space 
between elements doubles every insertion?  Hrm, perhaps this line:

     slots = (cast(slot_t*)p)[0 .. len];

should be more like this:

     slots = (cast(slot_t*)p)[0 .. startlen + 1];

so the next call to slots.length isn't aware of the unused space?

>> To be 64-bit safe.  Finally, is there any reason to use _d_toObject in 
>> this code instead of cast(Object)?  I'd think they would do the same 
>> thing?
> 
> Not exactly. cast(Object)p won't do the pointer adjustment if the type 
> of p is a void*. To convert an interface to its underlying Object, the 
> cast implementation needs to know what the interface type is.

Oh I see, so this is because p can be an interface as well.  Thanks.


Sean