C++项目目录结构（C++目录结构）

参考文章1：C++项目目录组织结构

参考文章2：干货：构建C/C++良好的工程结构

待更。。。

---

20230816

C++项目目录结构

在C++项目开发过程中，良好的目录结构对于项目的管理和维护至关重要。一份明确、有条理的目录结构能够让开发者更快地定位问题，同时也方便了代码的阅读和理解。

本文将会探讨以下主题：

• 标准的C++项目目录结构
• 如何组织你的源文件和头文件
• 使用Makefile进行项目构建
• 使用Git进行版本控制
• 一个例子：C++项目的实际案例分析

标准的C++项目目录结构

一个标准的C++项目通常会包含以下目录和文件：

/my_project
|-- bin
|-- build
|-- doc
|-- include
|-- src
|-- tests
|-- Makefile
|-- README.md

• bin/: 这个目录用来存放编译后的可执行文件。
• build/: 这个目录用来存放所有的.o和.dep文件，这些文件是由编译器生成的。
• doc/: 这个目录用来存放所有的文档，比如设计文档、需求文档等。
• include/: 这个目录用来存放所有的头文件（.h或.hpp文件）。
• src/: 这个目录用来存放所有的源文件（.cpp文件）。
• tests/: 这个目录用来存放所有的测试代码，通常会使用一些测试框架如Google Test。
• Makefile: 这个文件用来描述怎样从源代码生成可执行文件，以及如何清理整个项目。
• README.md: 这个文件用来描述项目的信息，比如项目的目的、如何构建项目、如何运行项目等。

以上就是一个标准的C++项目的目录结构。当然，根据项目的大小和复杂度，可能会有一些额外的目录和文件。例如，如果项目需要一些第三方库，通常会有一个lib/目录来存放这些库。

如何组织你的源文件和头文件

在C++项目中，源文件和头文件的组织方式对于代码的可读性和可维护性都非常重要。以下是一些关于如何组织这些文件的建议：

1. 每个类都应该有自己的头文件和源文件：这种方式可以使代码更易于理解和维护。头文件应该只包含类的声明，而源文件应该包含类的实现。例如，如果你有一个名为MyClass的类，你应该有一个MyClass.h的头文件和一个MyClass.cpp的源文件。

// MyClass.h
class MyClass {
public:
    MyClass();
    ~MyClass();
    void myMethod();
};

// MyClass.cpp
#include "MyClass.h"

MyClass::MyClass() {
    // Constructor implementation
}

MyClass::~MyClass() {
    // Destructor implementation
}

void MyClass::myMethod() {
    // Method implementation
}

2. 使用名称空间：在C++中，名称空间是一种封装类、函数和变量的方式，它可以避免命名冲突。建议将相关的类、函数和变量放在同一个名称空间中。

// MyClass.h
namespace MyNamespace {
    class MyClass {
        // ...
    };
}

3. 头文件保护：为了防止头文件被多次包含，可以使用预处理指令#ifndef、#define和#endif来实现头文件保护。

// MyClass.h
#ifndef MYCLASS_H
#define MYCLASS_H

class MyClass {
    // ...
};

#endif

使用Makefile进行项目构建

在C++项目中，Makefile是一个描述如何从源代码生成可执行文件的工具。以下是一个简单的Makefile示例：

CC=g++
CFLAGS=-I.

%.o: %.cpp
	$(CC) -c -o $@ $< $(CFLAGS)

my_program: main.o MyClass.o
	$(CC) -o my_program main.o MyClass.o

这个Makefile首先定义了编译器（CC）和编译选项（CFLAGS）。然后，它定义了如何从.cpp文件生成.o文件的规则。最后，它定义了如何从.o文件生成可执行文件的规则。

使用Git进行版本控制

在C++项目中，版本控制是必不可少的。Git是一个非常流行的版本控制系统，它可以帮助你跟踪代码的改动，以及合并不同开发者的改动。

以下是一个.gitignore文件的示例，它告诉Git哪些文件或目录不应该被版本控制：

# .gitignore
/bin/
/build/

一个例子：C++项目的实际案例分析

