Re: [boost] Libraries and C++ compliance

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Bruno Dutra via Boost Sent: 12 April 2017 06:55 To: Boost Developers List Cc: Bruno Dutra; Edward Diener Subject: Re: [boost] Libraries and C++ compliance

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.

+1 'Compliance with standard C++n ' is still a bit woolly - we haven't got any C++ compiler to a 'no known bugs' state. Failure to pass one library test doesn't necessarily mean that the library is not useful with that compiler - it may work usefully for many purposes. Passing all tests doesn't necessarily mean everything is perfect either. So I feel it is still helpful * to say which compilers passes all tests, so should work, * to say which compilers definitely won't work, * but also useful to say which compilers that probably or might work - but good luck ;-) Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830