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 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

...

...

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 , then there is no better way to check, than actually including 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

Robert Ramey wrote:

BOOST_NO_CXX17_STD_IS_DETECTED

According to http://en.cppreference.com/w/cpp/experimental/is_detected

it's currently in 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 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/

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 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 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 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.

On Tue, Sep 12, 2017 at 3:15 AM, Stephan T. Lavavej via Boost 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 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

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 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