On Dec 2, 2004, at 1:21 PM, Robert Zeh wrote:
Doug Gregor <dgregor@cs.indiana.edu> 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