Boost logo

Boost :

Subject: [boost] [Predef] Pre-review comments
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2012-02-19 07:37:32


- This stuff partially exists in Boost.Config. How will this be integrated?

- AMD stands for Advanced Micro Devices, not American Micro Devices

- The whole set of C and C++ standard libraries doesn't seem to be
covered. Are we supposed to infer it from the compiler or operating system?


- BOOST_ARCHITECTURE_ is maybe a bit long. Have you considered a shorter
name like BOOST_ARCH_ALPHA ?
Same comment for BOOST_LANGUAGE_

- BOOST_LANGUAGE_XXX uses a STD prefix for most languages except for
Objective-C. How about dropping the STD prefix? Also why not use CXX
instead of CPP?

- Standard C library is identified by LIBC, but standard C++ library is
identified by LIBSTD. I find that confusing, it should be orthogonal.
I take it LIBCXX wasn't chosen due to possible confusion with libc++.
It's their fault for choosing a ridiculously broad name. glibc is often
just called libc as well, yet this is not a problem.


indicate that "macro refinement" goes left to right.
It could be BOOST_OS_BSD_FREEBSD for FreeBSD.

Compiler frontend vs backend

The BOOST_CXX_ macros is used to define both frontends (BOOST_CXX_CLANG,
BOOST_CXX_EDG) and backends (BOOST_CXX_LLVM) and things that can be both

As for BOOST_CXX_CYGWIN, I have no idea what it's doing there. Cygwin
should be exclusively in BOOST_OS_CYGWIN. The compiler is a normal GCC.

As such it might be hard to tell which set of flags might be defined at
the same time.

Maybe the solution would be to split the set of frontends and backends,
with each value in each set being mutually exclusive.
Most compilers do not decouple frontends and backends, so it will end up
with a lot of unnecessary duplication though.

Non-mutually exclusive macros

Currently, the only macros that are not mutually-exclusive (outside of
the CXX macros outlined above, since they cover two different things)
are the BOOST_OS_BSD macros along with BOOST_OS_UNIX and BOOST_OS_SVR4.

It might be a good idea to expand on that on the architecture side (i.e.
any x86, 32 or 64 bit), and the compiler side (GCC-like compilers).
There are many variants of ARM as well, and a new 64-bit ARM will be
released soon. The design needs to be flexible enough to integrate this.

It might be good as well to put a clear distinction between a set of
mutually-exclusive macros and more global macros that can cover several

My use-cases

Just a few real use cases for which I use custom code in my software
today, and that I'd be glad to replace:

- Work-around a bug in the GCC frontend
- Use a feature present in GCC-like frontends
- Work-around a bug in the GCC backend
- Define special versions of functions for x86 both 32- and 64-bit
- Define special versions of functions for x86-64 only
- Use special code for Windows or POSIX operating systems (for that, I

Boost list run by bdawes at, gregod at, cpdaniel at, john at