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:
>> 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
> 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
> I ask because I'm trying
> to avoid any heap allocation, which I think of as slow.
Right, and this does avoid heap allocation.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk