Boost logo

Boost :

Subject: Re: [boost] [config] Request for BOOST_SYMBOL_IMPORT_VISIBLE ?
From: Alexander Arhipenko (arhipjan_at_[hidden])
Date: 2011-01-31 10:00:50


On Sat, Jan 29, 2011 at 2:37 AM, Mostafa <mostafa_working_away_at_[hidden]> wrote:
> Hi,
>
> I propose the introduction of BOOST_SYMBOL_IMPORT_VISIBLE to Boost.Config
> that behaves like BOOST_SYMBOL_IMPORT in all cases except gcc (and like
> compilers?) where it expands to "__attribute__((visibility("default")))".
[snip]...

Hi Mostafa,

I completely understood your motivation and use case of scenario A).
You need to re-export exception in order to catch it in the others dsos.
More precisely,
Lib A can throw exception a_error.
Lib B uses Lib A's functions that potentially can throw a_error.
Lib C uses Lib B's functionality and know that it can throw a_error
among the others.
Lib C want to catch a_error and make something about it (e.g., log a message).
For this you need to reexport a_error from Lib B.
(I wrote down the above in order to be sure that we are talking about
the same things,
please correct me if I'm wrong).

For such case you should have separate macro for a_error class, e.g.:

LIB_A_EXCEPTION.

I would implement it using current boost.config like this:

//library's A pseudo config.hpp file

//when we are building shared library A
#if defined LIB_A_BUILD_SHLIB
# if defined __GNUC___ || defined __INTEL_COMPILER //etc
# define LIB_A_EXCEPTION BOOST_SYMBOL_VISIBLE
# else
# define LIB_A_EXCEPTION BOOST_SYMBOL_EXPORT
# endif
# define LIB_A_DECL BOOST_SYMBOL_EXPORT
#endif

//when we are using shared library A
#if defined LIB_A_USE_SHLIB
# if defined __GNUC__ || defined __INTEL_COMPILER //etc...
# define LIB_A_EXCEPTION BOOST_SYMBOL_VISIBLE
# else
# define LIB_A_EXCEPTION BOOST_SYMBOL_IMPORT
# endif
# define LIB_A_DECL BOOST_SYMBOL_IMPORT
#endif

The problem about this solution is that it is:
1) Low-level (refers directly to compiler macros)
2) Contains a lot of boilerplate code that could be eliminted

The more elegant solution would be to have (as you are proposing) special
macroses in boost.config. BOOST_SYMBOL_VISIBLE is okay but it does
nothing on msvc.

So, I propose to have 2 new macroses:
BOOST_SYMBOL_VISIBLE_EXPORT//export "always" visible symbol from the library
BOOST_SYMBOL_VISIBLE_IMPORT//import "always" visible symbol to the library

They will be implemented like following:
#if defined _MSC_VER //|| defined the others that uses declspec macro family
# define BOOST_SYMBOL_VISIBLE_EXPORT BOOST_SYMBOL_EXPORT
# define BOOST_SYMBOL_VISIBLE_IMPORT BOOST_SYMBOL_IMPORT
#else
# define BOOST_SYMBOL_VISIBLE_EXPORT BOOST_SYMBOL_EXPORT
# define BOOST_SYMBOL_VISIBLE_IMPORT BOOST_SYMBOL_EXPORT
#endif

Having such macroses in boost.config we could significantly simplify
the example above:

//library's A pseudo config.hpp file

//when we are building shared library A
#if defined LIB_A_BUILD_SHLIB
# define LIB_A_EXCEPTION BOOST_SYMBOL_VISIBLE_EXPORT
# define LIB_A_DECL BOOST_SYMBOL_EXPORT
#endif

//when we are using shared library A
#if defined LIB_A_USE_SHLIB
# define LIB_A_EXCEPTION BOOST_SYMBOL_VISIBLE_IMPORT
# define LIB_A_DECL BOOST_SYMBOL_IMPORT
#endif

Boosters, what do you think?

Mostafa, unfortunately I did not completely understand scenario 2).
Am I correct that you want to export function foo from B library,
function bar from C library?
All of them return reference to MyShape that resides in library A.
Why not require B's, C's users to link library A?
I guess it's possible to re-export MyShape from B and C library on gcc platform
but can't be easily achived on msvc.

Regards


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk