如何布局我的c++程序?(我应该把。h和。cpp文件放在哪里?)

时间:2023-01-13 10:21:40

Currently, I program in Java and use Maven quite a bit. As so I've become accustom to the naming schemes and folder structures that I've used over the past 4 or 5 years.

目前,我在Java中编程,并使用了不少Maven。因此,我已经习惯了过去四五年使用的命名方案和文件夹结构。

As I have recently started to learn C++, I'm realizing that I have no idea where to put all my files. Should I keep everything broken down by namespace, or by what tier it is in? Where, for example, would I keep a series of files devoted to UI, as apposed to files meant to help store data?

当我最近开始学习c++时,我意识到我不知道把所有的文件放在哪里。我应该保留所有被命名空间分解的东西,还是通过它所在的层?例如,在哪里,我将保留一系列用于UI的文件,作为用于帮助存储数据的文件?

Are there any standards for this sort of thing?

这种事情有什么标准吗?

Clearly, there is no definitive answer to this question. I'm simply looking for a good guide. I do not want to start learning C++ by spending too much time worrying about how my files are laid out. I'd rather have some good models, and just get to the coding.

显然,这个问题没有明确的答案。我只是想找一个好的导游。我不想开始学习c++,花太多时间担心我的文件是如何布局的。我宁愿有一些好的模型,然后开始编码。

4 个解决方案

#1


5  

The following is fairly typical...

以下是相当典型的……

third-party library
  release
    obj
  debug
    obj
  include
  src
    sublib 1
    sublib 2

mylibrary
  release
    obj
  debug
    obj
  include
  src
    sublib 1
    sublib 2

myapp
  release
    obj
  debug
    obj
  subapp 1
  subapp 2

mylittleapp
  release
    obj
  debug
    obj

Basically, subfolders for subprojects is common for larger projects, but mostly a particular project has folders for src, include etc. A folder for each build configuration is common, and keeping the obj files and other intermediates in a subfolder of that is a good idea. It may be tempting to put subproject folders in obj folders, but usually that's unnecessary - the obj folders don't need to be well organised, so the only concern is a filename conflict, and the best fix for that is to have unique source filenames within (at least) each project.

基本上,子项目的子文件夹对于较大的项目是常见的,但是通常一个特定的项目有src、include等文件夹。每个构建配置都有一个文件夹,将obj文件和其他中间文件保存在其中的子文件夹中是一个好主意。在obj文件夹中放置子项目文件夹可能很诱人,但通常这是不必要的——obj文件夹不需要很好地组织,所以唯一需要关注的是文件名冲突,最好的解决方法是在每个项目中(至少)有唯一的源文件名。

The "include" folders should IMO only contain headers that will be #included by other projects - internal headers belong in the "src" folder.

“包含”文件夹应该只包含其他项目将包含的#标题——内部标题属于“src”文件夹。

Putting UI stuff in a separate folder isn't a bad idea, if it's big enough. I've seen UI stuff done as a separate static-linked top-level project, and I do mean app-specific here, not (e.g.) wxWidgets. Usually, though, that level of division is sub-project if it's worth separating at all. How you divide subprojects is more a matter of application-specific blocks in general, so it depends on whether UI stuff is best handled as a separate block or as separate chunks mixed in with task-specific logic.

把UI放到一个单独的文件夹中并不是一个坏主意,如果它足够大的话。我看到UI的工作是作为一个独立的静态链接的*项目完成的,这里我指的是特定于应用程序的项目,而不是(例如)wxWidgets。但是,通常,如果值得分离,那么这个级别的划分就是子项目。如何划分子项目通常更多地取决于特定于应用程序的块,因此它取决于UI内容是作为单独的块处理,还是作为与特定于任务的逻辑混合的独立块处理。

Namespaces aren't the most used language feature, possibly because a lot of people use "using" so much they don't make much difference. A namespace for a main library project makes sense, but associating subfolders to namespaces 1:1 isn't something I've seen. I personally have a namespace that encompasses most of my library code, with a couple of sub-namespaces for things rarely used in general, but used a lot in a few places (e.g. a "bitwise" namespaces). The sub-namespaces are limited to single source/header pairs, so no need for subfolders. Most of the library-specific selection is done by including the right header - except that I usually include the lot through a main-project top-level header anyway.

名称空间并不是最常用的语言特性,这可能是因为很多人使用“使用”太多了,它们没有多大区别。主库项目的名称空间是有意义的,但是我没有看到将子文件夹与名称空间1:1关联。我个人有一个包含我的大部分库代码的名称空间,它有两个子名称空间用于通常很少使用的东西,但是在一些地方(例如“按位计算”的名称空间)大量使用。子名称空间仅限于单个源/头对,因此不需要子文件夹。大多数特定于库的选择是通过包含正确的标题来完成的——除了我通常通过主项目*标题来包含这些标题。

Basically, namespaces are a way of avoiding naming conflicts. They don't necessarily associate with abstractions or functional blocks or anything. Within a particular project, you're probably better off just making sure the names don't conflict. As with the "std" namespace, it's fine to put a lot of stuff in one namespace.

