From d30e1a0e8f5e4f324e169d87908a5134a58aa449 Mon Sep 17 00:00:00 2001 From: Boris Kolpackov Date: Sun, 24 Sep 2017 16:41:37 +0200 Subject: Clarify header to module mapping in documentation --- doc/manual.cli | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) (limited to 'doc/manual.cli') diff --git a/doc/manual.cli b/doc/manual.cli index dd6f719..bc7bedd 100644 --- a/doc/manual.cli +++ b/doc/manual.cli @@ -1791,10 +1791,12 @@ existing codebases as well as supporting the dual, header/module interface for backwards-compatibility. Predictably, a well modularized (in the general sense) set of headers makes -conversion to C++ modules easier. As a result, it may make sense to spend some -time cleaning and re-organizing your headers prior to attempting -modularization. Inclusion cycles will be particularly hard to deal with (C++ -modules do not allow circular interface dependencies). +conversion to C++ modules easier. Inclusion cycles will be particularly hard +to deal with (C++ modules do not allow circular interface dependencies). +Furthermore, as we will see below, if you plan to provide the dual +header/module interface, then having a one-to-one header to module mapping +will simplify this task. As a result, it may make sense to spend some time +cleaning and re-organizing your headers prior to attempting modularization. Let's first discuss why the modularization approach illustrated by the following example does not generally work: -- cgit v1.1