From: Boris Kolpackov (boris_at_[hidden])
Date: 2024-04-09 18:07:55
Andrey Semashev via Boost <boost_at_[hidden]> writes:
> 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:
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?