What is a header?

[E. Robert Tisdale]

If a header is not necessarily a source file, and the sequences delimited by
< and > in header names aren't necessarily valid source file names,
what exactly is a header?

A header is an inclusion at the beginning (head) of your source file.
A header partially compensates for the lack of a true module interface
in the C and C++ programming languages.
A well designed header file is both self sufficient and idempotent.
A header file contains declarations and definitions
that are (or could be) common to two or more source files.
A header file should contain no source code that, by itself,
causes the compiler to emit object code.

 

[Steven T. Hatton]

A header is an inclusion at the beginning (head) of your source file.
A header partially compensates for the lack of a true module interface
in the C and C++ programming languages.
A well designed header file is both self sufficient and idempotent.
A header file contains declarations and definitions
that are (or could be) common to two or more source files.
A header file should contain no source code that, by itself,
causes the compiler to emit object code.

I had not noticed this reply until earlier today. That last point gives me a
bit of pause. Does it suggests I should never have a selfcontained class
definition in a header? Or will it only generate object code if it has an
instance defined? Can you clarify for me your reasoning for this rule?

Something occurred to me regarding headers. If I'm not mistaken, a header
exhibits an IS-A nature. If so, how could the abstract concept of a header
be represented as a class? When I tried to consider that question, I
realized it only seems to have meaning in the context of a source file.
That leads me to ask the same question of a source file.

 

[E. Robert Tisdale]

A header is an inclusion at the beginning (head) of your source file.
A header partially compensates for the lack of a true module interface
in the C and C++ programming languages.
A well designed header file is both self sufficient and idempotent.
A header file contains declarations and definitions
that are (or could be) common to two or more source files.
A header file should contain no source code that, by itself,
causes the compiler to emit object code.

I had not noticed this reply until earlier today.
That last point gives me a bit of pause. Does it suggest [that]
I should never have a selfcontained class definition in a header?
Or will it only generate object code if it has an
instance defined? Can you clarify for me your reasoning for this rule?
Something occurred to me regarding headers.
If I'm not mistaken, a header exhibits an IS-A nature. If so,
how could the abstract concept of a header be represented as a class?
When I tried to consider that question, I realized [that]
it only seems to have meaning in the context of a source file.
That leads me to ask the same question of a source file.

A header file contains the *interface*

cat file.hpp

#ifndef GUARD_FILE_HPP
#define GUARD_FILE_HPP 1
void f(void); // function declaration
#endif//GUARD_FILE_HPP

A source file contains the implementation

cat file.cpp

#include "file.hpp"
void f(void) { // function definition
// ...
}

The header file is included near the head (top)
of a source file (or another header file).
The function declaration does not by itself
cause the compiler to emit any [object] code.
If you include the function definition in multiple
source files and attempt to link the resulting objects together,
the link editor will complain about multiple definitions.

A class definition, by itself, does not cause the compiler
to emit any source code because all of the function definitions
within the class definition are inline by default.
Any external class member function definitions
should be sequestered in a separate source file
which can be compiled and linked into your application.

 

[Steven T. Hatton]

Steven T. Hatton wrote:
[snip]

A header file contains the *interface*

That part I accept as a laudable goal. I've seen header files that look
more like the following, than they do like an interface:

#ifndef _STLP_STRING
# define _STLP_STRING

# ifndef _STLP_OUTERMOST_HEADER_ID
# define _STLP_OUTERMOST_HEADER_ID 0x68
# include <stl/_prolog.h>
# endif

# ifdef _STLP_PRAGMA_ONCE
# pragma once
# endif

#if defined (_STLP_USE_NATIVE_STRING)

// as part of compiled runtime library depends on it.

# if defined (_STLP_MSVC)
# include <streambuf>
# include <istream>
# endif

# include _STLP_NATIVE_HEADER(string)

# endif /* _STLP_USE_NATIVE_STRING */

# if !defined (_STLP_USE_NATIVE_STRING) || defined (_STLP_USE_OWN_NAMESPACE)
# include <stl/_string.h>
# else
# include <stl/_string_hash.h>
# endif /*_STLP_USE_NATIVE_STRING */

// cleanup

# if (_STLP_OUTERMOST_HEADER_ID == 0x68)
# include <stl/_epilog.h>
# undef _STLP_OUTERMOST_HEADER_ID
# endif

