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.