Subject: Re: [boost] [Boost-users] [Fit]Â formal review starts today
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2016-03-09 13:43:53
Le 09/03/2016 09:13, work a écrit :
> On 2016-03-09 18:34, paul Fultz wrote:
>>> On Tuesday, March 8, 2016 4:58 PM, Vladimir Batov
>>> <Vladimir.Batov_at_[hidden]> wrote:
>>> ... a functor. I
>>> think it happens pretty much automatically.
>> Well, the library provides help for that as well, because currently
>> in C++ you
>> can't pass generic functions to other functions, like this:
>> std::accumulate(v.begin(), v.end(), 0, std::max); // Compile error
>> However, BOOST_FIT_LIFT will let you do that:
>> std::accumulate(v.begin(), v.end(), 0, BOOST_FIT_LIFT(std::max));
> Isn't it resolved with
> std::accumulate(v.begin(), v.end(), 0, boost::bind(std::max<int>, _1,
> Seems like std binders take care of the generic functions'
> "awkwardness". Am I missing anything?
I want to type
std::accumulate(v.begin(), v.end(), 0, std::max);
There is a proposal that will make this code correct.
I believe that the closest to that is
std::accumulate(v.begin(), v.end(), 0, OSAFA(std::max));
Where OSAFA mean Overload Set As Function Arguments  . The macro
BOOST_FIT_LIFT tries to go in this direction.
You can always continue to use bind, but I prefer to don't have to add
the <int> annotation.
As said before, I'm for the use of macros when we have a future language
feature. We need to find a good name.
A user is not forced to use the macro if this goes against its style or
company coding rules/guidelines.
>>> "if we construct the class as a global variable"
>>> Should I be excited about it? Globals are often a royal pain. Do I want
>>> to construct it a a global variable?
>> Whats the pain about these Global variables? They are const, can be
>> namespaced, and work just like free functions. However, they do have
> I much prefer creating things locally to minimize the scope and the
> potential for mis-use. If I (or someone) create something (an object),
> there is a potential desire to stick some stateful info/data into it.
> Then, the complexity snow-balls as it becomes a bottleneck in
> multi-threaded env.
I believe that the library should NOT promote global functions or
variables. The library should just provide some mechanism that help to
define those global functions. IMO, most of the documentation should
ignore all these STATIC macros.
>> First, by making them objects we can turn functions into first-class
> Why can't I use the standard binders to achieve that?..
> Or what do I gain by using Fit instead?
This is better question.
I believe that we need to see the Fit library as two different concerns:
HOF * provide some high order functions that are useful when doing
SHOF * provide some mechanisms that help to define global high order
You can ignore the second part (SHOF - static high order function) if
you don't want to define global high order functions or if you prefer to
define a function object to this end.
The first part HOF, includes a lot of useful functions. IMHO the library
need yet some modifications here and there, but I find that there is an
added value for those that want to use functional programming.
>> skipped considerable chunk...
> What I seem to hear is that Fit helps to overcome some plain-function
> limitations. I think you might want to consider highlighting what Fit
> adds compared to the standard binders. I felt that quite a few of your
> examples could be done using those binders. I might be wrong though.
I don't think you can do all with binders, but maybe I'm wrong. Bind is
a way to transform a non high order function on one that is high-order.
Maybe you can show how binding can be used to define some of the
function the library provides, compose, fix, flow, ...match, partial,
We need to have more functions and ways to compose them. Fit goes in
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk