On Sun, Mar 21, 2010 at 8:14 AM, Jeff Flinn <TriumphSprint2000@hotmail.com> wrote:
If you look at the archives of this mailing list, you will see that there was a concerted effort to keep libraries header-only in order to avoid the myriad of problems involved in ensuring that boost libraries are compiled with ALL required settings to be compatible with the users' build targets. In my experience - which I think the archives mirror - header-only libraries are easier to incorporate into existing build procedures, and enjoy a higher adoption rate due to that fact.
This line of thought misses the point of physically decoupling implementation details from interfaces. It *is* easier not to do it, this doesn't prove that it's better not to do it. A credit card with low introductory interest rate also enjoys higher adoption rate due to that fact, but it doesn't mean it's necessarily a good long term choice. The point of avoiding physical coupling is that changes in implementation details don't require user code to recompile. An important side effect is that the need for the ABIs to match is greatly reduced; so you *can* have a particular library compiled with different compiler options and that's OK. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode