Re: [boost] [system] Why is this not header-only?
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
On Wed, 04 Apr 2007 10:18:17 +1000 Matthew Herrmann <matthew.herrmann@zomojo.com> wrote:
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
Wow! and I mean it. I tried using Boost.Build as the base for a new build system, and I could not get anywhere at all. Do you have anything you could share? the system tiself, any docs, best practices, wiki, anything at all? I ended up wrapping the boost bjam stuff with a makefile that setup stuff and generated what I wanted. I would LOVE to get in-the-know by someone who's actually used that system for something other than building the out-of-the box boost.
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.
I agree with this as well. In fact, I played with asio to get it to get rid of the header-only implementation. Soem tricks and you can even eliminate the IOCTL constants.
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.
I agree with this as well. Compile times are a huge time sink. We build on very fast, modern machines with at lesat 2-4GB RAM, and compiles take a very long time.
Of course template code is a different kettle of fish.
Yeah... compile times are the biggest reason some of our algorithms are NOT template/generic.
AMDG Jody Hagins <jody-boost-011304 <at> atdesk.com> writes:
Of course template code is a different kettle of fish.
Yeah... compile times are the biggest reason some of our algorithms are NOT template/generic.
There's always explicit instantiation. In Christ, Steven Watanabe
Steven Watanabe wrote:
AMDG
Jody Hagins <jody-boost-011304 <at> atdesk.com> writes:
Of course template code is a different kettle of fish. Yeah... compile times are the biggest reason some of our algorithms are NOT template/generic.
There's always explicit instantiation.
Exactly -- and this can be easily layered on by the library user. If the library does it (like boost.serialization) then with the 'dll options' you get all the stuff -- even if you don't use it. I'll just remind folks that boost.process *is* a template library...so the issue of it being 'template code' is relevant. System, on the other hand is non-template code so the issues are different. Jeff
On Wed, 4 Apr 2007 00:43:22 +0000 (UTC) Steven Watanabe <steven@providere-consulting.com> wrote:
There's always explicit instantiation.
Right. However, that's not free either. In fact, it adds significant developer overhead to get all the explicit instantiations right. Note, I understand the "library implemented in a header" for templates. I still think there's ways to put parts of them in libraries, especially when providing wrappers around system resources.
Jody Hagins wrote:
On Wed, 4 Apr 2007 00:43:22 +0000 (UTC) Steven Watanabe <steven@providere-consulting.com> wrote:
There's always explicit instantiation.
Right. However, that's not free either. In fact, it adds significant developer overhead to get all the explicit instantiations right.
Luckily it's only the experts that are worried about this, so it's a slam dunk for them ;-)
Note, I understand the "library implemented in a header" for templates. I still think there's ways to put parts of them in libraries, especially when providing wrappers around system resources.
And how about a non-template class that consists of primarily small inlineable functions the make system access more typesafe? With inlining this sort of wrapper can be very efficient. If it's 'out of line' you may suffer additional execution overhead. I don't think the answer is cut and dried, but I know that if the library forces it out of line the user has no option (without code modifications to the lib). However, if it's inline the user can always make a wrapper if they want to isolate it. Still, I proposed having a Boost level macro so you could decide and not need the wrapper. Jeff
Matthew Herrmann wrote:
Of course template code is a different kettle of fish.
Makes me dream of the lost keyword 'export'... If only template code could be put in .cpp files, I'll be the first to throw (almost) everything out of .h files. Compile times these days are the 11th Plague of Egypt (well, it's Passover now) :-) ...
Matthew Herrmann wrote:
boost-request@lists.boost.org wrote:
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've lingered on this thread for some time and can't hold it in any longer. I can't agree more with Matthew. I was so impressed with the Boost Build concepts that I have converted both our win32 and linux builds for all of our products to use Boost Build. In fact, we aren't even using any of the Boost libraries in our production code yet. We were introduced to Boost Build when evaluating Boost and it resolved several build issues more cleanly than our in-house solution. It appears that we are an oddity in the community, but Boost Build and bjam was not a show stopper. Best Regards - Michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
participants (6)
-
Jeff Garland -
Jody Hagins -
Matthew Herrmann -
Michael Caisse -
Steven Watanabe -
Yuval Ronen