没有任何标准，C ++是一个非常开放的世界，您将看到；）

一切都是为了使最适合您的东西，但通常从已经尝试过的人那里获得建议就不会受到伤害。就个人而言，我尝试遵循这一惯例

/ProjectName
    /src
        /libs <- Libraries go here
            /Models <- Assuming you want to make a library out of your models
                User.h
                User.cpp
                ... <- Putting header and implementations together is not a problem,
                       they should be edited in parallel oftentimes
                /Utilities <- Should your library grow, you can make it more modular
                              by creating subdirectories
                              (that could contain subdirectories, etc.)
                    DBConnection.h
                    DBConnection.cpp

        /apps <- define your applications here.
                 They probably rely on classes and functions defined in one or several of your libaries define above.
            /ApplicationA
                Core.h
                Core.cpp
                Bootstrap.h
                Bootstrap.cpp
    /resources
    /doc

    # Below are 'environment specific' folders.
    /vs <- Visual studio project files
    /xcode <- Xcode project files

备注

标头和实现

• 头文件（.h或.hpp或无扩展名）确实定义了将在实现文件（.cpp）中实现的接口。但是，给两者都赋予相同的基名，并且仅通过扩展名（或不存在）来区分它们是很常见的。添加一个额外的.interface部件可能不会花很多钱，并且可能会使您的IDE（或其他工具）感到困惑，否则它们可以将头文件与其实现文件相关联。
• 出于相同的原因（不要混淆某些工具），将两个文件放在同一文件夹中会更容易：无论如何它们都是密切相关的。
  • 另外，如果以后需要更改文件夹结构（例如，进行模块化），则仅放置一个子文件夹（而不是您的方法中的两个文件夹）也可以使工作变得更轻松。

 自定义类型

C ++提供类的程序员定义自定义类型。在它们自己的头文件/实现文件对中定义自定义类型是很常见的。在您的情况下，DBConnection.h将定义一个DBConnection类，该类的（非内联）方法将在中实现DBConnection.cpp。

从个性上讲，我不怕为每种类型创建一对文件，这使将来的您和其他程序员更容易找到定义类型的文件。您可以通过制作子文件夹来管理数量不断增长的文件，这将迫使您模块化设计。

当然，有时您需要定义一个非常短的类，与另一个类紧密耦合。如果您认为两个类之间的链接足够牢固，则由您决定将这两个类都包含在一个共同的文件对中。

可扩展性

可能不是所有项目都需要关注，但是此目录结构在环境和构建管理方面可以扩展。将项目文件保留在顶层的单独文件夹中，并定义源代码外的构建，可以为其他IDE创建项目文件。

如果您应该采用这种方式，此层次结构也很容易接受CMake构建管理。甲CMakeLists.txt文件将被放置在顶层，此文件调用（项目名/下）add_subdirectory(src)，继而caling一个CMakeLists.txt在项目名/ SRC /等