I'm not very familiar with the C++ standard, but the C standard says pretty much nothing about file names at all (in stdio calls as well as in #include directives). In contrast, the Common Lisp standard attempted to unify all the wildly different conventions of systems in the 1980s in the form of “pathnames”.

File extensions seem to be pretty useful to humans even if the various programs of the day didn't care about them.

Good answer. It's helpful to keep in mind, that (fixed) file name extensions are a thing of CP/M or DOS. Most OS do not handle extensions at all. This includes systems like Unix. Here it's just a matter of user side convention to use some suffix, conventions not even all programs using the same data share. And then there are as well OS that don't allow such conventions as their legal character set for file names does not include delimiters at all. Some only allow uppercase letters and numbers.

Oh, and almost forgot, then there are OS with real file types, such that are part of the FS, defining different ways of handling on OS level. Like blocked, fixed record, variable record, indexed, tape accessed and soon. Here the file type has serious meaning, not just user level convention :))

"The compilers don't care." But automatic makefile rules do. "The editors don't care." It's useful for having custom editor modes for each type of source file. Sure, you could get it to work with any file extension you want (or none at all), but it's simply more convenient to use tools that expect conventions to be followed.

gcc -c foo.c compiles the file as C. gcc -c foo.cpp compiles the file as C++. The g++ command differs from the gcc command in that it links against the C++ library (irrelevant with the -c option).

@StayOnTarget I guess you never used IBM OS/360. That doesn't have any concept of "standard extensions" at all. In fact it doesn't even impose a "directory structure" on the file system in the Windows or Unix sense of "directory structure." Not to mention features like Partitioned Data Sets...

@DrSheldon, no, make doesn't care about extensions. There are predefined rules, and you certainly can add your own to handle your own funky language with filename extemsion ..fu, and you can teach your favourite editor to enter funky-mode when asked to edit something..fu

@StayOnTarget That depends on context. As a classic example from the land of UNIX, a file named README in a directory is by convention always plain text. It needs no file extension because the file name is well-known and a de-facto standard. The same goes for many of the configuration files that you might find in a user’s home directory on a typical UNIX-like system, the name implicitly states what the file is. In fact, a lot of the dot files you’ll find in a source directory these days have extensions not because people need them, but because the tools they configure require them.

If that would be unimportant, all modern system languages (Rust, Zig) would have no standard extension as well. Of course they all have. I am really surprised that this fundamental wrong answer gets so many upvotes here. Standards are highly important to let entities, which do not know each other, communicate safely and easily. Having several source code extensions helps absolutely no one. Of course every C++ coder knows how to deal with that and with much more involved system problems too. But he does not like it.

@adrasthea This answer is explaining the way things were. There was no "display icon X for extension Y and run with program Z on double-click". There weren't all of these common tools which keyed off of extensions. They were essentially comments for much of C++'s life.

@Owen Reynolds No, the answer blatantly explained the general case. And no again, Microsoft didn't invented the mouse. XWindows users had all this stuff and much more, a windows noob can no even dream about.

@adrasthea there is a standard for communicating information about file types. It's called MIME. It doesn't have anything to say about arbitrary thingies on the end of filenames offset by dots... um I mean "extensions".

@vonbrand Yes, make does care about file name extensions. make foo.o in a directory containing a file named foo.cpp will invoke g++ -c -o foo.o foo.cpp (at least on my system). With a file named foo.c it invokes cc rather than g++. The details may vary, but in general make recognize programming languages based on file name extensions.

@Keith Thompson: IIRC. when C++ first began to invade the workspace, makefiles would assume that the .cpp extension was a file containing C preprocessor commands. And I think it assumes a .l extension is a (f)lex source file...

Lisp implementations recognize suffixes. You can (load "foo") and it will figure out whether to load foo.lisp or foo.fasl. These details are not in the ANSI CL standard, but it behooves you to know what they are.

@adrasthea Spare us the ill-informed snipes at Windows, it's not 1995 and you're presumably not 14 years old.

@hobbs: MIME may be a standard, but it's a standard that isn't used at the OS level where files of source code live. AFAIK, anyway: certainly not in *nix environments,

I like this perspective. Mixing machine semantics into a human-readable string makes me feel a bit dirty.

@jamesqf MIME is used at the OS level, not in *nix environments, but in BeOS.

@DrSheldon On operating systems where file extensions are not used, editors know the filetype by OS metadata such as MIME or Filetype/Creator codes.