Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at