基本上,命名空间是避免命名冲突的一种方式。它们不一定与抽象或功能块或其他东西相关联。在特定的项目中,最好确保名称不冲突。与“std”名称空间一样,在一个名称空间中放置大量内容是可以的。

As you say, though, this isn't a definitive answer - there are of course minor variations and quite different approaches.

不过,正如你所说的,这并不是一个确定的答案——当然有一些细微的变化和非常不同的方法。

#2


1  

On small projects my team groups all the files together by a link unit ie library, DLL, EXE. If the unit is very large we will sometimes breakup the files by functional unit or subsystem so that if you need to edit a component they are generally in the same place.

在小型项目中,我的团队将所有文件由一个链接单元(即库、DLL、EXE)组合在一起。如果单元非常大,我们有时会按功能单元或子系统分解文件,因此如果需要编辑组件,它们通常位于相同的位置。

#3


1  

I break my projects by theme, one directory for theme:

我按主题分解我的项目,一个主题目录:

menu_planner
  src
     recipes
       debug -- contains debug object files and libraries
       release -- contains release object files and libraries
       obsolete -- contains obsolete source files
     ingredients
       debug -- contains debug object files and libraries
       release -- contains release object files and libraries
       obsolete -- contains obsolete source files
     references
       debug -- contains debug object files and libraries
       release -- contains release object files and libraries
       obsolete -- contains obsolete source files
     meals
       debug -- contains debug object files and libraries
       release -- contains release object files and libraries
       obsolete -- contains obsolete source files
     menus
       debug -- contains debug object files and libraries
       release -- contains release object files and libraries
       obsolete -- contains obsolete source files
  docs
     designs

My experience with C and C++ has shown to me that header and source files should be in the same directory. Often, finding a header file is more difficult when it is not in the same directory as the source file.

我对C和c++的经验告诉我,头文件和源文件应该在同一个目录中。通常,当与源文件不在同一个目录中时,查找头文件更加困难。

One directory (folder) per concept is a good idea. Any concept that is complex or compound should be split into multiple folders or concepts.

每个概念一个目录(文件夹)是个好主意。任何复杂或复合的概念都应该分为多个文件夹或概念。

I've also learned to make libraries. I use libraries to contain code that doesn't change much. The linking step performs faster with libraries than directories of object files.

我还学会了制作图书馆。我使用库来包含没有太大变化的代码。与对象文件的目录相比,使用库的链接步骤执行得更快。

However, work places (a.k.a. shops) may have different style rules that must be followed.

然而,工作场所(也叫商店)可能有不同的风格规则,必须遵守。

#4


0  

It is not necessary to have your header files and cpp files in the same folder. I have done this many times. You can have the in different folders and use another file to fetch/include both files on file, which you will use as your include. Visit the link below to get a better understanding of what I am saying. It shows you how to implement your own file organization structure.

不需要将头文件和cpp文件放在同一个文件夹中。我做过很多次了。您可以在不同的文件夹中使用另一个文件来获取/包含文件上的两个文件,您将使用它作为您的include。访问下面的链接来更好地理解我在说什么。它向您展示了如何实现自己的文件组织结构。

http://codednotes.blogspot.com/2014/01/organising-headers-and-source-files.html

http://codednotes.blogspot.com/2014/01/organising-headers-and-source-files.html

#1


5  

The following is fairly typical...

以下是相当典型的……

third-party library
  release
    obj
  debug
    obj
  include
  src
    sublib 1
    sublib 2

mylibrary
  release
    obj
  debug
    obj
  include
  src
    sublib 1
    sublib 2

myapp
  release
    obj
  debug
    obj
  subapp 1
  subapp 2

mylittleapp
  release
    obj
  debug
    obj

Basically, subfolders for subprojects is common for larger projects, but mostly a particular project has folders for src, include etc. A folder for each build configuration is common, and keeping the obj files and other intermediates in a subfolder of that is a good idea. It may be tempting to put subproject folders in obj folders, but usually that's unnecessary - the obj folders don't need to be well organised, so the only concern is a filename conflict, and the best fix for that is to have unique source filenames within (at least) each project.

基本上,子项目的子文件夹对于较大的项目是常见的,但是通常一个特定的项目有src、include等文件夹。每个构建配置都有一个文件夹,将obj文件和其他中间文件保存在其中的子文件夹中是一个好主意。在obj文件夹中放置子项目文件夹可能很诱人,但通常这是不必要的——obj文件夹不需要很好地组织,所以唯一需要关注的是文件名冲突,最好的解决方法是在每个项目中(至少)有唯一的源文件名。

The "include" folders should IMO only contain headers that will be #included by other projects - internal headers belong in the "src" folder.

“包含”文件夹应该只包含其他项目将包含的#标题——内部标题属于“src”文件夹。

Putting UI stuff in a separate folder isn't a bad idea, if it's big enough. I've seen UI stuff done as a separate static-linked top-level project, and I do mean app-specific here, not (e.g.) wxWidgets. Usually, though, that level of division is sub-project if it's worth separating at all. How you divide subprojects is more a matter of application-specific blocks in general, so it depends on whether UI stuff is best handled as a separate block or as separate chunks mixed in with task-specific logic.

