Re: [proto] Using a derived class as terminals in Boost.proto

lt; > proto::matches > > >::type > > > However, I feel this is not good style. Can this be expressed with the > is_base_of trait instead? > > > > > > On 04/14/2016 10:10 AM, Mathias Gaunard wrote: > >> On 14 April 2016 at 14:43, Frank Winter > <mailt

Re: [proto] Using a derived class as terminals in Boost.proto

On 14 April 2016 at 15:37, Frank Winter wrote: > > and still, I get basically the same error message: > > /home/fwinter/src/boost_1_60_0/boost/proto/context/default.hpp:121:41: > error: no match for ‘operator+’ (operand types are ‘Vector10’ and > ‘Vector10’) > BOOST_PROTO_BINARY_DEFAULT_

Re: [proto] Using a derived class as terminals in Boost.proto

On 14 April 2016 at 14:43, Frank Winter wrote: > Hi all! > > Suppose you'd want to implement a simple EDSL (Embedded Domain Specific > Language) with Boost.proto with the following requirements: > > Custom class 'Vector' as terminal > Classes derived from 'Vector' are working terminals to

Re: [proto] Holding children by copy or reference

On 30/09/13 20:19, Eric Niebler wrote: Yikes! You don't need me to tell you that's UB, and you really shouldn't encourage people to do that. Yet it's apparently the only way to get the same performance as the real thing. You can independently control how intermediate nodes are captured, a

Re: [proto] Holding children by copy or reference

On 30/09/13 08:01, Eric Niebler wrote: Therefore, to avoid performance issues, I'm considering moving to always using references (with the default domain behaviour), and relying on BOOST_FORCEINLINE to make it work as expected. Why is FORCEINLINE needed? The scenario is terminal a, b, c, r;

[proto] Holding children by copy or reference

Hi, A while ago, I recommended to set up domains so that Proto contains its children by value, except for terminals that should either be references or values depending on the lvalue-ness. This allows to avoid dangling reference problems when storing expressions or using 'auto'. I also said t

Re: [proto] Transform result_of nightmare and preserving terminal identity

On 31/10/12 21:28, Agustín K-ballo Bergé wrote: Quoting from my original mail, what I want is to replace the following geometric vector expression: p = q + r; by p[0] = q[0] + r[0], p[1] = q[1] + r[1], ..., p[N] = q[N] + r[N], p; It **can** be done with a transf

Re: [proto] fold_tree and grammar using external_transforms and state

On 26/07/2012 17:28, Joel Falcou wrote: Here is the deal: https://gist.github.com/3182676 Doesn't fold_tree normally take template arguments? I can't see any in the code here. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mail

Re: [proto] Refining the Proto concepts

On 18/07/2012 18:29, Eric Niebler wrote: Is there some code in Proto that is forcing the instantiation of those specializations? Probably, and that would unintended. One approach would be to replace these normalized forms with an equivalent incomplete type and fix all places where the code break

[proto] Refining the Proto concepts

In an experiment to reduce compile times, I'd like to try reducing the number of template instantiations tied to the use of Proto. To do this, one could start by defining his own expression types instead of wrappers of proto::expr, which is something that is more-or-less promoted by proto-11.

Re: [proto] Precomputing common matrix products in an expression

On 07/15/2012 10:25 AM, Bart Janssens wrote: OK, thanks for the comments. It's similar to what I had in mind, but (unless I'm missing something) all product terms in our expressions should have a distinct type if they represent different values, so I could get away with just using a fusion map a

Re: [proto] Precomputing common matrix products in an expression

On 07/15/2012 08:04 AM, Mathias Gaunard wrote: Assuming your expressions are CopyConstructible You'd also need them to be EqualityComparable or to use a comparator to use them as keys. A recursive call to fusion::equal_to would probably be a good defin

Re: [proto] Precomputing common matrix products in an expression

On 07/14/2012 08:46 AM, Joel Falcou wrote: In NT2, we use a schedule transform that iterate the expression tree and evaluate expression tagged as being needed to be evaluated once and store them in some shared_ptr like terminal. This allow us to "schedule" our loop nests in the proper order. Th

