Re: [boost] Boost.Local Review - comments by Andrzej

Subject: Re: [boost] Boost.Local Review - comments by Andrzej
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2011-11-15 12:00:30

On Tue, Nov 15, 2011 at 11:38 AM, Andrzej Krzemienski
<akrzemi1_at_[hidden]> wrote:
>> > One suggestion for the future, although I am not sure how useful it
> would
>> > turn out in practice is to have something like local expression, or
> even
>> > not necessarily a local one. This would be a function whose body
> consists
>> > of a single expression. The benefit you get is that the programmer does
> not
>> > need to specify a return type for it (you can use BOOST_TYPEOF for
> that),
>> > or doesn't even have to type keyword 'return', but this may be too much
> off
>> > topic.
>> Can you clarify with an example?
>
> In C++11 lambdas do not require specifying the return type, provided that
> the body of the function is a single return statement: because it is easy
> to deduce the type from such single return statement. Similarly, for
> Boost.Local if a function body consists of a single return statement you
> could (I guess) provide a more simple syntax. Instead of
>
>  BOOST_TYPEOF(sum) &   BOOST_LOCAL_FUNCTION_PARAMS(
>      double num,
>      const bind factor,
>      bind& sum
>  )
>  {
>      return sum += factor * num;  }
>  BOOST_LOCAL_FUNCTION_NAME(add);
>
> I could write:
>  BOOST_LOCAL_EXPRESSION_PARAMS(
>      double num,
>      const bind factor,
>      bind& sum
>  )
>  BOOST_LOCAL_EXPRESSION_END( add, sum += factor * num );
>
>
> You save me typing the return type and 'return' keyword. But now that I
> have written it down I do not think it is particularly useful.

I see. It _could_ look like this:

BOOST_LOCAL_NAMED_EXPR(
(add) ( double num, const bind factor, bind& sum ) (
    sum += facror * num
) )
double s = add(1.23);

or:

BOOST_LOCAL_NAMED_EXPR(add,
        double num, const bind factor, bind& sum,
    sum += factor * num
)
double s = add(1.23);

But I don't like neither one of them and I can't think of a nicer
syntax... Moreover, by putting the expression within the macro
(necessary for the macro to auto detect the eventual result type) you
pay the price of crazy pp errors if you make an error in programming
the expression.

>> I think in a nutshell the conclusion (which I will detail in the rest
>> of my comments below) was that Boost.Local is handy but on compilers
>> with C++11 lambdas you'd just use lambdas. At the same time,
>> Boost.Local allows you to write local functions that work also on
>> C++03 compilers and that have the same compile-time and run-time
>> performances of lambdas on C++11 compilers. So the /main/ audience
>> would be someone (like myself) that wants to do local function stuff
>> and expects lambda-like performances on C++11 but also has to deal
>> with C++03 compilers. There are other benefits like const& binding
>> which is not supported by C++11 lambdas (so how can I bind by const a
>> variable that has a very expensive copy constructor using C++11
>> lambdas?) and improve scope exit (i.e., local exit) but these other
>> benefits are probably minor in the general domain (they can be very
>> important or even essential is a specific and narrow domain like
>> Contract Programming but not critical in the general case).
>
> OK Lorenzo, I am convinced. Can we trade? I will vote 'yes', and you will
> add a motivation section in the documentation which will stress that the
> primary motivation of the library is to provide a uniform (in terms of
> syntax) support for local functions: fast and 'native' for C++11 compilers,
> and acceptable (using tricks) in older compilers. The library can be used
> directly or be a foundation for higher level libraries like Boost.Concept.

Sure, I will clarify the motivation in the docs even if you don't vote yet :)

> Review Managers,
> I am not really trading, I vote YES  for the Boost.Local and just request
> the motivation section in the documentation.

:)

> I think the situation of Boost.Local is similar to that of Boost.Move, and
> the latter was accepted into Boost. Also, having a library in Boost whose
> primary purpose is to serve as the foundation for other Boost libraries is
> not a precedent (I mean Boost.Proto and now Boost.Context).

Thanks a lot.
--Lorenzo