Re: [boost] Libraries and C++ compliance

On Wed, Apr 12, 2017 at 2:01 PM, Edward Diener via Boost < boost@lists.boost.org> wrote:

On 4/12/2017 1:55 AM, Bruno Dutra via Boost wrote:

...

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.

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.

I totally agree.

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.

I only realized this was not covered by the docs after reading this thread, I absolutely agree this is something worth of documenting, in fact I'm working on it.

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.

I think novel libraries tend to emphasize the compilers on which they are tested, because they often rely on bleeding edge features that might only be available on fairly recent and specific compiler versions (think Boost.Hana), whereas mature libraries need not care about this as much, as compilers eventually catch up and features become mainstream. Bruno