Subject: Re: [SG10] Should there be feature-testing for library features?
From: Nelson, Clark (clark.nelson_at_[hidden])
Date: 2013-01-25 11:31:31
> > But at the very least, I know that there's no way to use SFINAE to see
> whether an implementation has a specific library header. Would there be
> value in enabling people to write code that will adapt at that level to
> implementations that have made different degrees of progress toward
> implementing standard library features?
> We have some implementation experience here: Clang provides a
> __has_include, but nothing more granular.
Hmm, this raises an interesting question.
The lexical grammar has a production called "header-name". Its purpose is to prevent macro-expansion. That's important for header names within angle brackets. Otherwise, imagine what might happen if someone tried to include <errno.h> more than once, considering that <errno.h> defines a macro named "errno".
The interesting thing about this __has_include macro is that it is presumably a new context in which a header-name token is expected. That makes it pretty special.
Not that it isn't already pretty special. It certainly can't be implemented as a macro, not if its job is to scan include directories.
The ideal outcome of what we're doing would be a nearly seamless transition from one standard to the next; that it would be possible to write code that just works on a bunch of implementations, regardless of their degree of support for new features.
But there's probably no way to achieve that as regards new library headers. If a compiler doesn't have support for header-testing, code that tries to test for a new header is likely just to fail to compile, even if it could gracefully and correctly recover from the absence.
SG10 list run by email@example.com