Doug Gregor <dgregor@cs.indiana.edu> 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