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

From: Andrey Semashev (andysem_at_[hidden])
Date: 2007-04-03 17:28:33

Hello Sohail,

Wednesday, April 4, 2007, 12:18:44 AM, you wrote:

>> > Although I liked this at first too, it seems to me it cannot be
>> > always implemented.  I was now trying to add a singleton to my
>> > library and I can't do it with headers alone.   I need to maintain
>> > the pointer to the global instance somewhere, and that 
>> means having a
>> > global variable which cannot be defined in a header (or otherwise
>> > you'll get duplicates).  Unless I'm missing something, that is...
>> 
>> Static variable in an inline function.

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

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.
- 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.
- 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.
- 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.
- 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.
- 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).
- There are various problems related to dll load/unload order and
dependencies between them.
- Finally, I have to redistribute the dll with my application and make
sure that it will be correctly installed on the user's machine.

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.

-- 
Best regards,
 Andrey                            mailto:andysem_at_[hidden]