3

I really like using header-only libraries, as they are really easy to use (no linker issues or having to compile the library separately). For example most of the Boost library is header-only. But then again there are some parts, like boost::python, which requires to be build before. Is this a design choice or a technical necessity?

I gave Boost as an example but would appreciate a more general answer if possible.

Andriy Ivaneyko
  • 20,639
  • 6
  • 60
  • 82
NOhs
  • 2,780
  • 3
  • 25
  • 59
  • 2
    Reduces compilation times, as you can link to the pre-compiled library. For header only libraries you have to compile the library with the code each time, which can considerably increasing compilation times. – Banan Jan 20 '16 at 11:21
  • Yes and each time you use boost the compilation time increase so much. Each time you include a template with its implementation, in each c/cpp file the compiler is reinterpreting the implementation. When you compile Google-Chrome from sources, it takes about 24hours of compilation the first time, imagine with templates in headers only. – Pierre Emmanuel Lallemant Jan 20 '16 at 11:21
  • When a header needed for the implementation, introduces many ugly macros and names in the global namespace, the by far easiest way to isolate it is to only include it in a separate translation unit. That's called a **compiler firewall**, a.k.a. "Cheshire cat" (I don't know why). An alternative is to redeclare stuff, e.g. a Windows API function, but in general that can be very much work, and can introduce an ungood version dependence. – Cheers and hth. - Alf Jan 20 '16 at 11:22
  • Mainly because they are NOT open source. The other reason is the speed. – i486 Jan 20 '16 at 11:26

2 Answers2

7

The original reason to use compiled libraries is to spare compilation time. Libraries can be big. They can be huge.

Another argument is that they keep the source code apart. There is still a good deal of the universe which is not open-sourced.

1

In favor of header only:

  • Less time to set up / import
  • No linking trouble

Against header only:

  • Collisions between headers unresolvable with compile-time firewall between them
  • No dependency hiding possible
  • Increases compile time for each target that includes its headers
  • Adds to symbol pile exported from target. Your simple test file may now export a few thousand symbols.
  • (at extremes) May reduce separation between COMDAT-foldable symbols, causing multiple copies of your symbols to be irremovable from the target output files, causing bloat. This should only happen at 32k+ symbols on ELF, but happens much earlier on other targets (such as Mach-O).
dascandy
  • 7,184
  • 1
  • 29
  • 50
  • Except for the information hiding, all the problems are due to primitive tools. But information hiding / compiler firewall is a real problem. And so we wait, and wait, and wait, and ..., and wait, for modules, e.g. Daveed's. – Cheers and hth. - Alf Jan 20 '16 at 12:17