From: Robert Zeh (razeh_at_[hidden])
Date: 2004-12-02 18:05:16
Doug Gregor <dgregor_at_[hidden]> writes:
> > 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
[ 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk