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

Proto grammars and transforms handle this better than evaluators, which are deprecated. It would pay to look into some examples that use transforms. Sorry, that's all the advice I have time for at the moment. \e On Apr 14, 2016 10:33 AM, "Mathias Gaunard" wrote: >

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’) >

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

On 04/14/2016 10:10 AM, Mathias Gaunard wrote: 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:

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

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

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

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

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 too, e.g. Vector10 Reading the manual of Boost.proto it

Re: [proto] How to customize an expression in an EDSL , so as to make a deep copy of it?

Hi Masa, Good to hear, good luck with your work! Cheers, Bart On Fri, Jan 15, 2016 at 3:19 AM Masakatsu ITO(伊藤) wrote: > Hi Bart and Boost.Proto community, > > Thanks to you, I made some progress on my mini-EDSL and > have given a poster presentation at the small

Re: [proto] How to customize an expression in an EDSL , so as to make a deep copy of it?

Hi Bart and Boost.Proto community, Thanks to you, I made some progress on my mini-EDSL and have given a poster presentation at the small symposium of computer science in Japan to discuss about DSLs for scientific simulation. Although my EDSL still has lots of template errors, I hope to post its

Re: [proto] How to customize an expression in an EDSL , so as to make a deep copy of it?

Hi Bart, Thank you so much for fixing my source code and giving me this good starting point for my first mini-EDSL . I'll try to extend grammar objects and will learn more about Proto. You can create a proper proto terminal in your domain using: ExprWrapper const

Re: [proto] How to customize an expression in an EDSL , so as to make a deep copy of it?

On Fri, Dec 25, 2015 at 2:07 PM Masakatsu ITO(伊藤) wrote: > > Actually I tried to adapt my DiffereneceOperator type to Proto > as Proto Users Guide explains in "Adapting Existing Types to Proto". > > >

[proto] Paper about using Proto in FEM

Hi, I have written an open-access paper about using Proto for finite element assembly. It's roughly based on my 2013 CPPnow presentation and can be accessed here: http://www.hindawi.com/journals/sp/2015/797325/ Cheers, Bart ___ proto mailing list

Re: [proto] Clang compile times

On Thu, Nov 21, 2013 at 11:19 PM, Eric Niebler e...@boostpro.com wrote: Ugh, this is terrible news. If you have a self-contained repro (preprocessed translation unit), please file a clang bug. They'll take a regression of this magnitude seriously. OK, I added a bug at:

Re: [proto] Clang compile times

On 11/20/2013 02:36 AM, Bart Janssens wrote: Hello, I recently upgraded the OS and XCode on my Mac, resulting in the following clang version: Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn). The previous version was Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM

[proto] Clang compile times

Hello, I recently upgraded the OS and XCode on my Mac, resulting in the following clang version: Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn). The previous version was Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn) The new version is about 4 times slower when

Re: [proto] Holding children by copy or reference

On 2013-09-30 13:54, Mathias Gaunard wrote: 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

Re: [proto] Holding children by copy or reference

On Tue, Oct 1, 2013 at 12:59 AM, Mathias Gaunard mathias.gaun...@ens-lyon.org wrote: To clarify, in terms of performance, from best-to-worst: 1) everything by reference: no problem with performance (but problematic dangling references in some scenarios) 2) everything by value: no CSE or other

Re: [proto] Holding children by copy or reference

On 10/1/2013 12:05 AM, Bart Janssens wrote: On Tue, Oct 1, 2013 at 12:59 AM, Mathias Gaunard mathias.gaun...@ens-lyon.org wrote: To clarify, in terms of performance, from best-to-worst: 1) everything by reference: no problem with performance (but problematic dangling references in some

[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

Re: [proto] Holding children by copy or reference

On 9/30/2013 1:54 PM, Mathias Gaunard wrote: 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

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,

Re: [proto] Holding children by copy or reference

On 9/30/2013 11:08 AM, Mathias Gaunard wrote: 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

[proto] How to prevent function to be called for every evaluation of an expression?

Hi, for educational purposes I am implementing an EDSL for vector arithmetic and lazy evaluation which works quite nice (and fast) so far. But when I compile something like: Vector a, b, c; a = b + c + dotProduct(b, c); the result is computed correctly but dotProduct() is called for

Re: [proto] How to prevent function to be called for every evaluation of an expression?

What exactly is dotProduct? Is it a C++ function? If so, it will just get evaluated and the AST will contain the result of the evaluation. In that case I would expect it to only get evaluated once. How are you checking that it gets called multiple times? You might try setting a breakpoint in

Re: [proto] Proto v5

On 6/16/2013 11:59 AM, Agustín K-ballo Bergé wrote: On 15/06/2013 10:59 p.m., Eric Niebler wrote: - Some specific uses of Proto actions in constant expressions fail. GCC reports an ambiguity with ref-qualifiers in the following scenario: struct foo { int bar()

Re: [proto] Proto v5

On 15/06/2013 03:43 a.m., Agustín K-ballo Bergé wrote: On 14/06/2013 11:06 p.m., Eric Niebler wrote: (Sorry for the top-posting. I'm away from my computer.) The repository *is* compilable, if your compiler is clang built from trunk. I suspect there are bugs in Proto, gcc, and clang, and

Re: [proto] Proto v5

On 15/06/2013 10:59 p.m., Eric Niebler wrote: On 13-06-15 03:40 PM, Agustín K-ballo Bergé wrote: On 15/06/2013 03:43 a.m., Agustín K-ballo Bergé wrote: On 14/06/2013 11:06 p.m., Eric Niebler wrote: - Some specific uses of Proto actions in constant expressions fail. GCC reports an ambiguity

Re: [proto] Proto v5

I've made no effort so far to port Proto v5 to any compiler other than clang. I'm sure it would be a big job. I welcome any contributions. Otherwise, it'll get ported eventually, but probably not before I get the API settled. Eric Sent via tiny mobile device -Original Message- From:

Re: [proto] problems with proto::matches

On 12/13/2012 4:51 AM, Thomas Heller wrote: Hi, I recently discovered a behavior which i find quite odd: proto::matchesExpression, Grammar::type fails when Expression is not a proto expression. I would have expected that it just returns false in this case. What am I missing. Patch is

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

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

On 16/10/2012 03:50 p.m., Agustín K-ballo Bergé wrote: On 16/10/2012 02:22 a.m., Eric Niebler wrote: Hi Agustín, This is just a quick note to let you know that I'm currently at the standard committee meeting in Portland, and that I'll be unable to look until this until I get back next week.

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

On 16/10/2012 02:22 a.m., Eric Niebler wrote: Hi Agustín, This is just a quick note to let you know that I'm currently at the standard committee meeting in Portland, and that I'll be unable to look until this until I get back next week. Thank you for letting me know. Agustín K-ballo Bergé.-

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

On 10/13/2012 4:20 PM, Agustín K-ballo Bergé wrote: Hi All, I'm experimenting with Proto to build a DSEL that operates on geometric vectors. I'm trying to write a transform that would take an assign expression and unroll it component wise. For instance, I want to replace Hi Agustín, This

[proto] Joining Proto List

Eric suggested that I join this list. I have been working for some years on FC++ (the old web site died recently unfortunately but there is a link to it on http://c2.com/cgi/wiki?FunctoidsInCpp ). I have extended it a lot and also worked on a version using concepts to do the return type

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

Le 27/07/2012 08:11, Eric Niebler a écrit : You mean, a proto callable that wraps fusion::transform? No, we don't have one yet. If you write one, I'll put it in proto. OK Naming is becoming an issue, though. We already have proto::transform. You'd be adding proto::functional::transform that

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

On 7/27/2012 12:19 AM, Joel Falcou wrote: Le 27/07/2012 08:11, Eric Niebler a écrit : Naming is becoming an issue, though. We already have proto::transform. You'd be adding proto::functional::transform that would be totally unrelated. I think I screwed up with the namespaces. It should

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

Yeah i figured the code was amiss. After corrections and using your tip, it works. The I discovered it was not what I wanted ;) What I actually need to do is that when I encounter a bunch of bitwise_and_ node, I need to flatten them then pass this flattened tree + the initial tuple to the

Re: [proto] proto-11 progress report

On 7/17/2012 6:14 PM, Eric Niebler wrote: I'm considering adding the slots mechanism to proto-current so that this can be made to work there, also. The problem is that once you use a slot, the data parameter is no longer just a dumb blob. I can make proto::_data ignore the slots and just

Re: [proto] Refining the Proto concepts

On 7/18/2012 3:59 PM, Mathias Gaunard wrote: 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

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

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,

Re: [proto] _unpack transform

On 7/13/2012 6:37 AM, Mathias Gaunard wrote: 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

Re: [proto] _unpack transform

On 7/11/2012 10:32 AM, Eric Niebler wrote: f0(f1(f2(pack(_))...)) That's no so bad, actually. Now, the question is whether I can retrofit this into proto-current without impacting compile times. This is now implemented on boost trunk for proto-current. Seems to work without a significant

Re: [proto] _unpack transform

On 07/10/2012 11:18 PM, Eric Niebler wrote: I just committed to the proto-11 codebase a new transform called _unpack. You use it like this: _unpackf0(Tfx, f1(_)...) Where Tfx represents any transform (primitive or otherwise) f0 is any callable or object type, and f1(_) is an object or

Re: [proto] _unpack transform (was: proto-11 progress report)

On Tue, Jul 10, 2012 at 11:18 PM, Eric Niebler e...@boostpro.com wrote: The _unpack transform is pretty general, allowing a lot of variation within the pack expansion pattern. There can be any number of Tfx transforms, and the wildcard can be arbitrarily nested. So these are all ok: // just

Re: [proto] _unpack transform

On 7/11/2012 12:42 AM, Thomas Heller wrote: On 07/10/2012 11:18 PM, Eric Niebler wrote: I just committed to the proto-11 codebase a new transform called _unpack. You use it like this: _unpackf0(Tfx, f1(_)...) Where Tfx represents any transform (primitive or otherwise) f0 is any callable

[proto] _unpack transform (was: proto-11 progress report)

I just committed to the proto-11 codebase a new transform called _unpack. You use it like this: _unpackf0(Tfx, f1(_)...) Where Tfx represents any transform (primitive or otherwise) f0 is any callable or object type, and f1(_) is an object or callable transform. The ... denotes pseudo-pack

Re: [proto] proto-11 progress report

On 6/29/2012 4:49 AM, Mathias Gaunard wrote: 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. Right. Providing the higher-level

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

Re: [proto] proto-11 progress report

On 6/27/2012 2:11 PM, Mathias Gaunard wrote: 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

Re: [proto] proto-11 progress report

On 06/24/2012 01:10 AM, Eric Niebler wrote: I've made some good progress on the C++11 proto rewrite that I'd like to share. So far, it's been a less radical shift than I expected. You didn't try hard enough ;) Expressions vs. Grammars Many new users are confused by

Re: [proto] proto-11 progress report

On 6/25/2012 12:39 AM, Joel Falcou wrote: On 06/24/2012 01:10 AM, Eric Niebler wrote: snip int i = LambdaEval()(_1 + 42, 0, proto::tag::data = 8); The 3rd parameter associates the value 8 with the data tag. snip How do you set up

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_,

Re: [proto] Streamulus v0.1 is out: An EDSL for Event Stream Processing with C++

on Sat Jun 23 2012, Irit Katriel iritkatriel-/E1597aS9LQAvxtiuMwx3w-AT-public.gmane.org wrote: Good day, Streamulus is a C++ DSEL for event stream processing. It uses Proto to transform simple expressions into a data structure that computes the expression over an infinite stream of

Re: [proto] Streamulus v0.1 is out: An EDSL for Event Stream Processing with C++

On 24 Jun 2012, at 22:24, Eric Niebler wrote: Very interesting! So ... data flow? Or does this take inspiration from stream databases? Thank you. Yes, data flow. With central control to make sure things propagate through the graph in topological order. This is necessary for

Re: [proto] Streamulus v0.1 is out: An EDSL for Event Stream Processing with C++

on Sun Jun 24 2012, Eric Niebler eric-xT6NqnoQrPdWk0Htik3J/w-AT-public.gmane.org wrote: On 6/24/2012 8:50 AM, Irit Katriel wrote: In the accumulators library, all the accumulators are invoked for every update to the input. This is why the visitation order can be determined at compile

Re: [proto] Streamulus v0.1 is out: An EDSL for Event Stream Processing with C++

On 6/24/2012 4:42 PM, Dave Abrahams wrote: on Sun Jun 24 2012, Eric Niebler eric-xT6NqnoQrPdWk0Htik3J/w-AT-public.gmane.org wrote: On 6/24/2012 8:50 AM, Irit Katriel wrote: In the accumulators library, all the accumulators are invoked for every update to the input. This is why the

[proto] Streamulus v0.1 is out: An EDSL for Event Stream Processing with C++

Good day, Streamulus is a C++ DSEL for event stream processing. It uses Proto to transform simple expressions into a data structure that computes the expression over an infinite stream of inputs. With user-defined operators that can have side effects or maintain state, this scheme is very

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

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

Re: [proto] Who's using proto ?

On 06/06/2012 09:24 PM, Joel Falcou wrote: Hi, i'm in the process of writing a journal paper about proto and I wanted to give a realistic snapshot of who is using proto and for what. I know some already (the whole MSM Spirit team etc ) but i am sure there is other people lurking around

Re: [proto] Who's using proto ?

On 06/06/2012 09:24 PM, Joel Falcou wrote: Hi, i'm in the process of writing a journal paper about proto and I wanted to give a realistic snapshot of who is using proto and for what. I know some already (the whole MSM Spirit team etc ) but i am sure there is other people lurking around

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

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

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.

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

[proto] Who's using proto ?

Hi, i'm in the process of writing a journal paper about proto and I wanted to give a realistic snapshot of who is using proto and for what. I know some already (the whole MSM Spirit team etc ) but i am sure there is other people lurking around here. So, if you want to contribute, I wish

Re: [proto] Hold terminals by smart reference

On 6/4/2012 5:51 PM, Mathias Gaunard wrote: 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

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

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

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

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

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

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

[proto] restructuring expression

I have an arithmetic expression template where multiplication is commutative. Is there an easy way to order a chain of multiplications such that terminals with values (like proto::terminal double ) appear at the beginning? For example that arg1 * arg1 * 1.5 * arg1 will be transformed to 1.5 *

Re: [proto] restructuring expression

On 5/29/2012 1:44 AM, Karsten Ahnert wrote: I have an arithmetic expression template where multiplication is commutative. Is there an easy way to order a chain of multiplications such that terminals with values (like proto::terminal double ) appear at the beginning? For example that arg1 *

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 https://svn.boost.org/trac/boost/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

Re: [proto] Restructuring noses in generator

On 04/29/2012 02:41 AM, Eric Niebler wrote: And some_terminal is not in your domain? How does your generator get invoked? I guess I'm confused. Can you send a small repro? everything is in my domain, no problem ont his side, I'll try Mathias idea and report if anything breaks.

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,

Re: [proto] Restructuring noses in generator

On 4/28/2012 3:38 AM, Mathias Gaunard wrote: 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

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

On 4/25/2012 1:41 PM, Mathias Gaunard wrote: 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.

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

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

On 4/26/2012 9:35 AM, Mathias Gaunard wrote: 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

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

On 4/23/2012 10:17 PM, Joel Falcou wrote: On 04/24/2012 12:15 AM, Eric Niebler wrote: implicit_expr() returns an object that holds its argument and is convertible to any expression type. The conversion is implemented by trying to implicitly convert all the child expressions, recursively. It

[proto] The proper way to compose function returning expressions

Let's say we have a bunch of functions like sum and sqr defined on a proto domain to return expression of tag sum_ and sqr_ in this domain. One day we want to make a norm2(x) function which is basically sum(sqr(x)). My feeling is that I should be able to write it using sqr and sum

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

On 4/23/2012 1:01 PM, Joel Falcou wrote: Let's say we have a bunch of functions like sum and sqr defined on a proto domain to return expression of tag sum_ and sqr_ in this domain. One day we want to make a norm2(x) function which is basically sum(sqr(x)). My feeling is that I should be

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

On 04/24/2012 12:15 AM, Eric Niebler wrote: implicit_expr() returns an object that holds its argument and is convertible to any expression type. The conversion is implemented by trying to implicitly convert all the child expressions, recursively. It sort of worked, but I never worked out all

Re: [proto] Held nodes by value for Fundamental types

On 10/04/2012 00:00, Eric Niebler wrote: Thanks. I thought long about whether to handle the fundamental types differently than user-defined types and decided against it. The capture-everything-by-reference-by-default model is easy to explain and reason about. Special cases can be handled on a

Re: [proto] Held nodes by value for Fundamental types

On Tue, Apr 10, 2012 at 3:12 AM, Joel Falcou joel.fal...@lri.fr wrote: On 10/04/2012 00:00, Eric Niebler wrote: Thanks. I thought long about whether to handle the fundamental types differently than user-defined types and decided against it. The capture-everything-by-**reference-by-default

[proto] Held nodes by value for Fundamental types

Hello, I'm wondering if it would be appropriate to treat the fundamental types (char, short, int, double, ...) by value, by default. I wrote this simple piece of code. I'm not sure if I'm leaving without considering any other implication, but I think it may be an improvement. Please, tell me if

Re: [proto] Held nodes by value for Fundamental types

On 4/9/2012 2:21 PM, Fernando Pelliccioni wrote: Hello, I'm wondering if it would be appropriate to treat the fundamental types (char, short, int, double, ...) by value, by default. I wrote this simple piece of code. I'm not sure if I'm leaving without considering any other implication,

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

Re: [proto] user docs for advanced features

Hi Eric, On Mon, Jan 2, 2012 at 9:55 PM, Eric Niebler e...@boostpro.com wrote: Proto's users guide has been behind the times for a while. No longer. More recent and powerful features are now documented. Feedback welcome. Sub-domains:

Re: [proto] user docs for advanced features

On 1/4/2012 7:37 AM, Thomas Heller wrote: snip many good suggestions Thanks for adding this documentation! Great feedback. I've just accommodated all of it. Thanks! -- Eric Niebler BoostPro Computing http://www.boostpro.com ___ proto mailing list

Re: [proto] Grouping expressions

On 30/12/2011 17:34, Bart Janssens wrote: On Fri, Dec 30, 2011 at 7:01 AM, Eric Nieblereric-xT6NqnoQrPdWk0Htik3J/w...@public.gmane.org wrote: Are you certain your problem is caused by using operator() for grouping? I think this is just a very big expression template, and any syntax you

[proto] user docs for advanced features

Proto's users guide has been behind the times for a while. No longer. More recent and powerful features are now documented. Feedback welcome. Sub-domains:

Re: [proto] Problems with unary function node

On 10/22/2011 3:02 PM, Mathias Gaunard wrote: 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

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(). snip Sorry for the delay, and

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

On 26/08/2011 17:18, Eric Niebler wrote: Why can't you use a grammar to recognize patterns like these and take appropriate action? we do. Another point is that container based operation in our system need to know the number of dimension of the container. Domains carry this dimensions

Re: [proto] [Proto] Expression as fusion/MPL sequence

On 6/2/2011 11:12 AM, Joel falcou wrote: On 01/06/11 22:24, Eric Niebler wrote: Proto expressions are random access, but flattened views are forward-only. That's a limitation of the current implementation of the segmented Fusion stuff. It's a known problem. Segmented fusion needs a complete

Re: [proto] [Proto] Expression as fusion/MPL sequence

On 6/2/2011 7:02 AM, Joel Falcou wrote: Seems somethign crooky on this front. Calling fusion::at_c on expression ends up in error even after including boost/proto/fusion.hpp. Same way, flatten used as a transform seems to not give me a type that can be passed to any fusion or mpl function.

[proto] proto::expr vs. proto::basic_expr

Hi, Today I experimented a little bit with phoenix and proto. My goal was to decrease the compile time of phoenix. When I started the development of phoenix, Eric advised me to use proto::basic_expr to reduce compile times. Which makes sense giving the argumentation that on instatiating the

Re: [proto] Compiling in debug mode

Am Freitag, den 13.05.2011, 09:59 +0700 schrieb Eric Niebler: On 5/13/2011 5:45 AM, Bart Janssens wrote: Hi guys, [..] Is anyone aware of tweaks for GCC that reduce memory usage, but still produce useful debug info (just using -g now, no optimization)? I'll leave this for the gcc

Re: [proto] Compiling in debug mode

On Fri, May 13, 2011 at 9:46 AM, Daniel Oberhoff daniel.oberh...@fit.fraunhofer.de wrote: --param ggc-min-expand=30 --param ggc-min-heapsize=8192 in effect I think it is a space/speed tradeoff, though I haven't noticed any major slowdown. Thanks, these do reduce memory (somewhat), though

[proto] Compiling in debug mode

Hi guys, I've followed the recent discussion about compilation performance, it's good to know things are getting better and hopefully support for the new standard will help even more. Currently, my main problem is not so much the compile time itself, but how much RAM gets used in debug mode (GCC

  1   2   3   >