Boost logo

Boost :

From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2021-02-02 14:06:34

> This means that BOOST_PROGRAM_OPTIONS_DECL is incorrectly defined.
> So, the bottom line, BOOST_PROGRAM_OPTIONS_DECL must be defined to:
> - BOOST_SYMBOL_EXPORT - on Windows, when the library is being built;
> - BOOST_SYMBOL_IMPORT - on Windows, when the library is being consumed
> by user;
> - BOOST_SYMBOL_VISIBLE - in any other case.
> Then you can use BOOST_PROGRAM_OPTIONS_DECL to mark methods and
> classes that you want to be exported/imported from the library. If a
> particular type does not need to be exported/imported, but whose RTTI
> must still be accessible across library boundaries, mark that type
> still use BOOST_PROGRAM_OPTIONS_DECL to export/import select methods
> of that type, if needed.
> PS: I remember someone saying that on recent Windows
> dllexport/dllimport attributes are no longer necessary. I don't quite
> know how that works, but for backward compatibility we should probably
> keep using BOOST_SYMBOL_EXPORT/BOOST_SYMBOL_IMPORT as described above.

I thought that BOOST_SYMBOL_EXPORT and BOOST_SYMBOL_IMPORT are exactly
for this: You define *_DECL to *_EXPORT when building the library and
*_IMPORT otherwise (and <empty> for static linking)

Why do individual libraries now have to deal with the Windows vs
non-Windows case? Is there ANY Boost library which does this?

 From the BOOST_SYMBOL_VISIBLE description: "Needed for classes that are
not otherwise exported, but are used by RTTI". This sounds to me like
Now I'm left to wonder why individual libraries must now distinguish
between OSes additionally to their *_DYN_LINK.

And if Boost.Config is correct: What does BOOST_SYMBOL_IMPORT (on
non-Windows) mean then? If the default visibility is set to hidden
(-fvisibility=hidden), then this macro will NOT import an exported
symbol, it will create a new, private one.
This doesn't sound intentional.

Boost list run by bdawes at, gregod at, cpdaniel at, john at