471,319 Members | 1,779 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,319 software developers and data experts.

What sense do h files make in c/cpp?

xz
What sense do h files make in c/cpp?
I never thought about this question before.

Does the existence of h files make sense at all?

Why do we need to declare functions in h files and define/implement
them in cpp?

Jul 2 '07 #1
9 2015
xz wrote:
What sense do h files make in c/cpp?
I never thought about this question before.

Does the existence of h files make sense at all?

Why do we need to declare functions in h files and define/implement
them in cpp?
When you write code you can either: 1) put everything into a single file
or, 2) separate your code into multiple files. Except for very small
projects, option 1 is not practical, possible, and/or desirable. One
enormous source file is difficult to maintain (not to mention,
comprehend), slow to compile, and often outright impossible, such as
when interfacing with third party code for which the source is not
publicly available.

C++ supports "separate compilation" which means that individual source
files can be compiled separately and the end result can be combined into
an executable. Invariably parts of one source file will make reference
to parts of another source file (e.g., calling a function or using a
class defined elsewhere). The header file typically contains the
minimum information necessary for the compiler to understand such a
reference to the contents of another source file.

-Mark
Jul 2 '07 #2
xz
Thank you for your reply.

But I was not asking about Single File vs Multiple Files.
I definitely understand the significance of separating code into
different files.

However, why don't we always put the code describing one object, i.e.
both the declaration and the definition of one class, in the same
file, say, the cpp file?
When using this class, you can simply include the corresponding cpp
file, instead of include the h file like what we are currently doing.

If the use of h file is only for the speed of compiling, I don't see
much significance.
It's not worth to make the structure of the files much more
complicated only to save a little compiling time.
On Jul 2, 3:57 pm, Mark P <use...@fall2005REMOVE.fastmailCAPS.fm>
wrote:
xz wrote:
What sense do h files make in c/cpp?
I never thought about this question before.
Does the existence of h files make sense at all?
Why do we need to declare functions in h files and define/implement
them in cpp?

When you write code you can either: 1) put everything into a single file
or, 2) separate your code into multiple files. Except for very small
projects, option 1 is not practical, possible, and/or desirable. One
enormous source file is difficult to maintain (not to mention,
comprehend), slow to compile, and often outright impossible, such as
when interfacing with third party code for which the source is not
publicly available.

C++ supports "separate compilation" which means that individual source
files can be compiled separately and the end result can be combined into
an executable. Invariably parts of one source file will make reference
to parts of another source file (e.g., calling a function or using a
class defined elsewhere). The header file typically contains the
minimum information necessary for the compiler to understand such a
reference to the contents of another source file.

-Mark

Jul 2 '07 #3
xz
Here is am example for what I am talking about:

Declare and define the Apple class in one single file "Apple.cpp".
Then include this file in the "AppleTest.cpp" file to use it.

//Apple.cpp
#include<iostream>

using namespace std;

class Apple{
public:
void print();
};

void Apple::print() {
cout<<"I am an apple"<<endl;
}

//AppleTest.cpp
#include "Apple.cpp"

using namespace std;

int main() {
Apple apple;
apple.print();
}


On Jul 2, 3:57 pm, Mark P <use...@fall2005REMOVE.fastmailCAPS.fm>
wrote:
xz wrote:
What sense do h files make in c/cpp?
I never thought about this question before.
Does the existence of h files make sense at all?
Why do we need to declare functions in h files and define/implement
them in cpp?

When you write code you can either: 1) put everything into a single file
or, 2) separate your code into multiple files. Except for very small
projects, option 1 is not practical, possible, and/or desirable. One
enormous source file is difficult to maintain (not to mention,
comprehend), slow to compile, and often outright impossible, such as
when interfacing with third party code for which the source is not
publicly available.

C++ supports "separate compilation" which means that individual source
files can be compiled separately and the end result can be combined into
an executable. Invariably parts of one source file will make reference
to parts of another source file (e.g., calling a function or using a
class defined elsewhere). The header file typically contains the
minimum information necessary for the compiler to understand such a
reference to the contents of another source file.

-Mark

Jul 2 '07 #4
On 2007-07-02 23:33, xz wrote:
On Jul 2, 3:57 pm, Mark P <use...@fall2005REMOVE.fastmailCAPS.fm>
wrote:
>xz wrote:
What sense do h files make in c/cpp?
I never thought about this question before.
Does the existence of h files make sense at all?
Why do we need to declare functions in h files and define/implement
them in cpp?

When you write code you can either: 1) put everything into a single file
or, 2) separate your code into multiple files. Except for very small
projects, option 1 is not practical, possible, and/or desirable. One
enormous source file is difficult to maintain (not to mention,
comprehend), slow to compile, and often outright impossible, such as
when interfacing with third party code for which the source is not
publicly available.

