源文件组织

时间:2009-09-05 11:57:57

标签: c++ path include

我在组织源文件时遇到了一些麻烦。

我有自己的小型但不断增长的代码集合,我想在各种项目中使用。文件和文件夹布局是这样的:

库\ SUB1 \ source.h

库\ SUB1 \ source.cpp

库\ SUB2 \ source.h

库\ SUB2 \ source.cpp

我的一个问题是我想在我的其他项目中根据需要包含此代码。到目前为止,我已经使用绝对路径指向libary代码,但必须有更好的方法。

此外,我需要将我使用的每个库文件添加到项目的文件Visual Studio中,以便正确编译。

所以我的问题简直就是如何解决这个问题?处理上述情况的正确/最佳方法是什么。

4 个答案:

答案 0 :(得分:3)

我认为没有正确的方式来做到这一点 - 它将取决于你想要实现的目标。

以下是您可能不了解的一些事项:

  • 您可以在项目中使用相对路径。

  • 您可以在路径中使用环境变量。

  • 您可以将目录添加到Visual Studio的搜索规则中。

这使您可以更好地控制包含文件的位置,如果将文件夹添加到Visual Studio的搜索规则,则根本不需要包含任何路径。

答案 1 :(得分:3)

通常,您不应该将库中的源文件直接添加到其他项目中。将它们分别编译为库并使用它们。

为了组织图书馆的目录结构本身,我现在确定了类似以下结构的内容

  • LIBRARY1 / widget.h
  • LIBRARY1 /私人/ onlyinlib.h
  • LIBRARY1 /私人/ widget.cpp

(如适用)

  • LIBRARY1 /私人/资源/ widget.jpg
  • LIBRARY1 /私人/项目/ widget.xcode

我将所有标题直接放在库路径中,并且有一个子文件夹private,它将包含仅由库使用的所有内容,但绝不应该共享/公开。

最大的好处是我开始的每个项目只需要一个指向包含我的库的目录的包含路径,然后每个(公共)包含都像

一样完成
#include "library1/widget.h"

私人包含只是

#include "onlyinlib.h"

这有许多优点:

  • 如果引入了新的库,则不会弄乱项目/编译器设置以使标题“可见”。
  • 转移到其他编译器/平台也很麻烦。
  • 标题会自动“命名空间”,即通过包含部分路径,几乎不可能获得包含
  • 的名称标题
  • 如果标题来自哪里,如果标题是公共界面的一部分,那么它立即显而易见

答案 2 :(得分:2)

如果您必须包含第三方代码而不是仅仅链接预编译版本(例如,您可能需要对其进行修改或调整),请考虑使用分支它对于源代码控制:

  • / trunk / ... --- 您的代码在这里
  • / thirdparty --- 第三方图书馆的原始副本到这里
    • /第三方/ LIB1
    • /第三方/ LIB2
  • / trunk / lib1 --- 分支自: / thirdparty / lib1,可能带有本地更改
    • 这是您构建/链接的版本。

假设您使用了一个不错的源代码控制系统,此方案将允许您轻松升级到较新版本的第三方库,然后将这些更改与您在本地进行的更改合并。

例如,假设“lib1”发布了新版本:

  • 将更改提交至/ thirdparty / lib1。
  • / thirdparty / lib1 合并到 / trunk / lib1
  • 修复任何合并冲突。

这是IMO,是处理升级本地修改的第三方库的唯一理智方式。

答案 3 :(得分:1)

首先:将所有使用过的directorys添加到项目包含路径中。如果可能的话,将它们添加为相对路径。

第二:您必须将所有使用过的图书馆/源文件添加到您的项目中。这可以在项目资源管理器中完成,也可以在Project-> Linker选项卡中完成。在后一种情况下,您还必须将使用过的目录添加到项目库路径中。

通常在#include指令中使用路径不是一个好主意。