remove boost dependency as much as possible

[KrisThielemans]

We're having problems with conflicts with boost versions. This is a serious problem for the boost libraries that are compiled (i.e. not header-only), see e.g. #240, although header-only libraries could still throw up surprising things.

Doing this completely might be hard, but we should at least aim to get rid of explicit includes of boost in our .h files. That way, the boost dependency could be made private. But far better would be to get rid of it completely.

It seems to me that there are at present only few places where we use boost. For instance, in our .h files.

find ../../.. -type f -name \*.h -exec grep -nH -e boost/ {} +
../../../src/xGadgetron/cGadgetron/cgadgetron_shared_ptr.h:24:#include "boost/shared_ptr.hpp"
../../../src/xGadgetron/cGadgetron/gadget_lib.h:35:#include <boost/algorithm/string.hpp>
../../../src/xGadgetron/cGadgetron/gadgetron_client.h:33:#include <boost/asio.hpp>
../../../src/xGadgetron/cGadgetron/gadgetron_client.h:34:#include <boost/shared_ptr.hpp>
../../../src/xGadgetron/cGadgetron/gadgetron_client.h:35:#include <boost/thread/mutex.hpp>
../../../src/xGadgetron/cGadgetron/gadgetron_client.h:36:#include <boost/thread/thread.hpp>
../../../src/xGadgetron/cGadgetron/gadgetron_data_containers.h:33:#include <boost/algorithm/string.hpp>
../../../src/xGadgetron/cGadgetron/gadgetron_x.h:38:#include <boost/thread/mutex.hpp>
../../../src/xGadgetron/cGadgetron/gadgetron_x.h:39:#include <boost/shared_ptr.hpp>
../../../src/xGadgetron/cGadgetron/xgadgetron_utilities.h:36:#include <boost/thread/mutex.hpp>
../../../src/xSTIR/cSTIR/stir_types.h:24:#include <boost/algorithm/string.hpp>
../../../src/Registration/cReg/SIRFReg.h:55:#include <boost/filesystem.hpp>
../../../src/Registration/cReg/SIRFRegMisc.h:33:#include <boost/filesystem.hpp>
../../../src/Registration/cReg/SIRFRegNiftyResample.h:40:#include <boost/filesystem.hpp>
../../../src/Registration/cReg/SIRFRegParser.h:37:#include <boost/filesystem.hpp>

Quite a few of these seem to be left-overs from the past. Most can and should be replaced by their std versions, in particular uses of boost/shared_ptr.hpp. Hopefully mutex as well.

SIRFReg depends on boost/filesystem. Sadly, std::filesystem exists from C++-14 only. I'm a bit reluctant to require C++-14, although Gadgetron does it now anyway. I suggest to do a CMake check on existence of std::filesystem, and only use boost::filesystem if we need to.

If we cannot remove the dependency completely, a trick to get rid of it in the .h files is to use pre-declaration in the .h, and include it in the .cpp. This works for pointers and references. So, as opposed to have a boost::filesystem member, we could have a std::shared_ptr<boost::filesystem>. That's a bit ugly though.

[KrisThielemans]

Actually, std::filesystem is C++-17. It currently still causes extra trouble with gcc due to extra linking requirements.

@rijobro how useful was boost:filesystem for you? @NikEfth write a FilePath class for STIR to provide some similar functionality. If we're desperate, we could use that in SIRF somehow (splitting it off from STIR or whatever)

[ashgillman]

I think my changes to the geometry pulled in boost for linear algebra. I could use something else.

[KrisThielemans]

I should have said “dependency on compiled boost libraries”. Include-only ones are fine as far as I can see.

[rijobro]

@rijobro how useful was boost:filesystem for you?

I can get rid of it pretty easily.

How do I know if each aspect of boost that I'm using is just from the header, or requires the compiled Boost libraries?

If I remove all CMake lines akin to target_link_libraries(SIRFReg Boost::system Boost::filesystem) from my code, does that mean that it can only access the uncompiled headers? The SIRFReg code compiles fine without those CMake lines.

[KrisThielemans]

not sure if there's an easy way to find out if it's header-only, except by checking...

I'm somewhat amazed that you don't need to link to boost::filesystem, but I'd be a bit warry of using boost/filesystem headers and not linking to it. it's going to break at some point/with some version.

Obviously, boost is useful. but if dependence is really small, I'd try to cut it out. Might be worth having a look at stir::FilePath.

or we can get Mathworks to do the proper thing and link privately/statically...

[rijobro]

Ok. Well I've removed linking to the boost libs (58f4f55). If this becomes a problem as the boost version changes, I'll cross that bridge when I get to it.

[KrisThielemans]

Another motivation is at SyneRBI/SIRF-SuperBuild#161

[KrisThielemans]

@evgueni-ovtchinnikov could you check if we actually need #include <boost/algorithm/string.hpp> (see above). I don't think it's used.

[KrisThielemans]

At present, our CMake files force linking with Boost::system Boost::filesystem Boost::thread Boost::date_time Boost::chrono, see e.g. here. My impression is that we only need thread, but this depends on system and chrono (and header-only datetime). (More info on dependencies here

Of course, even if we don't really need to link with datetime, CMake has its own ideas on dependencies and will require it anyway.

Seems that we can get rid of filesystem though.

[evgueni-ovtchinnikov]

<boost/algorithm/string.hpp> defines iequals, which we use

[KrisThielemans]

let's

• create our own iequals e.g. like here such that we can remove string.hpp/
• replace boost::mutex with std::mutex
• remove boost/shared_ptr.hpp

but leave the rest as-is for now (boost::asio is header-only, boost::shared_ptr as well and is only used for old STIR, and apparently filesystem can be used header-only as well).