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@constrainttec.com> 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, _2));
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 [1] . 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 several advantages.
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 citizens.
Why can't I use the standard binders to achieve that?.. You can. 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 functional programming SHOF * provide some mechanisms that help to define global high order functions 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, for example. We need to have more functions and ways to compose them. Fit goes in this direction. Best, Vicente [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0119r1.pdf