Boost logo

Threads-Devel :

From: Anthony Williams (anthony_at_[hidden])
Date: 2006-03-13 04:32:58

Roland Schwarz <roland.schwarz_at_[hidden]> writes:

> Today I found a little time to prepare for start of the tss rewrite on
> windows.
> During the attempt to catch up the thread_rewrite branch, to find
> out how we are going on windows I found the following:
> 1) It seems like Anthony is trying to aim for a header only implementation
> on windows. Is my impression true? If so, I would like to learn the
> reasons
> for it. I believe header only should be avoided as much as possible,
> and only
> be used when linking is not feasible.

I very much like the fact that boost is generally header-only, as linking
against third-party libraries (e.g. boost) is not always convenient.

For non-library code, I do indeed prefer to use separate cpp files where

It allows me to use templates, so that (for example) boost::call_once can
accept any type of function object that is callable with no parameters, or
boost::condition::wait can accept and type of mutex lock, provided it can be
unlocked and then locked again.

> 2) TSS cannot be implemented header only. So even if there is an agreement
> for it, it could not be done (on windows).

Fair enough. However, I wouldn't argue against header-only for everything just
because TSS can't be done that way.

> 3) I cannot see the founding blocks we discussed for splitting the
> thread library
> into platform dependant code. All I found is that in the hpp files
> the windows
> part is #ifedef'fed to win32 specific includes leaving behind old
> (commented out) code fragments still belonging to windows.

I didn't want to touch the implementation for other platforms, so I just
added the #ifdef for Windows code, which defers to windows-specific headers as
discussed. As other platforms are worked on, they can be moved to their own
platform-specific headers too.

I thought I had removed all the windows-related code fragments from the
headers. Is there a specific one you have in mind? I'll have to check again

> 4) The cpp files altough empty (in the windows case) are still
> beeing compiled. Do we really want such an architecture?

No. I just haven't got round to sorting it out yet --- I'm not that proficient
with Jamfiles at the present time.

> Can we possibly go along the lines:
> E.g.:
> mutex.hpp
> ===
> #include "win/mutex.hpp"
> #elif defined (BOOST_HAS_MPTASKS)
> #include "mpt/mutex.hpp"
> #elif defined (BOOST_HAS_PTHREADS)
> #include "pthreads/mutex.hpp"
> #else
> #include "default/mutex.hpp"
> #endif
> ====

That's what I was aiming for, though with "detail/mutex_<platform>.hpp" rather than
"<platform>/mutex.hpp". We can change the directory structure if you like.

> where default might be the single threaded case or issue a compiler
> error.
> And for the cpp files in a similar fashion:
> mutex.cpp
> ===
> #include "win/mutex.cpp"
> #elif defined (BOOST_HAS_MPTASKS)
> #include "mpt/mutex.cpp"
> #elif defined (BOOST_HAS_PTHREADS)
> #include "pthreads/mutex.cpp"
> #else
> #include "default/mutex.cpp"
> #endif
> ====

Seems reasonable, though as you say, I'd rather not compile the empty .cpp
files on Windows.

Thanks for your thoughts,


Anthony Williams
Software Developer
Just Software Solutions Ltd

Threads-Devel list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at