Boost logo

Boost :

Subject: Re: [boost] "Software Development using the C++ Boost Library", book in preparatiion
From: Daniel J. Duffy (dduffy_at_[hidden])
Date: 2010-02-17 05:21:33


Thanks again for all the feedback. Here are some responses:
 
1. Phoenix: I'm sold :-) This will be a great library for applications. The chapter we had for Lambda is now for Phoenix. Nice that it can be used as a separate module. Maybe it should be a 1st-class library in its own right?
 
2. type erasure: I looked this term up but it seems as if it is similar to interface/device independent/ programming. In the past we built homemade Function and used it in combination with OO specialisation with virtual functions, Now boost Function is so much better. Mathematicians and engineers are used to functions and we adopt the same approach (e.g. using namespaces)
 
3. Ideally, we would like TR1 and boost to be as seamless as possible.
 
4. Fusion: I think this is useful, especially with Any?
 
5. Geometry: In a past life I worked in CAD, so I like it, although this could be a book in itself. An overview and a number of appropriate examples is something we could discuss. Many developers want to have a simple program to display their results.
A visualiser for multi_array would be great :-)
 
6. "Boost Library"; there are many libraries in the collection, What is the best description: "Boost", "Boost Suite" when referring to everything?
 
7. Numerical integration: I saw this extensive library in Vault. What is the status?
 
regards

Daniel

________________________________

From: boost-bounces_at_[hidden] on behalf of Jesse Perla
Sent: Tue 16-02-2010 15:46
To: boost_at_[hidden]
Subject: [boost] "Software Development using the C++ Boost Library",book in preparatiion

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)
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk