Subject: Re: [boost] [Boost-users] [Fit]Â formal review starts today
From: Paul Fultz II (pfultz2_at_[hidden])
Date: 2016-03-09 13:15:42
On Wednesday, March 9, 2016 at 2:13:54 AM UTC-6, work wrote:
> On 2016-03-09 18:34, paul Fultz wrote:
> >> On Tuesday, March 8, 2016 4:58 PM, Vladimir Batov
> > Maybe I need a little more explanation of components in the Quick Start
> > Guide.
> > Perhaps, also, a comparison of writing some of the examples without
> > using the
> > library...
> I think that's an excellent idea.
I do a comparison of something similar here:
> >> ... 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?
Well the bind should be unnecessary. You should be able to write:
std::accumulate(v.begin(), v.end(), 0, &std::max<int>);
I guess this is not the best example. In generic code, you may not know that
the container is a container of ints, so by passing along
`BOOST_FIT_LIFT(std::max)`, the types will be deduced. There are other cases
where the types have to be deduced, because the type are either unknown to
callee or is called with different types. If it were an algorithm over
not everything will be `int`, so its not as easy as writing `std::max<int>`.
> >> "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.
Well you create function globally, and these are just functions, the
same misuse that applies to functions applies here.
> 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.
These functions are initialized at compile-time and must be ConstCallable,
if data is added to the functions it must be initialized without
and cannot mutate the data when the function is called.
> > First, by making them objects we can turn functions into first-class
> > citizens.
> Why can't I use the standard binders to achieve that?.. Or what do I
> gain by using Fit instead?
Bind is a simple form of lambda expressions, so you can express a lot with
lambda expressions. Futhermore, the library provides the lazy adaptor which
works just like std::bind with the addition of being constexpr-friendly.
However, there is a lot that you can't do with bind. You can't do
nor recursion nor projections with bind. Even though you can do composition
and partial application, there can be complications when dealing with nested
bind expressions. So sometimes, its better to have a component that can just
handle composition or just handle partial application. Also, bind cannot
handle variadiac parameters as well.
> > 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 think it would be could idea to compare the library to the capabilities
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk