ansaurus

Question

Pedantic: What Is A Source File? What Is A Header? (Not A Newbie Question)

Answer 1

+1 A:

Isn't this saying that a header may be implemented as a source file, but there again may not be? as for "what is a source file", it seems very sensible for the standard not to spell this out, given the many ways that "files" are implemented.

anon 2010-08-12 16:02:54

A long time ago, I worked on a Forth system that didn't have files, although there was an optional file system available. It used disk blocks instead. Assuming sufficient system size (it wasn't big), etc., would it have been possible to implement standard C++95 on it?

David Thornley 2010-08-12 16:19:22

@David Yes, I remember that well - I wrote my own FORTH system in about 1981. Mine didn't even have the ability to access the CP/M file system, it only used blocks, but you could certainly implement files on top of the blocks, so I'd say "yes".

anon 2010-08-12 16:22:20

Absolutely sensible, and I expect that's the answer to my question. Coming from a Windows-application background, a header has always been a source file. Understanding that C++ goes well beyond just traditional apps running on a box, I was hoping to get more insight about what the differences are.

John Dibling 2010-08-12 19:40:49

Answer 2

+3 A:

My reading is that the standard headers, included by use of <> angle brackets, need not be actual files on the filesystem; e.g. an implementation would be free to enable a set of "built-in" operations providing the functionality of iostream when it sees #include <iostream>.

On the other hand, "source files" included with #include "xxx.h" are intended to be literal files residing on the filesystem, searched in some implementation-dependant manner.

Edit: to answer your specific question, I believe that "headers" are limited only to those #includeable facilities specified in the standard: iostream, vector and friends---or by the implementation as extensions to the standard. "Source files" would be any non-standard facilities (as .h files, etc.) the programmer may write or use.

Derrick Turk 2010-08-12 16:06:00

Does this suggest that programmers should not `#include <>` their own source files?

John Dibling 2010-08-12 16:10:03

@John: that is how I read the standard. I suppose an implementation could define its own additional </code>#include <></code>able "headers", but for outside code, quotes seem to be the way to go.

Derrick Turk 2010-08-12 16:11:30

@John: That would apparently be implementation-defined, as there is apparently no guarantee that `<>` will ever look for an actual file.

David Thornley 2010-08-12 16:13:44

@John: As I learned the oral tradition, <> is for stuff provided by the system and the compiler, and you should use "" for your own stuff, but as far as I know that is not actually *written* anywhere.

dmckee 2010-08-12 16:17:35

Regarding the edit: 16.2/2 (quoted in the question) says that a header is anything included with `<>`, not just the standard headers.

Mike Seymour 2010-08-12 16:25:03

@Mike: Sure...now what's a header? On most systems, it's a source file somewhere. However, the Standard explicitly says it doesn't need to be. Perhaps it is a file, but encrypted with an asymmetric key so that it can be read but not changed, and such that ordinary users couldn't create one. I think the standard allows that.

David Thornley 2010-08-12 16:35:26

@David: there is no definitive answer to "what is a header?", beyond "something included with `<>`"; it is what the implementation defines it to be. All the standard specifies is the effect of including the standard headers; everything else is left up to the implementation.

Mike Seymour 2010-08-12 16:48:18

@Derrick et al: It's interesting to interpret the Standard that programmers should not `#include <>` their own code. The Joint Strike Fighter standard dictates the opposite (citation follows): http://www2.research.att.com/~bs/JSF-AV-rules.pdf

John Dibling 2010-08-12 17:01:55

4.7 Header FilesAV Rule 33The #include directive shall use the <filename.h> notation to include header files.Note that relative pathnames may also be used. See also AV Rule 53, AV Rule 53.1, and AV Rule 55 for additional information regarding header file names.Rationale: The include form “filename.h” is typically used to include local header files. However, due to the unfortunate divergence in vendor implementations, only the <filename.h> form will be used.

John Dibling 2010-08-12 17:02:28

@John: it's wrong to interpret the Standard that way, because it says nothing of the sort. It's very clear: "How the places are specified or the header identified is implementation-defined."

Mike Seymour 2010-08-12 17:05:15

@John: I suspect the JSF guidelines were written to reflect the behavior of available compilers as opposed to the behavior specified by the standard.

Derrick Turk 2010-08-12 17:18:22

@Derrick: I think you're probably right, but it was interesting to me as my own policy has always been the opposite. Never use #include <> for your own code. The JSF made me rethink this, and is also what spurred this question.

John Dibling 2010-08-12 19:37:45

Answer 3

+2 A:

The standard headers (string, iostream) don't necessarily have to be files with those names, or even files at all. As long as when you say

#include <iostream>

a certain list of declarations come into scope, the Standard is satisfied. Exactly how that comes about is an implementation detail. (when the Standard was being written, DOS could only handle 8.3 filenames, but some of the standard header names were longer than that)

James Curran 2010-08-12 16:07:21

It seems to me that this particular case could have been handled by the "as if" rule, though. There are clearly defined effects of `#include <iostream>`, as well as other possible effects, and the "as if" rule by itself would seem to cover that.

David Thornley 2010-08-12 16:16:39

Answer 4

A:

Hmmm...

My casual understanding has been that the distinction between <> includes and "" includes was inherited from c and (though not defined by the standards) the de facto meaning was that <> searched paths for system and compiler provided headers and "" also searched local and user specified paths.

The definition above seem to agree in some sense with that usage, but restricts the use of "header" to things provided by the compiler or system exclusive of code provided by the user, even if they have the traditional "interface goes in the header" form.

Anyway, very interesting.

dmckee 2010-08-12 16:15:58

The standard doesn't restrict the use of "header" - it leaves it up to the implementation. If the implementor decides it can be user code, then it can be user code.

Mike Seymour 2010-08-12 16:38:49

Answer 5

+2 A:

As your quotes say: a header is something included using <>, and a source file is the file being compiled, or something included using "". Exactly where the contents of these come from, and what non-standard headers are available, is up to the implementation. All the Standard specifies is what is defined if you include the standard headers.

By convention, headers are generally system-wide things, and source files are generally local to a project (for some definition of project), but the standard wisely doesn't get bogged down in anything to do with project organisation; it just gives very general definitions that are compatible with such conventions, leaving the details to the implementation and/or the user.

Nearly all of the standard deals with the program after it's been preprocessed, at which time there are no such things as source files or headers, just the translations units that your last quote defines.

Mike Seymour 2010-08-12 16:21:02

ansaurus

tags:

views:

answers:

Pedantic: What Is A Source File? What Is A Header? (Not A Newbie Question)

related questions