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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk