Re: [lmi] Replacing boost with std C++11

[Greg Chicares]

On 2017-01-20 23:47, Greg Chicares wrote:
> On 2017-01-20 23:10, Vadim Zeitlin wrote:
> [...s/boost::bind/std::bind/...]
>> if you do run into any
>> problems with doing the straightforward replacement, it would, IMHO, be
>> worth replacing boost::bind with something else entirely rather than
>> leaving it be.
> 
> I'll try replacing boost::bind() with std::bind().
> 
> If that fails, I'll abort the task.

It was mostly straightforward:
 - s/boost::bind/std::bind/g
 - s/boost:ref/std::ref/
 - prepend "std::placeholder::" to _1, _2, ...
In one unit-test file, boost::bind() specified the return type, but
with C++11 we can must replace "<void>" with this atrocity:
  std::bind((void (product_database::*)(std::vector<double>&,e_database_key) 
const)&product_database::Query,&db,v,DB_MaturityAge)

> If it succeeds, then we should still replace std::bind() with something
> better.

That atrocity reminded me of the idiom "to sleep on firewood and taste gall".
After coding it in a single statement, I see the appeal of "something else
entirely" less as a theoretical luxury than a pragmatic imperative.

BTW, why the verbosely-named "placeholders"? Writing "std::" everywhere is
okay because it's short, but isn't almost everyone going to write
  using std::placeholders::_1;
anyway, defeating whatever encapsulation was intended?

Oh...and I see that C++17 plans to remove the currently deprecated
std::unary_function and std::binary_function. I had just been looking at
the last place where we use std::for_each():

    std::for_each
        (illustrator_names.begin()
        ,illustrator_names.end()
        ,illustrator(emission)
        );

and thinking that it's tidy enough and might as well be left alone
because rewriting it this way:

    for(auto const& i : illustrator_names)
        {
        illustrator(emission)(i);
        }

isn't an enormous improvement. But then I wondered why std::for_each()
seemed so tidy in this particular case, and realized that the reason
is that class illustrator derives from
  std::unary_function<fs::path const&, bool>
...but the reason it has that base class is to make std::for_each()
seem natural. Yet when std::unary_function is removed, we'll have to
make major, deep changes, and we'll lose all that for_each() goodness
anyway, so there's no reason not to make the above change now.