On 05/09/05, Anthony Williams <anthony_w.geo@yahoo.com> wrote:

...

Matt Hurd <matt.hurd@gmail.com> writes:

As for compilers, I generally use VC7.1 and gcc-4.0.1 (compiled for win32). I have access to VC6 if required.

Thanks. Updated.

I think we should try and make it a header-only library akin to most of the rest of boost, if we can; having to link in a separate library is a source of pain for users, especially if it has to be linked as a separate DLL. I appreciate that there are some areas which might require this, but if we can avoid the requirement when these areas are not used, that would be good (don't pay for what you don't use).

I think we have a general agreement of this as a goal. I've added a few simple goals as placeholders. I added a "hpp only" to the todo list so we can mark off the items if as hpp only as we go. Regards, Matt.

Beman Dawes <bdawes@acm.org> wrote:

Header-only libraries can be useful, but not if that means they have to include system headers. That is a disqualifier for portable code - too many really bad experiences with macros in system headers.

Boost.Threads already does this so at least we'll be no worse off ;-) matt. __________________________ e.g. from thread.hpp #ifndef BOOST_THREAD_WEK070601_HPP #define BOOST_THREAD_WEK070601_HPP #include <boost/thread/detail/config.hpp> #include <boost/utility.hpp> #include <boost/function.hpp> #include <boost/thread/mutex.hpp> #include <list> #include <memory> #if defined(BOOST_HAS_PTHREADS) # include <pthread.h> # include <boost/thread/condition.hpp> #elif defined(BOOST_HAS_MPTASKS) # include <Multiprocessing.h> #endif

Martin Slater wrote:

Please , please please no windows.h ;) Just spent an unhappy day or two again last week fighting against it. I would much prefer to link against something and anything that needed it was compiler firewalled in a cpp if possible.

I also agree that preferably all system headers should be banned from boost include files. This has been discussed back and forth mainly for threads and network. Is there a policy or guideline or is it from case to case. Would it be possible to handle in some other way so ther user can choose. From my point of view i think it's bad for several reasons; they are often bad citizens, compile time, knowing whats included so system apis aren't crept in code that should not use system apis. /Michel

I am really surprised to see everyone agreeing that a header-only implementation is preferable.

I completely agree with that sentiment.

In my day job we have strict rules about what is allowed to appear in header files, the principal reason being to reduce dependencies between header files in order to keep compile times and code bloat manageable. For example, we prefer forward declaring classes over #includes when possible, we use the pimpl idiom on occasion, we use abstract interfaces in as much code as possible, etc. All of which help to make for a more loosely coupled design which has the benefit of minimising the amount of code that is transitively included in each compilation unit.

I think that boost is an excellent set of C++ libraries, but I have always been dissapointed by the apparent philosophy of putting most or all code into header files. I can't remember the details, but we had one occasion about a year ago where our application's build times increased fairly dramatically when we upgraded boost versions. We tracked the problem down to a boost header that we were including having been changed to include another boost header which ended up transitively bringing in hundreds of header files.

Now I know that making the most of C++'s template mechanisms does imply that more code will end up in headers than traditional C/C++ code, but to me that is all the more reason to look extra hard for opportunites to place at least some of the code into .cpp files.

As a user of boost, linking in a few libraries is a minor pain that I am willing to take, compared to the pain of long build times.

cheers, mick

I think that many of the libraries are well suited to header only implementations. In particular, where most classes are templates. In something like threads however, the opposite is true. The implementation of threads is completely platform dependent and those platform details ought to be invisible (i.e. buried in .cpp files) to a library user. Building and linking in a library is a very small price to pay considering how good Boost.Build has become in recent releases. If there is to be any effort devoted to getting novices running Boost.Threads it should be directed at improving the "Getting Started" documentation (although I personally find it quite sufficient) or by providing pre-built libraries for the popular compilers. Glad to hear Boost.Threads is getting a re-work though. I thought it was a shame that it wasn't getting any attention lately, considering how important it is for cross-platform development. Thanks, Dylan Trotter

On 07/09/05, Mick Hollins <mick@hollins.id.au> wrote: Anthony Williams wrote:

...

Matt Hurd <matt.hurd@gmail.com> writes:

<snip>

...

I think we should try and make it a header-only library akin to most of the rest of boost, if we can; having to link in a separate library is a source of pain for users, especially if it has to be linked as a separate DLL. I appreciate that there are some areas which might require this, but if we can avoid the requirement when these areas are not used, that would be good (don't pay for what you don't use).

Anthony

<snip> good arguments for better quality via minimised dependencies and Lakos-esque "large scale" compiler firewalls and the like from Mick </snip> I guess the widespread adoption of the inclusion model for template based code has resulted in the wider adoption of the header only model. You could blame the lack of practical export facilities for that mainly I think. For many template based libs, especially heavy type computation libs like boost.mpl, you don't have much choice. That's just the downside of modern C++ until the compiler and linker technology catches up. I agree that all things being equal faster compile times and hidden platform dependencies are preferable. Auto-linking would take out most of the pain from linking. The big negative is for other library writers wishing to rely on basic synchronization primitives without forcing link dependencies where their current libs don't have such a requirement. For example, boost.spirit follows the header only approach but conditionally requires a basic synchronization primitive. It seems to cope OK with boost.thread as it is now, so perhaps it is not important. Any library writers have a comment on what they would prefer? Q: Library approach instead of header only Pros: - Faster compile times (I wonder how much faster in this case) - Minimises introduction of platform headers (more important IMO) and other dependencies Cons - May introduce link dependencies to libs that don't have them (autolinking should take care of this) - Perceived barrier to entry for use by library authors (needs more input from authors) - shared library linkage adornments detract from the code (pretty petty) - May not even be possible due to the nature of the statics required (make the argument moot, expect perhaps for the 2nd alternative approach below) - Easier support for header only. Witness the FAQs w.r.t. serialization, thread and regex linking issues. - Header only "encourages" synchronized versions of classes that may optionally have synch policy parametrisation. I dream that such policies would be as pervasive as allocators in STL so I can stop writing them myself. I have a dream... There are two other alternatives: 1. enable both by configuration macro (cpp becomes is used as an ipp) - unusual 2. decide on which should be header only to suit lib authors as I suspect simple synch primitives such as mutexes and their locks are needed by most authors. On balance the volume of the voices seems to indicate a preference for library approach rather than a header only attempt. Votes? Further pros or cons? matt.

"Peter Petrov" <ppetrov@ppetrov.com> wrote in message news:dflha4$dab$1@sea.gmane.org...

Matt Hurd wrote:

...

There are two other alternatives:

1. enable both by configuration macro (cpp becomes is used as an ipp) - unusual

2. decide on which should be header only to suit lib authors as I suspect simple synch primitives such as mutexes and their locks are needed by most authors.

On balance the volume of the voices seems to indicate a preference for library approach rather than a header only attempt.

Votes? Further pros or cons?

My vote would be for the hybrid approach - i.e. basic stuff is inline by default, but in the rare cases when system headers cause problems, it should be possible to switch to library-based implementation using a configuration macro. This should please everyone.

Trying to please everyone is a recipe for bloated difficult to maintain code, among other problems, IMO. Including system API headers from within our public library headers is poor software engineering practice, and except in the most exceptional circumstances we should avoid it. Beyond immediate problems, there is a long history of latent problems surfacing when porting such code to new platforms. --Beman