Re: [boost] Re: [signals] Performance

From: Doug Gregor (dgregor_at_[hidden])
Date: 2004-12-02 14:19:36

On Dec 2, 2004, at 1:21 PM, Robert Zeh wrote:
> Doug Gregor <dgregor_at_[hidden]> writes:
>
>> ...
>> [snipped]
>>
>> Unfortunately, some of them are pretty important. For instance, if one
>> tried to have a result_type that is an iterator, copying a
>> slot_call_iterator that has not been dereferenced could result in
>> undefined behavior, because the iterator would have been
>> default-constructed and therefore singular. That doesn't make the
>> optimization invalid, of course, but it does limit where we can apply
>> the optimization.
>
> This is just a thought, but I believe this could be fixed by defining
> the caching object so that it only copies the cached value if the
> cache is valid.

You're right, of course; we even do this in the implementation of 
named_slot_map! :)

> oesn't the optional<R> value have to be allocated on the heap when a
> slot_call_iterator is created,

Nope :) optional<R> does the equivalent of storing an R and storing a 
bool, both on the stack, but doesn't actually default-construct the R. 
It uses aligned_storage so that it has the space available within the 
optional<R>, but does an in-place new when you want to copy a value in.

> and doesn't it have to be a shared_ptr
> so that the copy semantics will be correct?

So long as the optional<R> is in the signal's operator(), I think the 
slot_call_iterators can just have a pointer to that optional<R> and 
we'll be okay... incrementing a slot_call_iterator would clear out the 
optional<R>.

>   I ask because I'm trying
> to avoid any heap allocation, which I think of as slow.

Right, and this does avoid heap allocation.

        Doug