Skip to content

Fix: patch bundled Boost hash.hpp for C++17 std::unary_function removal#2750

Open
Sahilll10 wants to merge 2 commits intosu2code:developfrom
Sahilll10:fix/cpp17-boost-unary-function-tecio
Open

Fix: patch bundled Boost hash.hpp for C++17 std::unary_function removal#2750
Sahilll10 wants to merge 2 commits intosu2code:developfrom
Sahilll10:fix/cpp17-boost-unary-function-tecio

Conversation

@Sahilll10
Copy link

Root Cause

boost/container_hash/hash.hpp has a guard #if defined(_HAS_AUTO_PTR_ETC)
which is MSVC-only. On MacOS/clang and GCC with C++17, this guard never
activates, so hash_base inherits from std::unary_function which was
removed in C++17, causing a build failure.

Fix

Patched the #else branch of hash_base in externals/tecio/boost.tar.gz
to use explicit typedef declarations instead of std::unary_function
inheritance. This matches what the #if branch already does correctly for
MSVC. No behaviour change.

Verification

Zero occurrences of unary_function remain in
boost/container_hash/hash.hpp after repacking.

Files Changed

  • externals/tecio/boost.tar.gz — one struct patched in boost/container_hash/hash.hpp

Fixes #2583

In C++17, std::unary_function was removed. The bundled Boost headers in
tecio (boost/container_hash/hash.hpp) use std::unary_function in hash_base
under a guard (_HAS_AUTO_PTR_ETC) that only activates on MSVC. On MacOS
clang and Linux GCC with C++17, the guard never triggers, causing a
compilation error.

Fix: replaced std::unary_function inheritance in the #else branch with
explicit typedef declarations, identical to what the #if branch already
does correctly.

Fixes su2code#2583
@joshkellyjak
Copy link
Contributor

joshkellyjak commented Mar 10, 2026

You can still use unary_functions, you just need to declare them as std::__unary_function. I think this a better way to do this as I suggest in the original issue. This way we are consistent with the original implementation in tecio's boost library.

Actually, I changed my mind, if this is fully deprecated in C++ 17 then the changes are probably better in the long run. LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants