Re: [boost] [Review] XInt Review

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

> I agree that something like that could be done, and there are plenty of other AST transformations we would make to improve even simple arithmetic expressions written by the user, but I'm not convinced we should.  If the user is able to write the optimal expression himself then my view is that a library does not need to optimize the user's suboptimal expressions.  If the user sees a problem with the expression he wrote (uses too much memory, runs too long) he can fix it himself.  As a user I would not expect the library to optimize my expressions for me, nor would I trust it to do so even if it claimed in its documentation that it does unless I understood the details of what it can or cannot do, which isn't something I would want to invest time in.
he, compositionnal repalcement is nowhere from hard to expect.
> We need to set a reasonable expectation for what the library should do.  These exact same types of optimizations could be applied to my Polygon library expression templates, but I judged it to be not worthwhile.  The common case for use of the expression template is a single operation and even in complex expressions that don't get broken across multiple statements the opportunity for improving on what was written is the exception, not the rule, and easily done manually by the user.  Implementing a compiler as a template metaprogram is exactly what I want to avoid in this case.  Every user will pay the compilation cost imposed by the abstraction, while few will benefit and those most in need of benefit are the ones who will optimize their expression by hand and benefit least.
>
>
I never say that, it doesn't do any meta-compilation, just rearranging 
of trees before evaluation.
And again your fear of compilation cost are vastly exagerated ...

Future of library design is exactly the opposite, leveragign details 
from user hands and implement them as active mechanism runnign at CT or 
RT dependign ont he grain and scope of said operation. The more 
intentional and wrapped an interface can be the better. We now have the 
tools to make the thingy implement itself automatically dependign on a 
alrge scope of factor so I really dont see the point of pushign this 
design forward. Are we Boost, the state of the art C++ lirbary or Boost 
the overly conservative library ?