Boost logo

Boost :

From: Jaakko Jarvi (jajarvi_at_[hidden])
Date: 2002-03-19 10:15:55

> I can contribute another point of view on library design in order to balance
> things. :-)
> When using bind, I sometimes encounter problems that the library doesn't
> address directly. Instead of immediately adding the feature, I look at the
> problem with the eyes of an "ordinary" user that doesn't have access to the
> source, and ask myself: "how can I solve this problem without making changes
> to the library?"

> For example, how can I make the first argument of a bind() expression be
> evaluated? I write a helper apply<> function object. It needs no support
> from bind in order to work.
This you can see from another angle too. Why should the first argument be
treated differently to begin with?

> Or, how can I construct an object? I'd provide a construct<T> function
> object; again, no changes to bind are necessary, it just works.
Gary's examples were not correct. This is what BLL does too.
construct<T> is a function object, as are new_ptr, new_array,
delete_ptr... So the following holds for BLL too:

> I won't be able to say construct<T>() + _1, but bind(construct<T>()) + _1

The things that are not function objects are control constructs,
exception throwing and handling expressions and cast expressions.
There are reasons for this. Control structures require special support
from the library anyway. You can write function objects like:

class throw_exception {
  template <class E>
  void operator()(E& e) { throw e; }

But there's no way to write something like:

class ifthen {
  template<class A, class B>
  void operator()(A& a, B& b)
    if (a()) b();

This functionality has to be in another layer of the library, which is
tricky enough to
not be part of the public interfcafe.
The same goes for exception handling structures.

Cast expressions could be function objects just as well, which is an
alternative to consider. It might be more natural.

> How can I throw an exception from within bind? I can write a throw_exception
> function object.
> Of course, all these helper function objects are not lambda expressions, so
> not _that_ much.
> There are things that belong in the library. _1 + _2 is much better than
> bind(std::plus<R>(), _1, _2). But we have to draw the line somewhere; you
> can't provide direct support in LL for everything; it's better to focus on a
> simple, well understood, logical subset of primitives that allow people to
> do everything without bothering you with feature requests.

Cheers, Jaakko
