Re: [boost] reference_wrapper as functor

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-12-20 18:22:03

From: "Joel de Guzman" <djowel_at_[hidden]>
> From: "Peter Dimov" <pdimov_at_[hidden]>
>
> > From: "Joel de Guzman" <djowel_at_[hidden]>
> > [...]
> > > The condition is expected to be a functor that returns
> > > a boolean condition. I was hoping that I can use the
> > > ref(b) as a functor such that I can write:
> > >
> > >     bool b;
> > >
> > >     if_p(ref(b))
> > >     [
> > >         parse_this
> > >     ]
> >
> > Not a good idea. In lambda terms the above is var(b), not ref(b). We've
been
> > using ref(x) to mean "just like x", i.e. ref(b)() means b(). One day we
> > might even get that core change that would enable
> > reference_wrapper<T>::operator T& to be considered in a ref(f)()
expression;
> > for now, we "fake" it in bind, function, etc.
>
> I beg to disagree. I do not see that as reasonable. The use of var(b)
> will bring in tons of scaffolding. This is the main reason why I want to
> request for the operator(). I've struggled hard to keep the core
> of Spirit small enough to do micro parsing. I do not wish to force the
> user to use lambda or phoenix, bind nor function just to do such a trivial
> operation that can be accomplished by a one-liner in ref(x).

I think you misunderstood; sorry for not being clear.

ref(x)(...) can mean two different things, both reasonable. One is to simply
return x. The other is to return x(...). The convention we have adopted so
far in bind and function is to treat ref as if ref(x)(...) returns x(...).
This has nothing to do with spirit using bind, function, or lambda. It's
about the semantics of ref.

In fact, if you use ref(b) as above, you now have no way to express the
other operation, make if_p store a reference to the function object:

if_p(ref(f))
[
]

This is necessary when f has state or cannot be copied.