tips for developing header only libraries?

[rozick1]

Hi

I'm developing a library which makes use of a core template class. Thus, the library is header only.

I've seen a number of different approaches to header only libraries:
1. The header defines the 'implementation' within the class body:

 template <typename T>
 class Foo{
   void doSomething (T x) {
     // implementation
   }
 };

2. The header defines the 'implementation' below the class body:

 template <typename T>
 class Foo{
   void doSomething (T x);
 };
 
 void Foo<T>::doSomething(T x) {
  // implementation
 }

3. The header includes a tpp/ipp file which has the 'implementation' of the templated class methods

// Foo.h

 template <typename T>
 class Foo{
   void doSomething (T x);
 };

 #include Foo.tpp

// Foo.tpp

 void Foo<T>::doSomething(T x) {
  // implementation
 }

4. Perhaps a combination of the above, with shorter methods using (1) and longer methods using (2)/(3)?

I've also seen different approaches to whether to include all of the library code in a single header or have a master header library which includes headers for each of the templated classes.

I've looked online for any guides on developing header only libraries but couldn't find much. I just wondered whether anyone had come across a guide or perhaps a good (but relatively simple) example of a header only library?

Thanks

[jonnin]

4).
Use 1 and 2, 1 for ~3-5 lines and 2 for longer. 3 should be avoided unless you have a reason to do so, or your company wants it this way, etc. Its just one more file to have to open/maintain and more weirdness that isnt necessary most of the time. My reasoning is that 2) is bloated for really short ones, assuming {} are aligned, that is 3 lines to do the function header and brackets + 1 at least for the code line. You have a line in the class as well so a second copy of the header is a total gain of bloat. Bigger than 5 the one line saved by keeping it in the class quickly becomes less important than the big fat interruption to the class definition. If small bodies feel disruptive to you, then 2) only is fine, and if you have more than a few of them, then 2) only looks better than using 1 at all (20 little getters and setters for example is disruptive, 3 or 4 of them not so bad?). Its subjective.

mostly it comes down to size. Huge things need to be broken up. Smaller things, not really so much. If the library is 50 pages of code, that last bit looks more attractive (master file(s) that pull in the smaller files). This is your driving point -- to make small pieces of code rather than huge ones, that are organized in an easy to understand and follow way.
Or, think of it like this: you downloaded this guy's library, and you open it up to see what you have. What do you want to see?! I want to see the main class in a file to look at its method headers. This is all I want. I don't care about its local variables, I don't care how it does what it does, I just want the methods so I can call them, with a comment or two on anything special that needs doing to use it.