Should we scrub the stack of all boost dependencies?

Data Management
#1

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:

  1. boost::test I’d be happy to see it replaced by some other framework (google?)
  2. boost::mpl We don’t use much, and the traits in C++11/14 may make the transition easy
  3. boost::multi_index I know @jbosch likes this one. Can we fork-and-port it?
  4. 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++
  5. boost::algorithm::trim_right_copy
  6. boost::any only in an RHL internal fits writer; easily replaced
  7. boost::filesystem::remove
  8. #include “boost/array.hpp” // not used?
  9. #include “boost/assign/list_of.hpp” // not used?
  10. boost::format
  11. boost::hash Used in the Mask code.
  12. boost::geometry In src/geom/polygon/Polygon.cc
  13. boost::iterator
  14. boost::lexical_cast See http://stackoverflow.com/questions/23582089/is-boostlexical-cast-redundant-with-c11-stoi-stof-and-family
  15. boost::math::constants, boost::math::special_functions
  16. boost::preprocessor Convenient, but must be self contained.
  17. boost::archive, boost::serialization // Long gone?
  18. boost::timer tests only? If so, move to python
  19. boost::variant Used in afwTable
#2

Will think about some of the others later. For now:

  1. boost::any: also used in PropertySet, I think.

  2. 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).

  3. boost::hash: I think C++11 handles this.

  4. boost::serialization isn’t quite dead yet; it’s the only way we have to serialize some important things (at least PropertySet and PropertyList, but I may be forgetting something else).

  5. 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.

#3

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.

#4

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.

#5

Are
boost::property_tree, boost::filesystem, boost::range, and boost::iterator
header only?

My guess is that filesystem isn’t, but the others are.

#6

Yup. For reference, the list can usually be found at e.g. http://www.boost.org/doc/libs/1_60_0/more/getting_started/unix-variants.html#header-only-libraries

#7

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.

#8

We definitely use PropertySet and PropertyList in C++ right now (they’re fairly important components of Exposure and 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++.

#9

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.

#10

hah! ok. thanks for clarifying.