Re: [proto] _unpack transform

On 07/11/2012 06:55 PM, Eric Niebler wrote: You're referring to this: http://lists.boost.org/proto/2010/11/0304.php I should have followed through! The code referenced there isn't available anymore. I remember putting it on my TODO list to understand the compile-time implications of it, becaus

Re: [proto] proto-11 progress report

On 28/06/2012 21:09, Eric Niebler wrote: After meditating on this for a bit, a thought occurred to me. Your unpack function is a generalization of the pattern used by the _default transform. It is indeed. Generators are intended to meet this need. What are they lacking for you? Is it the la

Re: [proto] proto-11 progress report

On 25/06/2012 23:30, Eric Niebler wrote: On 6/25/2012 12:21 PM, Mathias Gaunard wrote: There is a function which is very simple and that I found to be very useful when dealing with expression trees. unpack(e, f0, f1) which calls f0(f1(e.child0), f1(e.child1), ..., f1(e.childN)) I can do

Re: [proto] proto-11 progress report

On 24/06/2012 01:10, Eric Niebler wrote: As for what is not changing: Grammars, Transforms and Algorithms === It would be wonderful if there were a more natural syntax for describing proto algorithms rather than with structs, function objects, proto::or_, proto::

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

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 painl

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

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 o

Re: [proto] Hold terminals by "smart" reference

On 05/06/2012 20:38, Eric Niebler wrote: I want you to understand that I'm not just being obstructionist or obstinate. Proto's value functions are very simple and low-level and are called very frequently. Adding metaprogramming overhead there, as would be necessary for adding a customization poi

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

On 04/06/2012 21:48, Joel Falcou wrote: 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. The current Proto already allows to specify whether to hold by reference or value. The new thing is that Prot

Re: [proto] Hold terminals by "smart" reference

On 04/06/2012 17:52, Eric Niebler wrote: I don't know what you mean by the "right type". If you want it held by shared_ptr to manage lifetime, then shared_ptr is the right type, it seems to me. Or use a wrapper around a shared_ptr, whichever. I want all tree manipulation and transformation alg

Re: [proto] Hold terminals by "smart" reference

On 03/06/2012 18:36, Eric Niebler wrote: Plus I don't have a good way to distinguish between a terminal of shared_ptr and a terminal of T which is held through a shared_ptr. Have you tried a grammar? Something like (untested) proto::terminal< boost::shared_ptr< proto::_> > ? That would m

Re: [proto] Hold terminals by "smart" reference

On 03/06/2012 02:59, Eric Niebler wrote: There is no way to hook proto::value to return anything but what is stored in the terminal. It's a very dumb, low-level function. You could easily define your own value function that does something smarter, tho. I'm currently doing it with my own functi

[proto] Hold terminals by "smart" reference

There are some terminals that, due to life-time issues, I cannot hold by reference. I don't want, however, to hold them by value. What I'm currently doing is that I'm holding a shared_ptr by value. For all practical purposes, however, I'd prefer if the expression behaved as a terminal of a ref

Re: [proto] Feature request: control how the built-in operator overloads build expressions

On 11/05/2012 20:34, Eric Niebler wrote: This seems quite reasonable. Could you file a feature request on trac so I don't loose track of it? Thanks. Trac ticket #6891 I wanted to discuss this first because I was afraid you might discard the idea

[proto] Feature request: control how the built-in operator overloads build expressions

Proto comes with operator overloads that call make_expr if the arguments are in a compatible domain and if the grammar is satisfied. In some cases however, we'd like to build custom trees that don't exactly map to what the default operator overloads would do. We suggest adding an extension poi

Re: [proto] Restructuring noses in generator

