Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-01-25 07:02:59

From: "Aleksey Gurtovoy" <alexy_at_[hidden]>
> While the standard doesn't require function objects to be assignable, it's
> common (and reasonable) assumption that if you can copy-construct function
> object, you can copy-assign it as well. In fact, "assignable" is a key
> requirement for a function object that is intended to be used with "smart"
> iterators, such filtering iterator adaptor provided by the
> 'boost::iterator_adaptor' library. Apparently, function objects
> (internally) by 'boost::bind' library are exactly that [strange :] -
> copyable, but not assignable,

The function object returned by bind(f, a1, a2, ..., aN) stores copies of f,
a1, ..., aN, and therefore can not guarantee assignability. It can be made
Assignable provided that f, a1, ..., aN are Assignable, of course; I decided
against doing this to prevent users from assuming that bind_t is Assignable.
I did not see anything wrong with that since I haven't been able to come up
with an example where a function object needs to be Assignable, as in:

> - so, for example, writing something like
> this:
> boost::make_filter_iterator(
> views.begin()
> , views.end()
> , boost::bind<bool>(std::logical_and<bool>()
> , boost::bind(&view::is_visible, _1)
> , boost::bind(&view::contains, _1, point)
> ) // the predicate is not assignable
> )
> is pretty much useless, as the expression returns an iterator object that
> not assignable - i.e. something that is not an iterator at all, at least
> the one that you can use with the standard library algorithms.

This is an interesting example. The filter iterator stores a copy of the
function object.

What immediately comes to mind is, isn't it possible to make the iterator
hold a shared_ptr<Predicate> instead? This solves the Assignable problem
and, in general, refcounting the function object is better in cases where
it's stateful.

> As for 'boost::reference_wrapper<>', here is a proposed modification to
> it meet Assignable requirement (rather simple one, I admit :):

I don't know. ref() is supposed to model a reference, and references aren't
reseatable; but, OTOH, I don't have any solid technical (as opposed to
conceptual) argument against the change.

Boost list run by bdawes at, gregod at, cpdaniel at, john at