[boost] Re: Re: Re: Re: Re: Assignment library: review

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-04-13 08:10:00

"Peter Dimov" <pdimov_at_[hidden]> wrote in message
news:002101c4214f$0cfb5f30$1d00a8c0_at_pdimov2...
> Thorsten Ottosen wrote:
> > Hi Peter,
> >
> > [snp]
> >> Yes, of course it is possible to reject the example. But I don't
> >> want to reject it. It's useful.
> >
> > Ok. Could you present an example?
>
> This feature of bind is used to create stateful function objects. In a
> "real" lambda facility it corresponds to a local static variable:
>
>     for_each( first, last, lambda(v) { static int x = 0; f(v, ++x); } );
>
> The bind equivalent is
>
>     for_each( first, last, bind( f, _1, bind(incr, 0) ) );

ok, but couldn't incr() just be defined as 'int incr( int i ) { return i +
1; }' ?

Anyway, it is not the possibility of having "local static" data in function
objects
we are arguing about, its about what to pass that data to.

> Bind's emphasis is on usefulness, not hand-holding.

good frase :-)

>Its learning curve is
> inherently steep and more importantly, it simply cannot be flattened by
> making bind less useful.

I guess the current design gives maximal power; so it it seems ok. Requering
that the
user calls

bind( f, local_copy( i ) )

would document that the programmer knows that  f takes a reference, but that
it
can act on a copy. However, once you know the mechanism, you would be
irritated by such constraints.

br

Thorsten