On 27/04/12 21:47, Joel Falcou wrote: How can I use a custom generator to turn a specific node expression into a different version of itself without triggering endless recursive call ? My use cas is the following, i want to catch all function node looking like tag::function( some_terminal, gram

Re: [proto] The proper way to compose function returning expressions

On 26/04/12 18:02, Eric Niebler wrote: Interesting. I avoided this design because I was uncertain whether the compiler would be able to optimize out all the copies of the intermediate nodes. You're saying NT2 does it this way and doesn't suffer performance problems? And you've hand-checked the g

Re: [proto] The proper way to compose function returning expressions

On 24/04/12 22:31, Eric Niebler wrote: On 4/23/2012 10:17 PM, Joel Falcou wrote: On 04/24/2012 12:15 AM, Eric Niebler wrote: I think this is an important issues to solve as far as Proto grokability does. Agreed. It would be very nice to have. But you still have to know when to use it. One o

Re: [proto] Best way to change tag in generator?

On 01/31/2012 07:01 PM, Eric Niebler wrote: You mean, for instance, you want Proto's operator+ to return an expression with a tag other than tag::plus? Yes. Can I ask why? I need to attach certain information to the type of operation that the tag represents, and putting that information

[proto] Best way to change tag in generator?

For a couple of reasons, I'm considering replacing the proto-provided operator tags by my own in the generator of my domain. What would the easiest and less costly way of doing it? ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mai

Re: [proto] Problems with unary function node

On 10/29/2011 06:37 AM, Eric Niebler wrote: It could be that I'm stupid, or that I'm tired, or that your explanation is insufficient ... but I don't get it. My explanation is just a few bits from what kind of thing we do, sorry it wasn't helpful. It may help to say that it's not the actual e

Re: [proto] Problems with unary function node

On 28/10/2011 07:30, Eric Niebler wrote: Regardless, I'm convinced that a complete fix is possible, and I have it mostly coded. It would require you (the user) to disable unary function and assign in your domain via a grammar. But. It's expensive at compile time, and everybody pays. I need to be

Re: [proto] Problems with unary function node

On 10/18/2011 05:53 AM, Eric Niebler wrote: On 10/12/2011 2:24 PM, Mathias Gaunard wrote: There seems to be a significant problem with the unary function node (and by that I mean (*this)() ) generated by proto::extends and BOOST_PROTO_EXTENDS_USING_FUNCTION(). Sorry for the delay, and I&#

[proto] Problems with unary function node

There seems to be a significant problem with the unary function node (and by that I mean (*this)() ) generated by proto::extends and BOOST_PROTO_EXTENDS_USING_FUNCTION(). Indeed, it instantiates the generator before the expression type is complete, leading to very confusing ODR issues and a wh

Re: [proto] Defining the result domain of a proto operator

On 26/08/2011 16:45, Eric Niebler wrote: Before I answer, can you tell me why you've decided to put vector and matrix operations into separate domains? This seems like an artificial and unnecessary separation to me. Some operations are valid on vectors but not on matrices. Our grammar enforce

[proto] Defining the result domain of a proto operator

With the following Proto expression: m * v; with m in the matrix_domain and v in the vector_domain. vector_domain is a sub-domain of matrix_domain, so the common domain is matrix_domain. We want the '*' operation to model the matrix multiplication. matrix times vector yields a vector. Therefor

Re: [proto] Extendin proto::switch_

On 08/06/2011 07:30 AM, Eric Niebler wrote: On 8/5/2011 8:52 AM, Joel falcou wrote: There is few use case where I wish i can have a proto::switch_ like transform being extendable externally but based on something else than the expression tag like the result of an arbitrary meta-function. Is clo

[proto] Using make_expr with as_child or as_expr

make_expr is a fairly "funny" function, in that it decides whether the children should be taken by value or reference depending on whether they're wrapped in boost::(c)ref or not. In some cases, I really want to write something like proto::make_expr( proto::as_child(a0), proto::as_child(

Re: [proto] My own lambda for MSM / wish list

On 14/03/2011 22:12, Christophe Henry wrote: Calling phoenix expressions from the statement module return void. Calling phoenix expressions from any other modules return whatever ... depending on the "C++-Sense". It's ok, I can live with it, though I'll need to find a way around because I do n