C++ File Extensions Explained: .cc vs .cpp on Linux

By the end of this page, you will understand what C++ file extensions like .cc and .cpp mean, why both are valid, and how teams usually choose between them. You will also learn the practical rule that matters most: consistency within a project is more important than the specific extension you pick.

In C++, file extensions such as .cc, .cpp, .cxx, and sometimes .C are mostly conventions used to indicate that a file contains C++ source code.

They do not change the C++ language itself. What matters is how your compiler, build tool, IDE, and team treat those files.

The key idea

A C++ compiler needs to know that a file should be compiled as C++. File extensions are one common way tools infer that.

Common source file extensions include:

• .cpp
• .cc
• .cxx
• .C on some systems

Common header file extensions include:

• .h
• .hpp
• .hh
• .hxx

Is there a technical difference between .cc and .cpp?

Usually, no meaningful language difference exists between .cc and .cpp.

Both are commonly recognized by compilers and build systems as C++ source files. The difference is mostly:

• project style n- team preference
• toolchain convention
• historical usage

Why this matters in real programming

In real codebases, file naming affects:

• build tool configuration
• editor syntax highlighting
• code navigation
• team consistency
• onboarding new developers

If one project uses .cc and another uses .cpp, that does not mean one is more correct than the other. It usually just means the teams made different style choices.

What should you choose?

For most developers:

• use the convention already used in your project
• if starting a new project, pick one convention and apply it consistently
• on Linux, both .cc and .cpp are common and accepted

If you follow a style guide, then use the extension that guide recommends. For example, some large codebases, including Google-style codebases, prefer .cc. Many other projects prefer .cpp because it is immediately recognizable as “C plus plus source.”

Think of .cc and .cpp like two different labels on the same kind of storage box.

• One box is labeled books
• Another box is labeled reading-material

The labels look different, but both boxes can contain books.

Similarly:

• .cc means “this is C++ source code”
• .cpp also means “this is C++ source code”

The important part is that everyone in the room agrees on the labeling system. In a programming team, that means using one convention consistently so developers and tools know what to expect.

C++ file extensions are not syntax in the language itself, but they are part of how source files are organized.

Common file naming patterns

main.cpp
math_utils.cpp
parser.cc
server.cc
vector_helpers.cxx

Example with .cpp

// main.cpp
#include <iostream>

int main() {
    std::cout << "Hello, C++\n";
    return 0;
}

Compile it on Linux with:

g++ main.cpp -o app

Example with .cc

// main.cc
#include <iostream>

int main() {
    std::cout << "Hello, C++\n";
    return 0;
}

Compile it the same way:

g++ main.cc -o app

What this shows

The file contents are identical C++ code. Only the filename extension changed.

In normal Linux development with g++ or clang++, both are commonly treated as C++ source files.

Header pairing examples

Teams often pair source and header files by convention:

math_utils.cpp + math_utils.hpp
parser.cc + parser.hh

There is no single universal rule. The pair you use usually follows project style.

Consider this file:

// greet.cpp
#include <iostream>

int main() {
    std::cout << "Hi\n";
    return 0;
}

Now walk through what happens when you compile it:

g++ greet.cpp -o greet

Step by step

1. The compiler sees the filename greet.cpp.
2. The .cpp extension helps the tool recognize it as a C++ source file.
3. The compiler parses the file using C++ rules.
4. #include <iostream> brings in declarations needed for output.
5. The main function is compiled.
6. std::cout << "Hi\n"; becomes machine instructions for printing text.
7. The executable greet is created.

If the file were named greet.cc instead:

g++ greet.cc -o greet

The same general process happens. The extension is different, but the compiler still treats it as C++ source in normal setups.

Important takeaway

The extension mainly helps tools identify the file type. It does not make the code “more C++” or “less C++.”

Here are common situations where file extension conventions matter.

1. Team-based application development

A backend service may have dozens or hundreds of C++ files. Teams choose .cc or .cpp so the whole repository looks uniform.

2. Build systems

Tools like Make, CMake, Bazel, or Meson often detect source files by extension. Using standard extensions helps these tools work smoothly.

3. IDE and editor support

Editors use file extensions to decide:

• syntax highlighting
• code completion
• linting
• formatting rules

4. Cross-platform projects

A project built on Linux, macOS, and Windows may choose .cpp because many developers immediately recognize it. Another project may choose .cc because that is the team standard.

5. Large organizations

Large companies often standardize naming conventions through style guides. This makes automation and review easier.

