[boost] "Software Development using the C++ Boost Library", book in preparatiion

Subject: [boost] "Software Development using the C++ Boost Library", book in preparatiion
From: Jesse Perla (jesseperla_at_[hidden])
Date: 2010-02-16 09:46:59

Looks great to me.  A few comments:

---------- Forwarded message ----------
From: "Daniel J. Duffy" <ddu..._at_[hidden]>
Date: Feb 15, 12:55 am
Subject: "Software Development using the C++ Boost Library", book in
preparatiion
To: Boost Developers Archive

> 1.      Higher Order Functions
I used to use boost::function a lot, but now find myself using templated
classes with deduction of the function type instead and haven't used
boost::function for a long time .  I think when writing this section, it
would be nice to have a good sense of when type erasure using
boost::function is necessary.

I found that the main reason I was using boost::function was not type
erasure but rather that the types of the functions I was storing were
complicated so it was easier to stuff in a boost::function and then have an
easier way to reference the type.  After I started using auto, decltype, and
make_ functions, this became unnecessary.  Of course, you can't count on
people having "declype" or "auto", so my proposal would be to see if
BOOST_AUTO, etc. should be suggested as a temporary solution for people
without C++0X turned on.

One other thing worth thinking about here is whether you should plan for
standardizing on the tr1 namespace(and explain how to use boost::tr1).  This
might future proof the book as most mainstream compilers seem to have tr1
already. That said, I had a lot of problem with the tr1 library that comes
with the Microsoft compiler mixing boost functional programming libraries
and tr1::function/bind, so you might want to try things out before going
down this route.

> 6.      Utilities and other Libraries

I would love to see a short section on Fusion.   I have found Fusion very
useful and a good alternative to using type erasure for my applications.  Of
course, the numerical computing I do has almost everything known at compile
time which may distort my view.

Also consider type_traits and enable_if, and a minimalist use of MPL to
support managing overloads (mpl::and, not, if, etc.).  (a huge part of the
superb C++ Template Metaprogramming book is about  advanced features like
iterators or your own sequences, which isn't necessary for most users)