Re: [Flyweight] Hidden symbol visibility

From: Joaquin M López Muñoz (joaquinlopezmunoz_at_[hidden])
Date: 2021-02-08 09:05:24

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")?

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.

> 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 
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::flyweight<std::string,visible_static_holder> fw("hello");

Joaquín M López Muñoz