Why didn't C++ specify filename extensions?

Question

Apparently even today there is no single "official" standard for C++ file extensions. There are just common conventions.

To me this stands out as an anomaly... file extensions are heavily ingrained and I can't think of any other examples of such a popular file type not having standards for this. At least it seems peculiar and stands especially in contrast to C.

I looked in my copy of Bjarne Stroustrup's The C++ Programming Language (2nd edition, 1991) and it has this to say (Ch.4, p114):

Header files are conventionally suffixed by .h and files containing function or data definitions by .c. ... Other conventions, such as .C, .cxx, .cpp, and .cc, are also found. The manual for your compiler will be quite specific about this issue.

I wonder why Dr. Stroustrup chose not to be specific about this issue himself?

According to the Historical Note in chapter 0, formal industry standardization of C++ had been going on for years prior. One would have thought that standardizing on this detail would have / could have occurred then.

Where did these "competing" file extensions come from? Did this ever come up for standardization, but the idea was declined or deferred? I can see that today it might take overcoming a lot of inertia to change something like this, but that wouldn't have been so originally.

---

Edit: A lot of comments are focusing on the merits of filename extensions. That in itself is certainly not what is being asked. This is a historical question looking for facts about past events. Given that today we have multiple alternate extensions for C++ the question wants to know, "why is that so".

Also, seems there are two closely related aspects - one is "why didn't C++ specify this". The other is "given that C++ didn't, specifically why did the naming conventions fragment".

---

Update: Since this is a "history" question I'm looking for answers that are factual, ideally citing sources. Speculation and guessing may be useful in the comments, but I don't think would make for solid answers.

Answer 1

The first edition of Stroustrup's "The C++ Programming Language" (1986) consistently uses a ".h" extension for C++ header files and ".c" for C++ source files. C and C++ source files were distinguished by which compiler you used, cc for C and CC for C++.

The second edition (1991) uses the same convention, but mentions other extensions:

Header files are conventionally suffixed by .h and files containing function or data definitions by .c.. They are therefore often referred to as ".h files" and ".c files", respectively. Other conventions such as .C, .cxx, .cpp, and .cc are also found. The manual for your compiler will be quite specific about this issue.

So as of 1986, there was a conventional extension for C++ source files: .c. Over the following years, it was found useful to use the extension to distinguish between C and C++ source files, or perhaps some compiler implementers simply decided to use a different extension -- but that decision apparently was made separately by different people and groups. By the time the inconsistency became an issue, it was too late to agree on a single extension for C++ source files.

Note that many implementations do use the file extension to distinguish between C and C++ source files. make has implicit rules to generate an object file from C and C++ source files, and looks at the extension to determine which compiler to invoke. Other build systems do similar things. The gcc command will also look at the file extension; gcc -c foo.c compiles C, and gcc -c foo.cpp compiles C++. (The separate g++ command is intended for C++, but the only real difference is that g++ links with the C++ library, which isn't relevant when you use the -c option that just compiles a source file to an unlinked object file -- except that g++ will compile *.c files as C++.)

Tools typically recognize multiple extensions for C++ source files. gcc recognizes .cc, .cp, .cxx, .cpp, .CPP, .c++, and .C. GNU make appears to recognize .cc, .C, and .cpp (the inconsistency is annoying).

If Stroustrup had used, say, .cc and .hh in the first edition of his book, we'd probably all be using that today. (And if he had used .C and .H we'd have problems with case-insensitive systems like Windows.)

Answer 2

Because it's not important to ... anything.

The compilers don't care. The editors don't care. Back in the day, some operating systems didn't even HAVE "file extensions". DOS mandated them, DEC system mandated them. Unix didn't.

What's the standard extension for Fortran? For Pascal? For BASIC? Lots of convention, many system specific. But no standard.

You know what my file extension is for Lisp? It's .lisp. Well, a lot of legacy systems can't support a 4 letter extension. Guess it's .l then, or .lsp, or something else.

File names are local to the operating environment, and not necessarily portable. This is another reason the standard doesn't say anything about them.

Addenda:

I think there just needs to be some clarity here.

