1. 引言
该库定义了一组编译器、架构、操作系统、库和其他版本号，这些信息来源于它能够从 C、C++、Objective C 和 Objective C++ 的预定义宏或通常可用的头文件中收集到的信息。创建这个库的想法源于一个扩展 Boost Config 库的提案，该库旨在提供比其支持的功能定义更丰富、更一致的信息。以下是该简短提案的编辑版本。
1.1. 提案
目的是定义一组宏来识别编译器并一致地表示它们的版本。这包括：
-
一个唯一的
BOOST_VERSION_NUMBER(major,minor,patch)宏，用于指定版本号（不幸的是，BOOST_VERSION这个名称已被用于指示 Boost 本身版本号）。 -
一个编译器标识宏，适用于每个受支持的编译器，可在
#if/#elif指令中使用。所有宏都将被定义，无论编译器如何。与正在使用的编译器对应的宏将被定义为BOOST_VERSION_NUMBER的形式，以携带精确的编译器版本。所有其他宏将展开为计算为 false 的表达式（例如，令牌 0），以指示相应的编译器不存在。 -
可以在
boost/config/select_compiler.hpp中为所有宏设置“空值”；然后，对于每个编译器，相应的标识宏将被 #undef 并重新 #define 在相应的boost/compiler/(cc).hpp中；但是，在 Boost.Config 基础设施的上下文中，使用“前缀”头文件（待引入）或boost/config/suffix.hpp是一个更好的解决方案。
1.2. 当前库
当前的 Predef 库现在是一个独立的库，并且其范围已扩大。它包括对架构、编译器、语言、库、操作系统和字节序的检测和定义。主要好处是：
-
版本号始终定义，因此无需使用
#ifdef进行保护。 -
可用于
#ifdef检查的保护宏。 -
所有可能的定义都包含在单个
#include <boost/predef.h>中，因此它对预编译头文件的使用很友好。 -
可以包含特定的定义，例如
#include <boost/predef/os/windows.h>用于单个检查。 -
预定义宏可以直接用于预处理器和编译器表达式，以与其他类似定义的宏进行比较。
-
这些头文件可供支持 C 预处理器的多种语言使用。特别是 C++、C、Objective C 和 Objective C++。
1.3. 设计选择
一个重要的设计选择是关于如何通过单个整数来表示编译器版本，该整数适用于预处理指令。我们来做一些计算。“基本”的有符号类型在 C90（以及 C++，截至 2006 年）中是 long，在 C99 中是 intmax_t。long 类型至少应能表示数字 +2 147 483 647。这意味着最高有效数字只能是 0、1 或 2；如果我们希望所有十进制数字都能在 0 到 9 之间变化，我们可以考虑的最大范围是 [0, 999 999 999]。均匀分布，这意味着版本号的每个部分有 3 位十进制数字。
所以我们可以
-
使用不均匀分布，或
-
使用更多位数（更大的类型），或
-
使用 3/3/3，让特定的编译器/平台/stdlib 处理在 3 位数字范围内设置这些数字。
似乎相对安全地选择第一个选项，并将其设置为 2/2/5。这涵盖了 CodeWarrior 等，其主版本号高达甚至超过 10。某些编译器使用构建号而不是补丁号；在这种情况下，五位数（VC++ 8 已达到）似乎也是一个合理的限制。
|
ℹ
|
2/2/6 的方案允许更大的补丁/构建号，但代价是，例如，主版本号限制为 20（或在进一步限制下，限制为 21）。 |
读者可能会放心，这个决定实际上是在代码中的一个地方编码的，即 BOOST_VERSION_NUMBER 的定义。
1.4. 未来工作
尽管这个库的基础已经完成，但仍有大量工作可以做
-
目前，我们将库的检测限制在已知的内置预定义宏以及保证存在的系统和库头文件。添加类似自动配置预定义宏的功能可能会很有趣。这样我们就可以为用户特定的库和功能添加定义。
-
除了上述内容，最好添加一些用户控制以确定顶级头文件包含哪些头文件。尽管在当前库形式下，这问题不大，因为用户可以包含他们需要的特定头文件。
-
此外，即使没有自动配置之类的选项，也应该添加可选包含的头文件，以便用户可以为他们使用的库获得一致的版本号定义。
-
显然，还需要大量工作来重构现有的 Boost 库以使用 Predef 库。
-
并且，还需要持续添加对当前和未来编译器、平台、架构、语言和库的定义。
2. 使用预定义宏
要使用自动定义的预定义宏，只需包含单个顶级头文件即可。
#include <boost/predef.h>这将定义 [*所有] 库已知的版本宏。对于每个宏，它将被定义为零值表达式（当特定项未检测到时）或正值（当检测到时）。预定义宏分为五类，每类都有特定前缀的宏：
-
BOOST_ARCH_用于编译的目标系统/CPU 架构。 -
BOOST_COMP_用于正在使用的编译器。 -
BOOST_LANG_用于正在编译的语言标准。 -
BOOST_LIB_C_和BOOST_LIB_STD_用于正在使用的 C 和 C++ 标准库。 -
BOOST_OS_用于我们正在编译的目标操作系统。 -
BOOST_PLAT_用于操作系统或编译器之上的平台。 -
BOOST_ENDIAN_用于操作系统和架构组合的字节序。 -
BOOST_HW_用于特定硬件功能。 -
BOOST_HW_SIMD用于 SIMD（单指令多数据）检测。
|
ℹ
|
检测到的定义是编译期间目标配置的信息。特别是在交叉编译中，这意味着目标系统，而不是主机系统。 |
通过将这些宏与 BOOST_VERSION_NUMBER 宏进行比较，可以利用单个定义来与特定版本进行比较。例如，要根据 GCC C++ 编译器的版本做出选择，您可以这样做：
#include <boost/predef.h>
#include <iostream>
int main()
{
if (BOOST_COMP_GNUC >= BOOST_VERSION_NUMBER(4,0,0))
std::cout << "GCC compiler is at least version 4.0.0" << std::endl;
else
std::cout << "GCC compiler is at older than version 4.0.0, or not a GCC compiler" << std::endl;
return 0;
}如上所示，else 子句也涵盖了未检测到特定编译器的情况。但也可以进行测试以检测是否存在。所有预定义宏在未检测到时都定义为零（0）表达式。因此，可以使用自然单条件进行检测。例如：
#include <boost/predef.h>
#include <iostream>
int main()
{
if (BOOST_COMP_GNUC)
std::cout << "This is GNU GCC!" << std::endl;
else
std::cout << "Not GNU GCC." << std::endl;
return 0;
}并且由于预定义宏是预处理器定义，因此从预处理器也可以做到这一点：
#include <boost/predef.h>
#include <iostream>
#if BOOST_COMP_GNUC
#if BOOST_COMP_GNUC >= BOOST_VERSION_NUMBER(4,0,0)
const char * the_compiler = "GNU GCC, of at least version 4."
#else
const char * the_compiler = "GNU GCC, less than version 4."
#endif
#else
const char * the_compiler = "Not GNU GCC."
#endif
int main()
{
std::cout << the_compiler << std::endl;
return 0;
}此外，对于每个定义的版本宏，都有一个 *_AVAILABLE 宏，仅在检测到特定方面时定义。即，等同于：
#if BOOST_PREDEF_ABC
#define BOOST_PREDEF_ABC_AVAILABLE
#endif此外，对于每个方面，都有一个具有描述性名称的宏，说明检测的是什么。
2.1. *_EMULATED 宏
预定义宏保证在同一类别内唯一地被检测到。但存在多种底层检测可能性的上下文。一个众所周知的例子是 GCC 和 MSVC 编译器的检测，它们通常通过定义相同的基本宏来模拟。为了应对这种情况，允许检测头文件在检测到这种情况时定义 *_EMULATED 预定义宏。模拟的预定义宏将设置为检测的版本号，而不是该检测的常规预定义宏。例如，MSVC 将设置 BOOST_COMP_MSVC_EMULATED，但不设置 BOOST_COMP_MSVC，它还将设置 BOOST_COMP_MSVC_AVAILABLE。
2.2. 使用 BOOST_VERSION_NUMBER 宏
所有预定义宏都定义为使用 BOOST_VERSION_NUMBER 宏。该宏接受单独的主版本、次版本和补丁版本表达式：
#define BOOST_VERSION_NUMBER( major, minor, patch ) ...参数是：
-
主版本号，作为常量值表达式，范围在 [0,99] 之间。
-
次版本号，作为常量值表达式，范围在 [0,99] 之间。
-
补丁级别版本号，作为常量值表达式，范围在 [0,99999] 之间。
每个范围的限制是通过使用模（“%”）运算，即截断，而不是钳制来“强制执行”的。因此，这意味着限制仅足以防止出现越界问题，但不足以防止其他类型的问题，例如超出范围导致误检或漏检。 individual predefs 负责确保超出范围保证的正确使用。
参数的值可以是任何预处理器有效的常量值表达式。BOOST_VERSION_NUMBER 宏的定义以及任何其他预定义宏的定义中都只使用常量值算术。这意味着任何允许的基数都可以使用，即二进制、八进制、十进制和十六进制。例如：
#define MY_APPLICATION_VERSION_NUMBER BOOST_VERSION_NUMBER(2,0xA,015)等同于：
#define MY_APPLICATION_VERSION_NUMBER BOOST_VERSION_NUMBER(2,10,13)3. 添加新的预定义宏
我们知道像这样的库将是一个永无止境的进行中的工作。因此，我们期望并期待其他人贡献对预定义宏的更正和添加。考虑到这一点，我们需要保持定义新预定义宏的一致方式。因此，所有当前和未来的预定义宏都遵循相同的结构和要求。
3.1. 头文件的要求
所有预定义宏都需要遵循一组要求：
-
头文件必须使用 Boost 软件许可证。
-
默认情况下，预定义宏必须定义为
BOOST_VERSION_NUMBER_NOT_AVAILABLE。 -
一旦检测到预定义宏，就必须将其重新定义为非零值。
-
默认情况下，当检测到预定义宏时，它必须定义为
BOOST_VERSION_NUMBER_AVAILABLE。 -
如果可能，预定义宏将定义为检测到的版本号。
-
预定义宏必须根据需要定义
*_AVAILABLE宏。 -
预定义宏必须定义一个符号常量字符串名称宏。
-
预定义宏在定义后必须声明自己，以便测试系统使用。
-
预定义宏必须保证在每个类别中，它都是唯一被检测到的。
-
但是，预定义宏可以定义
*_EMULATED宏，以表明它之前已被另一个头文件检测到，并且正在被系统“模拟”。请注意，在这种情况下，*_AVAILABLE宏仍必须定义。
此外，还有一些预定义头文件应遵循的额外指南：
-
检测应避免包含可能未默认包含的额外头文件。
-
如果检测必须包含头文件，则尽可能将其括在检测中。
-
如果检测必须无条件地包含头文件，并且可以选择要包含的头文件，则应优先选择影响最小的。即，包含具有最少定义和其他依赖项的头文件。
3.2. 头文件的结构
为了通用性，建议新的预定义头文件遵循以下结构，就像当前预定义头文件一样。首先是版权和许可证声明，然后是包含守卫：
/*
Copyright Jane Doe YYYY
Distributed under the Boost Software License, Version 1.0.
(See accompanying file LICENSE_1_0.txt or copy at
https://boost.ac.cn/LICENSE_1_0.txt)
*/
#ifndef BOOST_PREDEF_category_tag_H
#define BOOST_PREDEF_category_tag_H如果检测依赖于对另一个预定义宏的检测，则应在此处包含那些头文件。
#include <boost/predef/CATEGORY_TAG/DEPENDENCY.h>根据您定义预定义宏的方式，您至少需要包含 version_number.h 头文件。但您可能还想包含 make.h 头文件，以获取版本号分解实用宏。
#include <boost/predef/version_number.h>
#include <boost/predef/make.h>Predef 库使用 Asciidoctor 进行文档编写，为了让单个预定义宏出现在参考章节中，我们在代码中添加了文档，然后是预定义宏的零值默认定义。我们强烈建议采用这种特定的文档和默认定义放置方式，因为某些开发环境会自动解释它并提供内联帮助。这尤其适用于流行的 Eclipse IDE。
/* tag::reference[]
= `BOOST_category_tag`
Documentation about what is detected.
*/
#define BOOST_category_tag BOOST_VERSION_NUMBER_NOT_AVAILABLE接下来是特定预定义宏的检测和定义。其结构是进行一次整体检查（condition_a），并将进一步的版本检测放在其中。整体检查中的第一个动作是“#undef BOOST_category_tag”，它会移除零值默认定义。其余部分由您决定如何进行检查以定义版本。但至少它必须“#define BOOST_category_tag BOOST_VERSION_NUMBER_AVAILABLE”作为最小程度地表明预定义宏已被检测到的备用方案。
#if (condition_a)
# undef BOOST_category_tag
# if (condition_b)
# define BOOST_category_tag BOOST_VERSION_NUMBER(major,minor,patch)
# else
# define BOOST_category_tag BOOST_VERSION_NUMBER_AVAILABLE
# endif
#endif我们还需要提供 *_AVAILABLE 版本的预定义宏。
#if BOOST_category_tag
# define BOOST_category_tag_AVAILABLE
#endif为了方便起见，我们还想提供一个 *_NAME 宏。
#define BOOST_category_tag_NAME "Name"至此，我们结束了包含守卫。我们在此之前完成此操作，因为测试系统会多次包含头文件以生成所需的测试代码。
#endif预定义宏的测试是自动化的，以生成对所有已定义的预定义宏（无论是否检测到）的检查。为了做到这一点，我们需要将预定义宏声明给测试系统。此声明对于常规使用是空的。而在测试程序中，它们会专门展开以创建信息性输出。
#include <boost/predef/detail/test.h>
BOOST_PREDEF_DECLARE_TEST(BOOST_category_tag,BOOST_category_tag_NAME)3.3. 添加独占预定义宏
对于需要互斥检测的预定义宏的头文件，我们需要添加检查和定义来检测何时预定义宏被多个头文件检测到。
内部编译器、操作系统和平台分别定义 BOOST_PREDEF_DETAIL_COMP_DETECTED、BOOST_PREDEF_DEFAIL_OS_DETECTED 和 BOOST_PREDEF_DETAIL_PLAT_DETECTED，以表明预定义宏首次被检测到。这用于防止在稍后包含的头文件中重复定义检测。在这些情况下，检测将改为这样编写：
#if !BOOST_PREDEF_DETAIL_category_DETECTED && (condition_a)
# undef BOOST_category_tag
# if (condition_b)
# define BOOST_category_tag BOOST_VERSION_NUMBER(major,minor,patch)
# else
# define BOOST_category_tag BOOST_VERSION_NUMBER(0,0,1)
# endif
#endif我们还包含一个头文件，当检测到时定义 *_DETECTED 宏。
#if BOOST_category_tag
# define BOOST_category_tag_AVAILABLE
# include <boost/predef/detail/CATEGORY_detected.h>
#endif关于头文件的其他所有内容与基本检测头文件相同。
3.4. 添加独占但模拟的预定义宏
由于编译器经常被其他编译器模拟，我们既希望实现编译器的独占检测，又希望提供我们检测到编译器模拟的信息。为了实现这一点，我们定义一个本地的 *_DETECTION 宏用于编译器检测。并有条件地定义基础编译器预定义宏 BOOST_COMP_compiler 或备用的 BOOST_COMP_compiler_EMULATED 预定义宏。
初始检测将如下所示：
#if (condition_a)
# if (condition_b)
# define BOOST_COMP_tag_DETECTION BOOST_VERSION_NUMBER(major,minor,patch)
# else
# define BOOST_COMP_tag_DETECTION BOOST_VERSION_NUMBER_AVAILABLE
# endif
#endif然后我们可以有条件地定义基础或模拟的预定义宏：
#ifdef BOOST_COMP_tag_DETECTION
# if defined(BOOST_PREDEF_DETAIL_COMP_DETECTED)
# define BOOST_COMP_tag_EMULATED BOOST_COMP_tag_DETECTION
# else
# undef BOOST_COMP_tag
# define BOOST_COMP_tag BOOST_COMP_tag_DETECTION
# endif
# define BOOST_category_tag_AVAILABLE
# include <boost/predef/detail/comp_detected.h>
#endif4. 参考
4.1. BOOST_ARCH 架构宏
4.1.1. BOOST_ARCH_ALPHA
DEC Alpha 架构。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
检测 |
|
4.0.0 |
|
5.0.0 |
|
6.0.0 |
4.1.2. BOOST_ARCH_ARM
ARM 架构。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
V.0.0 |
|
V.0.0 |
|
V.0.0 |
|
V.0.0 |
|
8.0.0 |
|
8.0.0 |
|
8.0.0 |
|
8.0.0 |
|
7.0.0 |
|
7.0.0 |
|
7.0.0 |
|
7.0.0 |
|
6.0.0 |
|
6.0.0 |
|
6.0.0 |
|
6.0.0 |
|
5.0.0 |
|
5.0.0 |
|
4.0.0 |
|
4.0.0 |
4.1.3. BOOST_ARCH_BLACKFIN
Analog Devices 的 Blackfin 处理器。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
检测 |
|
检测 |
4.1.4. BOOST_ARCH_CONVEX
Convex Computer 架构。
| 符号 | 版本 |
|---|---|
|
检测 |
|
1.0.0 |
|
2.0.0 |
|
3.2.0 |
|
3.4.0 |
|
3.8.0 |
4.1.6. BOOST_ARCH_IA64
Intel Itanium 64 架构。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
4.1.7. BOOST_ARCH_M68K
Motorola 68k 架构。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
6.0.0 |
|
6.0.0 |
|
6.0.0 |
|
4.0.0 |
|
4.0.0 |
|
4.0.0 |
|
3.0.0 |
|
3.0.0 |
|
3.0.0 |
|
2.0.0 |
|
2.0.0 |
|
2.0.0 |
|
1.0.0 |
|
1.0.0 |
|
1.0.0 |
|
0.0.1 |
|
0.0.1 |
|
0.0.1 |
4.1.8. BOOST_ARCH_MIPS
MIPS 架构。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
检测 |
|
V.0.0 |
|
1.0.0 |
|
1.0.0 |
|
2.0.0 |
|
2.0.0 |
|
2.0.0 |
|
3.0.0 |
|
3.0.0 |
|
4.0.0 |
|
4.0.0 |
4.1.9. BOOST_ARCH_PARISC
HP/PA RISC 架构。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
检测 |
|
1.0.0 |
|
1.1.0 |
|
1.1.0 |
|
1.1.0 |
|
2.0.0 |
|
2.0.0 |
|
2.0.0 |
|
2.0.0 |
4.1.10. BOOST_ARCH_PPC
PowerPC 架构。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
6.1.0 |
|
6.1.0 |
|
6.3.0 |
|
6.3.0 |
|
6.4.0 |
|
6.4.0 |
4.1.11. BOOST_ARCH_PPC_64
PowerPC 64 位架构。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
检测 |
|
检测 |
4.1.15. BOOST_ARCH_RS6000
RS/6000 架构。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
4.1.16. BOOST_ARCH_SPARC
SPARC 架构。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
9.0.0 |
|
9.0.0 |
|
8.0.0 |
|
8.0.0 |
4.1.17. BOOST_ARCH_SH
SuperH 架构：如果可用，则具体检测版本 [1-5]。
| 符号 | 版本 |
|---|---|
|
检测 |
|
5.0.0 |
|
4.0.0 |
|
3.0.0 |
|
3.0.0 |
|
2.0.0 |
|
1.0.0 |
4.1.20. BOOST_ARCH_X86
Intel x86 架构。这是一个类别，表示检测到 BOOST_ARCH_X86_32 或 BOOST_ARCH_X86_64。
4.1.22. BOOST_ARCH_X86_32
Intel x86 架构：如果可用，则具体检测版本 [3-6]。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
V.0.0 |
|
V.0.0 |
|
6.0.0 |
|
5.0.0 |
|
4.0.0 |
|
3.0.0 |
4.1.23. BOOST_ARCH_X86_64
X86-64 架构。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
4.2. BOOST_COMP 编译器宏
4.2.1. BOOST_COMP_BORLAND
Borland C++ 编译器。版本号可按主版本、次版本和补丁版本获取。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
V.R.P |
|
V.R.P |
4.2.2. BOOST_COMP_CLANG
Clang 编译器。版本号可按主版本、次版本和补丁级别获取。
| 符号 | 版本 |
|---|---|
|
检测 |
|
V.R.P |
4.2.4. BOOST_COMP_DEC
Compaq C/C++ 编译器。版本号可按主版本、次版本和补丁版本获取。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
V.R.P |
|
V.R.P |
4.2.5. BOOST_COMP_DIAB
Diab C/C++ 编译器。版本号可按主版本、次版本和补丁版本获取。
| 符号 | 版本 |
|---|---|
|
检测 |
|
V.R.P |
4.2.7. BOOST_COMP_SYSC
Dignus Systems/C++ 编译器。版本号可按主版本、次版本和补丁版本获取。
| 符号 | 版本 |
|---|---|
|
检测 |
|
V.R.P |
4.2.8. BOOST_COMP_EDG
EDG C++ Frontend 编译器。版本号可按主版本、次版本和补丁版本获取。
| 符号 | 版本 |
|---|---|
|
检测 |
|
V.R.0 |
4.2.9. BOOST_COMP_PATH
EKOpath 编译器。版本号可按主版本、次版本和补丁级别获取。
| 符号 | 版本 |
|---|---|
|
检测 |
|
V.R.P |
4.2.10. BOOST_COMP_GNUC
Gnu GCC C/C++ 编译器。版本号可按主版本、次版本和补丁级别（如果可用）获取。
| 符号 | 版本 |
|---|---|
|
检测 |
|
V.R.P |
|
V.R.0 |
4.2.12. BOOST_COMP_GHS
Green Hills C/C++ 编译器。版本号可按主版本、次版本和补丁版本获取。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
V.R.P |
|
V.R.P |
4.2.14. BOOST_COMP_IAR
IAR C/C++ 编译器。版本号可按主版本、次版本和补丁版本获取。
| 符号 | 版本 |
|---|---|
|
检测 |
|
V.R.P |
4.2.15. BOOST_COMP_IBM
IBM XL C/C++ 编译器。版本号可按主版本、次版本和补丁版本获取。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
检测 |
|
V.R.P |
|
V.R.P |
|
V.R.P |
|
V.R.P |
4.2.16. BOOST_COMP_INTEL
Intel C/C++ 编译器。版本号可按主版本、次版本和补丁版本获取。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
V.R |
|
V.R.P |
|
ℹ
|
由于 Intel 在版本号发布上的一个错误，当 __INTEL_COMPILER 为 9999 时，它被检测为版本 12.1.0。 |
4.2.20. BOOST_COMP_MWERKS
Metrowerks CodeWarrior 编译器。版本号可按主版本、次版本和补丁版本获取。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
V.R.P |
|
V.R.P >= 4.2.0 |
|
9.R.0 |
|
8.R.0 |
4.2.22. BOOST_COMP_MPW
MPW C++ 编译器。版本号可按主版本和次版本获取。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
检测 |
|
V.R.0 |
4.2.23. BOOST_COMP_NVCC
NVCC 编译器。版本号可按主版本、次版本和补丁级别获取，从 7.5 版本开始。
| 符号 | 版本 |
|---|---|
|
检测 |
|
V.R.P |
4.2.25. BOOST_COMP_PGI
Portland Group C/C++ 编译器。
| 符号 | 版本 |
|---|---|
|
检测 |
|
V.R.P |
4.2.26. BOOST_COMP_SGI
SGI MIPSpro 编译器。版本号可按主版本、次版本和补丁版本获取。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
V.R.P |
|
V.R.P |
4.2.27. BOOST_COMP_SUNPRO
Oracle Solaris Studio 编译器。版本号可按主版本、次版本和补丁版本获取。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
V.R.P |
|
V.R.P |
|
VV.RR.P |
|
VV.RR.P |
4.2.29. BOOST_COMP_MSVC
Microsoft Visual C/C++ 编译器。版本号可按主版本、次版本和补丁版本获取。
| 符号 | 版本 |
|---|---|
|
检测 |
|
V.R.P |
|
V.R.0 |
|
ℹ
|
2015 年之后的 Visual Studio 版本将不再由 Boost Predef 识别为营销版本号。取而代之的是，我们直接使用编译器版本号，即 _MSC_VER 号。 |
4.3. BOOST_LANG 语言标准宏
4.3.1. BOOST_LANG_CUDA
CUDA C/C++ 语言。如果可用，版本将检测为 VV.RR.P。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
VV.RR.P |
4.3.3. BOOST_LANG_STDC
标准 C 语言。如果可用，将根据 Epoch 日期检测标准年份为 YYYY.MM.1。
| 符号 | 版本 |
|---|---|
|
检测 |
|
V.R.P |
4.3.4. BOOST_LANG_STDCPP
标准 C++ 语言。如果可用，将根据 Epoch 日期检测标准年份为 YYYY.MM.1。由于 C++ 标准化过程的工作方式，定义的版本年份将不是人们通常熟知的标准年份。具体来说，定义的版本是：
| 检测到的版本号 | 标准年份 | C++ 标准 |
|---|---|---|
27.11.1 |
1998 |
ISO/IEC 14882:1998 |
41.3.1 |
2011 |
ISO/IEC 14882:2011 |
44.2.1 |
2014 |
ISO/IEC 14882:2014 |
47.3.1 |
2017 |
ISO/IEC 14882:2017 |
| 符号 | 版本 |
|---|---|
|
检测 |
|
YYYY.MM.1 |
4.3.5. BOOST_LANG_STDCPPCLI
标准 C++/CLI 语言。如果可用，将根据 Epoch 日期检测标准年份为 YYYY.MM.1。
| 符号 | 版本 |
|---|---|
|
检测 |
|
YYYY.MM.1 |
4.4. BOOST_LIB 库宏
4.4.1. BOOST_LIB_C_CLOUDABI
cloudlibc - CloudABI 的标准 C 库。版本号可按主版本和次版本获取。
| 符号 | 版本 |
|---|---|
|
检测 |
|
V.R.0 |
4.4.2. BOOST_LIB_C_GNU
GNU glibc 标准 C 库。版本号可按主版本和次版本获取。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
V.R.0 |
|
V.R.0 |
4.4.3. BOOST_LIB_C_UC
uClibc 标准 C 库。
| 符号 | 版本 |
|---|---|
|
检测 |
|
V.R.P |
4.4.5. BOOST_LIB_C_ZOS
z/OS libc 标准 C 库。版本号可按主版本、次版本和补丁版本获取。
| 符号 | 版本 |
|---|---|
|
检测 |
|
V.R.P |
|
V.R.P |
4.4.7. BOOST_LIB_STD_DINKUMWARE
Dinkumware 标准 C++ 库。如果可用，版本号按主版本、次版本和补丁版本获取。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
V.R.0 |
4.4.8. BOOST_LIB_STD_COMO
Comeau Computing 标准 C++ 库。版本号可按主版本获取。
| 符号 | 版本 |
|---|---|
|
检测 |
|
V.0.0 |
4.4.9. BOOST_LIB_STD_MSIPL
Modena Software Lib++ 标准 C++ 库。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
4.4.10. BOOST_LIB_STD_MSL
Metrowerks 标准 C++ 库。版本号可按主版本、次版本和补丁版本获取。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
V.R.P |
|
V.R.P |
4.4.11. BOOST_LIB_STD_RW
Roguewave 标准 C++ 库。如果可用，版本号按主版本、次版本和补丁版本获取。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
V.R.P |
4.4.12. BOOST_LIB_STD_SGI
SGI 标准 C++ 库。如果可用，版本号按主版本、次版本和补丁版本获取。
| 符号 | 版本 |
|---|---|
|
检测 |
|
V.R.P |
4.4.13. BOOST_LIB_STD_GNU
GNU libstdc++ 标准 C++ 库。版本号可按年份（自 1970 年起）、月份和日期获取。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
V.R.P |
|
V.R.P |
4.4.14. BOOST_LIB_STD_STLPORT
STLport 标准 C++ 库。版本号可按主版本、次版本和补丁版本获取。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
V.R.P |
|
V.R.P |
|
V.R.P |
4.4.16. BOOST_LIB_STD_MSVC
Microsoft 的 C++ 标准库。如果可用，版本号按主版本、次版本和补丁版本获取。补丁号是从 _MSVC_STL_UPDATE 派生的，取其最后五位数字（如下）。这意味着将 _MSVC_STL_UPDATE 值粘贴到 BOOST_VERSION_NUMBER 中将生成一个版本号，该版本号可以直接与 BOOST_LIB_STD_MSVC 进行比较。
| 符号 | 版本 |
|---|---|
|
检测 |
|
VV.R.0 |
|
00.0.0YYYMM |
4.5. BOOST_OS 操作系统宏
4.5.1. BOOST_OS_AIX
IBM AIX 操作系统。版本号可按主版本、次版本和补丁版本获取。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
4.3.0 |
|
4.1.0 |
|
3.2.0 |
|
3.0.0 |
4.5.4. BOOST_OS_BSD
BSD 操作系统。
BSD有各种分支操作系统，每个都可以单独检测。此宏检测以下变体并设置相应的版本号宏以匹配：
-
BOOST_OS_BSD_DRAGONFLYDragonFly BSD -
BOOST_OS_BSD_FREEFreeBSD -
BOOST_OS_BSD_BSDIBSDi BSD/OS -
BOOST_OS_BSD_NETNetBSD -
BOOST_OS_BSD_OPENOpenBSD
|
ℹ
|
通用 BOOST_OS_BSD 在所有情况下都设置，以表示某种形式的 BSD。如果检测到上述变体，则也会设置相应的宏。 |
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
4.2.0 |
|
4.3.0 |
|
4.4.0 |
|
V.R.0 |
4.5.5. BOOST_OS_CYGWIN
Cygwin 环境。
| 符号 | 版本 |
|---|---|
|
检测 |
|
V.R.0 |
4.5.8. BOOST_OS_IOS
iOS 操作系统。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
检测 |
|
__ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__*1000 |
4.5.11. BOOST_OS_MACOS
Mac OS 操作系统。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
10.0.0 |
|
9.0.0 |
4.5.13. BOOST_OS_QNX
QNX 操作系统。版本号可按主版本和次版本（如果可能）获取。并且版本 4 被具体检测。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
V.R.0 |
|
4.0.0 |
4.5.18. BOOST_OS_WINDOWS
Microsoft Windows 操作系统。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
4.5.22. BOOST_OS_BSD_NET
NetBSD 操作系统。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
V.R.P |
|
0.8.0 |
|
0.9.0 |
|
1.0.0 |
|
V.R.P |
4.5.23. BOOST_OS_BSD_OPEN
OpenBSD 操作系统。
| 符号 | 版本 |
|---|---|
|
检测 |
|
2.0.0 |
|
2.1.0 |
|
2.2.0 |
|
2.3.0 |
|
2.4.0 |
|
2.5.0 |
|
2.6.0 |
|
2.7.0 |
|
2.8.0 |
|
2.9.0 |
|
3.0.0 |
|
3.1.0 |
|
3.2.0 |
|
3.3.0 |
|
3.4.0 |
|
3.5.0 |
|
3.6.0 |
|
3.7.0 |
|
3.8.0 |
|
3.9.0 |
|
4.0.0 |
|
4.1.0 |
|
4.2.0 |
|
4.3.0 |
|
4.4.0 |
|
4.5.0 |
|
4.6.0 |
|
4.7.0 |
|
4.8.0 |
|
4.9.0 |
|
5.0.0 |
|
5.1.0 |
|
5.2.0 |
|
5.3.0 |
|
5.4.0 |
|
5.5.0 |
|
5.6.0 |
|
5.7.0 |
|
5.8.0 |
|
5.9.0 |
|
6.0.0 |
|
6.1.0 |
|
6.2.0 |
|
6.3.0 |
|
6.4.0 |
|
6.5.0 |
|
6.6.0 |
|
6.7.0 |
|
6.8.0 |
|
6.9.0 |
4.6. BOOST_PLAT 平台宏
4.6.5. BOOST_PLAT_MINGW
MinGW 平台，任意一种。版本号可按主版本、次版本和补丁版本获取。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
V.R.0 |
|
V.R.0 |
4.6.6. BOOST_PLAT_MINGW32
MinGW 平台。版本号可按主版本、次版本和补丁版本获取。
| 符号 | 版本 |
|---|---|
|
检测 |
|
V.R.0 |
4.6.7. BOOST_PLAT_MINGW64
MinGW-w64 平台。版本号可按主版本、次版本和补丁版本获取。
| 符号 | 版本 |
|---|---|
|
检测 |
|
V.R.0 |
4.6.8. BOOST_PLAT_WINDOWS_DESKTOP
UWP 用于 Windows 桌面开发。当平台 SDK 过旧不支持 UWP 时也可使用。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
4.6.9. BOOST_PLAT_WINDOWS_PHONE
UWP 用于 Windows Phone 开发。
| 符号 | 版本 |
|---|---|
|
检测 |
4.6.10. BOOST_PLAT_WINDOWS_RUNTIME
已弃用。
UWP 用于 Windows Phone 或 Store 开发。这与 UWP 的现有开发模型不符，且已弃用。请改用其他 `BOOST_PLAT_WINDOWS_*` 定义之一。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
4.6.11. BOOST_PLAT_WINDOWS_SERVER
UWP 用于 Windows Server 开发。
| 符号 | 版本 |
|---|---|
|
检测 |
4.6.12. BOOST_PLAT_WINDOWS_STORE
UWP 用于 Windows Store 开发。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
4.6.13. BOOST_PLAT_WINDOWS_SYSTEM
UWP 用于 Windows System 开发。
| 符号 | 版本 |
|---|---|
|
检测 |
4.6.14. BOOST_PLAT_WINDOWS_UWP
通用 Windows 平台在当前开发环境能够针对 UWP 开发时可用。
| 符号 | 版本 |
|---|---|
|
|
|
|
4.7. BOOST_HW 硬件宏
4.7.1. 使用 BOOST_HW_SIMD_* 预定义宏
SIMD 预定义宏取决于编译器选项。例如，您必须向 clang 或 gcc 添加 -msse3 选项以启用 SSE3。SIMD 预定义宏也是包容性的。这意味着如果启用了 SSE3，那么所有其他版本号较低的扩展都将隐式启用并被检测到。但是，某些扩展是 CPU 特定的，当启用更高版本时，它们可能不会被检测到或启用。
|
ℹ
|
使用 x86-64 架构时，SSE(1) 和 SSE2 默认自动启用。 |
要检查是否启用了任何 SIMD 扩展，您可以使用：
#include <boost/predef/hardware/simd.h>
#include <iostream>
int main()
{
#if defined(BOOST_HW_SIMD_AVAILABLE)
std::cout << "SIMD detected!" << std::endl;
#endif
return 0;
}编写 SIMD 特定代码时，您可能需要检查是否已检测到特定扩展。为此，您必须使用正确的架构预定义宏并进行比较。这些预定义宏的形式为 BOOST_HW_SIMD_"ARCH"（其中 "ARCH" 是 ARM、PPC 或 X86）。例如，如果您为 x86 架构编译代码，您将需要使用 BOOST_HW_SIMD_X86。其值将是该架构检测到的最新 SIMD 扩展的版本号。
要检查是否启用了扩展：
#include <boost/predef/hardware/simd.h>
#include <iostream>
int main()
{
#if BOOST_HW_SIMD_X86 >= BOOST_HW_SIMD_X86_SSE3_VERSION
std::cout << "This is SSE3!" << std::endl;
#endif
return 0;
}|
ℹ
|
_VERSION 定义将版本号映射到实际的标识符。这样，在编写比较时就更容易，而无需处理版本号。 |
要“严格”检查检测到的最新扩展：
#include <boost/predef/hardware/simd.h>
#include <iostream>
int main()
{
#if BOOST_HW_SIMD_X86 == BOOST_HW_SIMD_X86_SSE3_VERSION
std::cout << "This is SSE3 and this is the most recent enabled extension!"
<< std::endl;
#endif
return 0;
}由于预定义宏的版本系统和 SIMD 扩展宏的包容性属性，您可以轻松地检查支持的扩展范围：
#include <boost/predef/hardware/simd.h>
#include <iostream>
int main()
{
#if BOOST_HW_SIMD_X86 >= BOOST_HW_SIMD_X86_SSE2_VERSION &&\
BOOST_HW_SIMD_X86 <= BOOST_HW_SIMD_X86_SSSE3_VERSION
std::cout << "This is SSE2, SSE3 and SSSE3!" << std::endl;
#endif
return 0;
}|
ℹ
|
与 gcc 和 clang 不同，Visual Studio 不允许您精确指定要使用的 SSE 变体，仅会检测 SSE、SSE2、AVX 和 AVX2。有关更多信息，请参见 [@https://msdn.microsoft.com/en-us/library/b0084kay.aspx 此处]。 |
4.7.2. BOOST_HW_SIMD_ARM
ARM 的 SIMD 扩展（如果检测到）。版本号取决于检测到的最新扩展。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
检测 |
|
检测 |
| 符号 | 版本 |
|---|---|
|
BOOST_HW_SIMD_ARM_NEON_VERSION |
|
BOOST_HW_SIMD_ARM_NEON_VERSION |
|
BOOST_HW_SIMD_ARM_NEON_VERSION |
|
BOOST_HW_SIMD_ARM_NEON_VERSION |
4.7.3. BOOST_HW_SIMD_ARM_*_VERSION
这些定义代表 ARM SIMD 扩展版本。
|
ℹ
|
您必须将它们与预定义宏 BOOST_HW_SIMD_ARM 进行比较。= BOOST_HW_SIMD_ARM_NEON_VERSION |
NEON ARM 扩展版本号。
版本号为：1.0.0。
4.7.4. BOOST_HW_SIMD_PPC
PowerPC 的 SIMD 扩展（如果检测到）。版本号取决于检测到的最新扩展。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
检测 |
|
检测 |
| 符号 | 版本 |
|---|---|
|
BOOST_HW_SIMD_PPC_QPX_VERSION |
|
BOOST_HW_SIMD_PPC_VMX_VERSION |
|
BOOST_HW_SIMD_PPC_VMX_VERSION |
|
BOOST_HW_SIMD_PPC_VSX_VERSION |
4.7.5. BOOST_HW_SIMD_PPC_*_VERSION
这些定义代表 Power PC SIMD 扩展版本。
|
ℹ
|
您必须将它们与预定义宏 BOOST_HW_SIMD_PPC 进行比较。= BOOST_HW_SIMD_PPC_VMX_VERSION |
VMX powerpc 扩展版本号。
版本号为：1.0.0。= BOOST_HW_SIMD_PPC_VSX_VERSION
VSX powerpc 扩展版本号。
版本号为：1.1.0。= BOOST_HW_SIMD_PPC_QPX_VERSION
QPX powerpc 扩展版本号。
版本号为：2.0.0。
4.7.6. BOOST_HW_SIMD_X86
x86 的 SIMD 扩展（如果检测到）。版本号取决于检测到的最新扩展。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
|
检测 |
| 符号 | 版本 |
|---|---|
|
BOOST_HW_SIMD_X86_SSE_VERSION |
|
BOOST_HW_SIMD_X86_SSE_VERSION |
|
BOOST_HW_SIMD_X86_SSE_VERSION |
|
BOOST_HW_SIMD_X86_SSE2_VERSION |
|
BOOST_HW_SIMD_X86_SSE2_VERSION |
|
BOOST_HW_SIMD_X86_SSE2_VERSION |
|
BOOST_HW_SIMD_X86_SSE3_VERSION |
|
BOOST_HW_SIMD_X86_SSSE3_VERSION |
|
BOOST_HW_SIMD_X86_SSE4_1_VERSION |
|
BOOST_HW_SIMD_X86_SSE4_2_VERSION |
|
BOOST_HW_SIMD_X86_AVX_VERSION |
|
BOOST_HW_SIMD_X86_FMA3_VERSION |
|
BOOST_HW_SIMD_X86_AVX2_VERSION |
4.7.7. BOOST_HW_SIMD_X86_*_VERSION
这些定义代表 x86 SIMD 扩展版本。
|
ℹ
|
您必须将它们与预定义宏 BOOST_HW_SIMD_X86 进行比较。= BOOST_HW_SIMD_X86_MMX_VERSION |
MMX x86 扩展版本号。
版本号为：0.99.0。= BOOST_HW_SIMD_X86_SSE_VERSION
SSE x86 扩展版本号。
版本号为：1.0.0。= BOOST_HW_SIMD_X86_SSE2_VERSION
SSE2 x86 扩展版本号。
版本号为：2.0.0。= BOOST_HW_SIMD_X86_SSE3_VERSION
SSE3 x86 扩展版本号。
版本号为：3.0.0。= BOOST_HW_SIMD_X86_SSSE3_VERSION
SSSE3 x86 扩展版本号。
版本号为：3.1.0。= BOOST_HW_SIMD_X86_SSE4_1_VERSION
SSE4_1 x86 扩展版本号。
版本号为：4.1.0。= BOOST_HW_SIMD_X86_SSE4_2_VERSION
SSE4_2 x86 扩展版本号。
版本号为：4.2.0。= BOOST_HW_SIMD_X86_AVX_VERSION
AVX x86 扩展版本号。
版本号为：5.0.0。= BOOST_HW_SIMD_X86_FMA3_VERSION
FMA3 x86 扩展版本号。
版本号为：5.2.0。= BOOST_HW_SIMD_X86_AVX2_VERSION
AVX2 x86 扩展版本号。
版本号为：5.3.0。= BOOST_HW_SIMD_X86_MIC_VERSION
MIC (Xeon Phi) x86 扩展版本号。
版本号为：9.0.0。
4.7.8. BOOST_HW_SIMD_X86_AMD
x86 (AMD) 的 SIMD 扩展（如果检测到）。版本号取决于检测到的最新扩展。
| 符号 | 版本 |
|---|---|
|
检测 |
|
检测 |
|
检测 |
|
检测 |
| 符号 | 版本 |
|---|---|
|
BOOST_HW_SIMD_X86_SSE4A_VERSION |
|
BOOST_HW_SIMD_X86_FMA4_VERSION |
|
BOOST_HW_SIMD_X86_XOP_VERSION |
|
BOOST_HW_SIMD_X86 |
|
ℹ
|
此预定义宏包含所有其他 x86 SIMD 扩展，并且还具有其他更具体的扩展（FMA4、XOP、SSE4a）。您应该使用此预定义宏而不是 BOOST_HW_SIMD_X86 来测试是否检测到这些特定扩展。 |
4.7.9. BOOST_HW_SIMD_X86_AMD_*_VERSION
这些定义代表 x86 (AMD 特定) SIMD 扩展版本。
|
ℹ
|
您必须将它们与预定义宏 BOOST_HW_SIMD_X86_AMD 进行比较。= BOOST_HW_SIMD_X86_AMD_SSE4A_VERSION |
SSE4A x86 扩展（AMD 特定）。
版本号为：4.0.0。= BOOST_HW_SIMD_X86_AMD_FMA4_VERSION
FMA4 x86 扩展（AMD 特定）。
版本号为：5.1.0。= BOOST_HW_SIMD_X86_AMD_XOP_VERSION
XOP x86 扩展（AMD 特定）。
版本号为：5.1.1。
4.8. 其他宏
4.8.1. BOOST_ENDIAN_*
检测字节序内存顺序。此头文件中定义了四个宏，用于定义各种通常可能的字节序内存顺序：
-
BOOST_ENDIAN_BIG_BYTE，字节交换大端。 -
BOOST_ENDIAN_BIG_WORD，字交换大端。 -
BOOST_ENDIAN_LITTLE_BYTE，字节交换小端。 -
BOOST_ENDIAN_LITTLE_WORD，字交换小端。
检测是保守的，因为它只识别它确切知道的字节序。特别是双端字节序未被指示，因为它无法从操作系统提供的头文件以外的任何东西中实际确定字节序。并且当前已知的头文件并未定义程序化双端字节序是可用的。
此实现是对各种公开可用的信息和获取知识的汇编：
-
“预定义编译器宏”的不可或缺的文档 Endianness。
-
Wikipedia 计算机架构页面中提供的各种字节序规范。
-
定义字节序的头文件的通用可用搜索。
4.8.2. BOOST_ARCH_WORD_BITS
检测当前架构的原生字大小（以位为单位）。有两种类型的宏用于此检测：
-
BOOST_ARCH_WORD_BITS，给出字大小的位数（16、32、64）。 -
BOOST_ARCH_WORD_BITS_16、BOOST_ARCH_WORD_BITS_32和BOOST_ARCH_WORD_BITS_64，表示检测到给定字大小时。
它们允许进行单次检查和在代码中直接使用大小。
|
ℹ
|
字大小是手动确定在每个架构上的。因此，使用 wordsize.h 头文件也将包含所有架构头文件。 |
4.8.3. BOOST_PREDEF_WORKAROUND
BOOST_PREDEF_WORKAROUND(symbol,comp,major,minor,patch)用法
#if BOOST_PREDEF_WORKAROUND(BOOST_COMP_CLANG,<,3,0,0)
// Workaround for old clang compilers..
#endif定义一个与两个版本号的比较，该比较取决于 BOOST_STRICT_CONFIG 的定义。当定义 BOOST_STRICT_CONFIG 时，这将展开为一个可转换为 false 的值。这将导致禁用由 BOOST_PREDEF_WORKAROUND 条件保护的所有代码。当 BOOST_STRICT_CONFIG 未定义时，它将展开以测试给定的 symbol 版本值，使用 comp 比较 BOOST_VERSION_NUMBER(major,minor,patch)。
4.8.4. BOOST_PREDEF_TESTED_AT
BOOST_PREDEF_TESTED_AT(symbol,major,minor,patch)用法
#if BOOST_PREDEF_TESTED_AT(BOOST_COMP_CLANG,3,5,0)
// Needed for clang, and last checked for 3.5.0.
#endif定义一个与两个版本号的比较，该比较取决于 BOOST_STRICT_CONFIG 和 BOOST_DETECT_OUTDATED_WORKAROUNDS 的定义。当定义 BOOST_STRICT_CONFIG 时，这将展开为一个可转换为 false 的值。这将导致禁用由 BOOST_PREDEF_TESTED_AT 条件保护的所有代码。当 BOOST_STRICT_CONFIG 未定义时，它将展开为：
-
当
BOOST_DETECT_OUTDATED_WORKAROUNDS未定义时，一个可转换为true的值。 -
当
BOOST_PREDEF_WORKAROUND(symbol, ⇐, major, minor, patch)的展开为true且BOOST_DETECT_OUTDATED_WORKAROUNDS已定义时，一个可转换为true的值。 -
当
BOOST_PREDEF_WORKAROUND(symbol, >, major, minor, patch)的展开为true且BOOST_DETECT_OUTDATED_WORKAROUNDS已定义时，导致编译错误。
4.9. 版本定义宏
4.9.1. BOOST_VERSION_NUMBER
BOOST_VERSION_NUMBER(major,minor,patch)定义标准的版本号，具有以下特性：
-
十进制基数的整数，范围在 [0,1000000000) 之间。该数字范围设计用于容纳 (2,2,5) 的三元组。这适合 32 位值。
-
major号可以包含在 [0,99] 范围内。 -
minor号可以包含在 [0,99] 范围内。 -
patch号可以包含在 [0,99999] 范围内。 -
值可以以任何基数指定。因为定义的值是一个常量表达式。
-
值可以直接用于预处理器和编译器表达式，以与其他类似定义的宏进行比较。
-
实现强制执行主版本、次版本和补丁版本的各个范围。超出范围的值会被截断（模运算）。
BOOST_VERSION_NUMBER_MAJOR(N), BOOST_VERSION_NUMBER_MINOR(N), BOOST_VERSION_NUMBER_PATCH(N)这些宏从格式正确的版本号中提取主版本、次版本和补丁部分，生成一个范围在 [0,99] 或 [0,99999]（分别用于主/次版本号或补丁号）的预处理器表达式。
4.9.2. BOOST_PREDEF_MAKE_.. 宏
这组宏用于分解常见的供应商版本号宏，这些宏由版本、修订版和补丁数字组成。命名约定表明：
-
指定版本号的基数。“BOOST_PREDEF_MAKE_0X”用于十六进制数字，“BOOST_PREDEF_MAKE_10”用于十进制数字。
-
供应商版本号的格式。“V”表示版本数字，“R”表示修订数字，“P”表示补丁数字，“0”表示被忽略的数字。
宏是：
-
BOOST_PREDEF_MAKE_0X_VRP(V) -
BOOST_PREDEF_MAKE_0X_VVRP(V) -
BOOST_PREDEF_MAKE_0X_VRPP(V) -
BOOST_PREDEF_MAKE_0X_VVRR(V) -
BOOST_PREDEF_MAKE_0X_VRRPPPP(V) -
BOOST_PREDEF_MAKE_0X_VVRRP(V) -
BOOST_PREDEF_MAKE_0X_VRRPP000(V) -
BOOST_PREDEF_MAKE_0X_VVRRPP(V) -
BOOST_PREDEF_MAKE_10_VPPP(V) -
BOOST_PREDEF_MAKE_10_VVPPP(V) -
BOOST_PREDEF_MAKE_10_VR0(V) -
BOOST_PREDEF_MAKE_10_VRP(V) -
BOOST_PREDEF_MAKE_10_VRP000(V) -
BOOST_PREDEF_MAKE_10_VRPPPP(V) -
BOOST_PREDEF_MAKE_10_VRPP(V) -
BOOST_PREDEF_MAKE_10_VRR(V) -
BOOST_PREDEF_MAKE_10_VRRPP(V) -
BOOST_PREDEF_MAKE_10_VRR000(V) -
BOOST_PREDEF_MAKE_10_VV00(V) -
BOOST_PREDEF_MAKE_10_VVR_0PPPPP(V, P)，第二个参数指定一个年份-月份补丁级别，第一个数字被丢弃 -
BOOST_PREDEF_MAKE_10_VVRR(V) -
BOOST_PREDEF_MAKE_10_VVRRP(V) -
BOOST_PREDEF_MAKE_10_VVRRPP(V) -
BOOST_PREDEF_MAKE_10_VVRRPPP(V) -
BOOST_PREDEF_MAKE_10_VVRR0PP00(V) -
BOOST_PREDEF_MAKE_10_VVRR0PPPP(V) -
BOOST_PREDEF_MAKE_10_VVRR00PP00(V)
5. 检查工具
predef_check 工具提供了一个设施，用于构建一个程序，该程序将根据其构建时检测到的定义来检查给定的一组表达式。
5.1. predef_check 程序
尽管只有一个 predef_check 程序，但对于 Predef 检测到的每种语言都有变体，以匹配源文件的约定。对于所有这些变体，都通过一个表达式参数列表来调用。表达式将在特定的 predef_check 程序的上下文中进行评估，如果它们全部为真，则返回零 (0)。否则，将返回第一个假表达式的索引。
表达式语法很简单
predef-definition [ relational-operator version-value ]predef-definition 可以是 Predef 的任何定义。例如 BOOST_COMP_GCC。
relational-operator 可以是以下任何一个：>, <, >=, ⇐, == 和 !=。
version-number 可以是一个完整或部分的版本三元组值。如果是一个部分版本三元组，它会用零来补全。也就是说，x.y 等同于 x.y.0，而 x 等同于 x.0.0。
relations-operator 和 version-number 可以省略。在这种情况下，它等同于
predef-definition > 0.0.05.2. 与 Boost.Build 一起使用
您可以直接从 Boost Build 中使用 predef_check 程序来配置目标需求。这对于根据 Predef 中可用的详细版本信息控制项目中要构建的内容非常有用。基本用法很简单
import path-to-predef-src/tools/check/predef
: check require
: predef-check predef-require ;
exe my_windows_program : windows_source.cpp
: [ predef-require "BOOST_OS_WINDOWS" ] ;这个简单的用例将跳过构建 my_windows_program，除非正在为 Windows 构建。与直接的 predef_check 一样，您可以使用关系比较来传递多个表达式。例如
import path-to-predef-src/tools/check/predef
: check require
: predef-check predef-require ;
lib my_special_lib : source.cpp
: [ predef-require "BOOST_OS_WINDOWS != 0" "BOOST_OS_VMS != 0"] ;在这种情况下，my_special_lib 仅在操作系统不是 Windows 或 VMS 时构建。requires 规则是 check 规则的一个特例。并且是基于它定义的
rule require ( expressions + : language ? )
{
return [ check $(expressions) : $(language) : : <build>no ] ;
}表达式还可以使用显式的“and”、“or”逻辑运算符进行更复杂的检查
import path-to-predef-src/tools/check/predef
: check require
: predef-check predef-require ;
lib my_special_lib : source.cpp
: [ predef-require "BOOST_OS_WINDOWS" or "BOOST_OS_VMS"] ;您可以使用 check 规则来获得更多控制，并实现构建内容控制以外的其他功能。check 规则的定义是
rule check ( expressions + : language ? : true-properties * : false-properties * )当作为 Boost Build 目标的依赖项调用时，如果所有 expressions 都求值为真，则此规则会将 true-properties 添加到目标。否则，将把 false-properties 添加为依赖项。例如，您可以使用它来启用或禁用程序中的功能
import path-to-predef-src/tools/check/predef
: check require
: predef-check predef-require ;
exe my_special_exe : source.cpp
: [ predef-check "BOOST_OS_WINDOWS == 0"
: : <define>ENABLE_WMF=0
: <define>ENABLE_WMF=1 ] ;对于 check 和 require，language 参数控制使用哪个版本的 predef_check 程序来检查表达式。它默认为 "c++"，但可以是以下任何一种："c"、"cpp"、"objc" 和 "objcpp"。
6. 历史记录
6.1. 1.15.1
-
防止使用过时的
predef/check/predef.jamB2 模块。而是使用当前的predef/tools/check/predef.jam模块。 -
修复
architecture工具检查规则返回ppc而不是power。
6.5. 1.13
-
添加
ARCH_PPC_64预定义。 -
修复
ARCH_WORD_BITS*重定义警告/错误。 -
添加
ARCH_E2K，Elbrus 2000，来自 Konstantin Ivlev 的架构。 -
修复无法处理超过 10.x 版本的新 C++ 版本。
6.6. 1.12
-
切换到在 OpenBSD 上使用 endian.h 头文件。（Brad Smith）
-
修复无法处理高于 9 的 stdcxx 的新版本。
-
修复直接包含子 BSD OS 头文件导致重定义警告。
-
添加所有头文件直接包含的 CI 测试。
-
在 FreeBSD 上添加 clang 和 gcc 的 CI 测试。
-
添加
WORD_BITS预定义集来检测架构字长。最初的实现受 Mikhail Komarov 的提交启发。 -
添加 Cygwin 32 和 64 的 CI 测试。
6.7. 1.11
-
添加
BOOST_ARCH_RISCV。（来自 Andreas Schwab） -
添加 RISC-V 字节序检测。（来自 Thomas Petazzoni）
-
将文档转换为 AsciiDoctor 格式。
-
记录 C++ 标准的正确版本。
-
修复在 WinCE 中构建时由于头文件不可用而导致的编译错误。
-
删除已弃用的
BOOST_OS_ANDROID。 -
修复 Wine 的编译。（Kevin Puetz）
6.8. 1.10
-
修复从主 BSD 头文件错误包含子 BSD OS 头文件。
-
修复使用已弃用的
TARGET_IPHONE_SIMULATOR而不是较新的TARGET_OS_SIMULATOR。 -
添加
BOOST_PLAT_ANDROID以解决 Linux 和 Android OS 预定义之间的冲突。BOOST_OS_ANDROID预定义现已弃用，将在未来的版本中删除。 -
添加支持将 Predef 作为 CMake 项目使用。
-
添加支持将 Predef 作为独立的 B2 项目使用。
6.9. 1.9
-
修复
BOOST_COMP_NVCC*预定义。（来自 Benjamin Worpitz） -
为 Cygwin OS 预定义添加特定的版本信息。（来自 James E. King III）
6.10. 1.8
-
添加对 __ARM_ARCH 宏的支持。（来自 Tim Blechmann）
-
添加 PTX 架构的检测。（来自 Benjamin Worpitz）
-
添加 nvcc 编译器检测。（来自 Benjamin Worpitz）
-
添加对检测 CUDA 的支持。（来自 Benjamin Worpitz）
-
删除对已过时的 BOOST_ARCH_AMD64 的引用。（来自 Peter Kolbus）
6.11. 1.7
-
修复 BOOST_ARCH_PARISK/BOOST_ARCH_PARISC 拼写错误。
-
改进 Windows 通用平台检测。（来自 James E. King, III）
-
添加 CloudABI 和 cloudlibc 的检测。（来自 James E. King, III）
6.12. 1.6
-
将 Intel C/C++ 版本 9999 的检测修复为 12.1.0。
-
添加
BOOST_PREDEF_WORKAROUND和BOOST_PREDEF_TESTED_AT宏，用于缺陷的规避和检测。 -
添加 ARM64 MSVC SIMD 检测。（来自 Minmin Gong）
-
添加 iOS 模拟器与设备之间的检测，作为平台选择。（来自 Ruslan Baratov）
-
修复 MinGW 不正确的头文件保护。（来自 Ruslan Baratov）
6.13. 1.5
-
修复 Intel C/C++ 编译器版本规范。
-
添加
BOOST_VERSION_NUMBER_MAJOR、BOOST_VERSION_NUMBER_MINOR、BOOST_VERSION_NUMBER_PATCH宏，用于从有效版本号中提取组件。 -
更改 VS 版本编号。VS2015 之后的版本将使用编译器版本而不是变化的 المنتج 版本。
6.15. 1.4
-
添加 SIMD 硬件的检测。增加了
BOOST_HW_*类别。（来自 Charly Chevalier） -
添加仅编译版本的检查工具，以解决交叉编译用例。并将 BBv2 检查支持更改为使用仅编译检查。
-
修复测试警告。
-
修复 Windows 平台上
AVAILABLE宏的拼写错误。（来自 Vemund Handeland）
6.16. 1.3
-
修复
predef_check功能的许多问题。 -
更新 SunPro 检测以适应 Oracle 的最新编译器版本。
-
添加 Travis-CI 和 Appveyor 测试。
-
在 Boost Build 端为
predef_check表达式添加and和or逻辑运算符。 -
修复
BOOST_ARCH_PARISC的正确拼写名称（来自 Graham Hanson）。 -
修复
MAKE_YYYYM宏以正确限制月份（来自 rick68）。
8. 致谢
这个库的全面性离不开 indispensable resource Pre-defined C/C++ Compiler Macros Project 的存在。它过去是，现在仍然是构成这个库的定义的主要来源。感谢 Bjorn Reese 和所有为该资源做出贡献的志愿者。
如果不是 Boost 社区在八年时间里提供了宝贵的反馈，使之打磨成可用形式，这个库将是一团糟。特别是我想感谢：Mathias Gaunard、Robert Stewart、Joël Lamotte、Lars Viklund、Nathan Ridge、Artyom Beilis、Joshua Boyce、Gottlob Frege、Thomas Heller、Edward Diener、Dave Abrahams、Iain Denniston、Dan Price、Ioannis Papadopoulos 和 Robert Ramey。感谢 Joel Falcou 管理了这个库的评审。
版权声明
根据 Boost Software License, Version 1.0 分发。（请参阅随附的 LICENSE_1_0.txt 文件或访问 https://boost.ac.cn/LICENSE_1_0.txt）
Copyright 2005-2021 René Ferdinand Rivera Morell; Copyright 2015 Charly Chevalier; Copyright 2015 Joel Falcou