无需逐个模板特化，如何检测C++整数类型？

错误1：浮点类型的operator&编译错误 #

问题原因 #

原BitAndExists的实现逻辑存在缺陷：对于浮点类型（如float），尝试执行declval<float>() & declval<float>()时，编译器会优先匹配内置的按位与运算符，但该运算符本身不支持浮点类型，因此直接触发编译错误，而非匹配我们提供的模板operator&。这导致SFINAE机制无法生效，无法正确跳过非法表达式。

修复方案 #

改用std::void_t结合std::enable_if的SFINAE方式，同时提前排除浮点类型，避免触发非法的内置运算符调用：

#include <type_traits>
#include <utility>

#if __cplusplus >= 201103L
namespace impl
{
    template<typename T, typename = void>
    struct BitAndExists : std::false_type {};

    // 仅对非浮点类型，检测operator&是否存在且合法
    template<typename T>
    struct BitAndExists<T, std::enable_if_t<!std::is_floating_point_v<T>,
        std::void_t<decltype(std::declval<T>() & std::declval<T>())>>>
        : std::true_type {};
}
#endif

错误2：constexpr变量初始化非常量表达式 #

问题原因 #

原代码中has_integer_bit_and函数的if constexpr条件依赖于未正确工作的BitAndExists::value，导致部分分支的表达式无法在编译期确定为常量。此外，原逻辑中重复检查!is_floating_point，进一步增加了编译期表达式的不确定性。

修复方案 #

简化has_integer_bit_and的逻辑，利用已修复的BitAndExists（已排除浮点类型），确保所有分支返回的都是编译期常量：

namespace impl
{
    template <typename T>
    constexpr bool has_integer_bit_and()
    {
        if constexpr (BitAndExists<T>::value)
        {
            // 仅对支持&的非浮点类型，执行按位与检查
            return (T(0) & T(1)) == T(0);
        }
        else
        {
            return false;
        }
    }

    template <typename T>
    struct integral_checks {
        static constexpr bool bit_and_check = has_integer_bit_and<T>();
        // 整数除法会截断，浮点除法会得到1.5，因此该检查可区分整数与浮点
        static constexpr bool round_check = (T(3)/T(2)) == T(1);

        static constexpr bool value = bit_and_check && round_check;
    };

    // 指针和引用特化，直接返回false
    template <typename T>
    struct integral_checks<T*> : std::false_type {};
    template <typename T>
    struct integral_checks<T&> : std::false_type {};
}

template<typename T>
struct is_integral
{
    static constexpr bool value = impl::integral_checks<T>::value;
};

额外说明 #

• 需确保编译器支持C11及以上标准（std::void_t在C17引入，若使用C++11/14，可自行实现简易版void_t）：

  // C++11/14兼容的void_t实现
  template<typename...>
  using void_t = void;
  

• 该方案仍属于鸭子类型检测，可能存在边缘情况（如自定义类型重载了operator/和operator&并满足检查条件），但作为练习项目，可有效验证编译期类型检测的逻辑。

内容的提问来源于stack exchange，提问作者Tomáš Zato