diff options
author | Boris Kolpackov <boris@codesynthesis.com> | 2017-09-24 16:41:37 +0200 |
---|---|---|
committer | Boris Kolpackov <boris@codesynthesis.com> | 2017-09-24 16:41:37 +0200 |
commit | d30e1a0e8f5e4f324e169d87908a5134a58aa449 (patch) | |
tree | 6d8028690f1ac53b235e5322a3239607cb0cfab3 /doc/manual.cli | |
parent | 668a41c89459b2a3962cf140aa18c711043f6159 (diff) |
Clarify header to module mapping in documentation
Diffstat (limited to 'doc/manual.cli')
-rw-r--r-- | doc/manual.cli | 10 |
1 files changed, 6 insertions, 4 deletions
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: |