Re: [boost] Libraries and C++ compliance

Subject: Re: [boost] Libraries and C++ compliance
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-04-10 14:05:27

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_at_[hidden]> 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.