Re: [boost] Libraries and C++ compliance

Subject: Re: [boost] Libraries and C++ compliance
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-04-12 12:01:04

On 4/12/2017 1:55 AM, Bruno Dutra via Boost wrote:
> 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.

I do not think it is necessary to document with which compilers a 
library works, but it may certainly be helpful, as in your case. But 
this is still usually secondary to documenting the level of C++ 
compliance needed, which is primary. Compilers can change, even though 
older versions of compilers tend not to be "fixed" once a later version 
of a compiler is issued. So documentation saying that library LLL 
works/does-not-work with compilerX/versionY/C++modeZ is valuable, but 
usually less so than being specific as possible about library LLL's 
level of C++ compliance and/or the C++ features it uses at any level of 
C++ compliance.

My point is simply that if a library simply tells me only that it works 
with compilerX or with compilerX/versionY or even with 
compilerX/versionY/C++modeZ, it is not helpful to me at all if I need to 
know if it will work with compilerA/versionB/C++modeC. Whereas if it 
tells me the level of C++ compliance it needs and/or the C++ features it 
uses at any given level I usually have much better information about 
whether or not it will work with the compiler I am using.

> 
> 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.

These are great things to document. If a library has a fallback to using 
some lower level of C++ compliance that definitely needs to be 
documented. Again I wish to point out that even your remarks here, such 
as mentioning 'the Intel compiler', means very little to the end-user 
unless you mention versions and C++ compliance modes along with it in 
your official documentation.

> 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.

Well Boost PP "works" with the non-standard VC++ preprocessor of VC++ 8 
through the latest version of VC++ just released ( call it 14.1 ) 
through many workarounds, but the doc does not have to say this 
explicitly IMO unless the end-user has to do something special to get it 
to work in some cases.

Again I would be as specific as possible in the docs in Metal vis a vis 
certain compilers/versions/C++ compliance modes. I am not arguing in any 
way against such documentation.

> 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