如何在不修改项目源文件的情况下禁止C++代码中使用long类型？

针对你遇到的跨平台（Windows/Linux）long类型长度不一致的问题，同时又不想修改现有源文件、还要兼容外部库的long声明，我有几个可行的方案，都是通过编译工具链配置来实现的：

方案一：利用编译器的#pragma poison（GCC/Clang都支持） #

这个方法直接让long变成“有毒”标识符，一旦在项目代码中使用就会触发编译错误，同时通过系统头文件隔离避免影响外部库和标准库。

步骤如下：

1. 创建一个名为forbid_long.h的头文件，内容如下：

// 仅在非系统头文件中生效（系统头文件由-isystem指定）
#ifndef __SYSTEM_HEADER__
// GCC和Clang都支持的poison指令
#pragma GCC poison long
#pragma clang poison long
#endif

2. 调整编译选项：
   • 添加 -include forbid_long.h，让每个源文件开头自动包含这个头
   • 把所有外部库的包含路径从 -I 改成 -isystem（标准库路径默认就是系统路径，不需要改）
     这样一来，编译器处理系统头文件（包括外部库和标准库）时会忽略#pragma poison，只有项目自己的代码中使用long才会触发编译错误。

方案二：用Clang-Tidy自定义检查（适合用Clang工具链的项目） #

如果你的项目已经在使用Clang-Tidy做静态分析，可以自定义一个检查规则，专门捕捉long类型的变量声明，并将其设为错误级别。

大致思路：

• 写一个简单的Clang-Tidy检查插件，遍历代码中的变量声明，判断类型是否为long，如果是就抛出错误提示（比如建议用int32_t/int64_t替代）
• 在Clang-Tidy配置中启用这个检查，并加上 -warnings-as-errors 选项，这样在编译时就会直接报错，阻止代码提交

这个方法更加灵活，还可以扩展到检查long long或者其他你想禁止的类型，而且完全不会影响外部库的代码。

方案三：改进你之前的宏定义方法（规避标准头冲突） #

你之前尝试的#define long static_assert(...)思路是对的，但问题出在这个宏会影响标准头。我们可以通过条件编译让宏只在项目代码中生效：

创建forbid_long.h：

// 如果是系统头文件，直接把long定义回long（等于无效）
#ifdef __SYSTEM_HEADER__
#define long long
#else
// 在项目代码中，用static_assert触发编译错误
#define long static_assert(false, "禁止使用long类型，请使用int32_t/int64_t代替")
#endif

然后同样添加 -include forbid_long.h 编译选项，并把外部库路径改成 -isystem。这样标准头和外部库中的long不会被干扰，只有项目自己的代码会触发错误。

额外建议 #

不管用哪种方法，都应该在团队内明确推广使用<cstdint>中的固定宽度整数类型（比如int32_t、int64_t），从根源上解决跨平台的类型长度不一致问题，这才是长期的解决方案。

内容来源于stack exchange