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:
-
use an uneven distribution or
-
use more bits (a larger type) or
-
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_
andBOOST_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:
-
Major version number, as a constant value expression in the range [0,99].
-
Minor version number, as a constant value expression in the range [0,99].
-
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 |
---|---|
|
detection |
|
detection |
|
detection |
|
4.0.0 |
|
5.0.0 |
|
6.0.0 |
4.1.2. BOOST_ARCH_ARM
ARM architecture.
Symbol | Version |
---|---|
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
V.0.0 |
|
V.0.0 |
|
V.0.0 |
|
V.0.0 |
|
8.0.0 |
|
8.0.0 |
|
8.0.0 |
|
8.0.0 |
|
7.0.0 |
|
7.0.0 |
|
7.0.0 |
|
7.0.0 |
|
6.0.0 |
|
6.0.0 |
|
6.0.0 |
|
6.0.0 |
|
5.0.0 |
|
5.0.0 |
|
4.0.0 |
|
4.0.0 |
4.1.3. BOOST_ARCH_BLACKFIN
Blackfin Processors from Analog Devices.
Symbol | Version |
---|---|
|
detection |
|
detection |
|
detection |
|
detection |
4.1.4. BOOST_ARCH_CONVEX
Convex Computer architecture.
Symbol | Version |
---|---|
|
detection |
|
1.0.0 |
|
2.0.0 |
|
3.2.0 |
|
3.4.0 |
|
3.8.0 |
4.1.6. BOOST_ARCH_IA64
Intel Itanium 64 architecture.
Symbol | Version |
---|---|
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
4.1.7. BOOST_ARCH_M68K
Motorola 68k architecture.
Symbol | Version |
---|---|
|
detection |
|
detection |
|
6.0.0 |
|
6.0.0 |
|
6.0.0 |
|
4.0.0 |
|
4.0.0 |
|
4.0.0 |
|
3.0.0 |
|
3.0.0 |
|
3.0.0 |
|
2.0.0 |
|
2.0.0 |
|
2.0.0 |
|
1.0.0 |
|
1.0.0 |
|
1.0.0 |
|
0.0.1 |
|
0.0.1 |
|
0.0.1 |
4.1.8. BOOST_ARCH_MIPS
MIPS architecture.
Symbol | Version |
---|---|
|
detection |
|
detection |
|
detection |
|
V.0.0 |
|
1.0.0 |
|
1.0.0 |
|
2.0.0 |
|
2.0.0 |
|
2.0.0 |
|
3.0.0 |
|
3.0.0 |
|
4.0.0 |
|
4.0.0 |
4.1.9. BOOST_ARCH_PARISC
HP/PA RISC architecture.
Symbol | Version |
---|---|
|
detection |
|
detection |
|
detection |
|
1.0.0 |
|
1.1.0 |
|
1.1.0 |
|
1.1.0 |
|
2.0.0 |
|
2.0.0 |
|
2.0.0 |
|
2.0.0 |
4.1.10. BOOST_ARCH_PPC
PowerPC architecture.
Symbol | Version |
---|---|
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
6.1.0 |
|
6.1.0 |
|
6.3.0 |
|
6.3.0 |
|
6.4.0 |
|
6.4.0 |
4.1.11. BOOST_ARCH_PPC_64
PowerPC 64 bit architecture.
Symbol | Version |
---|---|
|
detection |
|
detection |
|
detection |
|
detection |
4.1.15. BOOST_ARCH_RS6000
RS/6000 architecture.
Symbol | Version |
---|---|
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
4.1.16. BOOST_ARCH_SPARC
SPARC architecture.
Symbol | Version |
---|---|
|
detection |
|
detection |
|
9.0.0 |
|
9.0.0 |
|
8.0.0 |
|
8.0.0 |
4.1.17. BOOST_ARCH_SH
SuperH architecture: If available versions [1-5] are specifically detected.
Symbol | Version |
---|---|
|
detection |
|
5.0.0 |
|
4.0.0 |
|
3.0.0 |
|
3.0.0 |
|
2.0.0 |
|
1.0.0 |
4.1.18. BOOST_ARCH_SYS370
System/370 architecture.
Symbol | Version |
---|---|
|
detection |
|
detection |
4.1.19. BOOST_ARCH_SYS390
System/390 architecture.
Symbol | Version |
---|---|
|
detection |
|
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.22. BOOST_ARCH_X86_32
Intel x86 architecture: If available versions [3-6] are specifically detected.
Symbol | Version |
---|---|
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
V.0.0 |
|
V.0.0 |
|
6.0.0 |
|
5.0.0 |
|
4.0.0 |
|
3.0.0 |
4.1.23. BOOST_ARCH_X86_64
X86-64 architecture.
Symbol | Version |
---|---|
|
detection |
|
detection |
|
detection |
|
detection |
|
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 |
---|---|
|
detection |
|
detection |
|
V.R.P |
|
V.R.P |
4.2.2. BOOST_COMP_CLANG
Clang compiler. Version number available as major, minor, and patch.
Symbol | Version |
---|---|
|
detection |
|
V.R.P |
4.2.3. BOOST_COMP_COMO
Comeau C++ compiler. Version number available as major, minor, and patch.
Symbol | Version |
---|---|
|
detection |
|
V.R.P |
4.2.4. BOOST_COMP_DEC
Compaq C/C++ compiler. Version number available as major, minor, and patch.
Symbol | Version |
---|---|
|
detection |
|
detection |
|
V.R.P |
|
V.R.P |
4.2.5. BOOST_COMP_DIAB
Diab C/C++ compiler. Version number available as major, minor, and patch.
Symbol | Version |
---|---|
|
detection |
|
V.R.P |
4.2.6. BOOST_COMP_DMC
Digital Mars compiler. Version number available as major, minor, and patch.
Symbol | Version |
---|---|
|
detection |
|
V.R.P |
4.2.7. BOOST_COMP_SYSC
Dignus Systems/C++ compiler. Version number available as major, minor, and patch.
Symbol | Version |
---|---|
|
detection |
|
V.R.P |
4.2.8. BOOST_COMP_EDG
EDG C++ Frontend compiler. Version number available as major, minor, and patch.
Symbol | Version |
---|---|
|
detection |
|
V.R.0 |
4.2.9. BOOST_COMP_PATH
EKOpath compiler. Version number available as major, minor, and patch.
Symbol | Version |
---|---|
|
detection |
|
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 |
---|---|
|
detection |
|
V.R.P |
|
V.R.0 |
4.2.12. BOOST_COMP_GHS
Green Hills C/C++ compiler. Version number available as major, minor, and patch.
Symbol | Version |
---|---|
|
detection |
|
detection |
|
V.R.P |
|
V.R.P |
4.2.13. BOOST_COMP_HPACC
HP aC++ compiler. Version number available as major, minor, and patch.
Symbol | Version |
---|---|
|
detection |
|
V.R.P |
4.2.14. BOOST_COMP_IAR
IAR C/C++ compiler. Version number available as major, minor, and patch.
Symbol | Version |
---|---|
|
detection |
|
V.R.P |
4.2.15. BOOST_COMP_IBM
IBM XL C/C++ compiler. Version number available as major, minor, and patch.
Symbol | Version |
---|---|
|
detection |
|
detection |
|
detection |
|
V.R.P |
|
V.R.P |
|
V.R.P |
|
V.R.P |
4.2.16. BOOST_COMP_INTEL
Intel C/C++ compiler. Version number available as major, minor, and patch.
Symbol | Version |
---|---|
|
detection |
|
detection |
|
detection |
|
detection |
|
V.R |
|
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 |
---|---|
|
detection |
|
V.R.P |
4.2.20. BOOST_COMP_MWERKS
Metrowerks CodeWarrior compiler. Version number available as major, minor, and patch.
Symbol | Version |
---|---|
|
detection |
|
detection |
|
V.R.P |
|
V.R.P >= 4.2.0 |
|
9.R.0 |
|
8.R.0 |
4.2.22. BOOST_COMP_MPW
MPW C++ compiler. Version number available as major, and minor.
Symbol | Version |
---|---|
|
detection |
|
detection |
|
detection |
|
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 |
---|---|
|
detection |
|
V.R.P |
4.2.24. BOOST_COMP_PALM
Palm C/C++ compiler. Version number available as major, minor, and patch.
Symbol | Version |
---|---|
|
detection |
|
V.R.P |
4.2.25. BOOST_COMP_PGI
Portland Group C/C++ compiler.
Symbol | Version |
---|---|
|
detection |
|
V.R.P |
4.2.26. BOOST_COMP_SGI
SGI MIPSpro compiler. Version number available as major, minor, and patch.
Symbol | Version |
---|---|
|
detection |
|
detection |
|
V.R.P |
|
V.R.P |
4.2.27. BOOST_COMP_SUNPRO
Oracle Solaris Studio compiler. Version number available as major, minor, and patch.
Symbol | Version |
---|---|
|
detection |
|
detection |
|
V.R.P |
|
V.R.P |
|
VV.RR.P |
|
VV.RR.P |
4.2.29. BOOST_COMP_MSVC
Microsoft Visual C/C++ compiler. Version number available as major, minor, and patch.
Symbol | Version |
---|---|
|
detection |
|
V.R.P |
|
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 |
---|---|
|
detection |
|
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 |
---|---|
|
detection |
|
detection |
|
VV.RR.P |
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 |
---|---|
|
detection |
|
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:
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 |
---|---|
|
detection |
|
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 |
---|---|
|
detection |
|
YYYY.MM.1 |
4.3.6. BOOST_LANG_STDECPP
Standard Embedded C++ language.
Symbol | Version |
---|---|
|
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 |
---|---|
|
detection |
|
V.R.0 |
4.4.2. BOOST_LIB_C_GNU
GNU glibc Standard C library. Version number available as major, and minor.
Symbol | Version |
---|---|
|
detection |
|
detection |
|
V.R.0 |
|
V.R.0 |
4.4.3. BOOST_LIB_C_UC
uClibc Standard C library.
Symbol | Version |
---|---|
|
detection |
|
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 |
---|---|
|
detection |
|
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 |
---|---|
|
detection |
|
V.R.P |
|
V.R.P |
4.4.6. BOOST_LIB_STD_CXX
libc++ C++ Standard Library.
Symbol | Version |
---|---|
|
detection |
|
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 |
---|---|
|
detection |
|
detection |
|
V.R.0 |
4.4.8. BOOST_LIB_STD_COMO
Comeau Computing Standard C++ Library. Version number available as major.
Symbol | Version |
---|---|
|
detection |
|
V.0.0 |
4.4.9. BOOST_LIB_STD_MSIPL
Modena Software Lib++ Standard C++ Library.
Symbol | Version |
---|---|
|
detection |
|
detection |
4.4.10. BOOST_LIB_STD_MSL
Metrowerks Standard C++ Library. Version number available as major, minor, and patch.
Symbol | Version |
---|---|
|
detection |
|
detection |
|
V.R.P |
|
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 |
---|---|
|
detection |
|
detection |
|
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 |
---|---|
|
detection |
|
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 |
---|---|
|
detection |
|
detection |
|
V.R.P |
|
V.R.P |
4.4.14. BOOST_LIB_STD_STLPORT
STLport Standard C++ library. Version number available as major, minor, and patch.
Symbol | Version |
---|---|
|
detection |
|
detection |
|
V.R.P |
|
V.R.P |
|
V.R.P |
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 |
---|---|
|
detection |
|
detection |
|
4.3.0 |
|
4.1.0 |
|
3.2.0 |
|
3.0.0 |
4.5.2. BOOST_OS_AMIGAOS
AmigaOS operating system.
Symbol | Version |
---|---|
|
detection |
|
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 |
---|---|
|
detection |
|
detection |
|
4.2.0 |
|
4.3.0 |
|
4.4.0 |
|
V.R.0 |
4.5.5. BOOST_OS_CYGWIN
Cygwin evironment.
Symbol | Version |
---|---|
|
detection |
|
V.R.0 |
4.5.7. BOOST_OS_HPUX
HP-UX operating system.
Symbol | Version |
---|---|
|
detection |
|
detection |
|
detection |
4.5.8. BOOST_OS_IOS
iOS operating system.
Symbol | Version |
---|---|
|
detection |
|
detection |
|
detection |
|
__ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__*1000 |
4.5.10. BOOST_OS_LINUX
Linux operating system.
Symbol | Version |
---|---|
|
detection |
|
detection |
|
detection |
|
detection |
4.5.11. BOOST_OS_MACOS
Mac OS operating system.
Symbol | Version |
---|---|
|
detection |
|
detection |
|
detection |
|
detection |
|
10.0.0 |
|
9.0.0 |
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 |
---|---|
|
detection |
|
detection |
|
V.R.0 |
|
4.0.0 |
4.5.15. BOOST_OS_UNIX
Unix Environment operating system.
Symbol | Version |
---|---|
|
detection |
|
detection |
|
detection |
|
detection |
4.5.16. BOOST_OS_SVR4
SVR4 Environment operating system.
Symbol | Version |
---|---|
|
detection |
|
detection |
|
detection |
|
detection |
4.5.17. BOOST_OS_VMS
VMS operating system.
Symbol | Version |
---|---|
|
detection |
|
detection |
|
V.R.P |
4.5.18. BOOST_OS_WINDOWS
Microsoft Windows operating system.
Symbol | Version |
---|---|
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
4.5.20. BOOST_OS_BSD_DRAGONFLY
DragonFly BSD operating system.
Symbol | Version |
---|---|
|
detection |
4.5.21. BOOST_OS_BSD_FREE
FreeBSD operating system.
Symbol | Version |
---|---|
|
detection |
|
V.R.P |
4.5.22. BOOST_OS_BSD_NET
NetBSD operating system.
Symbol | Version |
---|---|
|
detection |
|
detection |
|
V.R.P |
|
0.8.0 |
|
0.9.0 |
|
1.0.0 |
|
V.R.P |
4.5.23. BOOST_OS_BSD_OPEN
OpenBSD operating system.
Symbol | Version |
---|---|
|
detection |
|
2.0.0 |
|
2.1.0 |
|
2.2.0 |
|
2.3.0 |
|
2.4.0 |
|
2.5.0 |
|
2.6.0 |
|
2.7.0 |
|
2.8.0 |
|
2.9.0 |
|
3.0.0 |
|
3.1.0 |
|
3.2.0 |
|
3.3.0 |
|
3.4.0 |
|
3.5.0 |
|
3.6.0 |
|
3.7.0 |
|
3.8.0 |
|
3.9.0 |
|
4.0.0 |
|
4.1.0 |
|
4.2.0 |
|
4.3.0 |
|
4.4.0 |
|
4.5.0 |
|
4.6.0 |
|
4.7.0 |
|
4.8.0 |
|
4.9.0 |
|
5.0.0 |
|
5.1.0 |
|
5.2.0 |
|
5.3.0 |
|
5.4.0 |
|
5.5.0 |
|
5.6.0 |
|
5.7.0 |
|
5.8.0 |
|
5.9.0 |
|
6.0.0 |
|
6.1.0 |
|
6.2.0 |
|
6.3.0 |
|
6.4.0 |
|
6.5.0 |
|
6.6.0 |
|
6.7.0 |
|
6.8.0 |
|
6.9.0 |
4.6. BOOST_PLAT
platform macros
4.6.4. BOOST_PLAT_IOS_SIMULATOR
Symbol | Version |
---|---|
|
detection |
|
detection |
4.6.5. BOOST_PLAT_MINGW
MinGW platform, either variety. Version number available as major, minor, and patch.
Symbol | Version |
---|---|
|
detection |
|
detection |
|
V.R.0 |
|
V.R.0 |
4.6.6. BOOST_PLAT_MINGW32
MinGW platform. Version number available as major, minor, and patch.
Symbol | Version |
---|---|
|
detection |
|
V.R.0 |
4.6.7. BOOST_PLAT_MINGW64
MinGW-w64 platform. Version number available as major, minor, and patch.
Symbol | Version |
---|---|
|
detection |
|
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 |
---|---|
|
detection |
|
detection |
4.6.9. BOOST_PLAT_WINDOWS_PHONE
UWP for Windows Phone development.
Symbol | Version |
---|---|
|
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 |
---|---|
|
detection |
|
detection |
4.6.11. BOOST_PLAT_WINDOWS_SERVER
UWP for Windows Server development.
Symbol | Version |
---|---|
|
detection |
4.6.12. BOOST_PLAT_WINDOWS_STORE
UWP for Windows Store development.
Symbol | Version |
---|---|
|
detection |
|
detection |
4.6.13. BOOST_PLAT_WINDOWS_SYSTEM
UWP for Windows System development.
Symbol | Version |
---|---|
|
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 |
---|---|
|
|
|
|
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 |
---|---|
|
detection |
|
detection |
|
detection |
|
detection |
Symbol | Version |
---|---|
|
BOOST_HW_SIMD_ARM_NEON_VERSION |
|
BOOST_HW_SIMD_ARM_NEON_VERSION |
|
BOOST_HW_SIMD_ARM_NEON_VERSION |
|
BOOST_HW_SIMD_ARM_NEON_VERSION |
4.7.3. BOOST_HW_SIMD_ARM_*_VERSION
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 |
---|---|
|
detection |
|
detection |
|
detection |
|
detection |
Symbol | Version |
---|---|
|
BOOST_HW_SIMD_PPC_QPX_VERSION |
|
BOOST_HW_SIMD_PPC_VMX_VERSION |
|
BOOST_HW_SIMD_PPC_VMX_VERSION |
|
BOOST_HW_SIMD_PPC_VSX_VERSION |
4.7.5. BOOST_HW_SIMD_PPC_*_VERSION
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 |
---|---|
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
|
detection |
Symbol | Version |
---|---|
|
BOOST_HW_SIMD_X86_SSE_VERSION |
|
BOOST_HW_SIMD_X86_SSE_VERSION |
|
BOOST_HW_SIMD_X86_SSE_VERSION |
|
BOOST_HW_SIMD_X86_SSE2_VERSION |
|
BOOST_HW_SIMD_X86_SSE2_VERSION |
|
BOOST_HW_SIMD_X86_SSE2_VERSION |
|
BOOST_HW_SIMD_X86_SSE3_VERSION |
|
BOOST_HW_SIMD_X86_SSSE3_VERSION |
|
BOOST_HW_SIMD_X86_SSE4_1_VERSION |
|
BOOST_HW_SIMD_X86_SSE4_2_VERSION |
|
BOOST_HW_SIMD_X86_AVX_VERSION |
|
BOOST_HW_SIMD_X86_FMA3_VERSION |
|
BOOST_HW_SIMD_X86_AVX2_VERSION |
4.7.7. BOOST_HW_SIMD_X86_*_VERSION
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 |
---|---|
|
detection |
|
detection |
|
detection |
|
detection |
Symbol | Version |
---|---|
|
BOOST_HW_SIMD_X86_SSE4A_VERSION |
|
BOOST_HW_SIMD_X86_FMA4_VERSION |
|
BOOST_HW_SIMD_X86_XOP_VERSION |
|
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:
-
The indispensable documentation of "Pre-defined Compiler Macros" Endianness.
-
The various endian specifications available in the Wikipedia computer architecture pages.
-
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
, andBOOST_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
whenBOOST_DETECT_OUTDATED_WORKAROUNDS
is not defined. -
A value convertible
true
when the expansion ofBOOST_PREDEF_WORKAROUND(symbol, ⇐, major, minor, patch)
istrue
andBOOST_DETECT_OUTDATED_WORKAROUNDS
is defined. -
A compile error when the expansion of
BOOST_PREDEF_WORKAROUND(symbol, >, major, minor, patch)
is true andBOOST_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_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.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.2. 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.3. 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.4. 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.5. 1.10
-
Fix bad include of sub-BSD os headers from main BSD header.
-
Fix use of deprecated
TARGET_IPHONE_SIMULATOR
instead of newerTARGET_OS_SIMULATOR
. -
Add
BOOST_PLAT_ANDROID
to resolve conflict between Linux and Android OS predefs. TheBOOST_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.6. 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.7. 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.8. 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.9. 1.6
-
Fix Intel C/C++ version 9999 detection to be 12.1.0.
-
Addition of
BOOST_PREDEF_WORKAROUND
andBOOST_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.10. 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.11. 1.4.1
-
Small fixes for some redefinition errors, and mispelled macros.
-
Slightly rearrangement of structure to comply with current library requirements.
6.12. 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.13. 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
andor
logical operators forpredef_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.14. 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.15. 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).
|
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