微信公众号搜"智元新知"关注
微信扫一扫可直接关注哦!

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

在我的位置,我们有一个很大的C代码库,我认为如何使用头文件存在问题.

Visual Studio项目很多,但问题出在概念上并且与VS无关.每个项目都是一个模块,执行特定的功能.每个项目/模块都编译为库或二进制文件.每个项目都有一个包含所有源文件的目录 – * .cpp和* .h.一些头文件是模块的API(我的意思是声明创建的库的API的头文件的子集),一些是内部的.

现在问题 – 当模块A需要使用模块B时,A会添加B的源目录以包含搜索路径.因此,A在编译时可以看到所有B的模块内部头.

作为一个副作用,开发人员不必强调每个模块的确切API,我认为这是一个坏习惯.

我首先考虑了它应该如何应用.我想过创造
每个项目只有一个包含接口头文件的专用目录.希望使用该模块的客户端模块仅允许包含接口目录.

这种方法可以吗?你的位置如何解决问题?

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

谢谢
梅德

解决方法

这听起来像你在正确的轨道上.许多第三方图书馆都做同样的事情.例如:

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"

原文地址:https://www.jb51.cc/c/119618.html

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