Does BOOST_NO_EXCEPTIONS guarantee compatibility to -fno-exceptions?

Question

I want to use Boost.Filesystem together with -fno-exceptions. According to the Boost.Filesystem documentation it states that it supports the BOOST_NO_EXCEPTIONS macro.

However, the following snippet:

#define BOOST_NO_EXCEPTIONS

#include <boost/filesystem.hpp>

int main() {}

compiled with:

g++ -fno-exceptions boost_test.cpp

gives the error:

/.../boost/filesystem/operations.hpp: In constructor 'boost::filesystem::filesystem_error::filesystem_error(const string&, boost::system::error_code)': /.../boost/filesystem/operations.hpp:84:16: error: exception handling disabled, use -fexceptions to enable catch (...) { m_imp_ptr.reset(); }

I compile using gcc 5 and boost version 1.57 on Mac OSX (also tested on similar ubuntu setups).

I am wondering whether my understanding of BOOST_NO_EXCEPTIONS is right in that it should cover the usage of -fno-exceptions or whether it's simply there for the boost::throw_exception part?

Answer 1

Well, "no" is the obvious answer here, g++ cannot deal with the filesystem_error class. There's a humdinger in boost/filesystem/config.hpp:

//  throw an exception  ----------------------------------------------------------------//
//
//  Exceptions were originally thrown via boost::throw_exception().
//  As throw_exception() became more complex, it caused user error reporting
//  to be harder to interpret, since the exception reported became much more complex.
//  The immediate fix was to throw directly, wrapped in a macro to make any later change
//  easier.

#define BOOST_FILESYSTEM_THROW(EX) throw EX

This macro is used extensively in libs/filesystem/src/operations.cpp to throw exceptions. This is a show-stopper.

Fwiw, your sample program only appears to compile properly in clang and MSVC++, they only complain in their back-end about having to emit exception handling code, g++ does it in its front-end. No complaint from clang/msvc++ for this sample code since that exception handling code was already emitted previously, back when the boost libraries were built.

Which demonstrates another severe problem with your approach, you probably originally built boost without -fno-exceptions in effect. Not good.