C++ Logo


Advanced search

Re: [SG10] Should there be feature-testing for library features?

From: Nelson, Clark <clark.nelson_at_[hidden]>
Date: Fri, 25 Jan 2013 17:31:31 +0000
> > 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.


Received on 2013-01-25 18:41:26