Revision history [back]

I have not looked at the rosserial code, but there are a couple of reasons why developers sometimes put implementation code within header files.

1) If you put definitions exclusively in header files, the library becomes a "header-only library" meaning that you don't have to actually link against the library. A copy of the code is pulled into your source via the #include directive. This wastes more space as there's a copy of the function in every compilation unit (i.e. .cpp file), but usually is not a problem. For exaple, the popular sqlite database gives you the choice of using sqlite as a header file with library you link against or you can just include one giant amalgamated file. Boost does this often as well. Developers often like this because they can just throw the headers into their source tree and not have to add additional dependencies.

2) Though it's not guaranteed, compilers often inline function definitions in the header file. Depending on how often the functions are used and their size, often it makes more sense to keep them in the header.

3) Laziness - A lot of methods/functions, especially getters/setters are one-lines are it's convenient to just throw them into the .h file and leave the meaty code in the source file.

4) Templates - templates MUST be defined in header files due to the nature of how C++ instantiates templates

In general, you should try to keep as much code as possible in the cpp files so that only a single compiled version of your functions/methods/classes decreasing compile time and the size of your executable targets. If inlining is required, modern C++ compilers perform very aggressive inlining and in most cases will automatically inline functions better than you can. Also, this prevents users from having to recompile everything that touches your library if the implementation changes without the interface changing -- only a relink is required.

I also personally like keeping implementations out of header files as in C/C++ they are useful for referencing the API. Putting the code in header files can sometimes make them hard to read.

I have not looked at the rosserial code, but there are a couple of reasons why developers sometimes put implementation code within header files.

1) If you put definitions exclusively in header files, the library becomes a "header-only library" meaning that you don't have to actually link against the library. A copy of the code is pulled into your source via the #include directive. This wastes more space as there's a copy of the function in every compilation unit (i.e. .cpp file), but usually is not a problem. For exaple, the popular sqlite database gives you the choice of using sqlite as a header file with library you link against or you can just include one giant amalgamated .h file. Boost does this often as well. Developers often like this because they can just throw the headers into their source tree and not have to add additional dependencies.

2) Though it's not guaranteed, compilers often inline function definitions in the header file. Depending on how often the functions are used and their size, often it makes more sense to keep them in the header.

3) Laziness - A lot of methods/functions, especially getters/setters are one-lines one-liners are it's convenient to just throw them into the .h file and leave the meaty code in the source file.

4) Templates - templates MUST be defined in header files due to the nature of how C++ instantiates templates

In general, you should try to keep as much code as possible in the cpp files so that only a single compiled version of your functions/methods/classes decreasing compile time and the size of your executable targets. If inlining is required, modern C++ compilers perform very aggressive inlining and in most cases will automatically inline functions better than you can. Also, this prevents users from having to recompile everything that touches your library if the implementation changes without the interface changing -- only a relink is required.

I also personally like keeping implementations out of header files as in C/C++ they are useful for referencing the API. Putting the code in header files can sometimes make them hard to read.