Re: [boost] [threads] making parts of Boost.Threads header-only

Subject: Re: [boost] [threads] making parts of Boost.Threads header-only
From: Schrader, Glenn (gschrad_at_[hidden])
Date: 2009-04-08 17:31:22

> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
> On Behalf Of Brian Wood
> Sent: Wednesday, April 08, 2009 2:26 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] [threads] making parts of Boost.Threads header-only
> 
> Anthony Williams writes:
> >Emil Dotchevski <emildotchevski_at_[hidden]> writes:
> >>
> >> 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.
> 
> I'm sure you know more about Boost than I do, but I disagree that
> the implementation only changes when users change versions.  There
> are fixes that have to be applied by users to libraries from time to time.
> I tend to agree with Emil's arguments here.

I can see both sides of this. I don't like gratuitous inlining since it's a performance optimization and premature optimization is evil (per Knuth). Its also harder to set breakpoints on inlined functions. Also, if something is in a shared library there only needs to be one copy in memory rather than one per process. The places where inlining will actually make a performance difference are use-case dependent. This is a problem for a generic library like boost since it can be hard to predict all of the functions that some user might need to squeeze every last bit of performance out of. 

Even so, using the libraries isn't painless. One of the things that I don't like is that depending on how a build is configured the file names might or might not be mangled with the gcc version. It would be really nice if there were something like a pkg-config file that could be queried to find the names to link in for a given install. While I'm wishing it would be even better if accounted for inter-library dependencies and gave back all of the additional libraries (including system libraries) needed to link in given boost library.

--glenn