Boost logo

Boost :

From: Alexander Arhipenko (arhipjan_at_[hidden])
Date: 2008-07-11 02:54:30


Hi, Sebastien

On Thu, Jul 10, 2008 at 7:53 PM, Sebastien Binet
<hep.sebastien.binet_at_[hidden]> wrote:
>
> seems like a copy-paste bug in dso.hpp:
>
> +# define BOOST_DSO_EXPORT_EXCEPTION BOOST_DSO_EXPORT
> +# define BOOST_DSO_IMPORT_EXCEPTION BOOST_DSO_EXPORT
> ------------------------------------------------^^^^^^
>
> cheers,
> sebastien.
>

It's not copy paste error, it was done by intention.
Maybe you've mentioned, that BOOST_DSO_EXPORT(IMPORT)_EXCEPTION
differs for msvc and gcc.

I'll try to explain why we need special macro for exception export/import
(and why it differs for msvc and gcc) on the sample.

Let's assume I've created library My.Lib that links to Boost.Filesystem.
My.Lib doesn't handle any Boost.Filesystem exception.
It is supposed, that this will be done by My.Lib user.
Finally, executable file User.Exe links My.Lib and Boost.Filesystem.
Now consider use case:
User.Exe calls function my::lib::function() exported from My.Lib.
my::lib::function calls boost::filesystem::rename that can throw
filesystem_error. So, filesystem_error are thrown from
my::lib::function().
User.Exe catches filesystem_error, but mysterious
thing happens: filesystem_error will never be caught!
Because catch handler in User.Exe will look for typeinfo
of filesystem_error in My.Lib that doesn't have it.

So, My.Lib should export filesystem_error.
All above related to gcc, look also at http://gcc.gnu.org/wiki/Visibility,
exceptions section.

Firstly I discovered this issue with VisualAge C++ compiler.
I had shared library and following exported exception class:
class Error : public std::exception.
All was fine until I try to catch std::exception in binary that links
that shared library :(. As a result, we exported std::exception from
shared library too.

So, designer of My.Lib library should decide, handle all the boost.filesystem
exceptions and doesn't export them from My.Lib or not to handle and
export.

Regards


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