避免添加“包含路径”对于不直接 #included 的标头
假设我有两个vc++项目，proj_a和proj_b
proj_a包含头文件啊
proj_b对proj_a有依赖。它包含执行 #include
现在说，我还有 100 个项目，其文件#include
简单地说，如何保持任何 vc++ 项目的包含路径数量等于直接依赖项的数量？
我没有选项将 vc++ 环境设置设置为全局包含 ah 的路径，因为我团队中的其他人都必须导入我的设置，事情会变得更混乱。
我没有足够的想法，但有没有办法实现这是通过预编译头实现的吗？我认为它们是特定于项目的，不应该跨项目共享？
Suppose I have two vc++ project, proj_a and proj_b
proj_a contains a header file a.h
proj_b has dependency on proj_a. It contains file b.h that does #include <a.h>. I add a.h's directory in the "additional include directories" in its project settings to build it.
Now say, I have 100 more projects, whose files #include <b.h>. Only adding b.h's directory in the "additional" column does not work. I have to include the path of a.h too.. How to avoid this?
Simply put, how to keep the number of include paths for any vc++ project equal to the number of direct dependencies?
I don't have the option to set vc++ environment settings to globally include a.h's path since everybody else in my team will have to import my settings and things will turn messier..
I don't have enough idea but is there a way to achieve this through precompiled headers? I think they are project-specific and should not be shared across projects?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
依赖关系是可传递的。也就是说，由于
bh包含ah，因此包含bh的任何内容都需要能够找到ah。您唯一能做的就是以某种方式删除bh对ah的依赖，也许可以通过对ah中的类型使用前向声明> 而不是依赖头文件中类型的完整定义。如果这不是一个选项，至少您可以使用 Visual C++ 的“属性表”功能。这些允许您在单个文件中定义共享构建设置，该文件可以由任意数量的项目继承。这也将解决与协作者共享这些设置的问题。
Dependencies are transitive. That is, since
b.hincludesa.h, anything that includesb.hwill need to be able to finda.h. The only thing you can do about it is to somehow remove the dependency ofb.hona.h, perhaps by using a forward declaration for the types ina.hinstead of relying on the full definition of the types from the header file.If that's not an option, at least you can ease the pain of include paths that are duplicated across projects by using Visual C++'s "property sheet" feature. These let you define shared build settings in a single file which can be inherited by an arbitrary number of projects. This will also solve the problem of sharing these settings with your collaborators.
感谢尼克的回答。我可以在
bh中使用ah的相对路径，并在 proj_b 和其余 100 个项目中保存附加包含目录。实际上，在我的例子中，proj_a 有多种风格：'proj_a1、proj_a2 等，每个都有一个单独的 ah。其他 100 个项目通过在其设置中设置适当的 extra-include-directory 来决定要包含哪种风格。这是一个问题，每当我们需要升级 proj_a 风格时，所有包含目录都需要更改。
我通过删除所有包含目录并在其余项目中定义 PROJ_A1、PROJ_A2 等来解决这个问题。
bh不再是#include ah，它包含一个 a_redirector.h 头文件（带有相对路径）。在 a_redirector.h 中，我们有所有#ifdef PROJ_A1、#ifdef PROJ_A2等，它们查看包含特定ah文件（相对路径也在这里）取决于已定义的内容。现在，每当我们需要升级 proj_a 风格时，我只需要修改
a_redirector.h即可指向所有新的 ah，从而与早期架构相比具有单点控制。Thanks for the answer Nick. I could have used relative path to
a.hinsideb.hand save having additional-include-directories inside proj_b and rest of 100 projects.Actually, in my case there are multiple flavors of proj_a: 'proj_a1, proj_a2, etc. each having a separate a.h. The other 100 projects decide on which flavor to include by having appropriate additional-include-directory in their settings. This was an issue, whenever we need to upgrade proj_a flavors, all include-dirs will need to be changed.
I got across this problem by removing all include-dirs and instead defining PROJ_A1, PROJ_A2, etc. in the rest of projects.
b.hdoes not#include a.hanymore, it include a a_redirector.h header file instead (with relative path). Inside a_redirector.h, we have all#ifdef PROJ_A1,#ifdef PROJ_A2, etc. that looks at the include a particulara.hfile (relative paths here too) depending on what has been defined.Now, whenever we need to upgrade proj_a flavors, I need only to modify
a_redirector.honly to point to all new a.h thereby having a single point of control as compared to the earlier architecture.