C++ supports "separate compilation" which means that individual source
files can be compiled separately and the end result can be combined into
an executable. Invariably parts of one source file will make reference
to parts of another source file (e.g., calling a function or using a
class defined elsewhere). The header file typically contains the
minimum information necessary for the compiler to understand such a
reference to the contents of another source file.

Thank you for your reply.
First off, please don't top-post, and don't quote signatures, thanks.
But I was not asking about Single File vs Multiple Files. I
definitely understand the significance of separating code into
different files.

However, why don't we always put the code describing one object, i.e.
both the declaration and the definition of one class, in the same
file, say, the cpp file?
When using this class, you can simply include the corresponding cpp
file, instead of include the h file like what we are currently
doing.
Because if you do it that way you'll have to compile that code each time
you include it in some other file. By separating it you only have to
compile it once. Imagine a large project with a .h/.cpp pair of files
describing a class using throughout the project, imagine that this class
is quite big, and that the project have a couple of hundred files. With
your solution you'd have to compile that large class a couple of hundred
times, as it is now you only have to do it once.
If the use of h file is only for the speed of compiling, I don't see
much significance.
It's not worth to make the structure of the files much more
complicated only to save a little compiling time.
For large projects it not just a little time, it might be quite
significant amounts of time. Remember that the most expensive thing in
software development is the people working on the project, each minute
they have to wait on the compiler is wasted money.

--
Erik Wikström
Jul 2 '07 #5
On Jul 2, 11:33 pm, xz <zhang.xi...@gmail.comwrote:
But I was not asking about Single File vs Multiple Files.
I definitely understand the significance of separating code into
different files.
However, why don't we always put the code describing one object, i.e.
both the declaration and the definition of one class, in the same
file, say, the cpp file?
Because that's a bad policy. The two are generally the
responsibility of two different people. It's important to keep
them separate, and since files seem to be the organisational
method of choice...
When using this class, you can simply include the corresponding cpp
file, instead of include the h file like what we are currently doing.
Again, files seem to be the organisational method of choice:-).
In this case, the choice has been made by the build
system---all of the build systems I know are file based.
Including a .cpp file will mean recompiling all of the client
code any time you make a minor change in the implementation.
Definitly to be avoided.

And again, it would mean that you cannot acquire modification
rights on the implementation without also acquiring them on the
interface. Which is not a good thing.
If the use of h file is only for the speed of compiling, I don't see
much significance.
You don't see much significance between having to recompiler 20
or 30 lines, and having to recompile 2 million lines, just
because of trivial change in the implementation?
It's not worth to make the structure of the files much more
complicated only to save a little compiling time.
First, I think that the "complexity" is necessary for other
reasons anyway. But I don't consider a difference between 5 or
10 seconds and several hours just "a little".

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Jul 3 '07 #6
On Jul 3, 2:49 pm, James Kanze <james.ka...@gmail.comwrote:
On Jul 2, 11:33 pm, xz <zhang.xi...@gmail.comwrote:
But I was not asking about Single File vs Multiple Files.
I definitely understand the significance of separating code into
different files.
However, why don't we always put the code describing one object, i.e.
both the declaration and the definition of one class, in the same
file, say, the cpp file?

Because that's a bad policy. The two are generally the
responsibility of two different people. It's important to keep
them separate, and since files seem to be the organisational
method of choice...
When using this class, you can simply include the corresponding cpp
file, instead of include the h file like what we are currently doing.

Again, files seem to be the organisational method of choice:-).
In this case, the choice has been made by the build
system---all of the build systems I know are file based.
Including a .cpp file will mean recompiling all of the client
code any time you make a minor change in the implementation.
Definitly to be avoided.

And again, it would mean that you cannot acquire modification
rights on the implementation without also acquiring them on the
interface. Which is not a good thing.
If the use of h file is only for the speed of compiling, I don't see
much significance.

You don't see much significance between having to recompiler 20
or 30 lines, and having to recompile 2 million lines, just
because of trivial change in the implementation?
It's not worth to make the structure of the files much more
complicated only to save a little compiling time.

First, I think that the "complexity" is necessary for other
reasons anyway. But I don't consider a difference between 5 or
10 seconds and several hours just "a little".

--
James Kanze (GABI Software) email:james.ka...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
And also all the function definitions which are in the .cpp file are
compiled and put in their respective .o (object files). So if you
include the .cpp files the function definitions are then compiled
again with the .cpp which includes this .cpp file and then the linker
will say " there are multiple definitions of the same function" in
file_included.o and file_which_includes.o
The linker may either complain and stop or it may link with the first
symbol it found, which incidently is correct in this case and doesn't
absolve you of the sin.

