Re: [boost] Libraries and C++ compliance

Subject: Re: [boost] Libraries and C++ compliance
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2017-04-12 08:56:58

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] 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" <boost_at_[hidden]>
> 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
[phone]