First, this is a retro site, so things need to be taken in the perspective of how it was and viewed forward, rather than using the lens of today and viewing backward.

Second, we're talking "standard" here. Standards are, roughly, "MUST". MUST do this, MUST do that.

1986 is just at the peak of the wild west of computing when things were really starting to settle down. There was a large diversity of systems, and things like a file extension STANDARD, a MUST, were not tenable. Today, while kernels vary, operationally modern computing is almost (almost) a mono-culture. Not so back in the day.

And, in the end, in the large, the language doesn't care. Extensions and conventions are a tooling issue. Modern things like Go and Java are more than just languages, they mandate a broader environment outside of just syntax and semantics. They're offering an opinionated approach to development beyond just the language.

Back then, the languages had to fit a variety of machines. Nowadays, the environments are bringing their machine with them.

We've come a long way in 35 years.

Answer 3

I wonder why Dr. Stroustrup chose not to be specific about this issue himself?

You'll have to ask him. But based on what I've read from his website, he seems not to be strongly opinionated on stylistic matters like how to name files, where to put braces, or whether multi-word identifiers are written like_this or likeThis or LikeThis. His main concerns are resource-safety and type-safety.

Where did these "competing" file extensions come from?

I'm just guessing here, but:

• .C — because C++ is a “big” version of the C language. (Not usable on platforms with case-insensitive filesystems.)
• .cxx — 45° rotation of the plus signs
• .cpp — stands for “C plus plus”
• .cc — “C with classes”, maybe?
• .c++ — straightforward, but an OS may disallow + in filenames or give it some special meaning in the shell. And inconvenient to type on many keyboard layouts.

I can see that today it might take overcoming a lot of inertia to change something like this, but that wouldn't have been so originally.

Stroustrup started development on C with Classes in 1979. The first C++ standard was released in 1998. That's 19 years later. Even if you start counting with the first publication of The C++ Programming Language in 1985, that's 13 years of people using the language before it was standardized. Plenty of time for different ways of doing things to arise.

Also, note that when C++ was finally standardized, it was explicitly intended to be usable on multiple platforms with different file-naming rules. Even those that don't allow . in filenames at all. This is also why the C standard headers were renamed (e.g., <math.h> to <cmath>).

Answer 4

One important historic reason is that many old computer architectures didn't have the concept of filename extensions.

For example the Tandem computers I worked with in the late 1990s had for their entire file system just the following: computer/drive/directory/filename

That was it, no subdirectories, no filename extensions, and every name limited to 8 characters.

Other systems had different but similarly limited constructs.

As such, defining a programming language or operating system (often such things were limited by hardware, hardcoded in the hardware) to require certain things like filename extensions would seriously limit their applicability on different platforms than the ones they were originally created on. For operating systems this was often not a problem as they were designed for one specific hardware specification, but programming languages have always been intended for implementation on a variety of platforms so you wanted them to be as flexible as possible.

Answer 5

They key thing here is that the header name used in the #include directive is NOT necessarily a file name! It could be a key into a library or database of header declarations. (It was true on VMS.)

When the C++ standardization effort started, implementations usually did keep the header declarations in files, and there was no agreement on what the 'extension' or 'file type' should be. (DEC operating systems traditionally considered this a separate part of the file specification; Unix did not -- for Unix, . was just another character in the name.) Implementations used .h, .H, .hpp, .hxx, .h++, and I don't know what else. So in a subcommittee meeting, I suggested we leave this off of the header name and leave it up to the implementation to do what it wants -- look in a library or a database or append .h++ or .hpp or .H or whatever it wanted.

This would resolve a long argument where everybody had an opinion and there was probably no way to select the best practice. Andy Koenig from AT&T presented this to the whole committee and everybody accepted it. As far as I am concerned, implementations using stdio as a file name, instead of adding the extension that their IDEs or text editors will recognize as meaning that the file is in C++, are missing the whole point, and losing useful information.

Answer 6

Linux does not need extensions. The type of file is stored in file metadata (Linux system).

And the extension is used for the OS desktop to open file in a specific tool only. Like if your file is .docx, it will be opened in Microsoft Office or LibreOffice.