Hope That Helps.
--
Regards,
Taran

Jul 3 '07 #7
xz wrote:
What sense do h files make in c/cpp?
1) You often want to create functions, types and constants which
are local to one compilation unit and which you don't want
interfering with the rest of the program. For example, you might
want to have something like this in a cpp file:

namespace { const int LOOPS = 42; }

and you want that to be local to the current cpp file and not seen
anywhere else. You don't need to worry if some other cpp also uses
the name "LOOPS" for something completely different.

2) Related to 1, but more generally: By exposing the entire cpp file
to other cpp files, you are breaking the principle of minimal public
interfaces. A header file should contain as little code as possible:
That is, the public interface of that module and the bare minimum
implementation details enforced by technical reasons of the compiler.
All the implementation details which are not necessary in the header
file for technical reasons should be "hidden" in the cpp file. This
increases abstraction and modularity, which is good in the long run.

3) For technical reasons, if you are going to include a cpp file in
more than one other cpp file, all the functions in that cpp file must
be 'inline' or else you will get linker errors because of duplicate
implementations.

4) Related to that: If you have a static member variable or a static
variable local to that cpp file (usually inside a nameless namespace
or such), you *will* get a linker error if you include the cpp file in
more than one other cpp file. That's because the linker will see two
instances of that static variable and has no way of knowing which one
it should use. You can't "inline" static variables as you can do with
functions.

5) Compiling each cpp file separately (and keeping all headers as
minimal as possible and with as few #includes as possible) will
greatly speed compilation times in large projects. Usually if you
just modify one cpp file then the compiler just has to recompile
that cpp file and then it can link everything into the final binary.
If, however, that cpp file was included in dozens of other cpp files,
which in turn are included in dozens of others and so on, modifying
one cpp file may suddenly require for the compiler to recompile most
of the others too, for no good reason. With very large projects that
could take hours instead of a few seconds.

6) Likewise, compiling one cpp file would take much longer if it
includes dozens of other cpp files (which themselves include dozens
of others and so on).

7) If module A references module B, and module B references module A,
you have a problem. With minimal headers this problem can usually
be solved (as long at least one of A or B uses only references/pointers
to the other). However, if you always included the cpp files, you would
have no solution to this problem.

8) Header/source file pairs is not the only possible way of compiling.
Bunch-of-headers/big-precompiled-library is another very common
situation (which is actually almost always the case with the standard
libraries of the compiler). There's no reason why you would want to
have the entire source code of the library when just the headers are
enough to use it.
Jul 3 '07 #8
xz

Sorry for top-posting and thanks for reminding. I am a rookie here
that I did not know much about those things.

Also, thank you guys a lot for providing so many details.

I am actually switching from Java to C++. And in Java, I don't have
this header file thing. That's why I had the question.

Now, my understanding is that h files work as an interface between the
developers of the modules (the corresponding cpp files or the .o
files) and the users of the modules, i.e. the clients.
So they are like manuals and control panels. Basically, you read the h
files to know the usage of the classes and functions, and use them by
dealing with the h files.
Is that correct?

Jul 3 '07 #9
xz wrote:
I am actually switching from Java to C++. And in Java, I don't have
this header file thing.
That is, of course, a major defect of Java. Not that it doesn't
have header files, per se, of course---the C++ solution of
textual inclusion is far from elegant---but that it doesn't have
any means whatsoever of separating the external specification
from the actual code. That makes Java significantly more
difficult to use in larger projects.
That's why I had the question.
Now, my understanding is that h files work as an interface between the
developers of the modules (the corresponding cpp files or the .o
files) and the users of the modules, i.e. the clients.
So they are like manuals and control panels. Basically, you read the h
files to know the usage of the classes and functions, and use them by
dealing with the h files.
Is that correct?
More or less. I'm not sure about "reading the .h files"; on
most of the larger projects I've been on, they've been
automatically generated from the specifications (using Rational
Rose, or something of that sort), and aren't necessarily very
readable. But the .h files do represent a different type of
information, generally created at a different level. (This
isn't totally true, since they have to specify the private
members of the class as well. But with rigorous use of the
compilation firewall idiom...)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Jul 4 '07 #10

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

52 posts views Thread by Tony Marston | last post: by
54 posts views Thread by Brandon J. Van Every | last post: by
121 posts views Thread by typingcat | last post: by
16 posts views Thread by thenightfly | last post: by
1 post views Thread by mikeotp | last post: by
669 posts views Thread by Xah Lee | last post: by
3 posts views Thread by Developer.Man4 | last post: by
reply views Thread by rosydwin | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.