[boost] Specifying symbols, that have to be exported from shared library

From: Alexander Arhipenko (arhipjan_at_[hidden])
Date: 2008-07-09 01:56:25

Hi guys!
Without any doubt, any shared library should export as less symbols as possible.

First, this will decrease loading time of dynamic shared object.

Second, it could eliminate some binary compatibility issues in the future.

Boost libraries that are built as shared libraries (e.g., filesystem, datetime)
explicitly specify symbols that have to be exported, but only when
BOOST_HAS_DECLSPEC
defined. So, only when building with toolsets msvc and borland
(correct me if I'm wrong),
this 'export' functionality is used.

As we know, gcc allows not to export any symbol from shared library
(if compiler flag -fvisibility=hidden is used) except ones declared with
__attribute__((visibility("default"))), e.g.:
class __attribute__((visibility("default"))) exported_class {//...

As for me, it will be nice to exploit explicit symbols export in boost
(if compiler allows this).
In our software team, we use following macroses:
SFI_DSO_EXPORT, SFI_DSO_IMPORT that are defined as:
#if defined SFI_CC_GNUC
#  define SFI_DSO_EXPORT __attribute__((visibility("default")))
#  define SFI_DSO_HIDE   __attribute__((visibility("hidden")))
#  define SFI_DSO_IMPORT
#endif

#if defined SFI_CC_MSVC
#  define SFI_DSO_EXPORT __declspec(dllexport)
#  define SFI_DSO_HIDE
#  define SFI_DSO_IMPORT __declspec(dllimport)
#endif

//etc...

And some library use only them:
//config.hpp

#if defined  SFI_ALIB_BUILD_SHLIB
#  define   SFI_ALIB_DECL    SFI_DSO_EXPORT
#elif defined SFI_ALIB_USE_SHLIB
#  define   SFI_ALIB_DECL    SFI_DSO_IMPORT
#else
#  define   SFI_ALIB_DECL
#endif

Finally, here's the question.
What do you think about having something like BOOST_DSO_EXPORT/*IMPORT in boost?

Regards