Closed andrascii closed 5 years ago
The use of unary_function
is already guarded by an #ifdef
, removing it outright seems unnecessary. It seems to be that it would be better to fix the conditional.
from the Boost.Config docs:
BOOST_NO_CXX98_FUNCTION_BASE
: The standard library no longer supports std::unary_function
and std::binary_function
. They were deprecated in C++11 and is removed from C++14.
@mclow: this looks good to me now - corrects the PP logic as it should.
Do we need the _HAS_AUTO_PTR_ETC
checks at all?
Do we need the
_HAS_AUTO_PTR_ETC
checks at all?
Specifically in this part of code?
If _HAS_AUTO_PTR_ETC is defined to 0, std::auto_ptr and std::random_shuffle are not available.
What does this _HAS_AUTO_PTR_ETC
have to do with this code?
It looks like this macro was used to understand that std::unary_function
was removed...
Do we need the _HAS_AUTO_PTR_ETC checks at all?
Probably not any more, they're msvc specific and have been superseded by BOOST_NO_CXX98_FUNCTION_BASE.
This solutions isn't working. Compiler still has an error about std::unary_function
.
Macro BOOST_NO_CXX98_FUNCTION_BASE
isn't defined when I building the project.
I use cmake and set:
set(CMAKE_CXX_STANDARD 17)
And I use clang.
I still think that we need to just remove usage of std::unary_function.
Any suggestions?
This solutions isn't working. Compiler still has an error about std::unary_function.
What's the clang version, platform and standard library? We do test this in the Boost.Config tests so it should all be working.
BTW it would be wrong to simply remove all references to std::unary_function as that potentially breaks existing code.
This solutions isn't working. Compiler still has an error about std::unary_function.
What's the clang version, platform and standard library? We do test this in the Boost.Config tests so it should all be working.
BTW it would be wrong to simply remove all references to std::unary_function as that potentially breaks existing code.
clang version: Apple LLVM version 10.0.1 (clang-1001.0.46.4) Target: x86_64-apple-darwin18.7.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
Compile flag -std=gnu++1z also used
Well this is weird:
So maybe this is an Apple thing?
So I guess the question is whether we should define BOOST_NO_CXX98_FUNCTION_BASE for any compiler claiming to be C++14 or later "just in case" ?
So maybe this is an Apple thing?
Maybe it is.
But current solution for me is to define BOOST_NO_CXX98_FUNCTION_BASE
on my own before including boost/functional/hash.hpp
or just to avoid including this library.
Because standard library that is shipped with Xcode does not contain the std::unary_function
definition.
Because standard library that is shipped with Xcode does not contain the std::unary_function definition.
This is very confusing to me. I don't have Xcode installed, but I do have the most recent Apple command-line tools installed, and the headers that ship with those Apple LLVM version 10.0.1 (clang-1001.0.46.4)
definitely DO define unary_function
on line 960 of <utility>
.
Because standard library that is shipped with Xcode does not contain the std::unary_function definition.
This is very confusing to me. I don't have Xcode installed, but I do have the most recent Apple command-line tools installed, and the headers that ship with those
Apple LLVM version 10.0.1 (clang-1001.0.46.4)
definitely DO defineunary_function
on line 960 of<utility>
.
Okey, I'll recheck this thing today/tomorrow.
This is very confusing to me. I don't have Xcode installed, but I do have the most recent Apple command-line tools installed, and the headers that ship with those
Apple LLVM version 10.0.1 (clang-1001.0.46.4)
definitely DO defineunary_function
on line 960 of<utility>
.
I'm sorry, my mistake. I forgot to install patched library and regenerate my project using cmake.
Just to be able to compile boost with projects that uses C++17.