Subject: Re: [boost] Boost.Local Review - comments by Andrzej
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2011-11-15 11:38:42
> > One suggestion for the future, although I am not sure how useful it
> > turn out in practice is to have something like local expression, or
> > not necessarily a local one. This would be a function whose body
> > of a single expression. The benefit you get is that the programmer does
> > need to specify a return type for it (you can use BOOST_TYPEOF for
> > or doesn't even have to type keyword 'return', but this may be too much
> > 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(
const bind factor,
return sum += factor * num; }
I could write:
const bind factor,
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.
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).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk