Re: [boost] Boost.Local Review - comments by Andrzej
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 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. 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). Regards, &rzej
On Tue, Nov 15, 2011 at 11:38 AM, Andrzej Krzemienski <akrzemi1@gmail.com> 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
On Tue, Nov 15, 2011 at 8:38 AM, Andrzej Krzemienski <akrzemi1@gmail.com>wrote: [...]
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).
Duly noted. - Boost.Local Review Manager aka Jeff
participants (3)
-
Andrzej Krzemienski -
Jeffrey Lee Hellrung, Jr. -
Lorenzo Caminiti