Header include order

[CBFalconer]

You are confused.
A file included by the C preprocessor directive
is *not* necessarily a header file.
A file with *.h extension is *not* necessarily a header file.
Neither the C preprocessor or the C programming language
specify file name extensions for header files.

We should take especial notice now. That omniscient expert, ERT,
has made his pronouncement. Since he specifies his organization
as "Jet Propulsion Laboratory", and his return address as
@jpl.nasa.gov, he carries very imposing credentials. After all,
his abilities and careful standards adherence and understanding
are obviously protecting the entire US space program. The utter
drivel posted in c.l.c under his name is obviously a concerted
plot by the evil (left/right/center) to undermine his shining
reputation.

 

[Arthur J. O'Dwyer]

We should take especial notice now. That omniscient expert, ERT,
has made his pronouncement. Since he specifies his organization
as "Jet Propulsion Laboratory", and his return address as
@jpl.nasa.gov, he carries very imposing credentials. After all,
his abilities and careful standards adherence and understanding
are obviously protecting the entire US space program. The utter
drivel posted in c.l.c under his name is obviously a concerted
plot by the evil (left/right/center) to undermine his shining
reputation.

Chuck, as much as ERT has trolled and misinformed before, I
must say that your post looks uncalled-for here. I think he's
right -- a "header file," as the term is commonly used, refers
to a file that is included at the top of another file, and
contains declarations and macros and suchlike.
A file included in the middle of another file, containing
data or code templates, is *not* a "header file" -- it's a
"data file" or a "code template file."
FWIW, the Standard explicitly mentions that

[an] #include preprocessing
directive causes the named header or source file to be
^^^^^^^^^^^^^^
processed from phase 1 through phase 4, recursively.

by which I gather that the committee had something of the
same idea in mind. Makes sense to me, anyway.

So, let's leave the name-calling for the defenses of 'void
main' and 'malloc' casting, announcements of 'obvious trolls',
and indictments of 'indigenous plonkers', huh? IMHO
Tisdale is right for once.

-Arthur

 

[Richard Heathfield]

For header file includes

a.c file should always include a.h as the first file. That way
a.h will always be self sufficient and header file include order
will not matter.

The following article should help:

http://www.eventhelix.com/RealtimeMantra/HeaderFileIncludePatterns.htm

I doubt it. It's chock-full of syntax errors and undefined behaviour. Quite
a trick for a header file.

#ifndef _a_h_included_
#define _a_h_included_

It's a bad idea to use leading underscores.

#include "abase.h"
#include "b.h"

No source, no comment.

// Forward Declarations

Syntax error in C90.

class C;

Presumably class is typedef'd in abase.h or b.h?

class D;

class A : public ABase

And that's a syntax error.

Not a great page, IMHO.

 

[Moosebumps]

Good article, that's exactly what I do... took a while to pick that pattern
up, since I haven't seen it mentioned in a lot of C/C++ books. Some of my
coworkers still don't know when to use forward declarations.

 

[Dan Pop]

What do you call

struct foo foo_thing;

?

An object definition. Are you sure you've read the parenthetical note
in my previous post?

Dan

 

[Dan Pop]

I agree with Dan and Alan for the proverbial 99.44% of
all uses of header files, but there *are* cases where it
can be useful to put definitions in headers. A few I've
run across:

- When part of the code is generated by a "helper"
program, it's often convenient to have the helper
write a header. This is often seen in connection
with static initializations, where the main file
contains something like

static const struct thingummy big_table[] = {
#include "generated.h"
};

There's a quibble about whether the header in this
case "reserves storage" or not -- but at any rate,
it certainly doesn't contain declarations!

That file is NOT a header and using the .h extension doesn't make it one.
A more appropriate name for that file is generated.c.

The name "header" was not chosen at random for this type of files.

- Headers are a good place for widely-used `inline'
functions. Again, there's a quibble about whether
defining such a function "reserves storage," but
again it's clear that such a header contains more
than mere declarations.

We were clearly discussing about *object* definitions. Macro definitions,
type definitions and even inline and static function definitions do
belong to headers.

Dan

 

[Alan Balmer]

That's *not* a header file.
A header file is #included at the *head* of another file.

The standard defines the standard headers. It does not specify that
they can only be included at the "head" of another file.

 

[Alan Balmer]

An object definition. Are you sure you've read the parenthetical note
in my previous post?

That's why I asked the question. You said that your naming there
applied to types, not objects, but did not specify your convention for
describing object declarations/definitions.

 

[Alan Balmer]

In a header file included by stdlib.h

You'd have been right with either stddef.h or stdio.h.

The standard does not specify that stdlib.h includes any other files.

 

[Eric Sosman]

You'd have been right with either stddef.h or stdio.h.

The standard does not specify that stdlib.h includes any other files.

... but the Standard *does* specify that <stdlib.h>
defines `size_t'. 7.20, paragraph 2.

 

[Alan Balmer]

... but the Standard *does* specify that <stdlib.h>
defines `size_t'. 7.20, paragraph 2.

You're right, of course. I thought I remembered only three places
(above plus wchar.h). Should have double-checked.

 

[Dan Pop]

That's why I asked the question. You said that your naming there
applied to types, not objects, but did not specify your convention for
describing object declarations/definitions.

I'm using the standard terminology, no point in inventing my own: if it
reserves space, it's an object definition, otherwise it's a mere
declaration.

Dan

 

[CBFalconer]

.... snip ...

So, let's leave the name-calling for the defenses of 'void
main' and 'malloc' casting, announcements of 'obvious trolls',
and indictments of 'indigenous plonkers', huh? IMHO
Tisdale is right for once.

Where did I call him names? I referred to him as an "omniscient
expert". I attributed any misinformation posted (allegedly) by
him to a plot by evil fringe groups? However I should probably
have stripped all of his post apart from the "you are confused"
portion.

 

[Eric Sosman]

You're right, of course. I thought I remembered only three places
(above plus wchar.h). Should have double-checked.

Also <string.h>. The Standard's practice seems to be
that any header defines all the types used in its function
declarations. There are a few exceptions (e.g., <stdio.h>
doesn't define va_list even though vfprintf() et al. use
it), but they are rare.

I always get tripped up by `offsetof'. For some insane
reason I expect <stdlib.h> to provide it, but of course it's
found only in <stddef.h>. Evidence of a warped childhood,
I guess.

 

[Chris Torek]

Where did I call him names? I referred to him as an "omniscient
expert". I attributed any misinformation posted (allegedly) by
him to a plot by evil fringe groups?[/QUOTE]

I imagine Arthur interpreted this as sarcasm. (I certainly did. )

However I should probably have stripped all of his post apart from
the "you are confused" portion.

Whenever I see that line, I am reminded of the old "rogue" game.
I imagine my "@" character wandering about the dungeon, looking
for the Amulet of Yendor, and encountering a "T":

The Trollsdale hits! -more-

You are confused.

(Of course, in rogue, it was a different monster that caused
the "confusion", after which one's attempts to move or hit caused
a random direction to be chosen. Trolls merely hit very hard, and
had good built-in armor.)

(At the U of MD, we once managed to get hold of the source to an
older version of rogue, and someone "customized" it to put in the
names of various professors and other characters: "The Zelkowitz
hits! Your PhD is denied!" And so on.)

(Seriously, though, I do think he uses it more as a command than
a statement.)

 

[Alex]

On Wed, 19 Nov 2003 14:17:57 -0800, "E. Robert Tisdale"

You'd have been right with either stddef.h or stdio.h.

The standard does not specify that stdlib.h includes any other files.

Turns out I was incorrect.

A.3.11 GENERAL UTILITIES <stdlib.h>

EXIT_FAILURE
EXIT_SUCCESS
<...>
size_t

However, the fact that this is accomplished by the
inclusion of another header file, within stdlib.h,
is a speculation. It is not mandated by the standard.

Alex

 

[E. Robert Tisdale]

Turns out I was incorrect.

A.3.11 GENERAL UTILITIES <stdlib.h>

EXIT_FAILURE
EXIT_SUCCESS
<...>
size_t

However, the fact that this is accomplished by the
inclusion of another header file, within stdlib.h,
is a speculation. It is not mandated by the standard.

That's irrelevant.
All you need to do to prove my assertion false
is to present *one* example of an implementation
where size_t is defined in stdlib.h and *not*
in some included header file.

 

[Alex]

Alex wrote:

That's irrelevant.
All you need to do to prove my assertion false
is to present *one* example of an implementation
where size_t is defined in stdlib.h and *not*
in some included header file.

If you insist. Solaris 2.6:

/usr/include/stdlib.h:

<...>

#ifndef _SIZE_T
#define _SIZE_T
typedef unsigned int size_t;
#endif

<...>

Alex

 

[Richard Bos]

That's irrelevant.
All you need to do to prove my assertion false
is to present *one* example of an implementation
where size_t is defined in stdlib.h and *not*
in some included header file.

Nope. All we need to do to prove your assertion false is to note that
the Standard doesn't demand that <stdlib.h> includes any header files,
but does demand that it define size_t.

Richard

 

[Dan Pop]

I always get tripped up by `offsetof'. For some insane
reason I expect <stdlib.h> to provide it, but of course it's
found only in <stddef.h>.

In practice, offsetof is the only reason for including <stddef.h>.
The other thing defined only by <stddef.h> is ptrdiff_t, which is
seldom used explicitly.

Code needing NULL or size_t is extremely likely to include another
header defining them (<stdio.h>, <string.h> or <stdlib.h>, usually).

Dan