Boost logo

Boost :

From: John Maddock (jz.maddock_at_[hidden])
Date: 2022-04-05 16:50:20

>> 2) Can we share code content effectively between headers and
>> modules?  And by modules I mean "proper" ones: we should be able to
>> write "import boost.whatever;" rather than importing a header.
> This is possible and there's more than one way to do that. Both
> require an additional so-called module interface unit that defines the
> interface of a module (at least one per library).
> Option 1 is to export the public names through exported
> using-declarations in the purview of the module.
> Option 2 is a kind of preprocessor gymnastics in the existing headers
> to declare public names as exported when compiled from within the
> module interface unit. I've done that in the popular {fmt} library
> which is a so-called 'dual-mode library' (a term coined by me to
> describe the capability  of a library to be consumed as both a module
> and a traditional header)
Excellent, so it can be done, that was exactly what I was thinking of. 
Do you have  any feel for whether this improves performance and/or gets
much use?
>> 3) What directory structure should we all be using for module
>> definition files?
> Module interface units are just sources that require a special
> invocation at compile time.
Sure, but it's helpful for folks to know where to find stuff, we could
just put them under /src, but since they're completely orthogonal to
regular source files I would tend to opt for a separate directory.
>> 4) Do we have Boost.Build support yet?
> None afaik.
>> 5) What file extensions should we be using?
> Compiler vary here (msvc: .ixx, gcc: .cpp, clang: .cppm).
> SG15 seems to slowly converge towards .ixx. At least this is what I
> see in the SG15 meetings.
>> 6) I presume we would all use the boost.libraryname and
>> boost.libraryname.sub_feature naming convention with
>> boost.libraryname pulling in the whole library?
> A perfect situation for bikeshedding...
Green please, they're always green ;)
>> 7) Does anyone have a handle on the current state of std library
>> modularization?
> It is voted into the C++23 draft. Microsoft has an experimental
> implementation for ages, Stephan (STL) has this currently on his plate
> and is actively working on it. I expect this to see this Real Soon Now
> in msvc.
>> 8) Is there demand for this?
> I've tried to get a handle on a modularized Boost in the past year but
> its current implementation seems to be quite hostile towards modules.
>> And no doubt lots of other things I haven't thought of.
> There are a few pitfalls and things to consider if you want to use
> existing code in the modules world. I point out some of them in my
> talks last year (NDC, CppCon, Meeting C++). The last one from Meeting
> C++ 2021, "A (Short) Tour of C++20 Modules" is the most comprehensive
> and polished one, slides can be found on the Meeting C++ website. I
> gave a company training on topic that last week because the developers
> there are considering switching over to modules and were asking about
> the way forward, considerations to be taken into account, the state of
> the ecosystem, and all of my experiences in our daily use of modules
> in our company codebase.
Many thanks, John.

Boost list run by bdawes at, gregod at, cpdaniel at, john at