y handling them all). Also, as written the transform doesn't
recurse properly, and I'm having some trouble seeing how to correct this.
As I'm really just trying to get my mind around how proto works, any comments
would be appreciated.
Thanks
Nate Knight
test2.c
On Jan 14, 2011, at 12:29 PM, Nate Knight wrote:
> I've pasted some code below where I am trying to transform expressions of the
> form
>
> (a op b op c)[i]
>
> to
>
> (a[i] op b[i] op c[i])
>
> I managed to get this to work for the simple case
>
>
Eric Niebler writes:
>
> This is a fun little problem. The answer is very simple, but requires
> some knowledge of proto's pass_through transform, possessed by
> proto::nary_expr (and friends):
>
Eric,
Thanks for the pointers. I had tried this with nary_expr, but had some trouble
distributin
I see in the Proto documentation a trick for getting the Proto operator
overloads found by ADL using something like
template
struct my_complex
{
BOOST_PROTO_EXTENDS(
typename proto::terminal >::type
, my_complex
, proto::default_domain
)
};
The proto::pod_generator cl
> On 2/12/2011 7:17 AM, Nate Knight wrote:
>> I see in the Proto documentation a trick for getting the Proto operator
>> overloads found by ADL using something like
>>
>> template
>> struct my_complex
>> {
>>BOOST_PROTO_EXTENDS(
>>ty
> The second argument to BOOST_PROTO_DEFINE_OPERATORS is a domain. When
> defining a domain you (usually) specify a generator with an expression
> wrapper. What are you using for a domain, and how do you define it?
>
> When I want an end-user-friendly terminal type, I derive it from the
> express
On Feb 20, 2011, at 4:43 AM, Joel Falcou wrote:
> On 20/02/11 12:41, Eric Niebler wrote:
>> On 2/20/2011 6:40 PM, Joel Falcou wrote:
>>> On 20/02/11 12:31, Karsten Ahnert wrote:
It is amazing that the proto expression is faster then the naive one.
The compiler must really love the way p
Not sure what happened to those tables. I'll try again.
MacBook Pro, 10.6.6, Core 2 Duo
ProtoContextProtoTransform ProtoLambda Loop
GCC 4.2.1 (Apple) : 5.3565438 5.3721942 126.38458
1.3657978
GCC 4.4.5 : 1.8878364 1.8845548
I'm trying to understand why the two commented out lines fail to compile. It
seems to me
that ideally they would compile, but I may be missing some constraint that
makes these
lines incorrect. In the first case, it seems like the return type of the
default subscript evaluator
is being compu
On Feb 26, 2011, at 4:55 AM, Eric Niebler wrote:
> On 2/26/2011 8:18 AM, Nate Knight wrote:
>>
>> int main()
>> {
>>la::state_type x = {1.0,2.0};
>>la::state_type const& xc = x;
>>
>>// this compiles
>>la::EvalOpt()( lit
>
> In pseudo code it should look like this:
>
> Expressions< N > expressions;
> construct( expressions );// or something similar
> do_step( epxressions , x ); // my method
How about something like?
~
#include
using namespace boost::proto;
template
void my_met
On Mar 18, 2011, at 9:17 AM, Karsten Ahnert wrote:
> Hmm, this might work. It is similar to
>
> my_method( fusion::make_vector( i+i , i*i*i , i*i ) , x );
>
> But the expression might become really large, say 100 elements. A
> separation between construction and usage would be nicer.
How about
12 matches
Mail list logo
