title: What is the expected relation of C++ modules and dynamic linkage?
body: <p>The C++ modules TS provides an excellent facility for eliminating the preprocessor, improving compile times, and generally supporting much more robust, modular, code development in C++, for non-template code at least.</p>
  
  <p>The underlying machinery provides control over import and export of symbols in ordinary programs. </p>
  
  <p>However, there is a <em>major</em> problem developing libraries for two kinds of dynamic loading: startup time loading, and run time loading. This problem involves the exporting of symbols from the library, which is often discussed in terms of visibility.</p>
  
  <p>Generally, not all the extern symbols of the translation units used to construct a dynamic link library should be made visible to the user. In addition, with run time loading, especially with a plugin concept, the same symbol must be exported from many concurrently loaded libraries. </p>
  
  <p>On Windows the use of language extensions</p>
  
  <pre><code> __declspec(dllexport)
   __declspec(dllimport)
  </code></pre>
  
  <p>attached in source code as attributes of symbols, and more recently on gcc and clang systems on unix platforms, the use of</p>
  
  <pre><code>__attribute__((visibility("default")))
  __attribute__((visibility("hidden"))) 
  </code></pre>
  
  <p>are intended to support the provision and use of symbols intended to be made public by the library. Using these is complicated and messy: on Windows macros must be used to export the symbols whilst compiling the library, but import them when using it. On the unix platforms, the visibility must be set to default to both export and import the symbols, the compiler deciding itself, based on whether a definition is found or not: the compiler must be invoked with </p>
  
  <pre><code>-fvisibility=hidden 
  </code></pre>
  
  <p>switch. The export/import attributes are not required for static linkage, and probably should be macro'd out to an empty string. Making code and fiddling the build system so that this all works, especially considering that #includes must have the correct symbol visibility set during compilation of library translation units is very hard, the file structure required in repositories is a mess, the source code is littered with macros, and in general .. the whole thing is a disaster. Almost all open source repositories FAIL to correctly export symbols for dynamic linkage, and most programmers have no idea that dynamic library code structure (using two level namespaces) is quite different to static linkage.</p>
  
  <p>An example of how to do it (hopefully correctly) can be seen here:</p>
  
  <p><a href="https://github.com/calccrypto/uint256_t" rel="noreferrer">https://github.com/calccrypto/uint256_t</a></p>
  
  <p>This repository used to have 2 headers and 2 implementation files, the user of the built library would see 2 headers. There are now 7 headers and 2 implementation files and the user of the built library will see 5 header files (3 with extension <code>include</code> to indicate they're not to be directly included).</p>
  
  <p>So after that long winded explanation, the question is: will the final C++ modules specification help to solve problems with export and import of symbols for dynamic linkage? Can we expect to be able to develop for shared libraries without polluting our code with vendor specific extensions and macros?</p>