Re: [boost] [system] Why is this not header-only?

From: Sohail Somani (s.somani_at_[hidden])
Date: 2007-04-03 18:58:33

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Andrey Semashev
> 
> Hello Sohail,

Hi Andrey, thanks for joining in the fun :-)

> Wednesday, April 4, 2007, 12:18:44 AM, you wrote:
> > Oh come on guys, aren't we just getting silly? To avoid 
> what? Adding cpp
> > files to the build?
> 
> These files have to be added to every project that uses the lib which
> looks a bit strange in the first place. Or were you speaking about
> compiling these .cpp into .lib or .dll and linking?

Well I was talking about getting the samples running which I thought is
the biggest barrier to using Boost. But I was assuming that eventually
the user would be happy enough to then compile it into a library
themselves or figure out the magic of bjam.

The thing is, I've had these issues so many times (3rd-party libraries)
that my build can basically handle any weird build requirements. So for
me, building a new library is easy-peasy. I feel I will be getting
punished because I solved the problem in a somewhat non-stupid way. I
can't imagine any C++ developer not having solved this problem for
themselves. Indeed the boost guys did by writing Boost Jam.

> Externally linked modules (.dll or .so) often give a lot of headache,
> though sometimes they are really needed. The most common problems are:
> 
> - The dll needs to be built first. That means I have to go read the
> docs how to do it, what it depends on and compile.

Ok, and? You have to do this with everything you use. If you start
shipping "header-only" libraries, then you're just delaying the problem
because you ship all the "libraries". The equivalent would be to compile
all boost libraries into one giant dll. If you start shipping libraries
separately (i.e. out of sequence releases - which is in the plan, I
believe), the problem reappears.

> - Not all compilers have auto-link feature (GCC, doesn't, BTW). So I
> have to modify my projects to link against it. Note that this also
> implies that the import .lib or .so has to be available during this
> process. This may be easy to guarantee in small local builds but gives
> additional problems when running large distributed and parallel
> automatic (nightly) builds.

Use a build system that can handle it. This is C++ after all.

> - After building the application I will need this dll somewhere in my
> PATH or LD_LIBRARYPATH to execute the app. This means configuration
> problems - everywhere the app needs to be executed the dll should be
> available in one of the aforementioned paths

Use a static library if this is a real issue for you.

> - Even if the dll is available, I still don't know wether it is _my_
> dll, not the one that user or another application forgot to delete.
> This is where funny things like "why the hell it crashes on your PC?
> it works perfectly for me" happen. As a special case of this, I'm not
> sure the dll is linked with the same CRT as the application either.

Same as above.

> - On Linux (at least, may be not only there) there are a lot of
> problems with symbols visibility and their aliasing, especially in
> relatively large applications. Often such problems are quite difficult
> to track and isolate.

Use a linker script. Its pretty straightforward.

> - There may be problems with some core C++ features like RTTI and
> exceptions when used across dll boundaries. Linux is more affected to
> this. I guess, this may also take place when compiled by different
> compatible compilers modules interact (i.e. different versions of the
> same compiler or compatible compilers like VC and ICL)

I'll have to say that the best C++ interface is a C interface. Unless
you ship your source. Which boost does. \o/

> - There are various problems related to dll load/unload order and
> dependencies between them.

You'll have to specify where this is an issue with boost.

> - Finally, I have to redistribute the dll with my application and make
> sure that it will be correctly installed on the user's machine.

Use a static library.

> 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.

Same as above.