|
|
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
possible.
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
later.
> 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
> ===
> #if defined(BOOST_HAS_WINTHREADS)
> #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
> ===
> #if defined(BOOST_HAS_WINTHREADS)
> #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
-- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk