Emil Dotchevski wrote:
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. I don't see your point. AFAIK, mutexes do not require any features that have to reside in a separately compiled library.
In principle, nothing ever has to reside in a separately compiled library.
That's an exaggeration, just as having everything separately compiled.
You don't see my point because you think of the header-only approach as a good thing,
Not exactly. There are pros and cons, and in this case I find pros more valuable. And there are other header-only Boost libraries that I would rather have separately compiled.
whereas in my mind headers should be limited to things that must be in a header, such as functions for which inlining is critical, as well as template definitions. This reduces physical coupling, which is only a problem in large scale projects; unfortunately by the time it becomes a problem it is already too late.
I think, this particular case doesn't increase coupling in any considerable way. It won't introduce any header includes, classes or new functions, AFAICT. Besides, the need to link to the library is a way of coupling, too, so we'll remove it with the change.