Andrey Semashev via Boost
On 4/9/24 17:33, Boris Kolpackov wrote:
export namespace n { __symexport void f ();
class __symexport C { ... }; }
Thanks for the example. So, if I understood correctly, this is the same as what we do now: define a macro for symbol markup that expands to either dllexport or dllimport, depending on whether the library is being compiled or consumed.
It is the same mechanism (a macro) but you only need to ever define it to dllexport, never to dllimport. This allows a build system to define this macro automatically. In the above example, you as the library author never need to worry about defining __symexport or any other macros that would ordinarily be defined during the build to distinguish between static/shared and building/consuming. In other words, you can treat __symexport as a pseudo-keyword for exporting symbols from shared libraries that "just works".
I'm assuming this is ok to have `f()` and members of `C` not defined in the module?
Yes, that doesn't matter. Here is an example: https://github.com/build2/cxx20-modules-examples/blob/named-only-import-std/... https://github.com/build2/cxx20-modules-examples/blob/named-only-import-std/... This works with both MSVC and Clang on Windows.
Also, will this work if the compiled library itself is built without modules?
I haven't personally tried to dllexport a using-declaration but I assume that's how the MSVC folks modularized their standard library so presumably it works, at least in MSVC. Maybe Stephan can confirm?