> I know you may say that SG-10 is not really concerned with C++11
> because
> most
> compiler implementers have completely implemented it but I say
> that some
> have not and it would help if you could get them to agree to
> provide ways of
> detecting which features are implemented or not.

SG10 is interested in those features of C++11 that haven't been implemented
in every commercially-significant compiler; that's the purpose of the table
of C++11 features we already have.

The interesting question is whether an implementation that already provides
every C++11 feature, and already sets the value of the __cplusplus macro to
indicate that, would really be interested in adding several dozen new
redundant macro definitions, one for each individual feature. Personally, I
have my doubts.

Even if they did, that would not help any existing code base at all, since
that code needs to continue to work with all the implementations already
released that don't define these macros, but do have the corresponding
features.

It's conceivable that having a defined macro for each implemented feature of
C++11 might help people starting to work on a new code base. But with a
brand-new project, it's way simpler just to mandate the use of an
implementation that implements all of the C++11 features, and be done with
it.

There just doesn't seem to be any way that doing the same sort of work for
C++11 that we have already done for C++14 could realistically help the world
to a significant degree.

> At this stage since there is no way to detect which C++11 features
> are
> implemented and C++14 in some compilers, therefore it might be a
> good idea to
> suggest to Herb Sutter to publish a table in isocpp.org. This
> table should list all
> compiler implementations and should include which version of each
> implementation a C++11/C++14 (by proposal number, i.e. combining
> the tables
> I mentioned above) it was added in. I'm assuming that
> representatives of the
> compiler implementers are members of the ISO C++ committee
> therefore this
> table should not be too difficult to put together. I would also
> suggest to
> maintain the table for each revision of the standard.

I'm afraid creating such a table would involve considerable effort, and
maintaining it would be even more of a pain. Even worse, while it would be
interesting from a sort of marketing perspective -- enabling people to
compare implementations to figure out which one to use -- it would
necessarily be far less useful to programmers than for implementers to just
follow the recommendations we have already published, so code can be
written to work on a variety of implementations.

I would way rather see implementers put work into their implementations than
into marketing collateral.

If you want to produce the table you describe, please feel free to work on
it. But you might first want to check with Herb to see if he thinks it would
be appropriate to publish on isocpp.org.

Clark