On Wed, Jun 10, 2009 at 11:04 AM, Juergen Hunold<juergen.hunold@ivembh.de> wrote:

[snip]

That means "__attribute__((visibility("default")))", right ? Yes, exactly

[snip]

...

Oh, now I am confused. How exactly those symbols are to be used? Say, I declare an exception class in a header -- what modifiers should I use? Do we need BOOST_WHATEVER_EXCEPTION_DECL? Maybe you can write up some guidance for library authors?

Yeah, me too ;-)) That whole exception export thing is quite a miracle.

In response to above: I have written down 2 sample configuration files for the 'foo' library. #if !defined BOOST_FOO_DETAIL_CONFIG_HPP #define BOOST_FOO_DETAIL_CONFIG_HPP #if defined BOOST_FOO_BUILD_SHLIB # define BOOST_FOO_DECL BOOST_SYMBOL_EXPORT # define BOOST_FOO_EXCEPTION_DECL BOOST_EXCEPTION_EXPORT #elif defined BOOST_FOO_USE_SHLIB # define BOOST_FOO_DECL BOOST_SYMBOL_IMPORT # define BOOST_FOO_EXCEPTION_DECL BOOST_EXCEPTION_IMPORT #else # define BOOST_FOO_DECL # define BOOST_FOO_EXCEPTION_DECL #endif #endif Configuration file above will re-export all the exceptions marked with BOOST_FOO_EXCEPTION_DECL from shared library foo. So, if I write library 'bar', it will contain all the symbols exported by 'bar' and also all the exceptions from 'foo' library'. This is intended for the following scenario: exe test : main.cpp bar ; main.cpp: #include <bar.hpp> #include <foo/error.hpp> int main() { try { bar::function();//could potentially throw foo's exception } catch(const foo::error& e) { std::cerr<<"error occured: "<<e.what()<<'\n'; } return 0; } In case if 'bar' reexports exceptions from 'foo', the code above will succeed. Otherwise it will be aborted, since foo::error won't be caught. But, all these could be not enough for the sophisticated user. Assume, library 'bar' will use library 'foo' as an implementation detail and also will catch all the foo's exceptions. So, bar's maintainer doesn't want to re-export foo's stuff from his library. As a result, foo's maintainer should provide more sophisticated configuration file (I marked changes with '+'): #if !defined BOOST_FOO_DETAIL_CONFIG_HPP #define BOOST_FOO_DETAIL_CONFIG_HPP #if defined BOOST_FOO_BUILD_SHLIB # define BOOST_FOO_DECL BOOST_SYMBOL_EXPORT # define BOOST_FOO_EXCEPTION_DECL BOOST_EXCEPTION_EXPORT #elif defined BOOST_FOO_USE_SHLIB # define BOOST_FOO_DECL BOOST_SYMBOL_IMPORT +# if defined BOOST_FOO_EXCEPTION_REEXPORT # define BOOST_FOO_EXCEPTION_DECL BOOST_EXCEPTION_IMPORT +# else +# define BOOST_FOO_EXCEPTION_DECL BOOST_SYMBOL_IMPORT +# endif #else # define BOOST_FOO_DECL # define BOOST_FOO_EXCEPTION_DECL #endif #endif So, now bar library maintener have a choice: 1. Re-export foo's exceptions and let them left the bar library's boundaries 2. Catch all the foo's exceptions, process and do not re-export P.S. I've attached minimal bbv2 project that reproduce the problem with uncaught exception. To eliminate it, you can do the following: a) Replace FOO_DECL with FOO_EXCEPTION_DECL in Error class declaration b) Uncomment ~Error() declaration (foo/error.hpp) and definition (foo/foo.cpp)

Hi Juergen, On Wed, Jun 10, 2009 at 3:15 PM, Juergen Hunold<juergen.hunold@ivembh.de> wrote:

[snip]

...

But, all these could be not enough for the sophisticated user. Assume, library 'bar' will use library 'foo' as an implementation detail and also will catch all the foo's exceptions. So, bar's maintainer doesn't want to re-export foo's stuff from his library.

