defect macro for C++17 feature std::invoke()

[olk]

No description provided.

[jzmaddock]

My only complaint about this PR is that clang with libstdc++ pulls in unconditionally - we've worked pretty hard not to pull in large std lib headers like that, is there any way around this? Any new headers in 6.1 we can test for?

[olk]

maybe <experimental/filesystem> could be used

[jzmaddock]

<experimental/filesystem> was present in gcc-5.3.0, however there are a number of experimental C++17 headers new in gcc-6.1.0, and <experimental/memory_resource> looks like a good candidate?

[olk]

hmm - I used 'GCC 6 Release Series Changes, New Features, and Fixes' (https://gcc.gnu.org/gcc-6/changes.html) : 'An experimental implementation of the File System TS.'

I can't find a header usable for our purposes.

Maybe we could use the support for mathematical special functions (ISO/IEC 29124:2010), e.g. test __STDCPP_MATH_SPEC_FUNCS__for value 201003L.
what do you think?

[jzmaddock]

On 20/10/2016 11:53, Oliver Kowalke wrote:

hmm - I used 'GCC 6 Release Series Changes, New Features, and Fixes'
(https://gcc.gnu.org/gcc-6/changes.html) : 'An experimental
implementation of the File System TS.'

I can't find a header usable for our purposes.

What was wrong with <experimental/memory_resource> ?

It doesn't get explicitly mentioned in the release notes, but there are
a ton of new (and some old) headers in gcc-6.x, probably covered by
"Experimental support for most features of the second version of the
Library Fundamentals TS"?

Maybe we could use the support for mathematical special functions
(ISO/IEC 29124:2010), e.g. test __STDCPP_MATH_SPEC_FUNCS__for value
201003L.
what do you think?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#98 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEx5OCvkdAThBSuwz2qeRuMEbL2CdYo_ks5q10gWgaJpZM4KXU_x.

[olk]

changed to <experimental/memory_resource>

[jzmaddock]

We have a bit of an issue with this one that I'm not sure what to do about: the original specification of std::invoke was changed at the very last minute for C++17 with result_of becoming deprecated and replaced by invoke_result. Over the last couple of days I've updated the test case for this, and fixed up the resulting failures - but there's a catch - only the latest compilers (msvc-14.1up3, gcc-7) support a std conforming invoke, and one (clang+libc++) not at all.
Currently, only Boost.Context is using this macro, and I see there is a workaround in place for BOOST_NO_STD_INVOKE defined. So my question are:

• What should this macro signify? std conforming invoke or simply it's presence?
• What's the impact on existing users for defining this macro in more situations?

I'm asking because @NAThompson has some changes to Boost.Math which (probably) require the "fully conforming" meaning.

[jzmaddock]

See also: #221

[olk]

BOOST_NO_STD_INVOKE should test for std::invoke conformance

[jzmaddock]

BOOST_NO_STD_INVOKE should test for std::invoke conformance

So: just for the avoidance of doubt - does that mean you're OK with the changes?

[olk]

Yes, I've made some modifications and "Travis Build #56" passed.