-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Niall Douglas via Boost Sent: 10 April 2017 08:05 To: boost@lists.boost.org Cc: Niall Douglas Subject: Re: [boost] Libraries and C++ compliance

On 10/04/2017 03:24, Edward Diener via Boost wrote:

...

Please, please library authors this is important. No end-user or tester of your library wants to spend extended time trying to figure out why some compile fails when the answer turns out simply to be one of inadequate C++ conformance level for a particular compiler implementation being used with a particular level of conformance.

+1 - this IS really important to users. (and even info on what happens with older versions that the author cannot test, including any clues. "Some parts will probably work with C++ 2003 but no tested." are also useful). Using BOOST_STATIC_ASSERT_MSG at the right places is really helpful too.

Outcome is up for review here end of May.

Are you happy with its compiler support at https://ned14.github.io/boost.outcome/prerequisites.html? To save people clicking on the link:

"Outcome is a header only C++ 14 library known to work on these compilers or better:

clang 3.5 (LLVM) clang 3.7 (with Microsoft Codegen) GCC 5.4 VS2015 Update 2 Xcode 7.3 <snip>

Yes - just right. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

On 10/04/2017 10:09, Olaf van der Spek wrote:

On Mon, Apr 10, 2017 at 9:04 AM, Niall Douglas via Boost wrote:

...

Warning: MSVC generates significant code bloat when using Outcome in large code bases. If you can use VS2017 which implements C++ 14 constexpr and has a better optimiser for modern C++, you will see tigher executables. Execution speed is not particularly different, though one would have thought the extra cache load caused by code bloat might affect some applications. In this situation, use LLVM clang targeting

What situation? VS2015?

...

the MSVC ABI."

Note the phrase "Warning: **MSVC** generates significant ..." Note the earlier mention that VS2015 Update 2 or later is known to work. This implies VS2015 Update 1 or earlier does not. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 11/04/2017 08:03, Olaf van der Spek wrote:

...

...

...

Warning: MSVC generates significant code bloat when using Outcome in large code bases. If you can use VS2017 which implements C++ 14 constexpr and has a better optimiser for modern C++, you will see tigher executables. Execution speed is not particularly different, though one would have thought the extra cache load caused by code bloat might affect some applications. In this situation, use LLVM clang targeting

What situation? VS2015?

...

the MSVC ABI."

Note the phrase "Warning: **MSVC** generates significant ..."

Note the earlier mention that VS2015 Update 2 or later is known to work. This implies VS2015 Update 1 or earlier does not.

Does it not work at all or does it do bloated code?

What did the statement say? "Outcome is a header only C++ 14 library known to work on these compilers or better: clang 3.5 (LLVM) clang 3.7 (with Microsoft Codegen) GCC 5.4 VS2015 Update 2 Xcode 7.3" I cannot help if you don't read the text.

...

VS2017 which implements C++ 14 constexpr and has a better optimiser for modern C++, you will see tigher executables.

This bit makes it sound VS2017 is required to avoid the code bloat.

Exactly what the statement says. I don't see why we are discussing this? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On Mon, Apr 10, 2017 at 3:04 AM, Niall Douglas via Boost < boost@lists.boost.org> wrote: clang 3.5 (LLVM)

clang 3.7 (with Microsoft Codegen) GCC 5.4 VS2015 Update 2 Xcode 7.3

That's good, but as Edward pointed out knowing what values of -std= (or equivalent) are required is also needed. If the -std= default is acceptable, that should be mentioned too. Thanks, --Beman

On 4/10/2017 7:15 AM, Beman Dawes via Boost wrote:

On Mon, Apr 10, 2017 at 3:04 AM, Niall Douglas via Boost < boost@lists.boost.org> wrote:

clang 3.5 (LLVM)

...

clang 3.7 (with Microsoft Codegen) GCC 5.4 VS2015 Update 2 Xcode 7.3

That's good, but as Edward pointed out knowing what values of -std= (or equivalent) are required is also needed. If the -std= default is acceptable, that should be mentioned too.

The -std= default changes with each compiler/version so that is not necessary IMO for library authors to know or say. Niall mentioned C++14 so that is what is useful when someone says what their library needs. How C++14 translates to std= should be part of what the end-user should know when he uses a library with different compiler/versions. For instance my own particular setup for testing Boost libraries with Boost Build translates "c14" at the end of my own toolset "names" to the particular 'std=" switch for different compiler/versions I use for C++14 support. While this is usually "std=c++14" it does not have to be that, as sometimes something else works instead, such as "std=c++1y". Of course some compilers, aka VC++, can not be adjusted in such a way, so that it is also important for the end-user himself to know what level of compliance a particular compiler supports. I am far more concerned that library authors just state clearly what level of C++ compliance is needed to use their library and/or what level of C++ compliance is needed to use certain features of their library if those features differ from the general level. Of course stating what particular C++ construct support is needed, over and above basic C++1998/2003 support, also is helpful. As a side note I would really like to see libraries, which are tailored for Boost, use the Boost Config C++ feature testing macros to put out preprocessor #error messages when a feature that it needs is not supported during compilation, rather than letting the compiler simply fail because the construct in code cannot be parsed at the C++ conformance level the code expects. I even note that a number of our current libraries do not do this, but should. It is much more understandable to get a preprocessor #error message specific to the C++ feature needed in such cases, than to get a nest of difficult to decipher compile failures for particular constructs.

