Add a dedicated Standard C++ Library vendor macro string

[Quuxplusone]

Bugzilla Link	PR25407
Status	NEW
Importance	P enhancement
Reported by	m-w4@gmx.de
Reported on	2015-11-05 00:53:29 -0800
Last modified on	2015-11-09 05:56:37 -0800
Version	trunk
Hardware	All All
CC	dgregor@apple.com, llvm-bugs@lists.llvm.org, rnk@google.com
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also

Unlike other compilers, Clang supports various Standard C++ Libraries. It is
extremely difficult to determine from inside a program code which library from
which vendor in which version is actually used. Currently that is somewhat
feature-based. The problem emerges in particular on windows having gcc, clang's
libc++ and msvc, but also on linux having gcc and clang.
It would be most helpful to have a dedicated predefined macro string indicating
the vendor and the compiler/library version of that vendor. As an example,
clang could provide a __LIBCXX_VENDOR="GCC" and
__LIBCXX_VENDOR_VERSION="4.8.3", or accordingly __LIBCXX_VENDOR="CLANG" with
__LIBCXX_VENDOR_VERSION="3.7.0" etc. Such definitions would simplify the
identification of known peculiarities between the different implementations in
a program code, in particular for C++14 and newer features.

[Quuxplusone]

How do you propose for clang to know what standard library you are using or what version it is? It would just be a guess based on the include path.

[Quuxplusone]

Well, I was hoping a compiler to have more information than what could be done from a set of #ifdef macros or a build system like cmake. However, I'm not really familiar with compiler internals. The only solution I could come up with from a pure users perspective is detecting the default system library (e.g. libstdc++) and the libc++ at the build time of clang itself, and feeding that as input for those macros. Then again, all other (also like no std includes) would still be difficult/impossible to determine and could result in a 'CUSTOM' or 'UNKNOWN' value. Also recognizing the whole thing to be probably more of a linker's job, it seems like such vendor identification should rather be a definition in the C++ libraries itself. But that would be a matter for the standard committee.

Anyway, you might come up with a more useful approach for which I would be really happy. If not, just ignore or keep it in mind for some future improvements...