使用include filename中的项目目录

Using project directory in include filename

本文关键字：项目 include filename 使用      更新时间：2023-10-16

我正在开发仅限C++头的库，让我们称之为PROJ。当库标头包含另一个标头时，它使用：

#include <proj/foo.h>

编译器(gcc和clang)具有-I path-to-proj-parent。库的用户在其包含搜索路径中还应该有PROJ的父级。

我使用此方案的理由是，在将此库安装到默认可搜索父级(/usr/include/proj或/usr/local/include/proj)的proj子目录中后，库用户无需指定-I选项。

这个计划有缺点吗？使用不带proj/前缀的<foo.h>是更传统和推荐的方式吗？

问题不在于是否在subdir中安装(将有projsubdir)，而在于如何引用include文件。

如果您查看boost，您会注意到它们使用了类似的方案：

#include <boost/shared_ptr.hpp>

它的优点是可以防止与另一个依赖项中另一个名称相似的文件发生冲突。

然而，在助推的情况下，他们更进一步。如果包含<x/y/z.hpp>，那么您可能正在处理一个名为::x::y::z的实体(无论是函数还是类)。也就是说，项目中目录的布局方式模仿了命名空间组织。给自己定位真的很巧妙。

通常，大多数项目都隐藏在子目录(和子目录空间)中，但为了方便起见，最常用的项目被拉到boost命名空间中，因此它们的头直接位于boost文件夹中。还有一些方便的标头(其工作只是收集少量其他标头，以便一次将它们全部拉入)。

最后，你可能会注意到，如果你打开一个头文件，他们使用的包含保护遵循完全相同的层次结构：

#ifndef BOOST_SHARED_PTR_HPP_INCLUDED

再一次，因为它有助于避免冲突，因为它是以它所在的文件命名的，而且在整个Boost项目中(在区分大小写的文件系统上)，这个位置只能有一个。

如果在安装时创建proj目录，则可以在路径中包含proj。事实上，这是防止与其他包含文件发生名称冲突的好方法。

名称不应该是像"proj"这样的通用名称。它应该是特定于项目的。

相关文章：