On Fri, 2009-05-29 at 09:28 +0200, joaquin@tid.es wrote:
- 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.)
These are points for a lib developer to evaluate, not the Boost user. Remember we were talking of reasons why users prefer header-only.
Again, I've listed here my personal reasons (as a user). I think it could be instructive to try to gather more insight as to why our users prefer header-only libs, putting aside our own arguments as Boost authors.
Well - here is input from one boost user. I think single issue yes/no vote referendums produce some remarkably silly answers, as do poorly selected sets of questions in surveys. I could easily reply to a survey like this: Do you want header only libs (no need to "build" boost)? yes Do you want shorter builds? Yes Do you want to be able to use "system" or otherwise separately built/installed shared libraries rather than deploying libraries with each product etc? Yes Do you want to deal with the versioning and compatibility problems that can sometimes arise with shared libraries? No etc... The above noisy results are a result of asking questions that have too much to do with implementation. I don't care how the thing works so long as it works well and is easy to use. I suspect that goes for most users. To me easy to use means (things irrelevant to this thread elided): easy to build easy to deploy If you expect users to answer *how* to do those things I think you are giving users to much credit and/or trying to pass the buck on a hard problem :-) Now, if you avoid the need to build, you can't get easier than that - so header only it is - right? And if you don't need to deploy anything but the users own code - then can't get easier tan that - done! Header only is the winner! As far as it goes, I think that is actually a pretty accurate answer. However, the problem is that I also want my projects to build in a reasonable time, I don't want, when I build a whole suite of projects all using a common library, to have to build a common library N times once per project). Surely it is clear that the header only approach ultimately does not scale? Surely it is also clear that shared lib compatibility, versioning etc is a problem that can and has been solved? My biggest build and deployment problems have nothing to do with boost. Boost Build's uniqueness is not (now that the out of the box defaults are good and the basic knobs to twiddle are better documented) a significant impediment for basic use in my opinion at least. Its unfortunate that so much work has had to be done (and a big thanks to those responsible) to make Boost object code libraries easily (relatively) usable and deployable on a very common platform that makes these things remarkably hard. Please don't give up now! Darryl.