Boost logo

Boost :

Subject: Re: [boost] Rave for proposed Boost.Local (functions)
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2011-02-05 06:40:59


Mathias Gaunard <mathias.gaunard <at> ens-lyon.org> writes:
> On 03/02/2011 16:45, Thomas Heller wrote:
>
> >>> Now, let's consider another case, I want to do a.foo(b.bar()) + c.baz,
> >>> but with a, b, and c taken from the scope, and I don't want to have to
> >>> specify the types of a, b, and c. I can't do that in Phoenix without
> >>> defining the foo, bar and baz functions at namespace scope, since they
> >>> must have a template operator(), which is only allowed at that level. I
> >>> can, however, do that with no problem with Boost.Local.
> >>
> >> Well, you have seen nothing yet
> >
> >
http://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/libs/phoenix/doc/html/
phoenix/inside/extending_actors.html
> > A boilerplate macro for that would be a very welcome contribution...
>
> All of this still needs to happen at namespace scope.

Sure it would. The point of this exercise was to adapt some "old style" C++
class to be used in a phoenix expression. Much in the fashion of
BOOST_FUSION_ADAPT_STRUCT. Since you complained about using member functions
in a phoenix expression is a pain ...

> The problem with declaring those things at namespace scope is that they
> necessarily become far away from the lambda function you want to write.

Arguing like that disqualifies every library, since the defintion of the
functions you want to use is _very_ far away... I don't see a point in that
argument.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk