No. "#include [filespec]" means, verbatim: insert the contents
of [filespec] here. If the end result is valid C++ code, then
it's allowed. Whether [filespec] contains class definitions,
or functions, or anything else, it's allowed as along as the
end result, after all file inclusion, is valid C++ code.
It's a little more complicated than that. A program consists of
one or more translation units. The results of each expansion
after the include is a separate translation unit. Anything in
the header will be present in all of the translation units which
include it; if the header is included in more than one
translation unit, then anything in the header will be declared
or defined in multiple translation units.
In some cases (e.g. class definitions, template definitions,
inline functions, and declarations which aren't definitions)
this is required by the standard. In others ("normal" function
definitions), it is forbidden. So you put whatever must be
present in all translation units which use it in a header, and
anything else in a source file.
And for the original poster (since no one seems to have
mentionned it yet): there's nothing magic about .h and .cpp.
As far as the standard is concerned, both headers and source
files can have any name you want. Most compilers will treat
any file whose name ends in .cpp, .cxx or .cc (or .C, if the
file system is case sensitive) as a C++ source, so those endings
are highly recommended. (.cpp seems almost univeral in the
Windows world; under Unix, both .cc and .cpp seem to be used,
with perhaps a slight majority for .cc. .cxx and .C, I think,
are mainly historical.) All compilers I know will allow
absolutely anything for a header: `#inclued "toto.exe"' for
example, will work just fine. Still, such arbitrariness will
cause confusion for anyone working with your code, and possibly
with other tools as well, so you should probably stick more or
less to the conventions: .hpp if your sources are .cpp, .hh if
they're .cc, and .h for files which are shared between C and
C++. Modulo some exceptions: function implementations are often
put in a separate header file which is included by the "public"
header; .ihh (i for "inline") and .tcc (t for "template") seem
to be two frequent conventions for this. I also use .lhh for
local headers, which will not be exported; using a different
ending means that Doxygen won't pick them up when generating the
external documentation. (But that's a personal convention; I
don't think it's widespread practice.)
