From: Gavin Lambert (boost_at_[hidden])
Date: 2020-08-24 08:27:46
On 24/08/2020 06:34, Mike wrote:
> Not sure to which of the two suggestions you are replying, but I really
> don't understand why it should require any work for most of boost
> (except maybe the PP library) to be consumable as a header unit.
I haven't really been following modules, so someone please correct me if
I'm wrong, but I thought that the point was that they insulated both the
inside and the outside from stray symbols.
So if the module interface prefix explicitly #includes a "config.h" file
then any symbol in that will be visible to both users of the module and
the implementation of the module; but if user code #included "foo.h"
before importing the module then anything in foo.h would not be visible
inside the module. Similarly for #defining anything outside the
Most of Boost.Config and other macros would be fine with this, since
they're detecting compiler capabilities that aren't really customisable
(although some may depend on compiler parameters, which gets tricky;
this includes things like -std=).
But this would break a lot of other configuration macros like
BOOST_NO_EXCEPTIONS and BOOST_THREAD_VERSION (where they exist
explicitly for the app to indicate a preference, or are intended to be
influenced by both capabilities and preferences).
Perhaps if Boost.Config always explicitly included some well-known
header file name (that could somehow be overridden by the app), with a
requirement to put all config macros only in there. But then whatever
builds the modules would need to happen on a per-consuming-app basis
(which may defeat people who want to run b2 only once to build all the
libraries and then consume them from multiple apps).
I think you can still do the ABI-namespacing tricks to work around some
of this (such as having your module export both "v1" and "v2" at all
times in different namespaces, but then use macros in a plain header
file to control which are actually visible to the consuming code via
aliases based on the #defines in effect at the time). But this seems to
me to at some level defeat the point of doing modules in the first place.
If modules do end up requiring an explicit build step then they also end
up turning "header only libraries" into just another kind of static
library -- with some advantages and disadvantages over real static
libraries, perhaps, but mostly disadvantages over traditional
Hopefully, I'm missing something.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk