[boost] Re: [signals] Performance

From: Robert Zeh (razeh_at_[hidden])
Date: 2004-12-02 18:05:16

Doug Gregor <dgregor_at_[hidden]> writes:
> [snipped]
> 
> > doesn'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>.

[ snip ]

First let me mention that optional<R> is really cool.  I had never
really looked at it before today.

Let me see if I have the basic ideas down for the changes to
slot_call_iterator and signal's operator().

1) Modify slot_call_iterator's constructor to take an additional
   argument, which is a pointer to an optional<R> that it uses to
   cache the value of the slot call.  The slot_call_iterator will only
   use the optional<R> pointer; it will never delete it.

2) Have signal's operator() provide the pointer that
   slot_call_iterator's constructor now requires.  The pointer will be
   to a stack allocated optional<R>.

Wouldn't this create a slot_call_iterator that was fragile?  Copies of
the slot_call_iterator would be share the optional<R> pointer, which
could lead to really interesting results.  The slot_call_iterator's
lifetime would have to be within the optional<R> pointer's lifetime or
the slot_call_iterator would be accessing an invalid pointer.

Robert Zeh