El 07/02/2021 a las 16:36, Deniz Bahadir via Boost escribió:
[...]
In our company's code base we have been using Boost.Flyweight for several years now, compiling it with GCC (and Clang) and it worked just fine. (Thanks for it!)
However, lately we are trying to apply hidden symbol visibility to our code base and some of our unit-tests started failing mysteriously. After some intensive investigation I found out that it seems to be due to how we used Boost.Flyweight.
We are instantiating it with some custom types, using the default `boost::flyweights::static_holder` class, and are compiling it into a shared library A. However, these Boost.Flyweight types are not only used within that shared library A but also in some other shared library B and in some unit-test executables which link against shared library A. (And these unit-tests started failing.)
[...]
1. However, apart from longer program startup times, what other disadvantages might it have to use the `intermodule_holder` instead of the `static_holder` (assuming it still would be marked as "unique global symbol")?
2. And if, as it seems, `static_holder` has some advantages in general, would it be possible to (maybe conditionally) mark the `static_holder` (and/or `static_holder_class`) class with `BOOST_SYMBOL_VISIBLE` or something similar to allow using it even with hidden symbol visibility from different shared libraries? - Only applying default visibility to the template instantiations is ignored by GCC (with warning: "type attributes ignored after type is already defined [-Wattributes]"). - Besides, the C++ standard does not allow applying C++ attributes to template instantiations. (There was a proposal for allowing it, wg21.link/p0537, but I do not know what happened to it.) You can't make static_holder visible without changing Boost.Flyweight
None in principle, other than, as you say, longer startup times. intermodule_holder relies on boost::interprocess::ipcdetail::intermodule_singleton, which is notably complex. As for the advantages, intermodule_holder is compatible with Windows, where you don't have symbol visibility attributes. I guess this is not a concern to you. source code, but see below.
3. Would you have any other recommendations or suggestions I did not think about?
It's very easy to provide your own visible static holder: struct visible_static_holder:boost::flyweights::holder_marker { template<typename C> struct apply { struct type { BOOST_SYMBOL_VISIBLE static C& get() { static C c; return c; } }; }; }; ... boost::flyweightstd::string,visible_static_holder fw("hello"); Joaquín M López Muñoz