C++ Logo


Advanced search

Re: [isocpp-ext] How to provide functionality as both header file and module?

From: Daniel Ruoso <daniel_at_[hidden]>
Date: Wed, 25 May 2022 09:30:58 -0400
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

> 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

namespace mylibrary {
  class Component { ...

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


Received on 2022-05-25 13:31:10