How do I get ready for C++17? I have a piece of code which requires C++14. I want to use something from C++17 but I also want my code to work now. So I have #if C++14 being used namespace std { // implement C++ function } // std I've looked in the documentation for Boost.Config and can't find any hints there. What is the best way to do this? Robert Ramey
On Sun, Sep 10, 2017 at 12:30 PM, Robert Ramey via Boost < boost@lists.boost.org> wrote:
How do I get ready for C++17?
I have a piece of code which requires C++14. I want to use something
from C++17 but I also want my code to work now. So I have
#if C++14 being used namespace std { // implement C++ function } // std
I've looked in the documentation for Boost.Config and can't find any
hints there.
What is the best way to do this?
Robert Ramey
I like to configure on a per-feature basis, so I use these when boost Boost.Config falls short: http://en.cppreference.com/w/User:D41D8CD98F/feature_testing_macros Barrett
On 9/10/17 11:43 AM, Barrett Adair via Boost wrote:
I like to configure on a per-feature basis, so I use these when boost Boost.Config falls short: http://en.cppreference.com/w/User:D41D8CD98F/feature_testing_macros
Looks like the best answer so far
Barrett
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Wed, Sep 13, 2017 at 4:05 PM, Robert Ramey wrote:
On 9/10/17 11:43 AM, Barrett Adair via Boost wrote:
I like to configure on a per-feature basis, so I use these when boost Boost.Config falls short: http://en.cppreference.com/w/User:D41D8CD98F/feature_testing_macros
Looks like the best answer so far
Boost.Config actually uses the feature testing macros when available and when applicable (in combination with other things, i.e. an understanding of what the C++ implementation in question actually is known to support, regardless of what it advertises). Using the feature testing macros alone may not be what you want. Glen
On 9/13/17 6:17 PM, Glen Fernandes via Boost wrote:
On Wed, Sep 13, 2017 at 4:05 PM, Robert Ramey wrote:
On 9/10/17 11:43 AM, Barrett Adair via Boost wrote:
I like to configure on a per-feature basis, so I use these when boost Boost.Config falls short: http://en.cppreference.com/w/User:D41D8CD98F/feature_testing_macros
Looks like the best answer so far
Boost.Config actually uses the feature testing macros when available and when applicable (in combination with other things, i.e. an understanding of what the C++ implementation in question actually is known to support, regardless of what it advertises). Using the feature testing macros alone may not be what you want.
I'd be happy to used Boost.Config - that's where I looked first. But I don't see what I need in there.
Glen
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 9/13/17 21:24, Robert Ramey via Boost wrote:
On 9/13/17 6:17 PM, Glen Fernandes via Boost wrote:
Boost.Config actually uses the feature testing macros when available and when applicable (in combination with other things, i.e. an understanding of what the C++ implementation in question actually is known to support, regardless of what it advertises). Using the feature testing macros alone may not be what you want.
I'd be happy to used Boost.Config - that's where I looked first. But I don't see what I need in there.
Pull requests are welcome. -- Michael Caisse Ciere Consulting ciere.com
Boost.Config actually uses the feature testing macros when available and when applicable (in combination with other things, i.e. an understanding of what the C++ implementation in question actually is known to support, regardless of what it advertises). Using the feature testing macros alone may not be what you want. I'd be happy to used Boost.Config - that's where I looked first. But I don't see what I need in there.
Pull requests are welcome.
Indeed, or file a feature request. Note that historically Boost.Config has never added new macros unless there is demand from within Boost. And while it's true that we have been laggardly in adding C++17 feature macros, so far no one has ever asked for them either... not once till now. BTW, what I'm missing from this discussion, is exactly what C++17 features you are actually interested in? Finally, with regard to the CD6 macros, one of their issues, is that to determine if std lib feature X is present in header Y, then you must first include header Y. That means that were Boost.Config to wrap SD6 feature detection in it's own convenience macros, then it would end up #including the entire std lib - I think we can all agree that that's not a viable option. So if you want to know if is_invocable is present in <type_traits>, then there is no better way to check, than actually including <type_traits> and checking for that macro. Of course if some of the official macros turn out to be incorrectly set (ie feature is too buggy to actually use), then this can be revisited on a case by case basis. John. --- This email has been checked for viruses by AVG. http://www.avg.com
On 9/14/17 2:27 AM, John Maddock via Boost wrote:
Boost.Config actually uses the feature testing macros when available and when applicable (in combination with other things, i.e. an understanding of what the C++ implementation in question actually is known to support, regardless of what it advertises). Using the feature testing macros alone may not be what you want. I'd be happy to used Boost.Config - that's where I looked first. But I don't see what I need in there.
Pull requests are welcome.
Indeed, or file a feature request.
Hmmm - the problem is i'm already two interrupt levels below where I really want to be. So I was hoping for an existing fix that I didn't really have to think about. If something that starts out seeming trivial often end up sucking up a bunch of unanticipated time.
Note that historically Boost.Config has never added new macros unless there is demand from within Boost.
And while it's true that we have been laggardly in adding C++17 feature macros, so far no one has ever asked for them either... not once till now.
BTW, what I'm missing from this discussion, is exactly what C++17 features you are actually interested in?
BOOST_NO_CXX17_STD_IS_DETECTED According to http://en.cppreference.com/w/cpp/experimental/is_detected it's currently in <experimental/type_traits> as part of library fundamentals v2. I had mistakenly thought it was slated for C++17. So maybe it's not appropriate to include in Boost.Config yet. Robert Ramey
Robert Ramey wrote:
BOOST_NO_CXX17_STD_IS_DETECTED
According to http://en.cppreference.com/w/cpp/experimental/is_detected
it's currently in <experimental/type_traits> as part of library fundamentals v2. I had mistakenly thought it was slated for C++17. So maybe it's not appropriate to include in Boost.Config yet.
The usual practice for such additions is to add boost::is_detected into Boost.TypeTraits, obviating the need for a Config check and each library providing its own fallback. Or, you can use mp_valid from Mp11 instead, although it's not a drop-in replacement.
On Sun, Sep 10, 2017 at 1:30 PM, Robert Ramey via Boost wrote:
How do I get ready for C++17?
I have a piece of code which requires C++14. I want to use something from C++17 but I also want my code to work now. So I have
#if C++14 being used namespace std { // implement C++ function }
Don't define those things inside namespace std. Instead: namespace boost { namespace yours { namespace detail { #if /* C++17 thing available */ using std::thing; #else /* Define thing yourself */ #endif } } } And then use boost::yours::detail::thing in your library. Glen
On 10/09/2017 20:07, Glen Fernandes via Boost wrote:
On Sun, Sep 10, 2017 at 1:30 PM, Robert Ramey via Boost wrote:
How do I get ready for C++17?
I have a piece of code which requires C++14. I want to use something from C++17 but I also want my code to work now. So I have
#if C++14 being used namespace std { // implement C++ function }
Don't define those things inside namespace std. Instead:
namespace boost { namespace yours { namespace detail { #if /* C++17 thing available */ using std::thing; #else /* Define thing yourself */ #endif } } }
And then use boost::yours::detail::thing in your library.
And here is an example of use of exactly that technique which uses std::optional if available with the current compiler's configuration, otherwise a conforming optional<T> implementation: https://github.com/ned14/quickcpplib/blob/master/include/optional.hpp Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
I did the same thing with smart_ptr, allowing for a transition between boost and std in the Apache Thrift project going from C++03 to C++11. Unfortunately it was a bunch of trial and error as no macro seemed to cover it completely. https://github.com/apache/thrift/blob/master/lib/cpp/src/thrift/stdcxx.h - Jim On Sun, Sep 10, 2017 at 8:28 PM, Niall Douglas via Boost < boost@lists.boost.org> wrote:
On 10/09/2017 20:07, Glen Fernandes via Boost wrote:
On Sun, Sep 10, 2017 at 1:30 PM, Robert Ramey via Boost wrote:
How do I get ready for C++17?
I have a piece of code which requires C++14. I want to use something from C++17 but I also want my code to work now. So I have
#if C++14 being used namespace std { // implement C++ function }
Don't define those things inside namespace std. Instead:
namespace boost { namespace yours { namespace detail { #if /* C++17 thing available */ using std::thing; #else /* Define thing yourself */ #endif } } }
And then use boost::yours::detail::thing in your library.
And here is an example of use of exactly that technique which uses std::optional if available with the current compiler's configuration, otherwise a conforming optional<T> implementation:
https://github.com/ned14/quickcpplib/blob/master/include/optional.hpp
Niall
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost
On 11/09/2017 13:11, James E. King, III wrote:
I did the same thing with smart_ptr, allowing for a transition between boost and std in the Apache Thrift project going from C++03 to C++11. Unfortunately it was a bunch of trial and error as no macro seemed to cover it completely.
https://github.com/apache/thrift/blob/master/lib/cpp/src/thrift/stdcxx.h
The comment header in that Smart Pointers block seems incorrect, BTW. I assume you meant that BOOST_NO_CXX11_SMART_PTR was *not* defined in VS2010 and VS2012 (since they do implement std::shared_ptr). For the other part, perhaps you could have made use of BOOST_NO_CXX11_TEMPLATE_ALIASES?
On 9/10/17 12:07 PM, Glen Fernandes via Boost wrote:
On Sun, Sep 10, 2017 at 1:30 PM, Robert Ramey via Boost wrote:
How do I get ready for C++17?
I have a piece of code which requires C++14. I want to use something from C++17 but I also want my code to work now. So I have
#if C++14 being used namespace std { // implement C++ function }
Don't define those things inside namespace std. Instead:
Hmmmm - I've done this from time to time. Why would this be a bad thing?
#if /* C++17 thing available */
Actually, the question I meant to ask is what should go into the /* C++17 thing available */ I was thinking of something from Boost.Config - which I use a lot. Robert Ramey
Glen
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Monday, September 11, 2017, Robert Ramey wrote:
On 9/10/17 12:07 PM, Glen Fernandes via Boost wrote:
On Sun, Sep 10, 2017 at 1:30 PM, Robert Ramey wrote:
#if C++14 being used namespace std { // implement C++ function }
Don't define those things inside namespace std. Instead:
Hmmmm - I've done this from time to time. Why would this be a bad thing?
Because we only define things inside std that we are explicitly granted permission to (such as specializations of specific stand library types).
#if /* C++17 thing available */
Actually, the question I meant to ask is what should go into the
/* C++17 thing available */
I was thinking of something from Boost.Config - which I use a lot.
Yes. You should add BOOST_NO_CXX17_STD_IS_DETECTED or similar to Boost.Config, just as we have added similar C++17 feature detection macros recently (e.g BOOST_NO_CXX17_FOLD_EXPRESSIONS, for Peter to use in Boost.Mp11). We want to have these detections handled in one place that all Boost libraries can benefit from. Implementation vendors don't always define __cplusplus to a value that sensibly or accurately reflect the state of their conformance. Then there could be defects in their implementations that otherwise invalidate what conformance they advertised. Boost.Config is the thing we rely on to tell us otherwise. Glen
On 9/11/17 8:20 AM, Glen Fernandes via Boost wrote:
On Monday, September 11, 2017, Robert Ramey wrote:
On 9/10/17 12:07 PM, Glen Fernandes via Boost wrote:
On Sun, Sep 10, 2017 at 1:30 PM, Robert Ramey wrote:
#if C++14 being used namespace std { // implement C++ function }
Don't define those things inside namespace std. Instead:
Hmmmm - I've done this from time to time. Why would this be a bad thing?
Because we only define things inside std that we are explicitly granted permission to (such as specializations of specific stand library types).
Right. But why do "we" do this. What problem might violating such a permission cause?
Yes. You should add BOOST_NO_CXX17_STD_IS_DETECTED or similar to Boost.Config, just as we have added similar C++17 feature detection macros recently (e.g BOOST_NO_CXX17_FOLD_EXPRESSIONS, for Peter to use in Boost.Mp11).
Hmmmm - this would require more thought. My actual interest is the usage o the "detection idiom". So there should be a BOOST_NO_CXX71_DECTECTION_IDIOM ? Actually that would be ideal for my case. But it would seem to me that that would be quite a narrow audience to justify the effort. I'm willing to assume that any library which claims C++17 conformance would support the detection idiom, but I don't find a macro on Boost.Config which lets me know which version of the C++ standard library is supported. It might be there but I haven't found it. I guess I'm looking for BOOST_C_PLUS_PLUS_LIBRARY_VERSION or something like that.
We want to have these detections handled in one place that all Boost libraries can benefit from. Implementation vendors don't always define __cplusplus to a value that sensibly or accurately reflect the state of their conformance. Then there could be defects in their implementations that otherwise invalidate what conformance they advertised. Boost.Config is the thing we rely on to tell us otherwise.
I get this. I'm a big user and promoter of Boost.Config. Robert Ramey
Glen
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Monday, September 11, 2017, Robert Ramey wrote:
On 9/11/17 8:20 AM, Glen Fernandes via wrote:
Yes. You should add BOOST_NO_CXX17_STD_IS_DETECTED or similar to
Boost.Config, just as we have added similar C++17 feature detection macros
recently (e.g BOOST_NO_CXX17_FOLD_EXPRESSIONS, for Peter to use in Boost.Mp11).
Hmmmm - this would require more thought. My actual interest is the usage o the "detection idiom". So there should be a BOOST_NO_CXX71_DECTECTION_IDIOM ? Actually that would be ideal for my case. But it would seem to me that that would be quite a narrow audience to justify the effort. I'm willing to assume that any library which claims C++17 conformance would support the detection idiom, but I don't find a macro on Boost.Config which lets me know which version of the C++ standard library is supported. It might be there but I haven't found it.
I guess I'm looking for
BOOST_C_PLUS_PLUS_LIBRARY_VERSION
or something like that.
No, something like that sounds much less useful to me. Imagine if 90% of implementations had a correct and working std::is_detected but all of those had a broken or non-existent... say... std::launder, and so the macro you suggest would be defined. You don't care that those implementations don't have std::launder. You just care that they have std::is_detected. BOOST_NO_CXX71_DECTECTION_IDIOM sounds reasonable and still granular enough. Glen
On Mon, Sep 11, 2017 at 10:37 AM, Robert Ramey via Boost < boost@lists.boost.org> wrote:
Because we only define things inside std that we are explicitly granted
permission to (such as specializations of specific stand library types).
Right. But why do "we" do this.
Because the standard says so. See [namespace.std]. When this is violated, well, it's why we can't have nice things. As a user, well, you've invoked undefined behavior. The standard needs a place where it owns all the names.
What problem might violating such a permission cause?
Ever wonder why there is no std::hash_map (with that spelling)? Because vendors used to put their hash_map into namespace std, neither of which was quite compatible with the unordered_map eventually shipped in C++11. It is very deceiving to pretend you are part of the standard when you are not. -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
On 12/09/2017 03:37, Robert Ramey wrote:
On 9/11/17 8:20 AM, Glen Fernandes wrote:
Because we only define things inside std that we are explicitly granted permission to (such as specializations of specific stand library types).
Right. But why do "we" do this. What problem might violating such a permission cause?
You might cause the application to fail to compile correctly when used with an unexpected (or newer or older) STL that defines a conflicting symbol in that namespace. If you're the application author, you can get away with that more often, as you can change your offending code or perhaps use a different STL or different STL version. You don't have as much freedom as a library author.
Yes. You should add BOOST_NO_CXX17_STD_IS_DETECTED or similar to Boost.Config, just as we have added similar C++17 feature detection macros recently (e.g BOOST_NO_CXX17_FOLD_EXPRESSIONS, for Peter to use in Boost.Mp11).
Hmmmm - this would require more thought. My actual interest is the usage o the "detection idiom". So there should be a BOOST_NO_CXX71_DECTECTION_IDIOM ? Actually that would be ideal for my case. But it would seem to me that that would be quite a narrow audience to justify the effort. I'm willing to assume that any library which claims C++17 conformance would support the detection idiom, but I don't find a macro on Boost.Config which lets me know which version of the C++ standard library is supported. It might be there but I haven't found it.
I'm a little surprised that there doesn't seem to be a Boost.Config macro for std::void_t<>; but then there doesn't seem to be many C++17 macros yet at all. Perhaps the maintainer is just waiting to see what people want to test for, first.
I guess I'm looking for
BOOST_C_PLUS_PLUS_LIBRARY_VERSION
or something like that.
__cplusplus gives you the claimed conformance level of the compiler, which is usually (though not necessarily) in agreement with the STL. But that doesn't do you a lot of good as it's a big catch-all (and at least in the case of MSVC lags behind the actual individual feature support). So it's better to test for individual features that you need rather than a conformance level as a whole.
[Gavin Lambert]
__cplusplus gives you the claimed conformance level of the compiler, which is usually (though not necessarily) in agreement with the STL. But that doesn't do you a lot of good as it's a big catch-all (and at least in the case of MSVC lags behind the actual individual feature support).
That's intentional. If we were to update __cplusplus's value before completing C++11 (not to mention C++14/17), the Internet would riot. _MSVC_LANG reports the value that __cplusplus would have (in the recent versions that support /std:c++14, /std:c++latest, and now /std:c++17). Note that it isn't a claim to implement literally everything in the corresponding Standard. STL
On Tue, Sep 12, 2017 at 3:15 AM, Stephan T. Lavavej via Boost <boost@lists.boost.org> wrote:
[Gavin Lambert]
__cplusplus gives you the claimed conformance level of the compiler, which is usually (though not necessarily) in agreement with the STL. But that doesn't do you a lot of good as it's a big catch-all (and at least in the case of MSVC lags behind the actual individual feature support).
That's intentional. If we were to update __cplusplus's value before completing C++11 (not to mention C++14/17), the Internet would riot.
Well, MSVC never implemented C++98/03 completely, yet I think it defined __cplusplus as if it did. I don't think __cplusplus ever did provide any practical indication of the supported language and therefore its value doesn't matter much.
On 12/09/2017 12:15, Stephan T. Lavavej wrote:
[Gavin Lambert]
__cplusplus gives you the claimed conformance level of the compiler, which is usually (though not necessarily) in agreement with the STL. But that doesn't do you a lot of good as it's a big catch-all (and at least in the case of MSVC lags behind the actual individual feature support).
That's intentional. If we were to update __cplusplus's value before completing C++11 (not to mention C++14/17), the Internet would riot. I know it's intentional; that wasn't my point. It wasn't intended as a disparagement, just a statement of fact.
Although having said that, while I can understand the desire to not update it until the standard is fully implemented, it does seem a bit peculiar to do that -- and inconsistent with what GCC/Clang do (they just indicate which version is requested on the command line), so I don't know why you'd get a riot for doing the same as them. In fact I would think that would be a better thing to do, to improve consistency between compilers.
On 11/09/2017 16:58, Robert Ramey via Boost wrote:
On 9/10/17 12:07 PM, Glen Fernandes via Boost wrote:
On Sun, Sep 10, 2017 at 1:30 PM, Robert Ramey via Boost wrote:
How do I get ready for C++17?
I have a piece of code which requires C++14. I want to use something from C++17 but I also want my code to work now. So I have
#if C++14 being used namespace std { // implement C++ function }
Don't define those things inside namespace std. Instead:
Hmmmm - I've done this from time to time. Why would this be a bad thing?
Because it can fail. Newer stdlib implementations use inline namespaces so you just can't forward declare things in namespace std. You need more elaborated tricks: http://www.boost.org/doc/libs/1_65_1/boost/move/detail/std_ns_begin.hpp http://www.boost.org/doc/libs/1_65_1/boost/move/detail/std_ns_end.hpp A Boost.Config or similar library that does this would be useful. That way we could forward declare standard classes instead of pulling the whole header. Best, Ion
Em 10 sept 2017, às 19:30, Robert Ramey via Boost <boost@lists.boost.org> escreveu:
How do I get ready for C++17?
I have a piece of code which requires C++14. I want to use something from C++17 but I also want my code to work now. So I have
#if C++14 being used namespace std { // implement C++ function } // std
I've looked in the documentation for Boost.Config and can't find any hints there.
You might find this technique useful: http://bannalia.blogspot.com/2016/09/compile-time-checking-existence-of.html... The nice thing about it is you don't depend on implementation macros that might or might not be accurate. Joaquín M López Muñoz
On 9/10/17 1:00 PM, Joaquín M López Muñoz via Boost wrote:
Em 10 sept 2017, às 19:30, Robert Ramey via Boost <boost@lists.boost.org> escreveu:
How do I get ready for C++17?
I have a piece of code which requires C++14. I want to use something from C++17 but I also want my code to work now. So I have
#if C++14 being used namespace std { // implement C++ function } // std
I've looked in the documentation for Boost.Config and can't find any hints there.
You might find this technique useful:
http://bannalia.blogspot.com/2016/09/compile-time-checking-existence-of.html...
The nice thing about it is you don't depend on implementation macros that might or might not be accurate.
A little background I've been using the "detection idiom" which has worked well for my purposes. But this idiom is only found in C++17 libraries so I included the code for it in my C++14 application. But now I want to include my local version of the idiom itself only if there isn't one included in with the library so I can't depend upon it. So your solution looks promising. All this makes me wonder if the usage of Boost.Config might be diminished by using such techniques. Or perhaps, Boost.Config might be broadened to make the usage of such techniques more accessible to the "rest of us"
Joaquín M López Muñoz
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 09/10/17 23:00, Joaquín M López Muñoz via Boost wrote:
Em 10 sept 2017, às 19:30, Robert Ramey via Boost <boost@lists.boost.org> escreveu:
How do I get ready for C++17?
I have a piece of code which requires C++14. I want to use something from C++17 but I also want my code to work now. So I have
#if C++14 being used namespace std { // implement C++ function } // std
I've looked in the documentation for Boost.Config and can't find any hints there.
You might find this technique useful:
http://bannalia.blogspot.com/2016/09/compile-time-checking-existence-of.html...
The nice thing about it is you don't depend on implementation macros that might or might not be accurate.
This doesn't say if std::is_final is functional (i.e. not bugged). Also, hijacking an unrelated class template for feature detection is kind of hacky. And I wonder how portable this is. std::is_final may actually be std::some_internal_namespace::is_final; will it be found in this case?
participants (14)
-
Andrey Semashev -
Barrett Adair -
Gavin Lambert -
Glen Fernandes -
Ion Gaztañaga -
James E. King, III -
Joaquín M López Muñoz -
John Maddock -
Michael Caisse -
Nevin Liber -
Niall Douglas -
Peter Dimov -
Robert Ramey -
Stephan T. Lavavej