把UI放到一个单独的文件夹中并不是一个坏主意,如果它足够大的话。我看到UI的工作是作为一个独立的静态链接的*项目完成的,这里我指的是特定于应用程序的项目,而不是(例如)wxWidgets。但是,通常,如果值得分离,那么这个级别的划分就是子项目。如何划分子项目通常更多地取决于特定于应用程序的块,因此它取决于UI内容是作为单独的块处理,还是作为与特定于任务的逻辑混合的独立块处理。

Namespaces aren't the most used language feature, possibly because a lot of people use "using" so much they don't make much difference. A namespace for a main library project makes sense, but associating subfolders to namespaces 1:1 isn't something I've seen. I personally have a namespace that encompasses most of my library code, with a couple of sub-namespaces for things rarely used in general, but used a lot in a few places (e.g. a "bitwise" namespaces). The sub-namespaces are limited to single source/header pairs, so no need for subfolders. Most of the library-specific selection is done by including the right header - except that I usually include the lot through a main-project top-level header anyway.

名称空间并不是最常用的语言特性,这可能是因为很多人使用“使用”太多了,它们没有多大区别。主库项目的名称空间是有意义的,但是我没有看到将子文件夹与名称空间1:1关联。我个人有一个包含我的大部分库代码的名称空间,它有两个子名称空间用于通常很少使用的东西,但是在一些地方(例如“按位计算”的名称空间)大量使用。子名称空间仅限于单个源/头对,因此不需要子文件夹。大多数特定于库的选择是通过包含正确的标题来完成的——除了我通常通过主项目*标题来包含这些标题。

Basically, namespaces are a way of avoiding naming conflicts. They don't necessarily associate with abstractions or functional blocks or anything. Within a particular project, you're probably better off just making sure the names don't conflict. As with the "std" namespace, it's fine to put a lot of stuff in one namespace.

基本上,命名空间是避免命名冲突的一种方式。它们不一定与抽象或功能块或其他东西相关联。在特定的项目中,最好确保名称不冲突。与“std”名称空间一样,在一个名称空间中放置大量内容是可以的。

As you say, though, this isn't a definitive answer - there are of course minor variations and quite different approaches.

不过,正如你所说的,这并不是一个确定的答案——当然有一些细微的变化和非常不同的方法。

#2


1  

On small projects my team groups all the files together by a link unit ie library, DLL, EXE. If the unit is very large we will sometimes breakup the files by functional unit or subsystem so that if you need to edit a component they are generally in the same place.

在小型项目中,我的团队将所有文件由一个链接单元(即库、DLL、EXE)组合在一起。如果单元非常大,我们有时会按功能单元或子系统分解文件,因此如果需要编辑组件,它们通常位于相同的位置。

#3


1  

I break my projects by theme, one directory for theme:

我按主题分解我的项目,一个主题目录:

menu_planner
  src
     recipes
       debug -- contains debug object files and libraries
       release -- contains release object files and libraries
       obsolete -- contains obsolete source files
     ingredients
       debug -- contains debug object files and libraries
       release -- contains release object files and libraries
       obsolete -- contains obsolete source files
     references
       debug -- contains debug object files and libraries
       release -- contains release object files and libraries
       obsolete -- contains obsolete source files
     meals
       debug -- contains debug object files and libraries
       release -- contains release object files and libraries
       obsolete -- contains obsolete source files
     menus
       debug -- contains debug object files and libraries
       release -- contains release object files and libraries
       obsolete -- contains obsolete source files
  docs
     designs

My experience with C and C++ has shown to me that header and source files should be in the same directory. Often, finding a header file is more difficult when it is not in the same directory as the source file.

我对C和c++的经验告诉我,头文件和源文件应该在同一个目录中。通常,当与源文件不在同一个目录中时,查找头文件更加困难。

One directory (folder) per concept is a good idea. Any concept that is complex or compound should be split into multiple folders or concepts.

每个概念一个目录(文件夹)是个好主意。任何复杂或复合的概念都应该分为多个文件夹或概念。

I've also learned to make libraries. I use libraries to contain code that doesn't change much. The linking step performs faster with libraries than directories of object files.

我还学会了制作图书馆。我使用库来包含没有太大变化的代码。与对象文件的目录相比,使用库的链接步骤执行得更快。

However, work places (a.k.a. shops) may have different style rules that must be followed.

然而,工作场所(也叫商店)可能有不同的风格规则,必须遵守。

#4


0  

It is not necessary to have your header files and cpp files in the same folder. I have done this many times. You can have the in different folders and use another file to fetch/include both files on file, which you will use as your include. Visit the link below to get a better understanding of what I am saying. It shows you how to implement your own file organization structure.

不需要将头文件和cpp文件放在同一个文件夹中。我做过很多次了。您可以在不同的文件夹中使用另一个文件来获取/包含文件上的两个文件,您将使用它作为您的include。访问下面的链接来更好地理解我在说什么。它向您展示了如何实现自己的文件组织结构。

http://codednotes.blogspot.com/2014/01/organising-headers-and-source-files.html

http://codednotes.blogspot.com/2014/01/organising-headers-and-source-files.html