代码之家 › 专栏 › 技术社区 › dimba

C++模块之间的头文件依赖关系

development-environment dependencies c++

dimba · 技术社区 · 15 年前

有很多visualstudio项目,但问题是在概念上的,与VS无关。每个项目都是一个模块,执行特定的功能。每个项目/模块都编译为库或二进制文件。将.cpp文件的一些头文件声明给.cpp库,这意味着每个API文件的头文件都是.cpp文件的一个子集。

作为一个副作用,开发人员不会被迫集中于每个模块的确切API,我认为这是一个坏习惯。

我考虑了一个选择,首先应该如何。我想在

这种方法行吗?这个问题在你这里是怎么解决的?

UPD公司 在我之前的地方,开发是在Linux上用g++/gmake完成的,我们确实使用了将API头文件安装到一个公共目录中,这是一些答案的建议。现在我们有了使用cmake生成项目文件的Windows(visualstudio)/Linux(g++)项目。如何在visualstudio中强制预构建安装API头文件?

谢谢德米特里

6 回复 | 直到 15 年前

RC. 15 年前

听起来你说得对。许多第三方库也会这样做。例如:

3rdParty/myLib/src/-包含编译库所需的头文件和源文件
3rdParty/myLib/include/myLib/-包含外部应用程序要包含的头文件

有些人/项目只是将要由外部应用程序包含的标题放在/3rdParty/myLib/include中,但是添加额外的myLib目录有助于避免名称冲突。

假设您使用的结构是:3rdParty/myLib/include/myLib/

In Makefile of external app:
---------------
INCLUDE =-I$(3RD_PARTY_PATH)/myLib/include
INCLUDE+=-I$(3RD_PARTY_PATH)/myLib2/include
...
...

In Source/Headers of the external app
#include "myLib/base.h"
#include "myLib/object.h"

#include "myLib2/base.h"

Stack Overflow is garbage 15 年前

将接口头放在项目的根目录中,并为非API头创建一个子文件夹(称之为“internal”或“helper”或类似的名称)不是更直观吗?

Justin 15 年前

在我工作的地方,我们有一个在构建时创建的传递文件夹结构。定义库的头文件被复制到include文件夹中。我们使用定制的构建脚本,让开发人员指示应该导出哪些头文件。

subst

我们还有一个基于网络的引用构建,它允许我们对include和lib引用使用映射驱动器。

更新:我们的参考构建是构建服务器上的网络共享。我们使用一个参考构建脚本来设置构建环境和映射(使用 net use )生成服务器上的命名共享(即.\BLD\u SRV\REFERENCE_build_share)。然后在每周构建(或手动)期间,我们设置共享(使用 net share

然后,我们的项目将列出include和lib引用的绝对路径。

例如:

subst'ed local build drive j:\
mapped drive to reference build: p:\
path to headers: root:\build\headers
path to libs: root:\build\release\lib
include path in project settings j:\build\headers; p:\build\headers
lib path in project settings     j:\build\release\lib;p:\build\release\lib

Matt Price 15 年前

我见过这样的问题是通过在模块B中设置一组头文件来解决的,这些头文件作为构建过程的一部分随lib一起被复制到release目录中。然后模块A只看到那些头文件,而不能访问B的内部结构。通常我只在一个公开发布的大型项目中看到这一点。

对于内部项目来说,这是不可能的。通常的情况是,当他们很小的时候,这并不重要。当他们长大后,把它分开是如此的混乱,没有人愿意这样做。

Drew Hoskins 15 年前

也就是说,我比较喜欢你的方法。您甚至可以避免将这些目录添加到include路径中,这样人们就可以通过顶部的include中的相对路径来判断源文件所依赖的模块。

但是,根据项目的布局,在从头中包含它们时,这可能会有问题,因为头的相对路径来自.cpp文件,而不是.h文件,因此.h文件不一定知道它的.cpp文件在哪里。

但是,如果你的项目有一个扁平的层次结构,这是可行的。说你有

base\foo\foo.cpp
base\bar\bar.cpp
base\baz\baz.cpp
base\baz\inc\baz.h

现在任何头文件都可以包括
#include "..\baz\inc\baz.h

sbi 15 年前

在我曾经工作过的一个小组中,所有的public都保存在一个特定于模块的文件夹中,而私有的东西(private header,cpp file等)则保存在一个 _imp

base\foo\foo.h
base\foo\_imp\foo_private.h
base\foo\_imp\foo.cpp

_小鬼 _小鬼 子文件夹,知道你已经准备好发布API了。

#include "foo/foo.h"

但是,如果项目必须使用某些API,则API头将由API的内部版本复制/安装,无论构建系统在该平台上的位置是什么,然后作为系统标头进行安装:

#include <foo/foo.h>