Re: [boost] [all] Request for out of the box visibility support

Subject: Re: [boost] [all] Request for out of the box visibility support
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2018-08-18 11:03:08

On Fri, Aug 17, 2018, 19:38 Robert Ramey via Boost <boost_at_[hidden]>
wrote:

> On 8/16/18 11:21 PM, Antony Polukhin via Boost wrote:
>
> This is a worthy idea.  Having a shared library/dll export only those
> symbols which are required is a big improvement for the user.
>
> But, there's much more to it than meets the eye.   I implemented this
> for the serialization library as it was a huge PITA.
>
> a) The syntax for marking up exported functions is different for
> microsoft and other compilers.
>

Yes, but BOOST_SYMBOL_* macro help a lot.

b) when a library is built on a lot of nested/inherited classes it
> becomes non-obvious what to export.
>

Yes, which is not the point for most of the Boost libraries from the above
list.

<...>

> f) There was a paper for the standardization committee which included a
> proposal to help addressing this stuff - but it failed to gain enough
> interest to get the problem addressed.  In fact, the whole issue of
> dynamically loaded shared libraries raises a bunch of interesting
> problems - are global static variables unique?, etc. .  The concept can
> be very, very powerful in creating large extendable applications, but
> the C++ language is silent on the whole issue.  It's a serious problem
> but too unpleasant to actually address.
>

Yes, that was my paper. I was hoping to update it and present again in the
committee next year. Things do not go smooth with shared libraries in the
EWG, so for this year I've changed the approach and made a proposal on
dynamic loading (based on Boost.DLL) for LEWG.

<...>

> g) Actually it's unclear to me how the -fvisibility switch enters into
> this.  VC doesn't have it.  I don't think it's actually necessary and
> I'm not sure how it alters the functioning of the visibility.  I know,
> read the rules.  But like a lot of stuff in C++ the understanding
> provided by the baroque rules evaporates the minute one has to
> investigate the next ball of yarn.  It's just not possible to understand
> all of C++ at one time.
>

You may assume that VC has it enabled by default and there's no way to
disable it. There are actually many differences in border cases, but
trivial cases work in the same way.

Robert Ramey
>