Boost logo

Boost :

From: Daniela Engert (dani_at_[hidden])
Date: 2022-04-05 13:09:38

Hi John,

thanks for bringing up the topic of C++20 modules in the realm of Boost!

Am 05.04.2022 um 13:58 schrieb John Maddock via Boost:
> The title says it all really, but in more detail:
> 1) Is there any existing best practice we should follow yet?

WG21 SG15 is about to come up with a document on that. Until then, I've
touched this in my Meeting 2019 talk on modules, "Modules - the
beginner's guide"

Boost should be pretty safe here in general.

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

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

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

 Â  Dani

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