Am 25. Mai 2022 15:30:58 OEZ schrieb Daniel Ruoso <daniel_at_[hidden]>:
>Em qua., 25 de mai. de 2022 às 01:19, Nicolai Josuttis via Ext
><ext_at_[hidden]> escreveu:
>> However, their code is not necessarily only used within projects that use a build system.
>> It is a little piece of functionality useful in all kinds of programs (a key attribute of header files today).
>
>This comes up even regardless of the requirement to have a build
>system or not. Any transition to modules will very likely require
>mixing usage via headers and usage via named modules in the same
>program.
>

Sure, the mix will never die.

But if an
 import MyLittleMod;
would just work in all compilers that support modules, they could just provide a module, which supports far better encapsulation.


>> They want to avoid double-written code or scripts to transform code form one format to another (header files to module or vice versa)
>> And they really do not want to deliver/provide two different files of C++ code for the same functionality.
>> Which results in the following question:
>> What is the best approach / trick / hack to provide single-source code that can be used as both header file and module?
>> Or should customers in situations like this not replace header files by something that supports modules at all?
>
>My understanding, and I'd like some confirmation, is that you can
>export a redeclaration from the global module fragment into the named
>module. So you'd end up with something like
>
>mylibrary/component.h
>```
>namespace mylibrary {
> class Component { ...
> };
>}
>```
>
>mylibrary/component.ixx
>```
>module;
>#include "mylibrary_component.h"
>export module mylibrary.component;
>namespace mylibrary {
> export class Component;
>}
>```
>
>That way a codebase that wants to start using `import
>mylibrary.component` while some of the source files still say
>`#include <mylibrary/component.h>` would have a reasonable transition.
>
>daniel

-- 
Nico Josuttis
(sent from my mobile phone)