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.
- BOOST_CXX_GNUC might be better as BOOST_CXX_GNU or BOOST_CXX_GCC
- BOOST_OS_DRAGONFLY_BSD might be better as BOOST_OS_BSD_DRAGONFLY to
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
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
currently use BOOST_SYSTEM_WINDOWS_API / BOOST_SYSTEM_POSIX_API)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk