Re: [boost] [threads] making parts of Boost.Threads header-only
Anthony Williams writes:
Emil Dotchevski <emildotchevski@gmail.com> 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. Brian Wood Ebenezer Enterprises www.webEbenezer.net
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Brian Wood Sent: Wednesday, April 08, 2009 2:26 PM To: boost@lists.boost.org Subject: Re: [boost] [threads] making parts of Boost.Threads header-only
Anthony Williams writes:
Emil Dotchevski <emildotchevski@gmail.com> 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
On Wed, Apr 8, 2009 at 2:31 PM, Schrader, Glenn <gschrad@ll.mit.edu> wrote:
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.
The problem you're talking about applies only if the library is not built from sources, and building the Thread library from sources is rather painless. Just grab the cpps and throw them in your build system, that's about it. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On 8 Apr 2009, at 23:05, Emil Dotchevski wrote:
On Wed, Apr 8, 2009 at 2:31 PM, Schrader, Glenn <gschrad@ll.mit.edu> wrote:
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.
The problem you're talking about applies only if the library is not built from sources, and building the Thread library from sources is rather painless. Just grab the cpps and throw them in your build system, that's about it.
That assumes you aren't trying to distribute your code to people who might have different versions of boost installed. In that case, pulling part of boost into your build tree isn't going to work. Chris
On Apr 09, 2009 12:22 PM, Christopher Jefferson wrote:
On 8 Apr 2009, at 23:05, Emil Dotchevski wrote:
On Wed, Apr 8, 2009 at 2:31 PM, Schrader, Glenn <gschrad@ll.mit.edu> wrote:
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.
The problem you're talking about applies only if the library is not built from sources, and building the Thread library from sources is rather painless. Just grab the cpps and throw them in your build system, that's about it.
That assumes you aren't trying to distribute your code to people who might have different versions of boost installed. In that case, pulling part of boost into your build tree isn't going to work.
That is exactly the case that I have. Different users have different boost versions and they don't all build them the same way. --glenn
Please, can we stop to move code from cpp-files into headers?! It unnecessarily increases code bloading - I get binaries of multiple MBs size. Oliver
I understand the general objections to putting code in header files, but can we put dogma aside for a moment? Are we all actually looking at the proposed change? exceptions.cpp contains a handful of trivial function definitions, all of them empty or 1 line. Opposing this change on the basis of compile time or code bloat strikes me as ridiculous when the actual effect would be approximately zero. I see Emil's point about non-inline functions being occasionally useful for debugging, but it's entirely incidental to the purpose of the library. Anyway it's quite a stretch in this particular case. If an exception is being thrown you already know where the problem is showing up. Why not just use a debugger? Has anyone ever actually had occasion to abuse exceptions.cpp in this way? In the current situation, the lock/mutex headers are unnecessarily coupled to the Threads shared library. This is very inconvenient for users and other Boost libraries (hence lightweight_mutex). It can be the difference between having to compile/install Boost and integrate it into your build system or... not. And for what? A few empty function definitions? The only issue raised that I find at all convincing is Anthony's DLL boundary problem, but I'd be surprised if there isn't a solution to that. Barring any such technical hurdle, I think making exceptions.hpp header-only is a no-brainer. Patrick On Thu, Apr 9, 2009 at 12:32 PM, <k-oli@gmx.de> wrote:
Please, can we stop to move code from cpp-files into headers?! It unnecessarily increases code bloading - I get binaries of multiple MBs size.
Oliver _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (6)
-
Brian Wood -
Christopher Jefferson -
Emil Dotchevski -
k-oli＠gmx.de -
Patrick Mihelich -
Schrader, Glenn