[boost] [Predef] Pre-review comments

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

Misc
====

- 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?

Naming
======

- 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 
(BOOST_CXX_GNUC)

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 
configurations.

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 
currently use BOOST_SYSTEM_WINDOWS_API / BOOST_SYSTEM_POSIX_API)