让我们通过一个实际的C++项目来看看以上的原则如何应用。

JSON for Modern C++是一个非常流行的C++ JSON库。它的目录结构如下：

/json
|-- benchmark
|-- cmake
|-- doc
|-- include
|-- src
|-- test
|-- third_party
|-- .gitignore
|-- CMakeLists.txt
|-- README.md

可以看到，这个项目的目录结构和我们前面提到的标准目录结构非常相似。特别地，它有一个third_party/目录用来存放第三方库，这是一个非常常见的做法。

这个项目使用CMake作为其构建系统，因此它没有Makefile，而是有一个CMakeLists.txt文件。这个文件的功能和Makefile类似，它描述了如何从源代码生成可执行文件。

这个项目还使用了Git进行版本控制，可以看到它有一个.gitignore文件。

最后，这个项目的源文件和头文件都按照我们前面提到的原则进行了组织。例如，每个类都有自己的头文件和源文件，相关的类、函数和变量都放在同一个名称空间中，头文件都有头文件保护。

20231109 有的库不同架构的头文件是一样的，有的不一样，对于不一样的，要区分存放

类似于：

root@sx-virtual-machine:/userdata/testOtherPrj/20231106_arGlassesKyaiRestBuildTest/ky_ai/arnoldTestNdkDemo/KyaiRest/jni/yg/prj/kyai_rest# tree thirdparty/mosquitto/
thirdparty/mosquitto/
├── arm64
│?? ├── andriod
│?? └── linux
├── include
│?? └── mosquitto.h
└── x64
    ├── bin
    ├── include
    └── lib
        └── libmosquitto_static.a

8 directories, 2 files
root@sx-virtual-machine:/userdata/testOtherPrj/20231106_arGlassesKyaiRestBuildTest/ky_ai/arnoldTestNdkDemo/KyaiRest/jni/yg/prj/kyai_rest# 

因为我的mosquitto的头文件是相通的，所以我单独放外面的include目录，像libevent这种，我就单独放在各自架构的目录里。

20240716 关于第三方库的文件

第三方库的目录结构可以根据库的设计和功能需求有所不同，但有一些常见的组织方式可以参考。对于在项目中整合第三方库，理想的目录结构应该清晰且易于管理。以下是一种推荐的组织结构：

基本第三方库目录结构

your_project/
│
├── src/
│   ├── main.cpp       # 你的项目源文件
│   └── ...
│
├── include/           # 你的项目头文件
│   ├── your_header.h
│   └── ...
│
├── lib/               # 如果你有自己的静态或动态库
│   ├── libyourlib.a
│   └── ...
│
├── external/          # 第三方库目录
│   ├── library_name/  # 单个库的目录
│   │   ├── src/       # 第三方库的源代码
│   │   ├── include/   # 第三方库的头文件
│   │   ├── lib/       # 编译生成的库文件
│   │   └── CMakeLists.txt  # 如果库支持CMake
│   └── ...
│
├── build/             # 构建目录
│   └── ...
│
└── CMakeLists.txt     # 你的项目的CMake配置文件

说明

• src/: 这个目录包含你的项目的所有源代码文件。
• include/: 这里放置你项目的头文件。
• lib/: 用于存放你自己的项目可能会生成的库文件。
• external/: 专门用于存放所有第三方库。每个库都在自己的子目录中保持完整的目录结构，这有助于独立管理每个库。
  • library_name/: 这个子目录是指定第三方库的名称，里面包含该库的源代码、头文件、库文件及其自有的构建脚本（如 Makefile 或 CMakeLists.txt）。
• build/: 用于存放编译过程中生成的临时文件和最终的可执行文件。通常，这个目录不应该被加入版本控制（Git等）。

这种结构的优点是清晰且模块化，使得管理和更新第三方库变得更加容易。此外，这也有助于避免与项目本身的源代码和头文件混淆。你可以根据具体需求调整这种结构，例如，如果使用特定的包管理器，可能就不需要手动管理这些目录。

第三方目录命名

第三方目录命名成external或vendor或third_party都行，根据个人喜好。