boost-request@lists.boost.org wrote:
------------------------------
Message: 3 Date: Wed, 4 Apr 2007 01:28:33 +0400 From: Andrey Semashev <andysem@mail.ru>
...
And in return I only get reduced compilation time and application binary size (the dll will still be needed to run and distribute, but in case of a quick update I may provide only a small-sized exe without the unaffected dll). Honestly, after all experience I had so far I almost always prefer header-only solution, where possible and reasonable.
Hi All, Just my 5c on this, but we are using Boost Build to manage our software build process. We use a lot of separate libraries and compile a lot of code, even for a large compiler farm. Using Boost Build, it is trivial to create and use libraries, including 3rd party libraries, that separately compile. I don't find it at all inconvenient to use static libraries because that build system is designed to work _with_ the object file model that C++ sits on, not around it. I support the idea of header files for convenient use for new users, but for libraries that wrap evil C system headers with nice modern C++, its against the spirit of the task to still inherit all the macro and header ordering hell from the library I'm wrapping. And I don't care about optimising by inlining a call to flush to a slow disk. The header-only approach just doesn't scale like object files -- imagine how slow our builds would be if we had to recompile all the I/O code in our operating system every time we wrote a hello world application because they'd made it header-only. The solution is not to put that code it in a precompiled header and waste memory, but to do what the O/S guys have already done: compile it separately and just expose the facade through the object file interfaces designed specifically for that purpose. Of course template code is a different kettle of fish. I add my vote for the hybrid header/non-header model, where possible. The people who are using build systems are also probably the people who care about build times and macro/header ordering hell. They'll be prepared to invest time to set up library compilation etc. to get what they want. Others working on smaller projects won't care and won't have to deal with the start-up hassles. Best Regards, Matthew -- _________________________ Matthew Herrmann matthew.herrmann@zomojo.com