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
a
> 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
constructed
> (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
is
> not assignable - i.e. something that is not an iterator at all, at least
not
> 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
make
> 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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk