Boost logo

Boost :

Subject: Re: [boost] [threads] making parts of Boost.Threads header-only
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-04-08 03:32:18

On Tue, Apr 7, 2009 at 1:55 PM, Anthony Williams <anthony.ajw_at_[hidden]> wrote:
> Emil Dotchevski <emildotchevski_at_[hidden]> writes:
>> On Tue, Apr 7, 2009 at 8:57 AM, Anthony Williams <anthony.ajw_at_[hidden]> wrote:
>>> joaquin_at_[hidden] writes:
>>>> Looks like a sensible part of Boost.Threads, namely that
>>>> dealing with mutexes and locks, would be header-only
>>>> but for its relying on boost/thread/exceptions.hpp, whose
>>>> implementation is located at /libs/thread/*/exceptions.cpp.
>>>> Given that this .cpp mostly consists of extremely simple
>>>> definitions (as simple as do-nothing functions in many cases),
>>>> would it make sense to move this to inline definitions in
>>>> boost/thread/exceptions.hpp thus making mutexes and locks
>>>> header-only? This would greatly enhance the appeal of this
>>>> part of Boost.Threads, as having to link a separate module
>>>> is a considerable burden.
>>> That seems sensible.
>> I am against such a move. Boost Threads requires linking for other
>> features which makes it one of the few libraries in Boost that can be
>> properly designed to avoid unnecessary physical coupling. Unless
>> something is proven to cause performance problems it should not be
>> inlined, regardless of how simple it is.
> Wow, that's a hard line you've drawn there. I'm not sure I agree. The
> only reason this matters is if you're going to be changing the
> implementation and don't want to recompile the code that uses the
> header. For boost users, the implementation only changes if they change
> boost versions, and in that case I would expect people to recompile
> anyway --- I wouldn't trust something compiled against boost 1.37 to
> link against a 1.38 lib, for example.

You're arguing that physical coupling to something like Boost isn't a
problem. I'm arguing that introducing any physical coupling must be
justified. From certain point of view both arguments are valid, which
is why we disagree. :)

> 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.

I'm not sure I understand why the type IDs wont match, but I do believe you.

> I could change the code so that if you're linking against the static
> library then the exception functions are inline, since they can't be
> thrown across DLL boundaries anyway in this case. That would mean that
> if you were static linking against boost.thread then you wouldn't
> actually need the lib in some cases (e.g. if all you used was
> boost::mutex).

In my book this is another example of unnecessary physical coupling.
If I'm calling Boost Thread from an exception-neutral context, I'd
rather not see definitions of exception types (not that exceptions are
in any way special, this is just an example.)

Emil Dotchevski
Reverge Studios, Inc.

Boost list run by bdawes at, gregod at, cpdaniel at, john at