Boost logo

Boost :

From: Robert Zeh (razeh_at_[hidden])
Date: 2004-12-02 13:21:27


Doug Gregor <dgregor_at_[hidden]> 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.

> We could do it at compile time using some combination of type traits,
> probably. Unfortunately, those that come to
> mind--is_default_constructible and is_assignable--don't give us all
> the information we need, because iterators will return "true" for both
> but will have the wrong behavior. We would need to introduce a new
> trait for this.
>
> Actually, there is one other corner case that's really ugly. The
> combiner could theoretically do something like this:
>
> template<typename InputIterator>
> result_type operator()(InputIterator first, InputIterator last)
> {
> while (first != last) {
> InputIterator annoying = first;
> *first;
> if (*annoying) /* ... */
> }
> }
>
> I *think* that's valid code according to the Input Iterator
> requirements (but not 100% sure!), and without the pointer "*annoying"
> would call the slot again...
>
> Oh, I know a solution now... we stick an "optional<R> slot_result"
> into the signal's operator() and keep a pointer to that variable in
> the slot_call_iterator. The optional<R> has nearly the same effect as
> the cache interface you mentioned, but it doesn't require
> default-constructibility; storing a pointer to it ensures that
> slot_iterator copies are fast and that all slot_iterators see the
> updates (for those truly pathological combiners).

Doesn't the optional<R> value have to be allocated on the heap when a
slot_call_iterator is created, and doesn't it have to be a shared_ptr
so that the copy semantics will be correct? I ask because I'm trying
to avoid any heap allocation, which I think of as slow.

Robert


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk