Boost logo

Boost :

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

Am 02.02.21 um 15:21 schrieb Niall Douglas via Boost:
> On 02/02/2021 14:06, Alexander Grund via Boost wrote:
>> Why do individual libraries now have to deal with the Windows vs
>> non-Windows case? Is there ANY Boost library which does this?
> Outcome is correct on this. I think any of Dave's original libraries are
> correct on this, or at least, were once.
Ok, found an exception class there:

It is marked with BOOST_SYMBOL_VISIBLE, so we seem to agree, that this
is required for all user visible classes that are errors/exceptions or
virtual (and hence might be subject to dynamic_cast)
So this leaves the IMPORT/EXPORT only for classes, which are non-virtual
and have non-inline members.

Correct so far?

What about classes, which have a non-inline function, e.g. the recently
mentioned exception class with a non-inline `what()`?
Wouldn't that need to be IMPORT/EXPORT declared for Windows? And VISIBLE
for Linux (to be caught)? So would you need both here?

> Hidden symbols are subject to much more aggressive optimisation than
> default visibility symbols. So yes, this is intentional.

I'm aware of that. But I'm looking for a correct solution, i.e. one that
works across platforms. That it seemingly works on Linux seems to be
caused by a change to string comparison instead of "real" RTTI
comparison. The question is: Should it work, or has it always worked?
I mean we have one TU (in the shared lib) where the symbol is visible
and one (in the exe) where it is not. So how could the RTTI here be the

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