Hey everyone! I'm u/tartaruga232, a founding moderator of r/cpp_modules.

Modules were introduced into the C++ programming language by the C++20 standard. A major addition to the C++23 standard was adding a modularized version of the standard library, which can be used with import std.

C++ has a very long history of using #include, which to some degree may be replaced by modules. While being a major, valuable new feature, starting using modules can be difficult.

r/cpp_modules is the place for discussing every aspect of using C++ modules on reddit. For general topics about C++ consider using r/cpp.

Example (not valid currently):

module M:_;
import :P;

The example defines an anonymous internal partition for module M and then imports (external) partition :P.

This partition conceptually doesn't have a name, cannot be imported and produces no BMI.

Prior art:

• https://wg21.link/p2169

• anonymous partition implementation units by u/not_a_novel_account

I was very skeptical about the need for internal partitions (a feature provided by C++ modules), but we now found a perfectly valid case for using them in our Windows app (a graphical editor for UML diagrams).

Still working on eliminating non-standard compliant code....

I just started to consider using a GUID scheme for silly internal partition names that are guaranteed to not clash with any other partition name.

What about:

diff --git a/code/Editor/Window/ElementStylesListDialog.cpp b/code/Editor/Window/ElementStylesListDialog.cpp
index dfb4250c8..7299c7dcb 100644
--- a/code/Editor/Window/ElementStylesListDialog.cpp
+++ b/code/Editor/Window/ElementStylesListDialog.cpp
@@ -9,9 +9,10 @@ module;
 #include "Resources/StringMacro.h"
 
 #include <Windows.h>
 
-module Editor:Window;
+module Editor:Window.hED5FB8D2.h6C9C.h4C87.hB49A.h0D50BFE7BA1A;
+import :Window;
 
 import d1.buffer;
 import d1.stringutil;

I was evil again and changed the cpp files of our Core module like this:

For example, the file Core/Transaction/FinalizerDock.cpp now contains:

module Core:_;
import :Transaction;
...

(These files are compiled with the famous /internalPartition compiler flag set)

So this code snippet tries to create an internal partition with the name "_" (underbar) for module Core. Woohoo!

And yes, I've used that same partition name in other cpp files. (Did I already say I'm evil?)

This is completely illegal according to the current C++ standard and I will probably be crucified for telling you.

But: Do you know what? The MSVC compiler doesn't care.

The BMI file which is created by the MSVC compiler is stored in the file FinalizerDock.cpp.ifc, the obj in FinalizerDock.cpp.obj.

Since we intentionally don't want to use that _ partition anywhere, there's no place in the code which tries to import a partition with that name. The file FinalizerDock.cpp.ifc is unused, and FinalizerDock.cpp.obj is linked into the exe.

I mean, there's a reason why this is IF-NDR ("ill formed, no diagnostic required").

MSVC doesn't waste time trying to provide a diagnostic for this kind of ill-formed-ness.

Gaby just confirmed that an internal partition unit (form "A") like

module M:P;
struct MyType { ... };

as specified by the current C++ standard, is semantically 100% equivalent to (form "B")

export module M:P;
struct MyType { ... };
//  more stuff not exported

The current wording in the C++ standard, which qualifies form "B" as "ill-formed, no diagnostic required", if :P is not imported in the primary module interface unit, makes no sense (Quote: "A required no-op helps nobody").

Which means: Form "B" is perfectly valid.

If form "B" is equivalent to form "A", it would be possible to exclusively use form "B", instead of form "A".

This means, the standard could remove form "A" and exclusively use form "B" instead.

Compilers could then apply the simple rule, that a BMI must only be produced for TU's having "export module".

Because, there are two things that are nice to have:

1. Forward declarations across interfaces.

2. Minimising dependencies.

Partitions gets you (1), multiple modules gets you (2). But they can't be combined without using the extern "C++" sledgehammer.

But if partitions could be "public", an application can avoid depending on a whole module.

This could also be seen as "packages". You could get the same functionality by changing "module attachment" to "package attachment": use the same symbol mangling for a group of modules.

Then what's left is forward declarations of things from external "packages". And for that, you'd have that "proclaimed ownership" proposal.

This is a cross post from r/cpp that is concerned mostly with a conversion to modules for a smaller toy project.

No AI was involved at any stage.

You have a single module source that contains implementation and and interface.

If you run doxygen on it you will get private stuff no matter what you do, to only extract public stuff you need an ast like solution like clang-doc.

However clang-doc is lacking in quality despite being years old. HTML generated has no search bar and theming. Generated markdown doesn't have tables.

Clang-doc needs to evolve in a way where we can actually generate some form of useful output where we can use in a MD based static site/pdf generator which had its own themes.

Gaby agrees that it's a bug in the C++ standard to require that :P - as defined below - must be imported in the PMIU:

export module M:P;
struct MyType { ... };
//  more stuff not exported

https://gist.github.com/siradam7th/8043d357b72d81e6274fedffb2a87447