Boost is huge, and of variable quality. It was originally intended as a proving ground for things that people wanted to get into the C++0x standard and it succeeded – smart pointers, regexps, traits are all in C++11/14.
Now that mainstream compilers support C++11/14, I think we should ask if we still need boost. It’s a significant build dependency. Things that I found in afw (and aren’t in the new std library) are:
- boost::test I’d be happy to see it replaced by some other framework (google?)
- boost::mpl We don’t use much, and the traits in C++11/14 may make the transition easy
- boost::multi_index I know @jbosch likes this one. Can we fork-and-port it?
- boost::gil We use tiny bits of this in the afw image classes. I think we can replace it with a very small piece of home-brew C++
- boost::any only in an RHL internal fits writer; easily replaced
#include “boost/array.hpp” // not used?
#include “boost/assign/list_of.hpp” // not used?
- boost::hash Used in the Mask code.
- boost::geometry In src/geom/polygon/Polygon.cc
- boost::lexical_cast See http://stackoverflow.com/questions/23582089/is-boostlexical-cast-redundant-with-c11-stoi-stof-and-family
- boost::math::constants, boost::math::special_functions
- boost::preprocessor Convenient, but must be self contained.
- boost::archive, boost::serialization // Long gone?
- boost::timer tests only? If so, move to python
- boost::variant Used in afwTable
Will think about some of the others later. For now:
boost::any: also used in
PropertySet, I think.
boost::format: I’ve been using https://github.com/cppformat/cppformat in another project as a C++ string formatting library, and I quite like it. It’s tiny (embeddable, even), and it claims to be high performance (I haven’t verified).
boost::hash: I think C++11 handles this.
boost::serialization isn’t quite dead yet; it’s the only way we have to serialize some important things (at least
PropertyList, but I may be forgetting something else).
boost::variant: I’d like to get rid of this anyway, as I think it will make the library better, but it’s a fair amount of work.
Jim and I discussed this again a couple of days ago. Quite a few of the boost libraries that we use are header-only. If we can remove all the compiled libraries boost would be much less of a problem.
Note that std::regex is pretty meagre compared to boost::regex; and is std::regex isn’t even supported under gcc 4.8. I think we’ll need to stick with boost::regex until we can retire gcc 4.8 at least.
Data replication services being developed for qserv right now are making significant use of boost::asio, (header only) and I don’t know of an acceptable alternative for heavy-duty asynchronous socket programming? I expect boost::asio might show up soon in some other parts of qserv as well.
boost::property_tree, boost::filesystem, boost::range, and boost::iterator also offer some pretty convenient things for qserv.
boost::property_tree, boost::filesystem, boost::range, and boost::iterator
My guess is that
filesystem isn’t, but the others are.
yesterday @ktl said that PropertySet (and PropertyList) can be rewritten to be pure python. I don’t know how long we’ll have to be backward compatible though.
We definitely use
PropertyList in C++ right now (they’re fairly important components of
SourceCatalog, and play a big role in
Wcs constructor). I don’t think it’s impossible to get them to a pure-Python state eventually, but it’ll take some significant reworking of other classes first, to at least move some part of their persistence implementation out of C++.
No, no! I said that the persistence of those can be rewritten to be pure Python. The underlying classes will likely need to be C++ for quite a while.
hah! ok. thanks for clarifying.