On 2/1/2011 11:00 PM, Thomas Heller wrote:
Gregory Crosswhite wrote:
Hey everyone,
The purpose of this e-mail is to rave about Lorenzo's proposed Boost.Local library in the hopes of inspiring people to start the review process for it. :-) [...] Despite the Local Blocks and Local Exits feature, I can't see much difference to the already existing lambda libraries. I just looked through the Boost.Local documentation and immediately navigated to the "Alternatives" section and its not really correct regarding the features of Boost.Lambda and Boost.Phoenix. I am specifically talking about the "Bind variables in scope" and "Program body using usual C++ syntax" part. The last is debatable, but how are the above examples (both of Boost.Local and Boost.Phoenix) not C++ syntax? Can you highlight the advantages/disadvantages again?
Purely speculating, but I'd guess the difference in compile times could be quite a bit different, especially for more elaborate uses (both in terms of the number of template instantiations and function inlinings as well as the amount of header code to parse through and preprocessor code to expand). If so, do you consider that a "plus" for (proposed) Boost.Local over, e.g., Boost.Phoenix? It *might* also be *possible* that the higher transparency (from the perspective of the compiler) of functions written with (proposed) Boost.Local may give superior (faster, smaller, whatever) compiled code on some compilers than the equivalent in Boost.Phoenix. Obviously, though, I'm sure you (Thomas) along with Eric, Joel, Dan Marsden, and any number of other boosters with vastly more experience in expression template libraries would be better able to assess that possibility. It might help Lorenzo's cause to give specific examples where he (or anyone else) feels the (proposed) Boost.Local construct is superior in some way to the Boost.Phoenix construct. - Jeff