Proto for Boost mailing list page: Re: [proto] [proto-11] expression extension

Subject: Re: [proto] [proto-11] expression extension
From: Eric Niebler (eric_at_[hidden])
Date: 2012-06-04 15:18:17

On 6/3/2012 11:47 PM, Joel Falcou wrote:
> On 03/06/2012 09:41, Eric Niebler wrote:
>> 2) Rather than writing generators, you'll be defining per-domain
>> make_expr function objects that accept a tag and a number of children.
>> How you decide to assemble these into an expression is up to you, but
>> you can use a helper like make_custom_expr above to simplify things.
> 
> It's very important those make_expr functino object could be extended
> externally of any structure. By the look of it, it looks like
> it'll behave similary to the switch_ construct, aka a template functor
> inside a struct to be extended outside.

The make_expr function object takes as arguments the tag and the
children. You can do whatever you want. If open extensibility matters,
you can dispatch to a function found by ADL or to a template specialized
on the tag like proto::switch_. It's up to you.

>> 3) There are other per-domain customization points: (a) store_value,
>> which specifies the capture policy for non-proto objects in expressions,
>> and (b) store_child, which specifies how children are stored. For both
>> (a) and (b), the default is: lvalues are stored by reference and rvalues
>> are stored by (moved from) value. Expressions can safely be stored in
>> auto variables by default.
> 
> So I guess it also fix the problem we faced with Mathias on having to
> store everythign by value to have proper chains of expression building
> function works properly ?

Not sure what you mean. Are you referring to the current discussion
about having to use shared_ptr to store something? That seems unrelated
to me.

Assuming your types are efficiently movable, the default should just do
the right thing, and your expression trees can be safely stored in local
auto variables without dangling references. Does that help?

>> Thanks all for now. Feedback welcome. If you have wishlist features for
>> proto-11, speak now.
> 
> On eo fmy PHD student will start converting Quaff to C++11 this july, so
> depending on your advancement on Proot-11, we may give it a shot an
> dreport any missing features.

Proto-11 will probably take many months. I'm taking my time and
rethinking everything. Don't hold your work up waiting for it.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com