# Boost.Predef

René Ferdinand Rivera Morell

## 1. Introduction

This library defines a set of compiler, architecture, operating system, library, and other version numbers from the information it can gather of C, C++, Objective C, and Objective C++ predefined macros or those defined in generally available headers. The idea for this library grew out of a proposal to extend the Boost Config library to provide more, and consistent, information than the feature definitions it supports. What follows is an edited version of that brief proposal.

### 1.1. Proposal

The idea is to define a set of macros to identify compilers and consistently represent their version. This includes:

- A unique BOOST_VERSION_NUMBER(major,minor,patch) macro to specify version numbers (unfortunately, the name BOOST_VERSION is already taken to designate the version number of boost itself).

- A compiler identification macro, suitable for use in `#if`/`#elif` directives, for each of the supported compilers. All macros would be defined, regardless of the compiler. The one macro corresponding to the compiler being used would be defined, in terms of BOOST_VERSION_NUMBER, to carry the exact compiler version. All other macros would expand to an expression evaluating to false (for instance, the token 0) to indicate that the corresponding compiler is not present.

- "Null values" could be set, for all macros, in boost/config/select_compiler.hpp; then, for each compiler the corresponding identification macro would be #undef and re-#defined in the corresponding boost/compiler/(cc).hpp; however in the context of the Boost.Config infrastructure using a "prefix" header (to be introduced) or boost/config/suffix.hpp is a better solution.

### 1.2. Current Library

The current Predef library is now, both an independent library, and expanded in scope. It includes detection and definition of architectures, compilers, languages, libraries, operating systems, and endianness. The key benefits are:

- Version numbers that are always defined so that one doesn’t have to guard with `#ifdef`.

- Guard macros that can be used for `#ifdef` checks.

- All possible definitions are included with the single `#include <boost/predef.h>` so that it’s friendly to pre-compiled header usage.

- Specific definitions can be included, ex. `#include <boost/predef/os/windows.h>` for single checks.

- Predefs can be directly used in both preprocessor and compiler expressions for comparison to other similarly defined values.

- The headers are usable from multiple languages, that support the C preprocessor. In particular C++, C, Objective C, and Objective C++.

### 1.3. Design choices

An important design choice concerns how to represent compiler versions by means of a single integer number suitable for use in preprocessing directives. Let’s do some calculation. The "basic" signed type for preprocessing constant-expressions is long in C90 (and C++, as of 2006) and intmax_t in C99. The type long shall at least be able to represent the number `+2 147 483 647`. This means the most significant digit can only be 0, 1 or 2; and if we want all decimal digits to be able to vary between 0 and 9, the largest range we can consider is `[0, 999 999 999\`]. Distributing evenly, this means 3 decimal digits for each version number part.

So we can:

1. use an uneven distribution or

2. use more bits (a larger type) or

3. use 3/3/3 and have the particular compiler/platform/stdlib deal with setting the numbers within the 3-digit range.

It appears relatively safe to go for the first option and set it at 2/2/5. That covers CodeWarrior and others, which are up to and past 10 for the major number. Some compilers use the build number in lieu of the patch one; five digits (which is already reached by VC++ 8) seems a reasonable limit even in this case.

ℹ | A 2/2/6 scheme would allow for bigger patch/build numbers at the cost, for instance, of limiting the major version number to 20 (or, with further constraints, to 21).

It might reassure the reader that this decision is actually encoded in one place in the code; the definition of `BOOST_VERSION_NUMBER`.

### 1.4. Future work

Even though the basics of this library are done, there is much work that can be done:

- Right now we limit the detection of libraries to known built-in predefined macros, and to guaranteed to exist system and library headers. It might be interesting to add something like auto-configuration predefs. This way we can add definitions for user specific libraries and features.

- Along with the above, it might be good to add some user control as to which headers are included with the top-level header. Although in the current form of the library this is less of an issue as one can include the specific headers one needs.

- Additionally, even if there is no auto-configure style option.. It would be good to add optionally included headers so that user can get consistent version number definitions for libraries they use.

- And obviously there’s lots of work to do in reformulating the existing Boost libraries to use the Predef library.

- And there’s the continuing work of adding definitions for present and future compilers, platforms, architectures, languages, and libraries.

## 2. Using the predefs

To use the automatically defined predefs one needs to only include the single top-level header:

    #include <boost/predef.h>

This defines [*all] the version macros known to the library. For each macro it will be defined to either a`zero`valued expression for when the particular item is not detected, and to a`positive`value if it is detected. The predef macros fall onto five categories each with macros of a particular prefix:

- `BOOST_ARCH_` for system/CPU architecture one is compiling for.

- `BOOST_COMP_` for the compiler one is using.

- `BOOST_LANG_` for language standards one is compiling against.

- `BOOST_LIB_C_` and `BOOST_LIB_STD_` for the C and C++ standard library in use.

- `BOOST_OS_` for the operating system we are compiling to.

- `BOOST_PLAT_` for platforms on top of operating system or compilers.

- `BOOST_ENDIAN_` for endianness of the os and architecture combination.

- `BOOST_HW_` for hardware specific features.

- `BOOST_HW_SIMD` for SIMD (Single Instruction Multiple Data) detection.

ℹ | The detected definitions are for the configuration one is targeting during the compile. In particular in a cross-compile this means the target system, and not the host system.

One uses the individual definitions to compare against specific versions by comparing against the `BOOST_VERSION_NUMBER` macro. For example, to make a choice based on the version of the GCC C++ compiler one would:

    #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;
    }

As you might notice above the `else` clause also covers the case where the particular compiler is not detected. But one can make the test also test for the detection. All predef definitions are defined as a zero (0) expression when not detected. Hence one could use the detection with a natural single condition. For example:

    #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;
    }

And since the predef’s are preprocessor definitions the same is possible from the preprocessor:

    #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;
    }

In addition, for each version macro defined there is an `*_AVAILABLE` macro defined only when the particular aspect is detected. I.e. a definition equivalent to:

    #if BOOST_PREDEF_ABC
      #define BOOST_PREDEF_ABC_AVAILABLE
    #endif

Also for each aspect there is a macro defined with a descriptive name of what the detection is.

### 2.1. The `*_EMULATED` macros

Predef definitions are guaranteed to be uniquely detected within one category. But there are contexts under which multiple underlying detections are possible. The well known example of this is detection of GCC and MSVC compilers which are commonly emulated by other compilers by defining the same base macros. To account for this detection headers are allowed to define `*_EMULATED` predefs when this situation is detected. The emulated predefs will be set to the version number of the detection instead of the regular predef macro for that detection. For example MSVC will set `BOOST_COMP_MSVC_EMULATED` but not set `BOOST_COMP_MSVC`, and it will also set `BOOST_COMP_MSVC_AVAILABLE`.

### 2.2. Using the `BOOST_VERSION_NUMBER` macro

All the predefs are defined to be a use of the `BOOST_VERSION_NUMBER` macro. The macro takes individual major, minor, and patch value expressions:

    #define BOOST_VERSION_NUMBER( major, minor, patch ) ...

The arguments are:

1. Major version number, as a constant value expression in the range [0,99].

2. Minor version number, as a constant value expression in the range [0,99].

3. Patch-level version number, as a constant value expression in the range [0,99999].

The ranges for each are "enforced" by the use of a modulo ("%"), i.e. truncation, as opposed to a clamp. And hence this means that the limits are enforced only enough to keep from having out-of-range problems. But not enough to prevent other kinds of problems. Like exceeding the range and getting false detections, or non-detections. It is up to the individual predefs to ensure correct usage beyond the range guarantee.

The values for the arguments can be any preprocessor valid constant value expression. Only constant value arithmetic is used in the definition of the `BOOST_VERSION_NUMBER` macro and in any of the other predef macros. This means that any allowed base is possible, i.e. binary, octal, decimal, and hexadecimal. For example:

    #define MY_APPLICATION_VERSION_NUMBER BOOST_VERSION_NUMBER(2,0xA,015)

Is equivalent to:

    #define MY_APPLICATION_VERSION_NUMBER BOOST_VERSION_NUMBER(2,10,13)

## 3. Adding new predefs

We know that a library like this one will be an eternal work-in-progress. And as such we expect, and look forward to, others contributing corrections and additions to the predefs. With that in mind we need to keep a consistent way of defining the new predefs. Hence all current, and future, predefs follow the same structure and requirements.

### 3.1. Requirements of the header

All predefs need to follow a set of requirements:

- The headers must use the Boost Software License.

- The predef must, by default, be defined as `BOOST_VERSION_NUMBER_NOT_AVAILABLE`.

- The predef must be redefined to a non-zero value once detected.

- The predef must, by default, be defined to `BOOST_VERSION_NUMBER_AVAILABLE` when the predef is detected.

- If possible, the predef will be defined as the version number detected.

- The predef must define `*_AVAILABLE` macros as needed.

- The predef must define a symbolic constant string name macro.

- The predef must declare itself, after being defined, for the testing system.

- The predef must guarantee that it is the only one defined as detected per category.

- But a predef can define `*_EMULATED` macros to indicate that it was previously detected by another header and is being "emulated" by the system. Note that the `*_AVAILABLE` macros must still be defined in this situation.

And there are some extra guidelines that predef headers should follow:

- The detection should avoid including extra headers that might otherwise not be included by default.

- If the detection must include a header, prefer guarding it within the detection if possible.

- If the detection must include headers unconditionally, and has a choice of headers to include, prefer the ones with the least impact. I.e. include the one with the minimal set of definitions and other dependencies.

### 3.2. Structure of the header

For general consistency it’s suggested that new predef headers follow the structure below, as current predef headers do. First we have the copyright and license statement, followed by the include guard:

    /*
    Copyright Jane Doe YYYY
    Distributed under the Boost Software License, Version 1.0.
    (See accompanying file LICENSE_1_0.txt or copy at
    http://www.boost.org/LICENSE_1_0.txt)
    */

    #ifndef BOOST_PREDEF_category_tag_H
    #define BOOST_PREDEF_category_tag_H

If the detection depends on the detection of another predef you should include those headers here.

    #include <boost/predef/CATEGORY_TAG/DEPENDENCY.h>

Depending on how you are defining the predef you will at minimum have to include the `version_number.h` header. But you might also want to include the `make.h` header for the version number decomposing utility macros:

    #include <boost/predef/version_number.h>
    #include <boost/predef/make.h>

The Predef library uses Asciidoctor for documentation and for the individual predefs to appear in the reference section we add in-code documentation followed by the zero-value default definition of the predef macro. We strongly recommend this particular placement of the documentation and default definition because some development environments automatically interpret this and provide in-line help for the macro. In particular this works for the popular Eclipse IDE:

    /* tag::reference[]

    = `BOOST_category_tag`

    Documentation about what is detected.

    */

    #define BOOST_category_tag BOOST_VERSION_NUMBER_NOT_AVAILABLE

Next is the detection and definition of the particular predef. The structure for this is to do a single overall check (`condition_a`) and place further version detection inside this. The first action inside the overall check is to “#undef BOOST_category_tag” which removes the zero-value default. The rest is up to the you how to do the checks for defining the version. But at minimum it must “#define BOOST_category_tag BOOST_VERSION_NUMBER_AVAILABLE” as the fallback to minimally indicate that the predef was detected:

    #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

We also need to provide the `*_AVAILABLE` versions of the predef.

    #if BOOST_category_tag
    #   define BOOST_category_tag_AVAILABLE
    #endif

And for convenience we also want to provide a `*_NAME` macro:

    #define BOOST_category_tag_NAME "Name"

We close out the include guard at this point. We do whis before the test declaration as the testing system includes the headers multiple times to generate the needed testing code.

    #endif

The testing of the predef macros is automated to generate checks for all the defined predefs, whether detected or not. To do this we need to declare the predef to the test system. This declaration is empty for regular use. And during the test programs they expand out specially to create informational output:

    #include <boost/predef/detail/test.h>
    BOOST_PREDEF_DECLARE_TEST(BOOST_category_tag,BOOST_category_tag_NAME)

### 3.3. Adding exclusive predefs

For headers of predefs that need to be mutually exclusive in the detection we need to add checks and definitions to detect when the predef is detected by multiple headers.

Internally compiler, operating system, and platforms define `BOOST_PREDEF_DETAIL_COMP_DETECTED`, `BOOST_PREDEF_DEFAIL_OS_DETECTED`, and `BOOST_PREDEF_DETAIL_PLAT_DETECTED` respectively when the predef is first detected. This is used to guard against multiple definition of the detection in later included headers. In those cases the detection would instead be written as:

    #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

And we also include a header that defines the `*_DETECTED` macro when we have the detection:

    #if BOOST_category_tag
    #   define BOOST_category_tag_AVAILABLE
    #   include <boost/predef/detail/CATEGORY_detected.h>
    #endif

Everything else about the header is the same as the basic detection header.

### 3.4. Adding an exclusive but emulated predef

Because compilers are frequently emulated by other compilers we both want to have exclusive detection of the compiler and also provide information that we detected the emulation of the compiler. To accomplish this we define a local `*_DETECTION` macro for the compiler detection. And conditionally define either the base compiler predef `BOOST_COMP_compiler` or the alternate `BOOST_COMP_compiler_EMULATED` predef.

The initial detection would look like:

    #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

And then we can conditionally define the base or emulated predefs:

    #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>
    #endif

### 3.5. Using utility pattern macros

By including:

    #include <boost/predef/make.h>

One will get a set of utility macros to decompose common version macros as defined by compilers. For example the EDG compiler uses a simple 3-digit version macro (M,N,P). It can be decomposed and defined as:

    #define BOOST_COMP_EDG BOOST_PREDEF_MAKE_N_N_N(__EDG_VERSION__)

The decomposition macros are split into three types: decimal decomposition, hexadecimal decomposition, and date decomposition. They follow the format of using "N" for decimal, "F" for hexadecimal, and "Y", "M", "D" for dates.

## 4. Reference

### 4.1. `BOOST_ARCH` architecture macros

#### 4.1.1. `BOOST_ARCH_ALPHA`

DEC Alpha architecture.

Symbol | Version
--- | ---
`__alpha__` | detection
`__alpha` | detection
`_M_ALPHA` | detection
`__alpha_ev4__` | 4.0.0
`__alpha_ev5__` | 5.0.0
`__alpha_ev6__` | 6.0.0

#### 4.1.2. `BOOST_ARCH_ARM`

ARM architecture.

Symbol | Version
--- | ---
`__ARM_ARCH` | detection
`__TARGET_ARCH_ARM` | detection
`__TARGET_ARCH_THUMB` | detection
`_M_ARM` | detection
`__arm__` | detection
`__arm64` | detection
`__thumb__` | detection
`_M_ARM64` | detection
`__aarch64__` | detection
`__AARCH64EL__` | detection
`__ARM_ARCH_7__` | detection
`__ARM_ARCH_7A__` | detection
`__ARM_ARCH_7R__` | detection
`__ARM_ARCH_7M__` | detection
`__ARM_ARCH_6K__` | detection
`__ARM_ARCH_6Z__` | detection
`__ARM_ARCH_6KZ__` | detection
`__ARM_ARCH_6T2__` | detection
`__ARM_ARCH_5TE__` | detection
`__ARM_ARCH_5TEJ__` | detection
`__ARM_ARCH_4T__` | detection
`__ARM_ARCH_4__` | detection
`__ARM_ARCH` | V.0.0
`__TARGET_ARCH_ARM` | V.0.0
`__TARGET_ARCH_THUMB` | V.0.0
`_M_ARM` | V.0.0
`__arm64` | 8.0.0
`_M_ARM64` | 8.0.0
`__aarch64__` | 8.0.0
`__AARCH64EL__` | 8.0.0
`__ARM_ARCH_7__` | 7.0.0
`__ARM_ARCH_7A__` | 7.0.0
`__ARM_ARCH_7R__` | 7.0.0
`__ARM_ARCH_7M__` | 7.0.0
`__ARM_ARCH_6K__` | 6.0.0
`__ARM_ARCH_6Z__` | 6.0.0
`__ARM_ARCH_6KZ__` | 6.0.0
`__ARM_ARCH_6T2__` | 6.0.0
`__ARM_ARCH_5TE__` | 5.0.0
`__ARM_ARCH_5TEJ__` | 5.0.0
`__ARM_ARCH_4T__` | 4.0.0
`__ARM_ARCH_4__` | 4.0.0

#### 4.1.3. `BOOST_ARCH_BLACKFIN`

Blackfin Processors from Analog Devices.

Symbol | Version
--- | ---
`__bfin__` | detection
`__BFIN__` | detection
`bfin` | detection
`BFIN` | detection

#### 4.1.4. `BOOST_ARCH_CONVEX`

Convex Computer architecture.

Symbol | Version
--- | ---
`__convex__` | detection
`__convex_c1__` | 1.0.0
`__convex_c2__` | 2.0.0
`__convex_c32__` | 3.2.0
`__convex_c34__` | 3.4.0
`__convex_c38__` | 3.8.0

#### 4.1.5. `BOOST_ARCH_E2K`

E2K architecture.

Symbol | Version
--- | ---
`__e2k__` | detection
`__e2k__` | V.0.0

#### 4.1.6. `BOOST_ARCH_IA64`

Intel Itanium 64 architecture.

Symbol | Version
--- | ---
`__ia64__` | detection
`_IA64` | detection
`__IA64__` | detection
`__ia64` | detection
`_M_IA64` | detection
`__itanium__` | detection

#### 4.1.7. `BOOST_ARCH_M68K`

Motorola 68k architecture.

Symbol | Version
--- | ---
`__m68k__` | detection
`M68000` | detection
`__mc68060__` | 6.0.0
`mc68060` | 6.0.0
`__mc68060` | 6.0.0
`__mc68040__` | 4.0.0
`mc68040` | 4.0.0
`__mc68040` | 4.0.0
`__mc68030__` | 3.0.0
`mc68030` | 3.0.0
`__mc68030` | 3.0.0
`__mc68020__` | 2.0.0
`mc68020` | 2.0.0
`__mc68020` | 2.0.0
`__mc68010__` | 1.0.0
`mc68010` | 1.0.0
`__mc68010` | 1.0.0
`__mc68000__` | 0.0.1
`mc68000` | 0.0.1
`__mc68000` | 0.0.1

#### 4.1.8. `BOOST_ARCH_MIPS`

MIPS architecture.

Symbol | Version
--- | ---
`__mips__` | detection
`__mips` | detection
`__MIPS__` | detection
`__mips` | V.0.0
`_MIPS_ISA_MIPS1` | 1.0.0
`_R3000` | 1.0.0
`_MIPS_ISA_MIPS2` | 2.0.0
`__MIPS_ISA2__` | 2.0.0
`_R4000` | 2.0.0
`_MIPS_ISA_MIPS3` | 3.0.0
`__MIPS_ISA3__` | 3.0.0
`_MIPS_ISA_MIPS4` | 4.0.0
`__MIPS_ISA4__` | 4.0.0

#### 4.1.9. `BOOST_ARCH_PARISC`

HP/PA RISC architecture.

Symbol | Version
--- | ---
`__hppa__` | detection
`__hppa` | detection
`__HPPA__` | detection
`_PA_RISC1_0` | 1.0.0
`_PA_RISC1_1` | 1.1.0
`__HPPA11__` | 1.1.0
`__PA7100__` | 1.1.0
`_PA_RISC2_0` | 2.0.0
`__RISC2_0__` | 2.0.0
`__HPPA20__` | 2.0.0
`__PA8000__` | 2.0.0

#### 4.1.10. `BOOST_ARCH_PPC`

PowerPC architecture.

Symbol | Version
--- | ---
`__powerpc` | detection
`__powerpc__` | detection
`__powerpc64__` | detection
`__POWERPC__` | detection
`__ppc__` | detection
`__ppc64__` | detection
`__PPC__` | detection
`__PPC64__` | detection
`_M_PPC` | detection
`_ARCH_PPC` | detection
`_ARCH_PPC64` | detection
`__PPCGECKO__` | detection
`__PPCBROADWAY__` | detection
`_XENON` | detection
`__ppc` | detection
`__ppc601__` | 6.1.0
`_ARCH_601` | 6.1.0
`__ppc603__` | 6.3.0
`_ARCH_603` | 6.3.0
`__ppc604__` | 6.4.0
`__ppc604__` | 6.4.0

#### 4.1.11. `BOOST_ARCH_PPC_64`

PowerPC 64 bit architecture.

Symbol | Version
--- | ---
`__powerpc64__` | detection
`__ppc64__` | detection
`__PPC64__` | detection
`_ARCH_PPC64` | detection

#### 4.1.12. `BOOST_ARCH_PTX`

PTX architecture.

Symbol | Version
--- | ---
`__CUDA_ARCH__` | detection
`__CUDA_ARCH__` | V.R.0

#### 4.1.13. `BOOST_ARCH_PYRAMID`

Pyramid 9810 architecture.

Symbol | Version
--- | ---
`pyr` | detection

#### 4.1.14. `BOOST_ARCH_RISCV`

RISC-V architecture.

Symbol | Version
--- | ---
`__riscv` | detection

#### 4.1.15. `BOOST_ARCH_RS6000`

RS/6000 architecture.

Symbol | Version
--- | ---
`__THW_RS6000` | detection
`_IBMR2` | detection
`_POWER` | detection
`_ARCH_PWR` | detection
`_ARCH_PWR2` | detection

#### 4.1.16. `BOOST_ARCH_SPARC`

SPARC architecture.

Symbol | Version
--- | ---
`__sparc__` | detection
`__sparc` | detection
`__sparcv9` | 9.0.0
`__sparc_v9__` | 9.0.0
`__sparcv8` | 8.0.0
`__sparc_v8__` | 8.0.0

#### 4.1.17. `BOOST_ARCH_SH`

SuperH architecture: If available versions [1-5] are specifically detected.

Symbol | Version
--- | ---
`__sh__` | detection
`__SH5__` | 5.0.0
`__SH4__` | 4.0.0
`__sh3__` | 3.0.0
`__SH3__` | 3.0.0
`__sh2__` | 2.0.0
`__sh1__` | 1.0.0

#### 4.1.18. `BOOST_ARCH_SYS370`

System/370 architecture.

Symbol | Version
--- | ---
`__370__` | detection
`__THW_370__` | detection

#### 4.1.19. `BOOST_ARCH_SYS390`

System/390 architecture.

Symbol | Version
--- | ---
`__s390__` | detection
`__s390x__` | detection

#### 4.1.20. `BOOST_ARCH_X86`

Intel x86 architecture. This is a category to indicate that either `BOOST_ARCH_X86_32` or `BOOST_ARCH_X86_64` is detected.

#### 4.1.21. `BOOST_ARCH_Z`

z/Architecture architecture.

Symbol | Version
--- | ---
`__SYSC_ZARCH__` | detection

#### 4.1.22. `BOOST_ARCH_X86_32`

Intel x86 architecture: If available versions [3-6] are specifically detected.

Symbol | Version
--- | ---
`i386` | detection
`__i386__` | detection
`__i486__` | detection
`__i586__` | detection
`__i686__` | detection
`__i386` | detection
`_M_IX86` | detection
`_X86_` | detection
`__THW_INTEL__` | detection
`__I86__` | detection
`__INTEL__` | detection
`__I86__` | V.0.0
`_M_IX86` | V.0.0
`__i686__` | 6.0.0
`__i586__` | 5.0.0
`__i486__` | 4.0.0
`__i386__` | 3.0.0

#### 4.1.23. `BOOST_ARCH_X86_64`

X86-64 architecture.

Symbol | Version
--- | ---
`__x86_64` | detection
`__x86_64__` | detection
`__amd64__` | detection
`__amd64` | detection
`_M_X64` | detection

### 4.2. `BOOST_COMP` compiler macros

#### 4.2.1. `BOOST_COMP_BORLAND`

Borland C++ compiler. Version number available as major, minor, and patch.

Symbol | Version
--- | ---
`__BORLANDC__` | detection
`__CODEGEARC__` | detection
`__BORLANDC__` | V.R.P
`__CODEGEARC__` | V.R.P

#### 4.2.2. `BOOST_COMP_CLANG`

Clang compiler. Version number available as major, minor, and patch.

Symbol | Version
--- | ---
`__clang__` | detection
`__clang_major__`, `__clang_minor__`, `__clang_patchlevel__` | V.R.P

#### 4.2.3. `BOOST_COMP_COMO`

Comeau C++ compiler. Version number available as major, minor, and patch.

Symbol | Version
--- | ---
`__COMO__` | detection
`__COMO_VERSION__` | V.R.P

#### 4.2.4. `BOOST_COMP_DEC`

Compaq C/C++ compiler. Version number available as major, minor, and patch.

Symbol | Version
--- | ---
`__DECCXX` | detection
`__DECC` | detection
`__DECCXX_VER` | V.R.P
`__DECC_VER` | V.R.P

#### 4.2.5. `BOOST_COMP_DIAB`

Diab C/C++ compiler. Version number available as major, minor, and patch.

Symbol | Version
--- | ---
`__DCC__` | detection
`__VERSION_NUMBER__` | V.R.P

#### 4.2.6. `BOOST_COMP_DMC`

Digital Mars compiler. Version number available as major, minor, and patch.

Symbol | Version
--- | ---
`__DMC__` | detection
`__DMC__` | V.R.P

#### 4.2.7. `BOOST_COMP_SYSC`

Dignus Systems/C++ compiler. Version number available as major, minor, and patch.

Symbol | Version
--- | ---
`__SYSC__` | detection
`__SYSC_VER__` | V.R.P

#### 4.2.8. `BOOST_COMP_EDG`

EDG C++ Frontend compiler. Version number available as major, minor, and patch.

Symbol | Version
--- | ---
`__EDG__` | detection
`__EDG_VERSION__` | V.R.0

#### 4.2.9. `BOOST_COMP_PATH`

EKOpath compiler. Version number available as major, minor, and patch.

Symbol | Version
--- | ---
`__PATHCC__` | detection
`__PATHCC__`, `__PATHCC_MINOR__`, `__PATHCC_PATCHLEVEL__` | V.R.P

#### 4.2.10. `BOOST_COMP_GNUC`

Gnu GCC C/C++ compiler. Version number available as major, minor, and patch (if available).

Symbol | Version
--- | ---
`__GNUC__` | detection
`__GNUC__`, `__GNUC_MINOR__`, `__GNUC_PATCHLEVEL__` | V.R.P
`__GNUC__`, `__GNUC_MINOR__` | V.R.0

#### 4.2.11. `BOOST_COMP_GCCXML`

GCC XML compiler.

Symbol | Version
--- | ---
`__GCCXML__` | detection

#### 4.2.12. `BOOST_COMP_GHS`

Green Hills C/C++ compiler. Version number available as major, minor, and patch.

Symbol | Version
--- | ---
`__ghs` | detection
`__ghs__` | detection
`__GHS_VERSION_NUMBER__` | V.R.P
`__ghs` | V.R.P

#### 4.2.13. `BOOST_COMP_HPACC`

HP aC++ compiler. Version number available as major, minor, and patch.

Symbol | Version
--- | ---
`__HP_aCC` | detection
`__HP_aCC` | V.R.P

#### 4.2.14. `BOOST_COMP_IAR`

IAR C/C++ compiler. Version number available as major, minor, and patch.

Symbol | Version
--- | ---
`__IAR_SYSTEMS_ICC__` | detection
`__VER__` | V.R.P

#### 4.2.15. `BOOST_COMP_IBM`

IBM XL C/C++ compiler. Version number available as major, minor, and patch.

Symbol | Version
--- | ---
`__IBMCPP__` | detection
`__xlC__` | detection
`__xlc__` | detection
`__COMPILER_VER__` | V.R.P
`__xlC__` | V.R.P
`__xlc__` | V.R.P
`__IBMCPP__` | V.R.P

#### 4.2.16. `BOOST_COMP_INTEL`

Intel C/C++ compiler. Version number available as major, minor, and patch.

Symbol | Version
--- | ---
`__INTEL_COMPILER` | detection
`__ICL` | detection
`__ICC` | detection
`__ECC` | detection
`__INTEL_COMPILER` | V.R
`__INTEL_COMPILER` and `__INTEL_COMPILER_UPDATE` | V.R.P

ℹ | Because of an Intel mistake in the release version numbering when `__INTEL_COMPILER` is `9999` it is detected as version 12.1.0.

#### 4.2.17. `BOOST_COMP_KCC`

Kai C++ compiler. Version number available as major, minor, and patch.

Symbol | Version
--- | ---
`__KCC` | detection
`__KCC_VERSION` | V.R.P

#### 4.2.18. `BOOST_COMP_LLVM`

LLVM compiler.

Symbol | Version
--- | ---
`__llvm__` | detection

#### 4.2.19. `BOOST_COMP_HIGHC`

MetaWare High C/C++ compiler.

Symbol | Version
--- | ---
`__HIGHC__` | detection

#### 4.2.20. `BOOST_COMP_MWERKS`

Metrowerks CodeWarrior compiler. Version number available as major, minor, and patch.

Symbol | Version
--- | ---
`__MWERKS__` | detection
`__CWCC__` | detection
`__CWCC__` | V.R.P
`__MWERKS__` | V.R.P >= 4.2.0
`__MWERKS__` | 9.R.0
`__MWERKS__` | 8.R.0

#### 4.2.21. `BOOST_COMP_MRI`

Microtec C/C++ compiler.

Symbol | Version
--- | ---
`_MRI` | detection

#### 4.2.22. `BOOST_COMP_MPW`

MPW C++ compiler. Version number available as major, and minor.

Symbol | Version
--- | ---
`__MRC__` | detection
`MPW_C` | detection
`MPW_CPLUS` | detection
`__MRC__` | V.R.0

#### 4.2.23. `BOOST_COMP_NVCC`

NVCC compiler. Version number available as major, minor, and patch beginning with version 7.5.

Symbol | Version
--- | ---
`__NVCC__` | detection
`__CUDACC_VER_MAJOR__`, `__CUDACC_VER_MINOR__`, `__CUDACC_VER_BUILD__` | V.R.P

#### 4.2.24. `BOOST_COMP_PALM`

Palm C/C++ compiler. Version number available as major, minor, and patch.

Symbol | Version
--- | ---
`_PACC_VER` | detection
`_PACC_VER` | V.R.P

#### 4.2.25. `BOOST_COMP_PGI`

Portland Group C/C++ compiler.

Symbol | Version
--- | ---
`__PGI` | detection
`__PGIC__`, `__PGIC_MINOR__`, `__PGIC_PATCHLEVEL__` | V.R.P

#### 4.2.26. `BOOST_COMP_SGI`

SGI MIPSpro compiler. Version number available as major, minor, and patch.

Symbol | Version
--- | ---
`__sgi` | detection
`sgi` | detection
`_SGI_COMPILER_VERSION` | V.R.P
`_COMPILER_VERSION` | V.R.P

#### 4.2.27. `BOOST_COMP_SUNPRO`

Oracle Solaris Studio compiler. Version number available as major, minor, and patch.

Symbol | Version
--- | ---
`__SUNPRO_CC` | detection
`__SUNPRO_C` | detection
`__SUNPRO_CC` | V.R.P
`__SUNPRO_C` | V.R.P
`__SUNPRO_CC` | VV.RR.P
`__SUNPRO_C` | VV.RR.P

#### 4.2.28. `BOOST_COMP_TENDRA`

TenDRA C/C++ compiler.

Symbol | Version
--- | ---
`__TenDRA__` | detection

#### 4.2.29. `BOOST_COMP_MSVC`

Microsoft Visual C/C++ compiler. Version number available as major, minor, and patch.

Symbol | Version
--- | ---
`_MSC_VER` | detection
`_MSC_FULL_VER` | V.R.P
`_MSC_VER` | V.R.0

ℹ | Release of Visual Studio after 2015 will no longer be identified by Boost Predef as the marketing version number. Instead we use the compiler version number directly, i.e. the _MSC_VER number.

#### 4.2.30. `BOOST_COMP_WATCOM`

Watcom C++ compiler. Version number available as major, and minor.

Symbol | Version
--- | ---
`__WATCOMC__` | detection
`__WATCOMC__` | V.R.P

### 4.3. `BOOST_LANG` language standards macros

#### 4.3.1. `BOOST_LANG_CUDA`

CUDA C/C++ language. If available, the version is detected as VV.RR.P.

Symbol | Version
--- | ---
`__CUDACC__` | detection
`__CUDA__` | detection
`CUDA_VERSION` | VV.RR.P

#### 4.3.2. `BOOST_LANG_OBJC`

Objective-C language.

Symbol | Version
--- | ---
`__OBJC__` | detection

#### 4.3.3. `BOOST_LANG_STDC`

Standard C language. If available, the year of the standard is detected as YYYY.MM.1 from the Epoch date.

Symbol | Version
--- | ---
`__STDC__` | detection
`__STDC_VERSION__` | V.R.P

#### 4.3.4. `BOOST_LANG_STDCPP`

Standard C++ language. If available, the year of the standard is detected as YYYY.MM.1 from the Epoch date. Because of the way the C++ standardization process works the defined version year will not be the commonly known year of the standard. Specifically the defined versions are:

Table 1. Detected Version Number vs. C++ Standard Year
Detected Version Number | Standard Year | C++ Standard
--- | --- | ---
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

Symbol | Version
--- | ---
`__cplusplus` | detection
`__cplusplus` | YYYY.MM.1

#### 4.3.5. `BOOST_LANG_STDCPPCLI`

Standard C++/CLI language. If available, the year of the standard is detected as YYYY.MM.1 from the Epoch date.

Symbol | Version
--- | ---
`__cplusplus_cli` | detection
`__cplusplus_cli` | YYYY.MM.1

#### 4.3.6. `BOOST_LANG_STDECPP`

Standard Embedded C++ language.

Symbol | Version
--- | ---
`__embedded_cplusplus` | detection

### 4.4. `BOOST_LIB` library macros

#### 4.4.1. `BOOST_LIB_C_CLOUDABI`

cloudlibc - CloudABI’s standard C library. Version number available as major, and minor.

Symbol | Version
--- | ---
`__cloudlibc__` | detection
`__cloudlibc_major__`, `__cloudlibc_minor__` | V.R.0

#### 4.4.2. `BOOST_LIB_C_GNU`

GNU glibc Standard C library. Version number available as major, and minor.

Symbol | Version
--- | ---
`__GLIBC__` | detection
`__GNU_LIBRARY__` | detection
`__GLIBC__`, `__GLIBC_MINOR__` | V.R.0
`__GNU_LIBRARY__`, `__GNU_LIBRARY_MINOR__` | V.R.0

#### 4.4.3. `BOOST_LIB_C_UC`

uClibc Standard C library.

Symbol | Version
--- | ---
`__UCLIBC__` | detection
`__UCLIBC_MAJOR__`, `__UCLIBC_MINOR__`, `__UCLIBC_SUBLEVEL__` | V.R.P

#### 4.4.4. `BOOST_LIB_C_VMS`

VMS libc Standard C library. Version number available as major, minor, and patch.

Symbol | Version
--- | ---
`__CRTL_VER` | detection
`__CRTL_VER` | V.R.P

#### 4.4.5. `BOOST_LIB_C_ZOS`

z/OS libc Standard C library. Version number available as major, minor, and patch.

Symbol | Version
--- | ---
`__LIBREL__` | detection
`__LIBREL__` | V.R.P
`__TARGET_LIB__` | V.R.P

#### 4.4.6. `BOOST_LIB_STD_CXX`

libc++ C++ Standard Library.

Symbol | Version
--- | ---
`_LIBCPP_VERSION` | detection
`_LIBCPP_VERSION` | V.0.P

#### 4.4.7. `BOOST_LIB_STD_DINKUMWARE`

Dinkumware Standard C++ Library. If available version number as major, minor, and patch.

Symbol | Version
--- | ---
`_YVALS`, `__IBMCPP__` | detection
`_CPPLIB_VER` | detection
`_CPPLIB_VER` | V.R.0

#### 4.4.8. `BOOST_LIB_STD_COMO`

Comeau Computing Standard C++ Library. Version number available as major.

Symbol | Version
--- | ---
`__LIBCOMO__` | detection
`__LIBCOMO_VERSION__` | V.0.0

#### 4.4.9. `BOOST_LIB_STD_MSIPL`

Modena Software Lib++ Standard C++ Library.

Symbol | Version
--- | ---
`MSIPL_COMPILE_H` | detection
`__MSIPL_COMPILE_H` | detection

#### 4.4.10. `BOOST_LIB_STD_MSL`

Metrowerks Standard C++ Library. Version number available as major, minor, and patch.

Symbol | Version
--- | ---
`__MSL_CPP__` | detection
`__MSL__` | detection
`__MSL_CPP__` | V.R.P
`__MSL__` | V.R.P

#### 4.4.11. `BOOST_LIB_STD_RW`

Roguewave Standard C++ library. If available version number as major, minor, and patch.

Symbol | Version
--- | ---
`__STD_RWCOMPILER_H__` | detection
`_RWSTD_VER` | detection
`_RWSTD_VER` | V.R.P

#### 4.4.12. `BOOST_LIB_STD_SGI`

SGI Standard C++ library. If available version number as major, minor, and patch.

Symbol | Version
--- | ---
`__STL_CONFIG_H` | detection
`__SGI_STL` | V.R.P

#### 4.4.13. `BOOST_LIB_STD_GNU`

GNU libstdc++ Standard C++ library. Version number available as year (from 1970), month, and day.

Symbol | Version
--- | ---
`__GLIBCXX__` | detection
`__GLIBCPP__` | detection
`__GLIBCXX__` | V.R.P
`__GLIBCPP__` | V.R.P

#### 4.4.14. `BOOST_LIB_STD_STLPORT`

STLport Standard C++ library. Version number available as major, minor, and patch.

Symbol | Version
--- | ---
`__SGI_STL_PORT` | detection
`_STLPORT_VERSION` | detection
`_STLPORT_MAJOR`, `_STLPORT_MINOR`, `_STLPORT_PATCHLEVEL` | V.R.P
`_STLPORT_VERSION` | V.R.P
`__SGI_STL_PORT` | V.R.P

#### 4.4.15. `BOOST_LIB_STD_IBM`

IBM VACPP Standard C++ library.

Symbol | Version
--- | ---
`__IBMCPP__` | detection

#### 4.4.16. `BOOST_LIB_STD_MSVC`

Microsoft’s C++ Standard Library. If available version number as major, minor, and patch. The patch number is derived from `_MSVC_STL_UPDATE` by taking its five last digits (see below). This implies that pasting a `_MSVC_STL_UPDATE` value into `BOOST_VERSION_NUMBER` will produce a version number that is directly comparable to `BOOST_LIB_STD_MSVC`.

Symbol | Version
--- | ---
`_MSVC_STL_VERSION` | detection
`_MSVC_STL_VERSION` | VV.R.0
`_MSVC_STL_UPDATE` | 00.0.0YYYMM

### 4.5. `BOOST_OS` operating system macros

#### 4.5.1. `BOOST_OS_AIX`

IBM AIX operating system. Version number available as major, minor, and patch.

Symbol | Version
--- | ---
`_AIX` | detection
`__TOS_AIX__` | detection
`_AIX43` | 4.3.0
`_AIX41` | 4.1.0
`_AIX32` | 3.2.0
`_AIX3` | 3.0.0

#### 4.5.2. `BOOST_OS_AMIGAOS`

AmigaOS operating system.

Symbol | Version
--- | ---
`AMIGA` | detection
`__amigaos__` | detection

#### 4.5.3. `BOOST_OS_BEOS`

BeOS operating system.

Symbol | Version
--- | ---
`__BEOS__` | detection

#### 4.5.4. `BOOST_OS_BSD`

BSD operating system.

BSD has various branch operating systems possible and each detected individually. This detects the following variations and sets a specific version number macro to match:

- `BOOST_OS_BSD_DRAGONFLY` DragonFly BSD

- `BOOST_OS_BSD_FREE` FreeBSD

- `BOOST_OS_BSD_BSDI` BSDi BSD/OS

- `BOOST_OS_BSD_NET` NetBSD

- `BOOST_OS_BSD_OPEN` OpenBSD

ℹ | The general `BOOST_OS_BSD` is set in all cases to indicate some form of BSD. If the above variants is detected the corresponding macro is also set.

Symbol | Version
--- | ---
`BSD` | detection
`_SYSTYPE_BSD` | detection
`BSD4_2` | 4.2.0
`BSD4_3` | 4.3.0
`BSD4_4` | 4.4.0
`BSD` | V.R.0

#### 4.5.5. `BOOST_OS_CYGWIN`

Cygwin evironment.

Symbol | Version
--- | ---
`__CYGWIN__` | detection
`CYGWIN_VERSION_API_MAJOR`, `CYGWIN_VERSION_API_MINOR` | V.R.0

#### 4.5.6. `BOOST_OS_HAIKU`

Haiku operating system.

Symbol | Version
--- | ---
`__HAIKU__` | detection

#### 4.5.7. `BOOST_OS_HPUX`

HP-UX operating system.

Symbol | Version
--- | ---
`hpux` | detection
`_hpux` | detection
`__hpux` | detection

#### 4.5.8. `BOOST_OS_IOS`

iOS operating system.

Symbol | Version
--- | ---
`__APPLE__` | detection
`__MACH__` | detection
`__ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__` | detection
`__ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__` | __ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__*1000

#### 4.5.9. `BOOST_OS_IRIX`

IRIX operating system.

Symbol | Version
--- | ---
`sgi` | detection
`__sgi` | detection

#### 4.5.10. `BOOST_OS_LINUX`

Linux operating system.

Symbol | Version
--- | ---
`linux` | detection
`__linux` | detection
`__linux__` | detection
`__gnu_linux__` | detection

#### 4.5.11. `BOOST_OS_MACOS`

Mac OS operating system.

Symbol | Version
--- | ---
`macintosh` | detection
`Macintosh` | detection
`__APPLE__` | detection
`__MACH__` | detection
`__APPLE__`, `__MACH__` | 10.0.0
`otherwise` | 9.0.0

#### 4.5.12. `BOOST_OS_OS400`

IBM OS/400 operating system.

Symbol | Version
--- | ---
`__OS400__` | detection

#### 4.5.13. `BOOST_OS_QNX`

QNX operating system. Version number available as major, and minor if possible. And version 4 is specifically detected.

Symbol | Version
--- | ---
`__QNX__` | detection
`__QNXNTO__` | detection
`_NTO_VERSION` | V.R.0
`__QNX__` | 4.0.0

#### 4.5.14. `BOOST_OS_SOLARIS`

Solaris operating system.

Symbol | Version
--- | ---
`sun` | detection
`__sun` | detection

#### 4.5.15. `BOOST_OS_UNIX`

Unix Environment operating system.

Symbol | Version
--- | ---
`unix` | detection
`__unix` | detection
`_XOPEN_SOURCE` | detection
`_POSIX_SOURCE` | detection

#### 4.5.16. `BOOST_OS_SVR4`

SVR4 Environment operating system.

Symbol | Version
--- | ---
`__sysv__` | detection
`__SVR4` | detection
`__svr4__` | detection
`_SYSTYPE_SVR4` | detection

#### 4.5.17. `BOOST_OS_VMS`

VMS operating system.

Symbol | Version
--- | ---
`VMS` | detection
`__VMS` | detection
`__VMS_VER` | V.R.P

#### 4.5.18. `BOOST_OS_WINDOWS`

Microsoft Windows operating system.

Symbol | Version
--- | ---
`_WIN32` | detection
`_WIN64` | detection
`__WIN32__` | detection
`__TOS_WIN__` | detection
`__WINDOWS__` | detection

#### 4.5.19. `BOOST_OS_BSD_BSDI`

BSDi BSD/OS operating system.

Symbol | Version
--- | ---
`__bsdi__` | detection

#### 4.5.20. `BOOST_OS_BSD_DRAGONFLY`

DragonFly BSD operating system.

Symbol | Version
--- | ---
`__DragonFly__` | detection

#### 4.5.21. `BOOST_OS_BSD_FREE`

FreeBSD operating system.

Symbol | Version
--- | ---
`__FreeBSD__` | detection
`__FreeBSD_version` | V.R.P

#### 4.5.22. `BOOST_OS_BSD_NET`

NetBSD operating system.

Symbol | Version
--- | ---
`__NETBSD__` | detection
`__NetBSD__` | detection
`__NETBSD_version` | V.R.P
`NetBSD0_8` | 0.8.0
`NetBSD0_9` | 0.9.0
`NetBSD1_0` | 1.0.0
`__NetBSD_Version` | V.R.P

#### 4.5.23. `BOOST_OS_BSD_OPEN`

OpenBSD operating system.

Symbol | Version
--- | ---
`__OpenBSD__` | detection
`OpenBSD2_0` | 2.0.0
`OpenBSD2_1` | 2.1.0
`OpenBSD2_2` | 2.2.0
`OpenBSD2_3` | 2.3.0
`OpenBSD2_4` | 2.4.0
`OpenBSD2_5` | 2.5.0
`OpenBSD2_6` | 2.6.0
`OpenBSD2_7` | 2.7.0
`OpenBSD2_8` | 2.8.0
`OpenBSD2_9` | 2.9.0
`OpenBSD3_0` | 3.0.0
`OpenBSD3_1` | 3.1.0
`OpenBSD3_2` | 3.2.0
`OpenBSD3_3` | 3.3.0
`OpenBSD3_4` | 3.4.0
`OpenBSD3_5` | 3.5.0
`OpenBSD3_6` | 3.6.0
`OpenBSD3_7` | 3.7.0
`OpenBSD3_8` | 3.8.0
`OpenBSD3_9` | 3.9.0
`OpenBSD4_0` | 4.0.0
`OpenBSD4_1` | 4.1.0
`OpenBSD4_2` | 4.2.0
`OpenBSD4_3` | 4.3.0
`OpenBSD4_4` | 4.4.0
`OpenBSD4_5` | 4.5.0
`OpenBSD4_6` | 4.6.0
`OpenBSD4_7` | 4.7.0
`OpenBSD4_8` | 4.8.0
`OpenBSD4_9` | 4.9.0
`OpenBSD5_0` | 5.0.0
`OpenBSD5_1` | 5.1.0
`OpenBSD5_2` | 5.2.0
`OpenBSD5_3` | 5.3.0
`OpenBSD5_4` | 5.4.0
`OpenBSD5_5` | 5.5.0
`OpenBSD5_6` | 5.6.0
`OpenBSD5_7` | 5.7.0
`OpenBSD5_8` | 5.8.0
`OpenBSD5_9` | 5.9.0
`OpenBSD6_0` | 6.0.0
`OpenBSD6_1` | 6.1.0
`OpenBSD6_2` | 6.2.0
`OpenBSD6_3` | 6.3.0
`OpenBSD6_4` | 6.4.0
`OpenBSD6_5` | 6.5.0
`OpenBSD6_6` | 6.6.0
`OpenBSD6_7` | 6.7.0
`OpenBSD6_8` | 6.8.0
`OpenBSD6_9` | 6.9.0

### 4.6. `BOOST_PLAT` platform macros

#### 4.6.1. `BOOST_PLAT_ANDROID`

Android platform.

Symbol | Version
--- | ---
`__ANDROID__` | detection

#### 4.6.2. `BOOST_PLAT_CLOUDABI`

CloudABI platform.

Symbol | Version
--- | ---
`__CloudABI__` | detection

#### 4.6.3. `BOOST_PLAT_IOS_DEVICE`

#### 4.6.4. `BOOST_PLAT_IOS_SIMULATOR`

Symbol | Version
--- | ---
`TARGET_IPHONE_SIMULATOR` | detection
`TARGET_OS_SIMULATOR` | detection

#### 4.6.5. `BOOST_PLAT_MINGW`

MinGW platform, either variety. Version number available as major, minor, and patch.

Symbol | Version
--- | ---
`__MINGW32__` | detection
`__MINGW64__` | detection
`__MINGW64_VERSION_MAJOR`, `__MINGW64_VERSION_MINOR` | V.R.0
`__MINGW32_VERSION_MAJOR`, `__MINGW32_VERSION_MINOR` | V.R.0

#### 4.6.6. `BOOST_PLAT_MINGW32`

MinGW platform. Version number available as major, minor, and patch.

Symbol | Version
--- | ---
`__MINGW32__` | detection
`__MINGW32_VERSION_MAJOR`, `__MINGW32_VERSION_MINOR` | V.R.0

#### 4.6.7. `BOOST_PLAT_MINGW64`

MinGW-w64 platform. Version number available as major, minor, and patch.

Symbol | Version
--- | ---
`__MINGW64__` | detection
`__MINGW64_VERSION_MAJOR`, `__MINGW64_VERSION_MINOR` | V.R.0

#### 4.6.8. `BOOST_PLAT_WINDOWS_DESKTOP`

UWP for Windows Desktop development. Also available if the Platform SDK is too old to support UWP.

Symbol | Version
--- | ---
`WINAPI_FAMILY == WINAPI_FAMILY_DESKTOP_APP` | detection
`!BOOST_PLAT_WINDOWS_UWP` | detection

#### 4.6.9. `BOOST_PLAT_WINDOWS_PHONE`

UWP for Windows Phone development.

Symbol | Version
--- | ---
`WINAPI_FAMILY == WINAPI_FAMILY_PHONE_APP` | detection

#### 4.6.10. `BOOST_PLAT_WINDOWS_RUNTIME`

Deprecated.

UWP for Windows Phone or Store development. This does not align to the existing development model for UWP and is deprecated. Use one of the other `BOOST_PLAT_WINDOWS_*`definitions instead.

Symbol | Version
--- | ---
`BOOST_PLAT_WINDOWS_PHONE` | detection
`BOOST_PLAT_WINDOWS_STORE` | detection

#### 4.6.11. `BOOST_PLAT_WINDOWS_SERVER`

UWP for Windows Server development.

Symbol | Version
--- | ---
`WINAPI_FAMILY == WINAPI_FAMILY_SERVER` | detection

#### 4.6.12. `BOOST_PLAT_WINDOWS_STORE`

UWP for Windows Store development.

Symbol | Version
--- | ---
`WINAPI_FAMILY == WINAPI_FAMILY_PC_APP` | detection
`WINAPI_FAMILY == WINAPI_FAMILY_APP` (deprecated) | detection

#### 4.6.13. `BOOST_PLAT_WINDOWS_SYSTEM`

UWP for Windows System development.

Symbol | Version
--- | ---
`WINAPI_FAMILY == WINAPI_FAMILY_SYSTEM` | detection

#### 4.6.14. `BOOST_PLAT_WINDOWS_UWP`

Universal Windows Platform is available if the current development environment is capable of targeting UWP development.

Symbol | Version
--- | ---
`__MINGW64_VERSION_MAJOR` from `_mingw.h` | `>= 3`
`VER_PRODUCTBUILD` from `ntverp.h` | `>= 9200`

### 4.7. `BOOST_HW` hardware macros

#### 4.7.1. Using the `BOOST_HW_SIMD_*` predefs

SIMD predefs depend on compiler options. For example, you will have to add the option `-msse3` to clang or gcc to enable SSE3. SIMD predefs are also inclusive. This means that if SSE3 is enabled, then every other extensions with a lower version number will implicitly be enabled and detected. However, some extensions are CPU specific, they may not be detected nor enabled when an upper version is enabled.

ℹ | SSE(1) and SSE2 are automatically enabled by default when using x86-64 architecture.

To check if any SIMD extension has been enabled, you can use:

    #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;
    }

When writing SIMD specific code, you may want to check if a particular extension has been detected. To do so you have to use the right architecture predef and compare it. Those predef are of the form `BOOST_HW_SIMD_"ARCH"` (where `"ARCH"` is either `ARM`, `PPC`, or `X86`). For example, if you compile code for x86 architecture, you will have to use `BOOST_HW_SIMD_X86`. Its value will be the version number of the most recent SIMD extension detected for the architecture.

To check if an extension has been enabled:

    #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;
    }

ℹ | The _VERSION defines that map version number to actual real identifiers. This way it is easier to write comparisons without messing up with version numbers.

To "strictly" check the most recent detected extension:

    #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;
    }

Because of the version systems of predefs and of the inclusive property of SIMD extensions macros, you can easily check for ranges of supported extensions:

    #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;
    }

ℹ | Unlike gcc and clang, Visual Studio does not allow you to specify precisely the SSE variants you want to use, the only detections that will take place are SSE, SSE2, AVX and AVX2. For more informations, see [@https://msdn.microsoft.com/en-us/library/b0084kay.aspx here].

#### 4.7.2. `BOOST_HW_SIMD_ARM`

The SIMD extension for ARM (if detected). Version number depends on the most recent detected extension.

Symbol | Version
--- | ---
`__ARM_NEON__` | detection
`__aarch64__` | detection
`_M_ARM` | detection
`_M_ARM64` | detection

Symbol | Version
--- | ---
`__ARM_NEON__` | BOOST_HW_SIMD_ARM_NEON_VERSION
`__aarch64__` | BOOST_HW_SIMD_ARM_NEON_VERSION
`_M_ARM` | BOOST_HW_SIMD_ARM_NEON_VERSION
`_M_ARM64` | BOOST_HW_SIMD_ARM_NEON_VERSION

#### 4.7.3. `BOOST_HW_SIMD_ARM_*_VERSION`

Those defines represent ARM SIMD extensions versions.

ℹ | You MUST compare them with the predef `BOOST_HW_SIMD_ARM`. = `BOOST_HW_SIMD_ARM_NEON_VERSION`

The NEON ARM extension version number.

Version number is: 1.0.0.

#### 4.7.4. `BOOST_HW_SIMD_PPC`

The SIMD extension for PowerPC (if detected). Version number depends on the most recent detected extension.

Symbol | Version
--- | ---
`__VECTOR4DOUBLE__` | detection
`__ALTIVEC__` | detection
`__VEC__` | detection
`__VSX__` | detection

Symbol | Version
--- | ---
`__VECTOR4DOUBLE__` | BOOST_HW_SIMD_PPC_QPX_VERSION
`__ALTIVEC__` | BOOST_HW_SIMD_PPC_VMX_VERSION
`__VEC__` | BOOST_HW_SIMD_PPC_VMX_VERSION
`__VSX__` | BOOST_HW_SIMD_PPC_VSX_VERSION

#### 4.7.5. `BOOST_HW_SIMD_PPC_*_VERSION`

Those defines represent Power PC SIMD extensions versions.

ℹ | You MUST compare them with the predef `BOOST_HW_SIMD_PPC`. = `BOOST_HW_SIMD_PPC_VMX_VERSION`

The VMX powerpc extension version number.

Version number is: 1.0.0. = `BOOST_HW_SIMD_PPC_VSX_VERSION`

The VSX powerpc extension version number.

Version number is: 1.1.0. = `BOOST_HW_SIMD_PPC_QPX_VERSION`

The QPX powerpc extension version number.

Version number is: 2.0.0.

#### 4.7.6. `BOOST_HW_SIMD_X86`

The SIMD extension for x86 (if detected). Version number depends on the most recent detected extension.

Symbol | Version
--- | ---
`__SSE__` | detection
`_M_X64` | detection
`_M_IX86_FP >= 1` | detection
`__SSE2__` | detection
`_M_X64` | detection
`_M_IX86_FP >= 2` | detection
`__SSE3__` | detection
`__SSSE3__` | detection
`__SSE4_1__` | detection
`__SSE4_2__` | detection
`__AVX__` | detection
`__FMA__` | detection
`__AVX2__` | detection

Symbol | Version
--- | ---
`__SSE__` | BOOST_HW_SIMD_X86_SSE_VERSION
`_M_X64` | BOOST_HW_SIMD_X86_SSE_VERSION
`_M_IX86_FP >= 1` | BOOST_HW_SIMD_X86_SSE_VERSION
`__SSE2__` | BOOST_HW_SIMD_X86_SSE2_VERSION
`_M_X64` | BOOST_HW_SIMD_X86_SSE2_VERSION
`_M_IX86_FP >= 2` | BOOST_HW_SIMD_X86_SSE2_VERSION
`__SSE3__` | BOOST_HW_SIMD_X86_SSE3_VERSION
`__SSSE3__` | BOOST_HW_SIMD_X86_SSSE3_VERSION
`__SSE4_1__` | BOOST_HW_SIMD_X86_SSE4_1_VERSION
`__SSE4_2__` | BOOST_HW_SIMD_X86_SSE4_2_VERSION
`__AVX__` | BOOST_HW_SIMD_X86_AVX_VERSION
`__FMA__` | BOOST_HW_SIMD_X86_FMA3_VERSION
`__AVX2__` | BOOST_HW_SIMD_X86_AVX2_VERSION

#### 4.7.7. `BOOST_HW_SIMD_X86_*_VERSION`

Those defines represent x86 SIMD extensions versions.

ℹ | You MUST compare them with the predef `BOOST_HW_SIMD_X86`. = `BOOST_HW_SIMD_X86_MMX_VERSION`

The MMX x86 extension version number.

Version number is: 0.99.0. = `BOOST_HW_SIMD_X86_SSE_VERSION`

The SSE x86 extension version number.

Version number is: 1.0.0. = `BOOST_HW_SIMD_X86_SSE2_VERSION`

The SSE2 x86 extension version number.

Version number is: 2.0.0. = `BOOST_HW_SIMD_X86_SSE3_VERSION`

The SSE3 x86 extension version number.

Version number is: 3.0.0. = `BOOST_HW_SIMD_X86_SSSE3_VERSION`

The SSSE3 x86 extension version number.

Version number is: 3.1.0. = `BOOST_HW_SIMD_X86_SSE4_1_VERSION`

The SSE4_1 x86 extension version number.

Version number is: 4.1.0. = `BOOST_HW_SIMD_X86_SSE4_2_VERSION`

The SSE4_2 x86 extension version number.

Version number is: 4.2.0. = `BOOST_HW_SIMD_X86_AVX_VERSION`

The AVX x86 extension version number.

Version number is: 5.0.0. = `BOOST_HW_SIMD_X86_FMA3_VERSION`

The FMA3 x86 extension version number.

Version number is: 5.2.0. = `BOOST_HW_SIMD_X86_AVX2_VERSION`

The AVX2 x86 extension version number.

Version number is: 5.3.0. = `BOOST_HW_SIMD_X86_MIC_VERSION`

The MIC (Xeon Phi) x86 extension version number.

Version number is: 9.0.0.

#### 4.7.8. `BOOST_HW_SIMD_X86_AMD`

The SIMD extension for x86 (AMD) (if detected). Version number depends on the most recent detected extension.

Symbol | Version
--- | ---
`__SSE4A__` | detection
`__FMA4__` | detection
`__XOP__` | detection
`BOOST_HW_SIMD_X86` | detection

Symbol | Version
--- | ---
`__SSE4A__` | BOOST_HW_SIMD_X86_SSE4A_VERSION
`__FMA4__` | BOOST_HW_SIMD_X86_FMA4_VERSION
`__XOP__` | BOOST_HW_SIMD_X86_XOP_VERSION
`BOOST_HW_SIMD_X86` | BOOST_HW_SIMD_X86

ℹ | This predef includes every other x86 SIMD extensions and also has other more specific extensions (FMA4, XOP, SSE4a). You should use this predef instead of `BOOST_HW_SIMD_X86` to test if those specific extensions have been detected.

#### 4.7.9. `BOOST_HW_SIMD_X86_AMD_*_VERSION`

Those defines represent x86 (AMD specific) SIMD extensions versions.

ℹ | You MUST compare them with the predef `BOOST_HW_SIMD_X86_AMD`. = `BOOST_HW_SIMD_X86_AMD_SSE4A_VERSION`

SSE4A x86 extension (AMD specific).

Version number is: 4.0.0. = `BOOST_HW_SIMD_X86_AMD_FMA4_VERSION`

FMA4 x86 extension (AMD specific).

Version number is: 5.1.0. = `BOOST_HW_SIMD_X86_AMD_XOP_VERSION`

XOP x86 extension (AMD specific).

Version number is: 5.1.1.

### 4.8. Other macros

#### 4.8.1. `BOOST_ENDIAN_*`

Detection of endian memory ordering. There are four defined macros in this header that define the various generally possible endian memory orderings:

- `BOOST_ENDIAN_BIG_BYTE`, byte-swapped big-endian.

- `BOOST_ENDIAN_BIG_WORD`, word-swapped big-endian.

- `BOOST_ENDIAN_LITTLE_BYTE`, byte-swapped little-endian.

- `BOOST_ENDIAN_LITTLE_WORD`, word-swapped little-endian.

The detection is conservative in that it only identifies endianness that it knows for certain. In particular bi-endianness is not indicated as is it not practically possible to determine the endianness from anything but an operating system provided header. And the currently known headers do not define that programatic bi-endianness is available.

This implementation is a compilation of various publicly available information and acquired knowledge:

1. The indispensable documentation of "Pre-defined Compiler Macros" Endianness.

2. The various endian specifications available in the Wikipedia computer architecture pages.

3. Generally available searches for headers that define endianness.

#### 4.8.2. `BOOST_ARCH_WORD_BITS`

Detects the native word size, in bits, for the current architecture. There are two types of macros for this detection:

- `BOOST_ARCH_WORD_BITS`, gives the number of word size bits (16, 32, 64).

- `BOOST_ARCH_WORD_BITS_16`, `BOOST_ARCH_WORD_BITS_32`, and `BOOST_ARCH_WORD_BITS_64`, indicate when the given word size is detected.

They allow for both single checks and direct use of the size in code.

ℹ | The word size is determined manually on each architecture. Hence use of the `wordsize.h` header will also include all the architecture headers.

#### 4.8.3. `BOOST_PREDEF_WORKAROUND`

    BOOST_PREDEF_WORKAROUND(symbol,comp,major,minor,patch)

Usage:

    #if BOOST_PREDEF_WORKAROUND(BOOST_COMP_CLANG,<,3,0,0)
        // Workaround for old clang compilers..
    #endif

Defines a comparison against two version numbers that depends on the definion of `BOOST_STRICT_CONFIG`. When `BOOST_STRICT_CONFIG` is defined this will expand to a value convertible to `false`. Which has the effect of disabling all code conditionally guarded by `BOOST_PREDEF_WORKAROUND`. When `BOOST_STRICT_CONFIG` is undefine this expand to test the given `symbol` version value with the `comp` comparison against `BOOST_VERSION_NUMBER(major,minor,patch)`.

#### 4.8.4. `BOOST_PREDEF_TESTED_AT`

    BOOST_PREDEF_TESTED_AT(symbol,major,minor,patch)

Usage:

    #if BOOST_PREDEF_TESTED_AT(BOOST_COMP_CLANG,3,5,0)
        // Needed for clang, and last checked for 3.5.0.
    #endif

Defines a comparison against two version numbers that depends on the definion of `BOOST_STRICT_CONFIG` and `BOOST_DETECT_OUTDATED_WORKAROUNDS`. When `BOOST_STRICT_CONFIG` is defined this will expand to a value convertible to `false`. Which has the effect of disabling all code conditionally guarded by `BOOST_PREDEF_TESTED_AT`. When `BOOST_STRICT_CONFIG` is undefined this expand to either:

- A value convertible to `true` when `BOOST_DETECT_OUTDATED_WORKAROUNDS` is not defined.

- A value convertible `true` when the expansion of `BOOST_PREDEF_WORKAROUND(symbol, ⇐, major, minor, patch)` is `true` and `BOOST_DETECT_OUTDATED_WORKAROUNDS` is defined.

- A compile error when the expansion of `BOOST_PREDEF_WORKAROUND(symbol, >, major, minor, patch)` is true and `BOOST_DETECT_OUTDATED_WORKAROUNDS` is defined.

### 4.9. Version definition macros

#### 4.9.1. `BOOST_VERSION_NUMBER`

    BOOST_VERSION_NUMBER(major,minor,patch)

Defines standard version numbers, with these properties:

- Decimal base whole numbers in the range [0,1000000000). The number range is designed to allow for a (2,2,5) triplet. Which fits within a 32 bit value.

- The `major` number can be in the [0,99] range.

- The `minor` number can be in the [0,99] range.

- The `patch` number can be in the [0,99999] range.

- Values can be specified in any base. As the defined value is an constant expression.

- Value can be directly used in both preprocessor and compiler expressions for comparison to other similarly defined values.

- The implementation enforces the individual ranges for the major, minor, and patch numbers. And values over the ranges are truncated (modulo).

    BOOST_VERSION_NUMBER_MAJOR(N), BOOST_VERSION_NUMBER_MINOR(N), BOOST_VERSION_NUMBER_PATCH(N)

The macros extract the major, minor, and patch portion from a well formed version number resulting in a preprocessor expression in the range of [0,99] or [0,99999] for the major and minor, or patch numbers respectively.

#### 4.9.2. `BOOST_PREDEF_MAKE_..` macros

These set of macros decompose common vendor version number macros which are composed version, revision, and patch digits. The naming convention indicates:

- The base of the specified version number. “BOOST_PREDEF_MAKE_0X” for hexadecimal digits, and “BOOST_PREDEF_MAKE_10” for decimal digits.

- The format of the vendor version number. Where “V” indicates the version digits, “R” indicates the revision digits, “P” indicates the patch digits, and “0” indicates an ignored digit.

Macros are:

- `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)`, the second parameter specifies a year-month patch level with the first digit discarded

- `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)`

#### 4.9.3. `BOOST_PREDEF_MAKE_*..` date macros

Date decomposition macros return a date in the relative to the 1970 Epoch date. If the month is not available, January 1st is used as the month and day. If the day is not available, but the month is, the 1st of the month is used as the day.

- `BOOST_PREDEF_MAKE_DATE(Y,M,D)`

- `BOOST_PREDEF_MAKE_YYYYMMDD(V)`

- `BOOST_PREDEF_MAKE_YYYY(V)`

- `BOOST_PREDEF_MAKE_YYYYMM(V)`

## 5. Check Utilities

The `predef_check` utility provides a facility for building a program that will check a given set of expressions against the definitions it detected when it was built.

### 5.1. `predef_check` programs

Even though there is only one `predef_check` program, there are variations for each of the languages that are detected by Predef to match the convention for sources files. For all of them one invokes with a list of expression arguments. The expressions are evaluated within the context of the particular `predef_check` program and if they all are true zero (0) is returned. Otherwise the index of the first false expression is returned.

The expression syntax is simple:

    predef-definition [ relational-operator version-value ]

predef-definition can be any of the Predef definitions. For example `BOOST_COMP_GCC`.

relational-operator can be any of: `>`, `<`, `>=`, `⇐`, `==` and `!=`.

version-number can be a full or partial version triplet value. If it’s a partial version triple it is completed with zeros. That is `x.y` is equivalent to `x.y.0` and `x` is equivalent to `x.0.0`.

The relations-operator and version-number can be omitted. In which case it is equivalent to:

    predef-definition > 0.0.0

### 5.2. Using with Boost.Build

You can use the `predef_check` programs directly from Boost Build to configure target requirements. This is useful for controlling what gets built as part of your project based on the detailed version information available in Predef. The basic use is simple:

    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" ] ;

That simple use case will skip building the `my_windows_program` unless one is building for Windows. Like the direct `predef_check` you can pass multiple expressions using relational comparisons. For example:

    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"] ;

And in that case the `my_special_lib` is built only when the OS is not Windows or VMS. The `requires` rule is a special case of the `check` rule. And is defined in terms of it:

    rule require ( expressions + : language ? )
    {
        return [ check $(expressions) : $(language) : : <build>no ] ;
    }

The expression can also use explicit "and", "or" logical operators to for more complex checks:

    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"] ;

You can use the `check` rule for more control and to implement something other than control of what gets built. The definition for the `check` rule is:

    rule check ( expressions + : language ? : true-properties * : false-properties * )

When invoked as a requirement of a Boost Build target this rule will add the `true-properties` to the target if all the `expressions` evaluate to true. Otherwise the `false-properties` get added as requirements. For example you could use it to enable or disable features in your programs:

    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 ] ;

For both `check` and `require` the `language` argument controls which variant of the `predef_check` program is used to check the expressions. It defaults to "c++", but can be any of: "c", "cpp", "objc", and "objcpp".

## 6. History

### 6.1. 1.15.0

- Add detection of Microsoft STL (from Henrik Gaßmann).

### 6.2. 1.14.0

- Add detection of LoongArch (from Zhang Na).

### 6.3. 1.13.1

- Fix spelling of "epoch".

- Add missing parenthesis in `sparc.h` (from tkoecker).

- Update documentation to use Rouge code styling and Amber general style.

### 6.4. 1.13

- Add `ARCH_PPC_64` predef.

- Fix `ARCH_WORD_BITS*` redefinition warnings/errors.

- Add `ARCH_E2K`, Elbrus 2000, architecture from Konstantin Ivlev.

- Fix not handling recent C++ version that go above 10.x version.

### 6.5. 1.12

- Switch to using the endian.h header on OpenBSD. (Brad Smith)

- Fix not handling recent versions of stdcxx that go above version 9.

- Fix including sub-BSD OS headers directly causing redef warnings.

- Add CI testing of direct inclusion of all headers.

- Add CI testing on FreeBSD for clang and gcc.

- Add `WORD_BITS` set of predefs to detect the architecture word size. Initial implementation inspired by submission from Mikhail Komarov.

- Add CI testing for Cygwin 32 and 64.

### 6.6. 1.11

- Add `BOOST_ARCH_RISCV`. (from Andreas Schwab)

- Add RISC-V endian detection. (from Thomas Petazzoni)

- Convert documentation to AsciiDoctor format.

- Document correct versions for C++ standard.

- Fix compile error from not available header when building in WinCE.

- Remove deprecated `BOOST_OS_ANDROID`.

- Fix compile for Wine. (Kevin Puetz)

### 6.7. 1.10

- Fix bad include of sub-BSD os headers from main BSD header.

- Fix use of deprecated `TARGET_IPHONE_SIMULATOR` instead of newer `TARGET_OS_SIMULATOR`.

- Add `BOOST_PLAT_ANDROID` to resolve conflict between Linux and Android OS predefs. The `BOOST_OS_ANDROID` predef is now deprecated and will be removed in a future release.

- Add support for consuming Predef as a CMake project.

- Add support for consuming Predef as a standalone B2 project.

### 6.8. 1.9

- Fixes for `BOOST_COMP_NVCC*` predefs. (from Benjamin Worpitz)

- Add specific version information for Cygwin OS predef. (from James E. King III)

### 6.9. 1.8

- Add support for __ARM_ARCH macro. (from Tim Blechmann)

- Add detection for PTX architecture. (from Benjamin Worpitz)

- Add nvcc compiler detection. (from Benjamin Worpitz)

- Add support for detecting CUDA. (from Benjamin Worpitz)

- Remove reference to obsolete BOOST_ARCH_AMD64. (from Peter Kolbus)

### 6.10. 1.7

- Fix BOOST_ARCH_PARISK/BOOST_ARCH_PARISC typo.

- Improved Windows Universal Platform detection. (from James E. King, III)

- Add detection for CloudABI with cloudlibc. (from James E. King, III)

### 6.11. 1.6

- Fix Intel C/C++ version 9999 detection to be 12.1.0.

- Addition of `BOOST_PREDEF_WORKAROUND` and `BOOST_PREDEF_TESTED_AT` macros for defect workarounds and detection.

- Add ARM64 MSVC SIMD detection. (from Minmin Gong)

- Add detection of iOS simulator vs device as a platform choice. (from Ruslan Baratov)

- Fix MinGW incorrect header guard. (from Ruslan Baratov)

### 6.12. 1.5

- Fix Intel C/C++ compiler version specification.

- Add `BOOST_VERSION_NUMBER_MAJOR`, `BOOST_VERSION_NUMBER_MINOR`, `BOOST_VERSION_NUMBER_PATCH` macros to extract components from valid version numbers.

- Change VS version numbering. Version after VS2015 will use the compiler version instead of the varied product versions.

### 6.13. 1.4.1

- Small fixes for some redefinition errors, and mispelled macros.

- Slightly rearrangement of structure to comply with current library requirements.

### 6.14. 1.4

- Add detection of SIMD hardware. With the addition of the `BOOST_HW_*` category (from Charly Chevalier).

- Add compile only version of check utilities to address cross-compile use cases. And changed the BBv2 check support to use compile only checks.

- Fix test warnings.

- Fix typos on `AVAILABLE` macros for Windows Platform. (from Vemund Handeland)

### 6.15. 1.3

- Fix many problems with `predef_check` functionality.

- Update SunPro detection to accommodate latest version of compiler from Oracle.

- Addition of Travis-CI and Appveyor testing.

- Add `and` and `or` logical operators for `predef_check` expression on the Boost Build side.

- Fix `BOOST_ARCH_PARISC` to correctly spelled name (from Graham Hanson).

- Fix `MAKE_YYYYM` macros to correctly limit the month (from rick68).

### 6.16. 1.2

- Account for skip in Visual Studio product version vs. compiler version. This supports version of VS 2015 an onward.

- Add detection of Haiku OS (from Jessica Hamilton).

- Some fixes to endian detection for Android (from mstahl-at-redhat.com).

- Add missing `BOOST_PREDEF_MAKE_0X_VVRRPP` macro (from Erik Lindahl).

- Add `predef_check` program and BBv2 integration for build configuration checks.

### 6.17. 1.1

- Addition of `BOOST_PLAT_*` platform definitions for MinGW and Windows platform variants.

- Detection of ARM architecture for Windows compilers to target mobile devices of Windows 8.

- Improved ARM detection for 64 bit ARM.

- Added detection of iOS an an operating system.

- Improved detection of endianess on some platforms.

- Addition of exclusive plus emulated definitions for platform and compiler detection.

⚠ | The big change for this version is the restructuring of the definitions to avoid duplicate definitions in one category. That is, only one `BOOST_OS_*`, `BOOST_COMP_*`, and `BOOST_PLAT_*` variant will be detected (except for sub-categories).

## 7. To Do

- Improve reference documentation.

## 8. Acknowledgements

The comprehensiveness of this library would not be possible without the existence of the indispensable resource that is the Pre-defined C/C++ Compiler Macros Project. It was, and continues to be, the primary source of the definitions that make up this library. Thanks to Bjorn Reese and all the volunteers that make that resource possible.

This library would be an incoherent mess if it weren’t for Boost community that provided invaluable feedback for the eight years that it took to polish into a useable form. In particular I would like to thank: 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, and Robert Ramey. And thanks to Joel Falcou for managing the review of this library.

## Colophon

Distributed under the Boost Software License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at https://www.boost.org/LICENSE_1_0.txt)

Copyright 2005-2021 René Ferdinand Rivera Morell; Copyright 2015 Charly Chevalier; Copyright 2015 Joel Falcou