Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.syntblaze.com/llms.txt

Use this file to discover all available pages before exploring further.

The global module fragment is a dedicated section at the beginning of a C++20 module unit used exclusively for evaluating preprocessor directives and including legacy header files. It acts as a structural bridge between the traditional preprocessor paradigm and the modern module system, ensuring that declarations from legacy headers are attached to the implicit global module rather than the named module being defined.

​
Syntax and Structure

The fragment is initiated by the module; directive and is strictly terminated by the module declaration (either export module <name>; or module <name>;). 
module; // Initiates the global module fragment

#include <iostream>
#include <vector>
#include "legacy_c_header.h"

#define INTERNAL_CONFIG_FLAG 1

export module core_system; // Terminates the fragment, begins module purview

// C++ declarations for the module begin here
export void initialize_system();

​
Technical Mechanics and Constraints

  • Content Restrictions: The global module fragment is restricted to preprocessor directives (#include, #define, #if, etc.). Writing direct C++ declarations (e.g., void foo(); or int x = 5;) lexically within this fragment is ill-formed. The compiler only accepts C++ declarations in this region if they are the result of expanding an #include directive.
  • Module Purview Isolation: The fragment exists outside the module purview. Entities declared within the included headers are attached to the global module, not the named module.
  • Export Restrictions: Because entities in the global module fragment do not belong to the named module, they cannot be exported by it. Consumers importing the named module will not transitively receive the declarations from the global module fragment.
  • Macro Hygiene: Macros defined or included within the global module fragment are visible to the code within the subsequent module purview of that specific translation unit. However, these macros are strictly stripped at the module boundary; they do not leak to external translation units that import the module.
  • Reachability vs. Visibility: While the declarations from the global module fragment are not exported (and thus not visible for name lookup by importers), they may become reachable if the module’s exported interface depends on them (e.g., an exported function returning a type defined in a header included in the fragment). Reachability allows the compiler to understand the memory layout and semantics of the type without polluting the importer’s namespace.
Master C++ with Deep Grasping Methodology!Learn More