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

[Vadim Zeitlin]

On Fri, 20 Jan 2017 22:57:38 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2017-01-20 19:25, Vadim Zeitlin wrote:
GC> > On Fri, 20 Jan 2017 18:07:49 +0000 Greg Chicares <address@hidden> wrote:
GC> [...]
GC> > GC> I haven't given any thought to <boost/bind.hpp>
GC> > GC> yet, but this article:
GC> > GC>   
http://stackoverflow.com/questions/10555566/difference-between-c11-stdbind-and-boostbind
GC> > GC> seems hopeful.
GC> > 
GC> >  I'd strongly prefer to get rid of bind() completely rather than just
GC> > replacing boost::bind with std::bind.
GC> 
GC> Yes, that should be our goal. Still, if I can do a simple change
GC> like s/boost::bind/std::bind/g and it works, then that achieves
GC> the minor goal of reducing dependency on boost at little cost.

 I'm not sure if replacing boost::bind with std::bind is as simple as that.
At least I remember running into problems when doing this due to the
differences of placeholders handling when doing it in another project. But
this was already several years ago and, AFAIR, I was using std::tr1::bind
and not std::bind itself, so maybe the problem was really due to this
(especially as I also used Boost.TR1 on some platforms).

 To stop rambling, what I meant to say was that 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.

GC> And let's include std::transform() etc., too. For example:
GC> 
GC> // TODO ?? Replace these long lines with PETE expressions.
GC>     // ET !! miscellaneous_charges += AmortLoad_ + ExtraSepAcctCharge_;
GC>     std::transform(miscellaneous_charges.begin(), 
miscellaneous_charges.end(), AmortLoad_         .begin(), 
miscellaneous_charges.begin(), std::plus<double>());
GC>     std::transform(miscellaneous_charges.begin(), 
miscellaneous_charges.end(), ExtraSepAcctCharge_.begin(), 
miscellaneous_charges.begin(), std::plus<double>());
GC> 
GC> Replacing the names with simpler ones, we have double-precision
GC> vectors X, A, and B, and we wish to do this:
GC>     X += A + B; // If we had the expressiveness of, say, FORTRAN.
GC> which can be expressed tersely and elegantly in C++98 thus:
GC>     std::transform(X.begin(), X.end(), A.begin(), X.begin(), 
std::plus<double>());
GC>     std::transform(X.begin(), X.end(), B.begin(), X.begin(), 
std::plus<double>());
GC> The question is whether to use PETE for that. That seemed like the
GC> obvious thing to do years ago; I just never found the time.

 I don't think we need PETE for something as simple as this and I'm not
sure if using it would still allow the compiler to auto-vectorize the loop
as it would definitely do if we wrote an explicit one here. This is really
compiler-dependent and, of course, only really matters for big vectors, but
the benefits of auto-vectorization, i.e. of use of SIMD instructions to do
the operation on several vector elements at once, are enormous, so if we
really care about performance we simply must explore this.

GC> PETE lets us write many simple APL expressions pretty well, but
GC> bind() doesn't really let us write decent Haskell.

 No, for this we'd need Rust.
VZ