Notes taken at the C++ modules BoF
Attendees: 91
Semi-BoF on modules & header units
- header units
- build performance (several 100K files of tokenizing/processing), imports become very low cost
- protection from pollution with preprocessor noise
- protection of accidental exports
- makes it harder to violate ODR
- similar to PCH but language native
see https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/devel/c%2B%2B-modules
- header-units compiled into cached artifact, not an object file / redistributable
- relies on ODR rather than #ifdef guards
- ODR tricky with anonymous types (enums!)
- ODR even applies across modules that might import locally consistent but globally conflicting type definitions
- inline functions declared static vs. used/exported hacked around in specs
- g++ on branch starting to detect/check above cases
- requires building first; need enumeration facility ("what header units exist?")
Kernel vs. glibc
headers sometimes conflict, in annoying & irrelevant ways; glibc being relatively constrained by POSIX, kernel less so
- might need a glibc-specific namespace wrapper to fully isolate the two
- c++ committee thinking about c++ module wrapping for glibc
- -flto already encounters some of these conflicts
- gcc middle-end may consider types equivalent more so than at the language level
Iain Sandoe, conditional code in one or other header? Not likely due to e.g. consistency with printf formatting directives (long long => %lld).
- DJ, why not intXX_t? Different language level types, plus historical compatibility length-varying "long" decls.