Re: [proto] [proto-11] expression extension

2012-06-14 Thread Joel Falcou
Just a question that just struck me. Will this rewrite be backward 
compatible with C++03  for the features that make sense ? I think the 
C++03 version may benefit from the new expression extension mechanism etc.


___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto


Re: [proto] [proto-11] expression extension

2012-06-06 Thread Mathias Gaunard

On 03/06/2012 09:41, Eric Niebler wrote:


Hey all, this is just an FYI. I've been hard at work at a ground-up
redesign of proto for C++11. I've gotten far enough along that I know
what expression extension will look like, so I thought I'd share. This
should interest those who want finer control over how expressions in
their domain are constructed. Without further ado:

 templatetypename Tag, typename Args
 struct MyExpr;

 struct MyDomain
   : proto::domainMyDomain
 {
 struct make_expr
   : proto::make_custom_exprMyExpr, MyDomain
 {};
 };

 templatetypename Tag, typename Args
 struct MyExpr


Wouldn't it be more interesting for make_custom_expr to take a 
meta-function class?

___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto


Re: [proto] [proto-11] expression extension

2012-06-06 Thread Eric Niebler
On 6/5/2012 11:10 PM, Mathias Gaunard wrote:
 On 03/06/2012 09:41, Eric Niebler wrote:

 Hey all, this is just an FYI. I've been hard at work at a ground-up
 redesign of proto for C++11. I've gotten far enough along that I know
 what expression extension will look like, so I thought I'd share. This
 should interest those who want finer control over how expressions in
 their domain are constructed. Without further ado:

  templatetypename Tag, typename Args
  struct MyExpr;

  struct MyDomain
: proto::domainMyDomain
  {
  struct make_expr
: proto::make_custom_exprMyExpr, MyDomain
  {};
  };

  templatetypename Tag, typename Args
  struct MyExpr
 
 Wouldn't it be more interesting for make_custom_expr to take a
 meta-function class?

The template template parameter is distasteful, I agree, but I can shave
template instantiations this way. There's no need to instantiate a
nested apply template for every new expression type created. Especially
now with template aliases, it's quite painless to adapt a template to
have the interface that make_custom_expr expects. That was my reasoning,
at least.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto


Re: [proto] [proto-11] expression extension

2012-06-06 Thread Mathias Gaunard

On 06/06/2012 08:24, Eric Niebler wrote:


The template template parameter is distasteful, I agree, but I can shave
template instantiations this way. There's no need to instantiate a
nested apply template for every new expression type created. Especially
now with template aliases, it's quite painless to adapt a template to
have the interface that make_custom_expr expects. That was my reasoning,
at least.


I hadn't considered template aliases, I guess with those it is just fine.
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto


Re: [proto] [proto-11] expression extension

2012-06-04 Thread Joel Falcou

Le 04/06/2012 21:18, Eric Niebler a écrit :

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.


Ok perfect


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?


I was thinking of the case where we constructed a foo expression by
calling expression constructor one  into the other. I guess it fixes that.


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


No problem, just that if you need some reality check at some point we 
may provide a non trivial test case. We're doing it anyway ;)




___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto


Re: [proto] [proto-11] expression extension

2012-06-04 Thread Eric Niebler
On 6/4/2012 12:48 PM, Joel Falcou wrote:
 Le 04/06/2012 21:18, Eric Niebler a écrit :
 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?
 
 I was thinking of the case where we constructed a foo expression by
 calling expression constructor one  into the other. I guess it fixes that.

One into the other? I must be dense. Not getting it. ???

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto


Re: [proto] [proto-11] expression extension

2012-06-04 Thread Eric Niebler
On 6/4/2012 6:08 PM, Mathias Gaunard wrote:
 Eric Niebler wrote:
 Proto-11 will probably take many months. I'm taking my time and
 rethinking everything. Don't hold your work up waiting for it.
 
 Best thing to do is probably to make it lighter, keep separate things
 separate, and truly extendable.
 
 For example, transforms seem too tighly coupled with the rest in the
 current Proto version, and their limitations are quite intrusive.

Can you be more specific and give some examples? BTW, I appreciate your
helping to improve proto.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto