Re: [boost] [Review] XInt Review

Subject: Re: [boost] [Review] XInt Review
From: Joel Falcou (joel.falcou_at_[hidden])
Date: 2011-03-09 14:23:06

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.