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: https://github.com/boostorg/outcome/blob/15ec857dd65dfbb710d33bd567ee3f14c62...
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 same?