Abstract
While cramming all your code into a single source file is always possible (even for huge programs), a larger code base is far easier to manage if you organize related source code (functions, constants, types, and so on) into logical, composable units, each in their own files. Not least because you and others can then construct different applications out of these same building blocks. As of C++20, the composition unit of choice is a module.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Notes
- 1.
Because <string> predates C++20, it is not technically written as a module but as a header. It therefore also does not actually export any entities the way a true module would—at least not explicitly. Most C++ Standard Library headers, though—all except those that it inherits from C, such as <cmath> and <cctype> (see also Chapter 2)—can be treated and imported as if they were a module. All entities that these headers define then act as if they were exported from a module. Conceptually, it is therefore perfectly fine to think of <string> and most other Standard Library headers as a module. We refer to Appendix A for further details on the relation between headers and modules.
- 2.
Modules were only introduced in C++20. While export has always been a C++ keyword, module and import were not. To avoid breaking existing code, these two could not simply be turned into full-blown keywords like export, switch, or enum. That is, you are, technically, still allowed to use module or import as the name of a variable, function, type, or namespace. Of course, we strongly advise against doing so in new code. If you ever do have to use legacy entities named either module or import in module files, you may have to add the scope resolution operator :: (introduced later in this chapter) in front of their names at times to make the compiler accept your code (that is, you then may have to use ::module or ::import instead of module or import).
- 3.
When reading about modules, you may also encounter the term module unit instead of module file. We refer to Appendix A for the difference between translation units and source files.
- 4.
Don’t worry if you are not that familiar with Roman numerals: This section is about understanding the roman module, and not so much about understanding the implementations of the to_roman() and from_roman() functions.
- 5.
Unless that function is declared as inline with the inline keyword. Definitions of inline functions, like those of templates, are part of the module interface. We refer to Appendix A for a more detailed discussion of inlining and inline functions.
- 6.
Other examples include inline functions (whose definitions are required to be inlined at the calling sides) and constexpr functions (whose definitions are required for static evaluation). We discuss inline functions in more detail in Appendix A (available online).
- 7.
This is actually not entirely accurate; entities with internal linkage can never be used from outside the file that they are declared in, not even within the same module. But since creating entities with internal linkage is never really required when writing modules (in technical speak, it is far easier to simply give all nonexported entities module linkage), we do not discuss that possibility here yet. Refer to Appendix A for more details about the different types of linkage.
- 8.
Module implementation partitions are sometimes also called internal partitions.
- 9.
Not to be confused with Myspace™, once the largest social networking site in the world. (We checked: Myspace™ was originally stylized as “MySpace” and now as “myspace”; so, yes, given that namespace names are case sensitive, mySpace was still available!)
Author information
Authors and Affiliations
Rights and permissions
Copyright information
© 2020 Ivor Horton and Peter Van Weert
About this chapter
Cite this chapter
Horton, I., Van Weert, P. (2020). Modules and Namespaces. In: Beginning C++20. Apress, Berkeley, CA. https://doi.org/10.1007/978-1-4842-5884-2_11
Download citation
DOI: https://doi.org/10.1007/978-1-4842-5884-2_11
Published:
Publisher Name: Apress, Berkeley, CA
Print ISBN: 978-1-4842-5883-5
Online ISBN: 978-1-4842-5884-2
eBook Packages: Professional and Applied ComputingApress Access BooksProfessional and Applied Computing (R0)