In real projects, developers rarely debate file extensions in isolation. They usually choose a convention as part of a broader codebase style.

Common patterns

1. Follow the existing repository

If a codebase already uses .cc, new files should usually also use .cc.

If it uses .cpp, stick with .cpp.

This is similar to other style choices like:

• brace formatting
• naming conventions
• header extension choice
• test file naming

2. Build tool configuration

A build file may explicitly list sources:

add_executable(app
    main.cpp
    parser.cpp
    config.cpp
)

Or:

add_executable(app
    main.cc
    parser.cc
    config.cc
)

Both are fine as long as the files exist and the project is consistent.

3. Header/source pairing

Teams often choose matching patterns to make files easier to find:

• widget.cpp with widget.hpp
• widget.cc with widget.h
• widget.cc with widget.hh

4. Validation and tooling

Linters, formatters, and scripts may include extension-based rules, for example:

• format all *.cc files
• run checks on *.cpp files
• generate compilation databases from known source suffixes

This is one reason consistency matters more than the specific extension.

1. Thinking .cc and .cpp mean different C++ versions

They do not indicate different language standards like C++11, C++17, or C++20.

The language version is chosen with compiler flags, for example:

g++ -std=c++20 main.cpp -o app

2. Mixing conventions randomly

Broken example from a style perspective:

main.cpp
parser.cc
math_utils.cxx
engine.cpp

This may still compile, but it looks inconsistent and can confuse tooling or teammates.

3. Assuming every tool treats every extension the same

Most modern tools handle common C++ extensions, but not every script or custom build setup does.

If a tool only searches for *.cpp, then .cc files may be skipped.

4. Using unusual or ambiguous extensions without checking tools

Some extensions are less common and may need extra configuration.

5. Confusing .c with C++ source

Broken example:

// main.c
#include <iostream>

int main() {
    std::cout << "Hello\n";
}

A .c file is generally treated as C source, not C++ source.

Use a C++ extension instead:

// main.cpp
#include <iostream>

int main() {
    std::cout << "Hello\n";
    return 0;
}

How to avoid these mistakes

• follow your project convention
• check your compiler and build tool expectations
• keep source and header naming predictable
• use compiler flags, not file extensions, to choose the C++ standard

.cc vs .cpp

Practical rule

If you are choosing for a new project:

• choose .cpp if you want the most immediately recognizable extension for many developers
• choose .cc if you are following a style guide or team convention that prefers it

Either way, be consistent.

Quick reference

• .cc and .cpp both usually mean C++ source file.
• There is usually no language-level difference between them.
• On Linux, both are commonly used.
• The best practice is usually follow the existing project convention.
• If starting a new project, pick one and use it consistently.

Common source extensions

.cpp
.cc
.cxx

Common header extensions

.h
.hpp
.hh
.hxx

Compile examples

g++ main.cpp -o app
g++ main.cc -o app

Important rule

File extension does not choose the C++ standard.

Use compiler flags for that:

g++ -std=c++17 main.cpp -o app
g++ -std=c++20 main.cc -o app

Best practice

• existing codebase > personal preference
• consistency > extension debate
• standard tool support > unusual naming

Is .cc better than .cpp for C++ on Linux?

No. Both are commonly used on Linux. The better choice is usually whichever convention your project already follows.

Do .cc and .cpp compile differently?

Usually no. Standard C++ compilers generally treat both as C++ source files.

Which extension is more modern in C++?

Neither is inherently more modern. They are naming conventions, not language features.

What extension should I use for a new C++ project?

Pick one standard extension such as .cpp or .cc, then use it consistently across the project.

Why do some style guides prefer .cc?

Style guides often choose one convention to keep large codebases consistent. That does not make other common extensions wrong.

Can I mix .cc and .cpp in one project?

You can, but it is usually not recommended unless there is a specific reason. Consistency makes projects easier to maintain.

Does the file extension control whether I use C++11 or C++20?

No. The C++ standard version is controlled by compiler options like -std=c++20.

What about header extensions like .h and .hpp?

Those are also conventions. Different teams use different header naming styles, just as they do for source files.

• C++ compiler flags — needed to choose language standards like C++17 or C++20.
• CMake source files — build systems often organize and detect files by extension.
• Header files in C++ — source extensions are often paired with header naming conventions.
• C vs C++ source files — important because .c is usually treated differently from .cc or .cpp.
• Coding style guides — teams often standardize file naming through style rules.
• Build systems — tools like Make and CMake rely on predictable file organization.
• Project conventions — consistency across a codebase is a core maintenance practice.