Re: [Flyweight] Hidden symbol visibility

From: Deniz Bahadir (deniz.bahadir_at_[hidden])
Date: 2021-02-08 12:35:33

Am 08.02.21 um 10:05 schrieb Joaquin M López Muñoz via Boost:
> 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.

You guessed right.
We are developing on and for Linux and do not really care for Windows 
compatibility.

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

Thanks, I thought about doing it like so.
I might give it a try. Although, if `intermodule_holder` really has no 
real runtime-disadvantage we might just switch to using it. (Some of my 
colleagues would prefer to not rely on "unique global symbols".)

>
> Joaquín M López Muñoz 

Thanks a lot, Joaquín.

Deniz

-- 
BENOCS GmbH
Dipl.-Inform. Deniz Bahadir
Reuchlinstr. 10 D
10553 Berlin
Germany
Phone: +49 - 30 / 577 0004-22
Email: deniz.bahadir_at_[hidden]
www.benocs.com
Board of Management: Stephan Schroeder, Dr.-Ing. Ingmar Poese
Commercial Register: Amtsgericht Bonn HRB 19378