Re: [boost] [Review] XInt Review

Subject: Re: [boost] [Review] XInt Review
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2011-03-09 14:38:26

Joel Falcou wrote:
> On 09/03/11 19:14, Simonson, Lucanus J wrote:
>> This is a serious question that I'm posing with all humility.  What
>> benefit does proto provide in this case?  What do we "get" for using
>> it and what does it "cost".  Can you sketch a comparison between an
>> expression template operator+ on some concrete big int type both
>> with and without use of Proto and walk us through how the use of
>> proto is helpful and worthwhile?  I can already reason that compile
>> time with Proto will be higher than without, though I would be
>> convinced by benchmarks to the contrary.  We don't need concept
>> checking in this case, so what does proto buy us?        
> The fact that you dont have to maintain clunky and possibly inavsive
> ET 
> core code. Writing the operator thingy to be all ET-enabled is a real
> mess and seriously, when you did it a couple of times by hand and did
> once with proto, you dont want to go back.
> 
> More over the cocnept of grammar and transform make your ET intent
> more clear. You can have multiples transform aimed at different pass
> inyou r 
> ASt evalaution and have them cleanly separated fromt he main ET core
> code. transforms are also interchangeable and can be applied in a
> variety of context, support a nice and intutive recursive matching
> notation. 
> 
> As for application, matching pattern of successive operators is a
> couple 
> of lines in proto and is library agnostic. Writing a pattern matcher
> for arbitrary hand written ET code is not that trivial. For compile,
> it's 
> always the saem. if you write crap proto it will be crap. All my proto
> based code has a non significant upfront compile overhead, and well,
> it 
> comes from the preprocessing around and not proto itself.

Granted, proto has a number of very nice features.  The question is, would xint benefit from them?  Does this library require transforms and or multiple passes?  I certainly hope not.  The default operator precidence happens to the one we want in this case (as far as I understand) so what is the point of defining a grammar for operator expressions to achieve what would happen by default without one?

Please correct me if I am wrong.

Regards,
Luke