C and C++ File Extensions: .c, .h, .cc, .cpp, .cxx, and .hpp

C and C++ source-file extensions are mostly conventions, not language rules. In practice, .c normally identifies C source, while .cc, .cpp, and .cxx normally identify C++ source. Likewise, .h is a general header extension and .hpp often signals a C++-only header. The most important rule is to choose a convention, configure your build tools correctly, and use it consistently.

A file extension helps people, editors, compilers, and build systems decide how to treat a file. It is not part of the C or C++ language syntax.

The key distinction is usually the language mode:

• A .c file is conventionally compiled as C.
• A .cc, .cpp, or .cxx file is conventionally compiled as C++.
• A .h or .hpp file is a header: code intended to be included by other source files with #include.

Different compilers and build systems recognize different extension defaults. For example, a command-line compiler may choose C or C++ mode from the filename, while a build system such as CMake can explicitly set the language regardless of the suffix.

Headers are not limited to declarations. They often contain:

• Function declarations and type definitions.
• Constants and macros.
• struct, class, and enum declarations.
• inline function definitions.
• C++ template definitions, which generally must be visible to code that uses them.

A C++ compiler can compile many C-like programs, but C and C++ are distinct languages. Some valid C programs are not valid C++, and some valid C++ programs are not valid C. Therefore, do not assume a file is simply a file with extra features.

Think of file extensions as labels on folders in a workshop:

• .c means “send this folder to the C workbench.”
• .cpp, .cc, and .cxx mean “send this folder to the C++ workbench.”
• .h and .hpp mean “this folder contains shared instructions that other folders can reference.”

The labels do not change the paper inside the folder. A build tool can be told to use a different workbench. But clear labels prevent people and tools from making the wrong assumption.

The preprocessor includes a header with #include.

/* math_utils.h */
#ifndef MATH_UTILS_H
#define MATH_UTILS_H

int add(int left, int right);

#endif

/* math_utils.c */
#include "math_utils.h"

int add(int left, int right) {
    return left + right;
}

/* main.c */
#include <stdio.h>
#include "math_utils.h"

int main(void) {
    printf("%d\n", add(2, 3));
    return 0;
}

In this C example:

Consider this C++ example:

// score.hpp
#pragma once

int bonusPoints(int score);

// score.cpp
#include "score.hpp"

int bonusPoints(int score) {
    return score + 10;
}

// main.cpp
#include <iostream>
#include "score.hpp"

int main() {
    std::cout << bonusPoints(90) << '\n';
}

When the program is built:

1. The compiler starts compiling main.cpp as C++ because of its extension.
2. #include "score.hpp" effectively inserts the header's declaration into during preprocessing.

Common extension choices in real projects include:

• C libraries: .h for public API headers and .c for implementations.
• C++ applications: .hpp or .h for headers, plus .cpp, .cc, or .cxx for implementations.
• Cross-platform libraries: C headers may expose an API usable from both C and C++.
• Template-heavy C++ libraries: template definitions are often placed entirely in .hpp files because users need to see the definitions at compile time.
• Generated code: a tool may generate .c and .h files, while C++ generators may produce .cpp and .hpp files.
• Large repositories: a team may choose .cc because it matches its style guide, while another chooses .cpp because it is familiar on its platform.

The extension itself is less important than consistent language selection and a predictable project layout.

Teams normally define an extension policy in their style guide and enforce it through build configuration, editor settings, and code review.

A typical C++ layout might look like this:

project/
├── include/
│   └── inventory/
│       └── item.hpp
├── src/
│   └── item.cpp
└── tests/
    └── item_test.cpp

Useful real-project patterns include:

• Public versus private headers: public headers live under an include/ directory; implementation-only headers may stay near .cpp files.
• Include guards or #pragma once: prevent a header from being processed more than once in one translation unit.
• Include your matching header first: in a .cpp file, including its own header early can reveal missing includes in that header.

// item.cpp
#include "inventory/item.hpp"  // Check this header is self-contained.

#include <stdexcept>

• C-compatible headers: when a header is consumed by both languages, C++ code commonly wraps declarations in extern "C".

/* api.h */




  {


 ;


}

Treating extensions as universal compiler rules

Not every tool recognizes every extension in the same way. A compiler or build system may require configuration for an uncommon suffix.

Avoid it: check your compiler and build-tool documentation, and make the language explicit when necessary.

Mixing C and C++ accidentally

// file.c
#include <iostream>  // Not a C standard header.

A .c file is normally compiled as C, so C++ headers and syntax will fail.

Avoid it: rename and compile the file as C++ only if the file is meant to be C++.

Assuming all C code is valid C++

Some C constructs have different rules in C++. For example, C permits implicit conversion from void* in assignment, while C++ does not.

/* Valid C, but not valid C++ without a cast. */
int *values = malloc(10 * sizeof *values);

Avoid it: compile C files with a C compiler and C++ files with a C++ compiler. Do not rely on accidental compatibility.

Putting non-inline function definitions in a widely included header

// broken.hpp
{
     value * value;
}

• .c → conventionally a C source file.
• .cc, .cpp, .cxx → conventionally C++ source files.
• .h → a header usable for C, C++, or both, depending on its contents.
• .hpp → conventionally a C++-only header.
• Extensions are conventions interpreted by compilers and build tools; they are not language syntax.
• Headers can contain more than declarations: macros, types, constants, inline functions, and templates are common.
• Use include guards or #pragma once in headers.
• Define ordinary non-inline functions in one source file, not in a header included by many source files.
• A C++ compiler is not a drop-in replacement for a C compiler; the languages differ.
• Pick one C++ source extension (.cpp, .cc, or .cxx) per project and stay consistent.

Is there a real difference between .cpp, .cc, and .cxx?

Usually no. They are all common conventions for C++ source files. The practical difference is whether your compiler, editor, and build system recognize the selected extension automatically.

Should I use .h or .hpp for C++ headers?

Either is valid. Use .hpp if your project wants to signal that the header requires C++. Use .h if that is the existing project convention or if the header should also work from C.

Can a .h file contain C++ classes?

Yes. The extension does not restrict its contents. However, a header containing C++ classes cannot be compiled as C.

Can I compile a .c file as C++?

Yes, if you explicitly configure the compiler or build system to treat it as C++. Renaming it to .cpp, .cc, or .cxx is usually clearer unless an external constraint requires .c.

Why are template implementations often in .hpp files?

C++ templates usually need their full definitions visible where they are instantiated. Keeping declarations and definitions in a header is the simplest common approach.

• C preprocessor and #include — explains how header content is inserted before compilation.
• Header guards and #pragma once — prevents repeated inclusion of a header.
• Compilation and linking — explains why declarations and definitions can be in separate files.
• Translation units — describes the source-plus-included-header unit compiled by the compiler.
• C and C++ interoperability — covers using C APIs from C++ with extern "C".
• C++ inline functions — explains safe function definitions in headers.
• C++ templates — explains why template definitions are commonly header-only.
• Build systems — controls which compiler and language mode are used for each file.