C++分层目录项目如何用简单命令编译？该目录结构是否合理？

你现在的代码分散到了src下的多级子目录，头文件和实现文件分离存放，需要额外指定头文件搜索路径和所有cpp文件的路径，有两种常用的编译方式：

• 手动指定所有cpp文件，适合文件较少的场景：
  命令如下：
  g++ src/main.cpp src/methods/a.cpp src/methods/b.cpp -I src/classes -o main
  其中-I src/classes是告诉编译器在src/classes目录下查找自定义头文件，不加这个参数编译器会因为找不到a.h、b.h报错。
• 通配符匹配所有cpp文件，适合文件较多不想逐个输入的场景：
  命令如下：
  g++ $(find src -name "*.cpp") -I src/classes -o main
  如果后续项目规模扩大，更推荐使用Make、CMake等构建工具管理编译逻辑，不用每次手动输入长命令。

这个结构有基础的分层意识，但不符合C++项目的通用开发规范，不算合理的生产级项目结构，核心问题在于：
你将同一个类的声明文件（.h）和实现文件（.cpp）拆分到了两个完全独立的目录，日常开发时修改某个类的逻辑需要在两个目录之间来回切换，维护成本很高。

通用的C++项目分层逻辑一般按业务模块/功能模块划分目录，同一个模块的头文件和实现文件放在同一个目录下，示例结构参考：

project

• src/
  • module_a/
    • a.h
    • a.cpp
  • module_b/
    • b.h
    • b.cpp
  • main.cpp
• .editorconfig
• .gitignore
  如果项目是对外提供能力的库项目，可以额外增加顶层include/目录存放对外暴露的公共头文件，内部实现的头文件和cpp依旧放在src对应模块目录下即可。如果是小型可执行项目，所有.h和.cpp直接放在src根目录也完全没问题，比拆分声明和实现的结构效率更高。

你当前的结构不是完全不能用，只是不符合行业通用习惯，长期维护的性价比很低。

内容的提问来源于stack exchange，提问作者Charles Braga