From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2021-02-02 15:25:28
> Far better though, in my opinion, to replace all dynamic_cast with
> static_cast, and don't mark all vptr containing classes as always visible.
>
> This is because there are real problems with link times, ABI collision
> and poor codegen with BOOST_SYMBOL_VISIBLE. Those impact all users far
> more frequently than dynamic_cast, which nobody should be using in any case.
I'll ignore the controversial last sentence for the sake of the discussion.
The scope for BOOST_SYMBOL_VISIBLE (or the fixed _DECL) is narrow: It is
(according to my suggestion) to be applied to classes which the user may
catch or dynamic_cast.
Everything else (i.e. most of Boost) stays hidden with all benefits.
> I don't think it is for library authors to force semantics onto users in
> this area.
>
> If an end user asks for -fvisibility=hidden, they opt into everything
> that entails, footguns and all. All the library author can do is a best
> effort to not screw things up within their library if end users enable that.#
He opted into exporting/making visible only classes which need this.
And classes marked with BOOST_SYMBOL_IMPORT likely do need this.
"Likely" because of the already mentioned difference between ELF and PE.
By not declaring any class which may be caught or RTTI used (through
dynamic_cast) as VISIBLE we FORCE the user to not use -fvisibility=hidden
IMO this is unacceptable as there is no opt-out or partial change or
anything the user can do to make this work.
> Most Boost libraries clearly document whether they depend on RTTI or
> not. If they do, you can't use either -fvisibility=hidden nor -fno-rtti.
The Boost library does not depend on RTTI, the interaction between the
user library and the boost library does.