#endif /* _STLP_STRING */

// Local Variables:
// mode:C++
// End:


I understand this is all preprocessed to render the actual header that goes
into the file where it's included. It just doesn't seem to be serving one
commonly advertised purpose of an *interface*, i.e., readability.

#ifndef GUARD_FILE_HPP
#define GUARD_FILE_HPP 1
void f(void); // function declaration
#endif//GUARD_FILE_HPP

A source file contains the implementation

#include "file.hpp"
void f(void) { // function definition
// ...
}

The header file is included near the head (top)
of a source file (or another header file).

Assuming the headers are files. The Standard states the following:
"A header is not necessarily a source file, nor are the sequences delimited
by < and > in header names necessarily valid source file names (16.2)."

Is any file that is #included a header file? For example:

http://doc.trolltech.com/3.3/moc.html#moc
"If the class declaration above is found in the file myclass.cpp, the moc
output should be put in a file called myclass.moc. This file should be
#included in the implementation file, i.e. myclass.cpp should contain the
line

#include "myclass.moc"

at the end. This will cause the moc-generated code to be compiled and linked
together with the normal class definition in myclass.cpp, so it is not
necessary to compile and link it separately, as in Method A."

Is the myclass.moc a header file according to the specification? The
standard seems to allow for the inclusion of "source files" as well as
headers, but doesn't seem to provide a very clear definition of what that
means.

If you include the function definition in multiple
source files and attempt to link the resulting objects together,
the link editor will complain about multiple definitions.

The ODR.

A class definition, by itself, does not cause the compiler
to emit any source code because all of the function definitions
within the class definition are inline by default.

I'm confident you are describing the behavior of any reasonable compiler
implementation, but I wonder if this is actually specified.

Any external class member function definitions
should be sequestered in a separate source file
which can be compiled and linked into your application.

I agree.

I also asked the following, which I would also like to find a reasonable
answer for:

If I'm not mistaken, a header exhibits an IS-A nature. If so,
how could the abstract concept of a header be represented as a class?
When I tried to consider that question, I realized [that]
it only seems to have meaning in the context of a source file.
That leads me to ask the same question of a source file.

I have the sense there are many terms and assumptions used in the Standard
which are not defined, but are fairly specific to the subject. "Header" is
a good example, I use "header" in many different ways in different
contexts, but the specific meaning in a C++ context seems to be assumed
without significant clarification.

 

[E. Robert Tisdale]

I have the sense there are many terms and assumptions used in the Standard
which are not defined, but are fairly specific to the subject.
"Header" is a good example, I use "header" in many different ways
in different contexts, but the specific meaning in a C++ context
seems to be assumed without significant clarification.

All "header" really means is that it is included
near the head of a source file or another header.
C doesn't support module interfaces explicitly
so headers were used to *improvise*
without ever acknowledging this deficiency in the language.

 

[Steven T. Hatton]

All "header" really means is that it is included
near the head of a source file or another header.
C doesn't support module interfaces explicitly
so headers were used to *improvise*
without ever acknowledging this deficiency in the language.

"I'd like to see Cpp abolished." - Bjarne Stroustrup

So why does it survive? My suspicion is that everybody thinks the other guy
knows how it's defined, and how it works. People think it's sacrosanct and
not subject to question or challenge. The ugly truth is, nobody knows how
it is defined other than 'poorly'.

 

[Gary Labowitz]

"I'd like to see Cpp abolished." - Bjarne Stroustrup

So why does it survive? My suspicion is that everybody thinks the other guy
knows how it's defined, and how it works. People think it's sacrosanct and
not subject to question or challenge. The ugly truth is, nobody knows how
it is defined other than 'poorly'.

Nonsense. Headers were used to simulate COBOL copybooks. Since
everyone knew how THEY worked (in 1964) it all made perfectly good
sense. With file type associations, I half-like cpp as an extention
that launches my preferred compiler. It would be nice to have cp1,
cp2, etc. for launching different compilers.
Hey! I can do that for myself! The trouble is it ain't portable and my
files may eventually get used by another programmer at work. The real
movement to guard against is people who suggest using the same file
type for generic identification (.src for all source, .doc for all
documents, .txt for all text, etc.).