On Apr 12, 2017 1:13 AM, "Edward Diener via Boost"
wrote:
But again I do not see the issue of libraries having to document which
compilers and in which modes they support rather than which level of
coompliance the library supports. It is then up to the end-user to
understand the compiler(s) being used and to use the proper compiler
switches for a given library. My OP was to get library creators to take
seriously the effort to specify the C++ compliance level(s) of their
library in the library docs.
I would just like to point out, that sometimes it's not enough to document
*just* what's the minimum C++ standard a library requires, because we must
not forget that compilers have plenty of bugs, irrespective of whether they
support the required C++ features or not, so it is *also* necessary to
document which specific version of compilers it's known to work with.
Take Metal for instance, the only C++14 feature it requires are relaxed
constant expressions, but there is a built in workaround for compilers that
don't implement it, so it would technically be possible to use it even on a
C++11 compiler that implements alias templates and in fact it works on MSVC
14 and GCC < 5 relying solely on C++11 features. However still MSVC 12 and
the Intel Compiler are unable to pass a single unit test because they have
serious issues with the kind of SFINAE Metal relies on. up until recently
it also didn't work on GCC prior to 5, because of similar issues and it
only works on MSVC 14 because of a myriad of workarounds and *a lot* of
effort invested on working around it's many bugs. IOW in the case of Metal
it's just as important to document which compilers it's known to work with
as it is to state the level of C++ compliance required.
Bruno
