I've been taught to keep class definitions and code separate.
However, I've seen situations where people would often include some bits of code in the header, e.g. simple access methods which returns a reference of a variable.
Where do you draw the line?
It's up to you. Boost puts almost all of it's code in the header... and they're a well respected library.
Generally speaking, things you want the compiler to inline, or templated code. In either case, the code must be available to the compiler everywhere it's used, so you have no choice.
However, note that the more code you put in a header file, the longer it will take to compile - and the more often you'll end up touching header files, thus causing a chain reaction of slow builds :)
One reason to minimize the amount of code in headers is to minimize the amount of code to be recompiled when the implementation changes. If you don't care about that you can have any amount of code in headers.
Sometimes having the code in headers only is done intentionally to expose the code - ATL does that for eaxmple.
I would stick with the code in .c and .cpp files and headers stuff in .h, .hpp files. Reason is that when I download a .tar.gz or zip of source code, I'm always looking for the .h files for the header stuff and the .cpp files for the source. Many people are used to that so I think you should keep that style.
When you have code in the header file for simple getter/setter methods, it's more or less just fine because you either want to save some working time because of code maintenance (typing same method in header and implementation file), or because you actually want the method to be inline due to function call overhead in time critical places.
You will not only be subjected to slower builds, the linking time might be huge if you have a lot of classes visible more or less everywhere.
Another down side with mixing code between header and implementation files is readability. If you consistenly declare in header file and consistenly keep the code in the implementation file, it's easier to keep the same order between the methods. There are no missing gaps if you know what I mean.
Cheers !
Also note that you can wind up with some strange side-effects if you put code in a header file and aren't careful with your Makefile. I once had a bug due to code I changed in a header that was recompiled into some files but not others because the dependencies weren't correct in the Makefile. This isn't a big deal if you generate your Makefile automatically.
When developing a large C++ project, you need to be vigilant to make each .CPP file couple with as few header files as reasonably possible.
So I have a simple rule for "drawing the line":
If, by inlining the implementation, your header file now needs to include an additional header file, you should move the implementation out of the header and into the .CPP file.
Of course, that isn't the only reason not to inline, but this is a definite example of a line that shouldn't be crossed.
You will want code in the header if you wish to 'inline' the code. Otherwise, there are more advantages to sticking the implementation in the body.
But when the header grows in size, it will take more and more time to compile, so it is useful to use precompiled headers.