Boost logo

Boost :

Subject: Re: [boost] [threads] making parts of Boost.Threads header-only
From: David Abrahams (dave_at_[hidden])
Date: 2009-04-13 17:46:43


on Wed Apr 08 2009, Peter Bartlett <pete-AT-pcbartlett.com> wrote:

> Quoting Anthony Williams <anthony.ajw_at_[hidden]>:
>
>> Andrey Semashev <andrey.semashev_at_[hidden]> writes:
>>
>>> Anthony Williams wrote:
>>>
>>>> In any case, after further thought I remembered the reason I didn't do
>>>> this before. If the exceptions are header-only then they cannot be
>>>> thrown from a DLL and caught outside the DLL, since the type-ids won't
>>>> match. This would mean that any exceptions thrown by the DLL version of
>>>> boost.thread wouldn't be able to be caught in user code other than by
>>>> catching std::exception or with catch(...). This is the case for
>>>> MSVC/Windows anyway --- I'm not sure about other compilers/platforms.
>>>
>>> Is it so? On which MSVC version? I'm asking because I throw/catch
>>> exceptions across dll boundaries all the time on Windows and haven't
>>> had any problems yet. There are some issues on Linux, but they are
>>> solved (more or less) with visibility tunings.
>>
>> Hmm. I'll have to try it out when I get a chance. Maybe I'm mistaken,
>> but that's certainly my recollection.
>>
>> If everything does work then that hurdle is removed.
>
> Well I do that within my own code all the time too so I know it works on MSVC.
> But I am in complete control of that code.
>
> Item 62 from Sutter and Alexandrescu, "Don't allow exceptions to
> propagate across module boundaries", is germane.

So you take that to mean that a DLL shouldn't throw exceptions?

> Actually their advice is more specific than the title suggests: "Don't
> allow exceptions to propagate between two pieces of code unless you
> control the compiler and compiler options used to build both sides".

...even if you _do_ control both sides?

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

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