...

As a side note I would really like to see libraries, which are tailored for Boost, use the Boost Config C++ feature testing macros to put out preprocessor #error messages when a feature that it needs is not supported during compilation, rather than letting the compiler simply fail because the construct in code cannot be parsed at the C++ conformance level the code expects.

This should happen during configure step, so that the user gets an error before even building the library.

A library's headers may have much lower demands on the C++ version than the source code. So your headers should still do feature checking and #error out. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

AMDG On 04/10/2017 08:35 AM, Paul Fultz II via Boost wrote:

...

On Apr 10, 2017, at 9:05 AM, Edward Diener via Boost wrote:

As a side note I would really like to see libraries, which are tailored for Boost, use the Boost Config C++ feature testing macros to put out preprocessor #error messages when a feature that it needs is not supported during compilation, rather than letting the compiler simply fail because the construct in code cannot be parsed at the C++ conformance level the code expects.

This should happen during configure step, so that the user gets an error before even building the library.

That works for libraries that have a configure step, which is not most Boost libraries. In Christ, Steven Watanabe

course some compilers, aka VC++, can not be adjusted in such a way, so that it is also important for the end-user himself to know what level of compliance a particular compiler supports.

The newer MSVC's now have a /std: switch. You'll be glad to know it doesn't follow the same semantics as -std= because well, it's Microsoft. cmake 3.8 does not appear to understand the MSVC /std: switch yet because if you ask it for the C++ 17 standard when targeting MSVC, it pukes.

As a side note I would really like to see libraries, which are tailored for Boost, use the Boost Config C++ feature testing macros to put out preprocessor #error messages when a feature that it needs is not supported during compilation, rather than letting the compiler simply fail because the construct in code cannot be parsed at the C++ conformance level the code expects. I even note that a number of our current libraries do not do this, but should. It is much more understandable to get a preprocessor #error message specific to the C++ feature needed in such cases, than to get a nest of difficult to decipher compile failures for particular constructs.

Most of the compilers released during the last two years have varying support for C++17 feature test macros (VS2017 is very compliant here interestingly). If your library has no dependency on Boost, use those. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 11/04/2017 04:57, Edward Diener via Boost wrote:

On 4/10/2017 10:53 AM, Niall Douglas via Boost wrote:

...

The newer MSVC's now have a /std: switch. You'll be glad to know it doesn't follow the same semantics as -std= because well, it's Microsoft.

The new MSVC remains completely undocumented more than one month after it has been released, so whatever /std: switch it does have is guesswork AFAICS. But yes, if the new MSVC has such a switch it is an advance over the previous versions which just offered a single level of C++ compliance, whatever it was, which the end-user had to understand exactly.

There's an official blog post about it: https://blogs.msdn.microsoft.com/vcblog/2016/06/07/standards-version-switche... And it's documented in the new doc wiki site (although the search is atrociously bad, so you can't find it unless you already know what you're looking for and even then have to navigate through several side paths before you can get to it): https://docs.microsoft.com/en-us/cpp/build/reference/std-specify-language-st...

On 11/04/2017 21:54, Andrey Semashev via Boost wrote:

On 04/11/17 02:24, Gavin Lambert via Boost wrote:

...

There's an official blog post about it:

https://blogs.msdn.microsoft.com/vcblog/2016/06/07/standards-version-switche...

Blog is not documentation. One should not be required to follow blogs or other social media to know how to use a compiler.

Which is why the second link I posted was an official documentation link.

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

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.

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

On 4/10/2017 7:24 PM, Gavin Lambert via Boost wrote:

On 11/04/2017 04:57, Edward Diener via Boost wrote:

...

On 4/10/2017 10:53 AM, Niall Douglas via Boost wrote:

...

The newer MSVC's now have a /std: switch. You'll be glad to know it doesn't follow the same semantics as -std= because well, it's Microsoft.

The new MSVC remains completely undocumented more than one month after it has been released, so whatever /std: switch it does have is guesswork AFAICS. But yes, if the new MSVC has such a switch it is an advance over the previous versions which just offered a single level of C++ compliance, whatever it was, which the end-user had to understand exactly.

There's an official blog post about it:

https://blogs.msdn.microsoft.com/vcblog/2016/06/07/standards-version-switche...

And it's documented in the new doc wiki site (although the search is atrociously bad, so you can't find it unless you already know what you're looking for and even then have to navigate through several side paths before you can get to it):

https://docs.microsoft.com/en-us/cpp/build/reference/std-specify-language-st...

It seems as if Microsoft has now decided to put their documentation online, but not currently viewable locally as help topics. Thanks for alerting me to this. Online docs are certainly better than no docs, even if the TOC, Index and Search are much worse, if not non-existent, online.