Re: [boost] Rave for proposed Boost.Local (functions)

Subject: Re: [boost] Rave for proposed Boost.Local (functions)
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2011-02-02 03:06:13

Jeffrey Lee Hellrung, Jr. wrote:

> 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).

Yes, compile times are kind of a problem right now.
(We need bigger machines :P)

> If so, do you consider that a "plus" for (proposed)
> Boost.Local over, e.g., Boost.Phoenix?

(This is a biased statement.)
I personally don't like the macros to define Boost.Local functions, they are 
too verbose. I'd rather pay for higher compile times than having to use 
these macros.

However, for people liking this syntax, lower compile times are an absolute 
plus over the other ET based lambda libraries.

> 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.

Expression templates have the same order of visibility than any other header 
only library.
There us no use in discussing a theoretical possibility, we need benchmarks 
here :)

> 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.

That will be highly appreciated.

> 
> - Jeff
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost