Boost C++ Libraries

...one of the most highly regarded and expertly designed C++ library projects in the world. — Herb Sutter and Andrei Alexandrescu, C++ Coding Standards

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:

ℹ
 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.1

  • Guard against using the obsolete predef/check/predef.jam B2 module. Instead of using the current predef/tools/check/predef.jam module.

6.2. 1.15.0

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

6.3. 1.14.0

  • Add detection of LoongArch (from Zhang Na).

6.4. 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.5. 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.6. 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.7. 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.8. 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.9. 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.10. 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.11. 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.12. 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.13. 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.14. 1.4.1

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

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

6.15. 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.16. 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.17. 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.18. 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