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

Subject: Re: [boost] [all] Request for out of the box visibility support
From: Robert Ramey (ramey_at_[hidden])
Date: 2018-08-17 15:14:13

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.

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

c) when a library depends upon another library, it can become even more 
problematic.

d) when doing stuff like running gcc compiler creating shared library 
under windows things can get confused.

e) Our testing matrix doesn't display or maintain different results base 
on whether a test is being run with shared or static linking.  So the 
value of the test results is much diminished.  There are so many 
combinations that one must really depend upon the test results but these 
don't have the required information.

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.

g) In the absense of any guidence from the standard and compilers not 
being on the same page, there's an opportunity to create a boost library 
of macros, documentation, and macros and who knows what else.  We have a 
great starting point with John Maddox's work on the subject - which is 
what I depend on.  But still, the situation is so messed up, I would 
hope that can be expanded upon.

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.

Robert Ramey