On Thu, May 28, 2009 at 11:39 PM, <joaquin@tid.es> wrote:
Emil Dotchevski escribió:
On Thu, May 28, 2009 at 11:15 PM, Joaquin M Lopez Munoz <joaquin@tid.es> wrote: My point is that if there's pressure from users to have header-only libs (as you and also I recognize) I think the least we can do is try to understand and analyze these reasons to see their merit. If pressure were the other way around (i.e. users demanding that code be moved out of .hpps as much as possible) we wouldn't be having this sort of discussions.
As a user, I can describe *my* reasons to favor header-only libs:
1. The whole bjam-driven building process is nontrivial and time and space consuming. 2. If autolinking is not available, picking up the right lib variant is not trivial. 3. Bulding libs selectively is not as easy as it might seem, due to the fact that interlib dependencies might force you to build libB when using libA, and you don't know in advance.
These are indicative of build system problems. It's true, you can work around build system inadequacies by avoiding building libraries.
4. I'm not concerned about ABI issues given that, to start with, no ABI compatibility guarantees are provided across Boost versions.
Sure, ABI compatibility is not the issue.
This is not to say that I'd like *every* lib to be header-only; but I'd say the benefits of moving to a link-based lib should be balanced against points 1-4.
Assume for a moment that 1-3 were solved at the build system level. What reasons do you have for putting code in headers? I can think of only two: - Code that must be there, e.g. templates - Performance reasons: 1) inlining functions and 2) not using pimpl in code that is provably critical (the price is greater physical coupling.) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode