New C++14 config macros - opinions wanted
There is a pull request to add new config macros for C++14 features (https://github.com/boostorg/config/pull/39), I have a few questions really, particularly for those more familiar with C++14 than me: * Do we need these? * Are these the correct names? * Are the proposed tests correct? Thanks, John.
On Wed, Sep 24, 2014 at 10:12 AM, John Maddock
* Do we need these?
Some of them would be nice to have, in any case. e.g. The absence of BOOST_NO_CXX14_VARIABLE_TEMPLATES would enable a library author to provide things like _v value traits [conditionally, for those who only care about C++14 and want to use them, or just for consistency with the C++ standard library that now provides them].
* Are these the correct names?
I think these ones are reasonable: - BOOST_NO_CXX14_DECLTYPE_AUTO - BOOST_NO_CXX14_VARIABLE_TEMPLATES - BOOST_NO_CXX14_GENERIC_LAMBDAS - BOOST_NO_CXX14_BINARY_LITERALS - BOOST_NO_CXX14_DEPRECATED_ATTRIBUTES And this one after renaming slightly: - BOOST_NO_CXX14_RELAXED_CONSTEXPR And this one instead, for lambda capture: - BOOST_NO_CXX14_LAMBDA_CAPTURE_EXPRESSIONS (Or perhaps not, if it's too lengthy)
* Are the proposed tests correct?
I'll put aside some time to look at the tests; I haven't reviewed them yet. Glen
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi John, On 2014/09/25 2:12, John Maddock wrote:
There is a pull request to add new config macros for C++14 features (https://github.com/boostorg/config/pull/39), I have a few questions really, particularly for those more familiar with C++14 than me: Thank you for picking up my PR.
* Do we need these? Fusion starts to support constexpr but, some function don't compile due to unmet c++11 constexpr limitations. I think it is inconvenient for c++11 user who doesn't require constexpr. This is my first motivation.
* Are these the correct names? * Are the proposed tests correct? I anxious the wording; singular or plural form? Is the name too long? ...
Thanks, Kohei Takahashi -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJUI2w5AAoJEGGyPxPRp/zo8coQALUqsQ1w5qej+kSRx+42tGgl Eme2VoOYoPMF6kpFEI7hKT4FNLHWgU5xJdgbahQixbjvban2WcYMdPkEjmry203k ZLvIL+Id4b0AaysgL4WsOpfWqr72z/NjPruuCqrzyqPHHCvgnBBB0b+7Hn7l/bi5 FuQWk+7iyz3n4aZbC6V8uDnBB4lHxyw3kltITpL7VSoz70mCFSJ+Q9SeR7u3BFI0 TIlhnQKsZuRzGIFa3Xbxu4l+w5LT0KhNjQdx48OXCzm6d7SRB6zmeo+re3FfIh3y nWoAikYT6vvdqSQUAjZsUk1ygZDtqDGybaZP2T1EsPPVmRWP7wiUPZQamWMAkp+E WIQ5sCiiv4spRdpXumaMxhUb7xuRFlJpslpZo2g6289FWKfcUFJW/p9VOsOE1PQ/ guUb0jw921C+EPaRf6mC85dkt9pt9eXLUyB+/StBbLzckr+eDU0K2MqL7c03fOBM 3sX6i6qbrUriD20chPkix7vGPYHs52V/ySda4XqY834lZzNn9KY7QL4fIAXknqLd pJWJ6l+XZugxBTdCM0JnQsDmSQpBG0+jT5QSt8AkXvCxBKPoUYgL/QUGuELq8xJ2 PgaCLlFZ5bmBT2SP9l4imIgW2vzWMAp6PhK1dut9UuyKx4/LqvJrMz6BEwmyGwfC FV8VlAugwRUtyOGDj/H1 =Oof+ -----END PGP SIGNATURE-----
Le 24/09/14 19:12, John Maddock a écrit :
There is a pull request to add new config macros for C++14 features (https://github.com/boostorg/config/pull/39), I have a few questions really, particularly for those more familiar with C++14 than me:
* Do we need these? Yes I think. * Are these the correct names? I suggest to take a look at the names clang uses and choose the better
http://clang.llvm.org/docs/LanguageExtensions.html
* Are the proposed tests correct?
I'll take a look next weekend. Vicente
John Maddock wrote:
There is a pull request to add new config macros for C++14 features (https://github.com/boostorg/config/pull/39), I have a few questions really, particularly for those more familiar with C++14 than me:
* Do we need these?
As a data-point, Qt expects the SD-6 macros to be present and working for C++14 features, instead of providing similar macros. https://codereview.qt-project.org/#/c/87474/ I'd recommend to use the SD-6 macros instead wherever provided, until there's a reason to add a wrapper macro (such as a broken implementation).
* Are these the correct names?
CMake also aims to use the same names as used by clang __has_feature, with a few exceptions. Mostly these are also the same as the SD-6 names. http://www.cmake.org/cmake/help/git-master/prop_gbl/CMAKE_CXX_KNOWN_FEATURES... Given that SD-6 uses one name with different numerical values (__cpp_constexpr) for something which clang expresses with two names (__cxx_constexpr and __cxx_relaxed_constexpr), and given that C++17 might make constexpr even more 'relaxed', it's not certain how long naming can be sub-contracted to clang :). Thanks, Steve.
On Thu, Sep 25, 2014 at 10:50 AM, Stephen Kelly
John Maddock wrote:
There is a pull request to add new config macros for C++14 features (https://github.com/boostorg/config/pull/39), I have a few questions really, particularly for those more familiar with C++14 than me:
* Do we need these?
As a data-point, Qt expects the SD-6 macros to be present and working for C++14 features, instead of providing similar macros.
The problem with SD-6 is that different compilers may implement features with different levels of conformance, including SD-6 itself. IMHO, besides __has_include, these feature test macros are not very useful and are basically equivalent to testing the compiler version and similar macros. I don't think Boost libraries should rely on these macros directly. Boost.Config, OTOH, may use these macros to define its own macros, if it is known that the particular compiler supports SD-6 correctly enough. We can use these macros as reference for naming decisions as well (although I like MEMBER_INITIALIZERS_AND_AGGREGATES more than the cryptic aggregate_nsdmi).
Andrey Semashev wrote:
I don't think Boost libraries should rely on these macros directly. Boost.Config, OTOH, may use these macros to define its own macros, if it is known that the particular compiler supports SD-6 correctly enough.
Find more opinion/discussion regarding these issues here: http://thread.gmane.org/gmane.comp.lang.c++.isocpp.features/17/focus=24 Thanks, Steve.
I don't think Boost libraries should rely on these macros directly. Boost.Config, OTOH, may use these macros to define its own macros
Agreed. I think that Boost.Config should aim to be forward-compatible with the SD-6 macros / feature tests. What I mean is that the naming and categorization of the features and headers should be more or less a 1-to-1 mapping to SD-6 such that at some point in the future, when many compilers provide SD-6 feature tests, the Boost.Config macro will simply need to wrap (or be defined by) the SD-6 macros. But, of course, you cannot rely on SD-6 for that now, but you can lay out the names and category in concert with SG10 (and Clang dev-team too, as they are leading on this issue) to make sure that Boost.Config and SD-6 have a harmonious future. Doesn't everyone agree that in the best of worlds, say in 5-10 years, Boost.Config would be nothing more than a wrapper for SD-6 macros? Wouldn't that be wonderful maintenance-wise? No more endless tweaking for which compiler and version supports which feature (at least, assuming compiler vendors are honest when advertising their features through the SD-6 macros). Oh, and you need to add a macro for n3644 "null forward iterators", because it's an important C++14 feature ;) That's my two-cents, Mikael.
On 25/09/14 08:50, Stephen Kelly wrote:
John Maddock wrote:
There is a pull request to add new config macros for C++14 features (https://github.com/boostorg/config/pull/39), I have a few questions really, particularly for those more familiar with C++14 than me:
* Do we need these?
As a data-point, Qt expects the SD-6 macros to be present and working for C++14 features, instead of providing similar macros.
https://codereview.qt-project.org/#/c/87474/
I'd recommend to use the SD-6 macros instead wherever provided, until there's a reason to add a wrapper macro (such as a broken implementation).
Which compilers correctly implement this and which do not? Some of the C++14 features as available as early as GCC 4.7, Clang 3.4 and VS14 CTP1. Do all of these support SD-6 macros?
On Wed, Sep 24, 2014 at 9:12 PM, John Maddock
There is a pull request to add new config macros for C++14 features (https://github.com/boostorg/config/pull/39), I have a few questions really, particularly for those more familiar with C++14 than me:
* Do we need these?
It won't harm, I guess.
participants (8)
-
Andrey Semashev -
Glen Fernandes -
John Maddock -
Kohei Takahashi -
Mathias Gaunard -
Mikael Persson -
Stephen Kelly -
Vicente J. Botet Escriba