9

A number of posts are pretty adamant that source code should not go in a header and that header files should be kept to a minimum. I've been sticking to this with my own code, but I want to use someone else's code to achieve a particular goal (the code is documented here http://ftp.arl.mil/random/).

I notice that this is basically one giant header file which defines a class. Is it OK to leave this in a header file? Should I copy it all to a .cpp file and create a new .h that just declares the functions, structures etc?

If I split it into a .cpp and a .h as I propose, will it work? Or do classes need to be in the header to be accessed by all source code?

Garrett
  • 4,007
  • 2
  • 41
  • 59
user3111174
  • 121
  • 1
  • 1
  • 5
  • 1
    The point of distributing a giant header file is not having to link against a library/cpp file. The user can include the file once, use it and be done with it. I imagine it would be a pain in the ass if this was a tar.gz file and you had to compile it before you could use it. It is different from how you would treat header/cpp files in your application. –  Jan 09 '14 at 16:16
  • 6
    There are reasons to put source code in header files. There are reasons not to. You should understand the issues rather than trying to follow an arbitrary rule. – Dale Wilson Jan 09 '14 at 16:17
  • 1
    I don't recomand it, except in some case where it can be cool to have only a .h for a class. But I usually use `inline` in order to do this clean. There is some good tutorials to understand why put all in the header or not. Check [this](http://stackoverflow.com/questions/453372/writing-function-definition-in-header-files-in-c) question for informations. – MokaT Jan 09 '14 at 16:17

3 Answers3

7

Declarations (stating that something exists) that need to be seen in more than one cpp file should go in header files. Declarations that are local to a single cpp file should be in the cpp file itself.

Definitions (providing the body of a function or allocating/initializing variables) should usually go in cpp files, but not always.

The question you need to understand is does the compiler have enough information to do its job if it has seen the header file and not the corresponding cpp file.

For example: you can call a method if the compiler has seen the declaration (the method prototype) -- unless the method is generic (a templated method or a member of a templated class) or inline in which case the compiler needs to have seen the definition (the method body) too.

Therefore normal methods go in cpp files; templated methods go in header files; inline methods go in header files (and so on).

There are other situations in which definitions belong in header files including static member constants. It all comes back to giving the compiler the information it needs one one hand vs minimizing coupling between separate compilable units on the other. Again there are no hard-and-fast rules, just guidelines coupled with the knowledge and experience of the developer writing the code.

Dale Wilson
  • 9,166
  • 3
  • 34
  • 52
  • Not all declarations should go in headers. Not all definitions should go in source files. Sorry, but I just can't agree with you. – John Dibling Jan 09 '14 at 17:06
  • But I can agree with you. There is no hard-and-fast rule other than to understand how the compilation process works. I'll edit the "Declarations go in headers" clause to be something that you might be able to agree with.. – Dale Wilson Jan 09 '14 at 18:51
  • Thanks, I agree with that. +1 – John Dibling Jan 09 '14 at 19:08
6

.h files are usually shared between many .cpp files. The global variables and function code should not be in the header files, because it would make duplicates during linking.

Constants, defines, function headers and class declarations are fine in header files. You don't have to declare the same thing multiple times and you can share the definitions between .cpp files.

V-X
  • 2,979
  • 18
  • 28
4

source code should not go in a header and that header files should be kept to a minimum.

This is a popular assertion, and while it may generally not be bad advice, you should not draw absolute conclusions from it. Sometimes headers should be minimal and not include definitions. Sometimes the opposite is true. There are reasons why you would do one or the other, but "people say" is not one of them.

Consider the C++ Standard Library. Better yet, consider Boost. Some prestigious C++ experts have said that Boost is the most well-designed C++ library in history. But if you look at the libraries you'll see that they are basically just giant header files for the most part. How does this reconcile with what "they" say?

The point is this: you must understand the reasons why certain files are designed the way they are, and make up your own mind about what is Right and Wrong for each situation.

Should I copy it all to a .cpp file and create a new .h that just declares the functions, structures etc?

I would say probably not. This sounds like a recipe for a maintenance nightmare to me. It would be my first instinct to use the 3rd party library they way the library's author intended it to be used. That way you won't be off the support grid, and you won't introduce a new set of complications that you will be completely on your own to figure out. Unless you have a specific, provable reason to alter the architecture of the library, don't. "They say" isn't a good enough reason for me.

John Dibling
  • 99,718
  • 31
  • 186
  • 324