检查类型是否可以清洗

Question

我想创建一个类型特征,用于检查特定类型是否可以使用标准库的无序容器的默认实例化进行清理,因此如果它具有有效的特化std::hash.我认为这将是一个非常有用的功能(例如std::set,std::unordered_set在通用代码中使用故障保护).所以我认为std::hash没有为每种类型定义,开始制作以下SFINAE解决方案:

template<typename T> std::true_type hashable_helper(
    const T&, const typename std::hash<T>::argument_type* = nullptr);

template<typename T> std::false_type hashable_helper(...);

//It won't let me derive from decltype directly, why?
template<typename T> struct is_hashable 
    : std::is_same<decltype(hashable_helper<T>(std::declval<T>())),
                   std::true_type> {};

(如果这不是最好的解决方案,甚至是错误的,请原谅我适度的SFINAE能力.)

但后来我了解到,gcc 4.7和VC++ 2012都定义std::hash了任何类型T,只是static_assert非专业版.但是有条不紊地编译它们(以及使用gcc 4.7的libstdc ++ 扼流3.1),而不是断言导致编译错误.这似乎是合理的,因为我认为SFINAE没有处理(对吧？),所以SFINAE解决方案似乎根本不可能.更糟糕的是,它甚至没有在通用模板中,但只是没有定义其运算符,导致在尝试使用它时出现链接器错误(这总是比编译错误更糟,我无法想象任何方式将链接器错误转换为编译器错误).static_assertgcc 4.6static_assertstd::hash()

那么,如果类型具有有效的特化std::hash,或者至少对于static_assert通用模板中的库(以某种方式将static_assert错误转换为SFINAE非错误),是否有任何符合标准且可移植的方式来定义返回类型特征？

Answer 1

从 C++17 开始，现在可以以更优雅的方式做到这一点。来自cppreference关于 std::hash：

该模板的每个特化要么启用（“未污染”），要么禁用（“中毒”）。对于库和用户都没有为其提供启用的专业化 std::hash 的每个类型 Key，该专业化存在并且被禁用。禁用的特化不满足 Hash、不满足 FunctionObject，并且 std::is_default_constructible_v、std::is_copy_constructible_v、std::is_move_constructible_v、std::is_copy_assignable_v、std::is_move_assignable_v 都是假的。换句话说，它们存在，但不能使用。

这意味着 STL 必须删除 C++17 中的 static_assert。这是'Clang-6.0.0 -std=c++17'的工作解决方案：

#include <functional>
#include <ios>
#include <iostream>
#include <type_traits>

template <typename T, typename = std::void_t<>>
struct is_std_hashable : std::false_type { };

template <typename T>
struct is_std_hashable<T, std::void_t<decltype(std::declval<std::hash<T>>()(std::declval<T>()))>> : std::true_type { };

template <typename T>
constexpr bool is_std_hashable_v = is_std_hashable<T>::value; 

struct NotHashable {};

int main()
{
    std::cout << std::boolalpha;
    std::cout << is_std_hashable_v<int> << std::endl;
    std::cout << is_std_hashable_v<NotHashable> << std::endl;
    return 0;
}

例如，当您使用boost::hash_combine或boost::hash_range时，这可能会派上用场。如果包含包含以下代码示例的标头，则不再需要为特定类型定义 boost 哈希。

#include <boost/functional/hash_fwd.hpp>

template <typename T, typename = std::void_t<>>
struct is_boost_hashable : std::false_type { };

template <typename T>
struct is_boost_hashable<T, std::void_t<decltype(boost::hash_value(std::declval<T>()))>> : std::true_type { };

template <typename T>
constexpr bool is_boost_hashable_v = is_boost_hashable<T>::value;  

namespace boost
{
    template <typename T>
    auto hash_value(const T &arg) -> std::enable_if_t<is_std_hashable_v<T> &&
                                                      !is_boost_hashable_v<T>, std::size_t>
    {
        return std::hash<T>{}(arg);
    }
}

注意is_boost_hashable_v，这对于避免歧义是必要的，因为 boost 已经为很多散列提供了散列。

Answer 2

看来我们有两个相互矛盾的要求:

1. 如果实例化可能失败并且从重载集中删除相应的函数,则SFINAE旨在避免模板的任何实例化.
2. static_assert() 例如,在模板的实例化期间,意图产生错误.

在我看来,1.明确胜过2.,即你的SFINAE应该工作.从两个独立的编译器供应商的外观不同意,不幸的是不是他们之间,而是与我.该标准似乎没有指定默认定义的std::hash<T>外观和似乎仅针对std::hash<T>专门用于类型的情况施加约束T.

我认为你提出的类型特征是一个合理的想法,应该得到支持.但是,似乎标准并不能保证它可以实现.可能值得为编译器供应商提出这个问题和/或为标准提交缺陷报告:据我所知,目前的规范没有明确指出应该发生什么.......如果规范当前要求上述类型特征失败,则可能是需要纠正的设计错误.