This is the gcc case, right ? With msvc, you have to "re-export" the used symbols anyway (by marking them "__dllimport". So why do you want to hide the symbols with gcc ?

I guess, I was not clear and typed too many words ;). Consider the following: foo: [foo::function, foo::Error] bar: [bar::function,] ('[]' - means list of exported symbols) In case, when 'bar' depends on 'foo' and foo::Error is not re-exported: bar: [bar::function]. So, bar only exports bar::function symbol. This is the same for gcc and msvc (I've rechecked msvc's case with dumpbin utility). In case, when foo::Error is re-exported (i.e., foo:Error always have 'default' visibility): bar: [bar::function, foo::Error]. This only relates to gcc.

So why do you want to hide the symbols with gcc ? The reason could be binary compatibility.

Regards

Alexander Arhipenko wrote:

[snip] I have written down 2 sample configuration files for the 'foo' library.

#if !defined BOOST_FOO_DETAIL_CONFIG_HPP #define BOOST_FOO_DETAIL_CONFIG_HPP

#if defined BOOST_FOO_BUILD_SHLIB

Should be named BOOST_FOO_SOURCE.

# define BOOST_FOO_DECL BOOST_SYMBOL_EXPORT # define BOOST_FOO_EXCEPTION_DECL BOOST_EXCEPTION_EXPORT #elif defined BOOST_FOO_USE_SHLIB

Just #else should be enough, see the 'Supporting Windows Dll's' section at http://www.boost.org/development/separate_compilation.html

# define BOOST_FOO_DECL BOOST_SYMBOL_IMPORT # define BOOST_FOO_EXCEPTION_DECL BOOST_EXCEPTION_IMPORT #else # define BOOST_FOO_DECL # define BOOST_FOO_EXCEPTION_DECL #endif

#endif

Configuration file above will re-export all the exceptions marked with BOOST_FOO_EXCEPTION_DECL from shared library foo. So, if I write library 'bar', it will contain all the symbols exported by 'bar' and also all the exceptions from 'foo' library'. This is intended for the following scenario:

exe test : main.cpp bar ;

main.cpp:

#include <bar.hpp> #include <foo/error.hpp>

int main() { try { bar::function();//could potentially throw foo's exception } catch(const foo::error& e) { std::cerr<<"error occured: "<<e.what()<<'\n'; }

return 0; }

In case if 'bar' reexports exceptions from 'foo', the code above will succeed. Otherwise it will be aborted, since foo::error won't be caught.

But, all these could be not enough for the sophisticated user. Assume, library 'bar' will use library 'foo' as an implementation detail and also will catch all the foo's exceptions. So, bar's maintainer doesn't want to re-export foo's stuff from his library. As a result, foo's maintainer should provide more sophisticated configuration file (I marked changes with '+'):

#if !defined BOOST_FOO_DETAIL_CONFIG_HPP #define BOOST_FOO_DETAIL_CONFIG_HPP

#if defined BOOST_FOO_BUILD_SHLIB # define BOOST_FOO_DECL BOOST_SYMBOL_EXPORT # define BOOST_FOO_EXCEPTION_DECL BOOST_EXCEPTION_EXPORT #elif defined BOOST_FOO_USE_SHLIB # define BOOST_FOO_DECL BOOST_SYMBOL_IMPORT +# if defined BOOST_FOO_EXCEPTION_REEXPORT

Exceptions should be re-exported by default, IMHO.

# define BOOST_FOO_EXCEPTION_DECL BOOST_EXCEPTION_IMPORT +# else +# define BOOST_FOO_EXCEPTION_DECL BOOST_SYMBOL_IMPORT +# endif #else # define BOOST_FOO_DECL # define BOOST_FOO_EXCEPTION_DECL #endif

#endif

So, now bar library maintener have a choice: 1. Re-export foo's exceptions and let them left the bar library's boundaries 2. Catch all the foo's exceptions, process and do not re-export

P.S. I've attached minimal bbv2 project that reproduce the problem with uncaught exception. To eliminate it, you can do the following: a) Replace FOO_DECL with FOO_EXCEPTION_DECL in Error class declaration b) Uncomment ~Error() declaration (foo/error.hpp) and definition (foo/foo.cpp)

------------------------------------------------------------------------

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost