On Thu, May 20, 2010 at 9:54 AM, Alexander Arhipenko <arhipjan@gmail.com> wrote:
On Thu, May 6, 2010 at 7:42 PM, Jürgen Hunold <juergen.hunold@ivembh.de> wrote:
Hi Beman,
Some comments on patch.
1) The first version of BOOST_SYMBOL_EXPORT/IMPORT macro had slightly different definition for gcc (something like this): #define BOOST_SYMBOL_EXPORT __attribute__((visibility("default")) #define BOOST_SYMBOL_IMPORT
Assume that I've built boost filesystem library with hidden visibility. After that I've used boost filesystem functionality in my custom shared library foo (also build with hidden visibility). Assume also that boost filesystem was used as an implementation detail. You will never find any references to filesystem in foo's public interface.
In case when __attribute__((visibility("default")) is always defined, foo's ABI contains boost filesystem's exported symbols also. In case if BOOST_SYMBOL_EXPORT/IMPORT macros defined as above, foo's ABI contains only it's own exported symbols.
In my opinion, shared library ABI should not contain any implementation details. So, I would rather vote for using export/import macros defined as above. Please, correct me if I'm wrong or misunderstood something.
My patch was based on Jürgen's original " #define BOOST_SYMBOL_IMPORT". We need to get input from him as to why that changed in his second patch.
2) What do you think about having BOOST_SYMBOL_EXPORT/IMPORT always defined? This will decrease #ifdef branches in libraries configuration files (config.hpp).
I just tried that on <boost/system/config.hpp>, and it is quite a bit shorter (12 loc vs 19 loc), reads better, and is probably easier to teach. So unless someone objects, I'll follow your suggestion. Thanks, --Beman