std::make_signed和std::make_unsigned是<type_traits>中用于编译期整型符号转换的模板别名，仅对整型类型有效，不支持float、bool、enum、std::byte等，且char用法依赖平台。
std::make_signed 和 std::make_unsigned 是什么
它们是 C++ 标准库中定义在 <type_traits> 头文件里的模板别名，用于在编译期把一个整型类型“映射”为对应的有符号或无符号版本。不是运行时转换，也不是类型转换函数，而是类型计算工具。
比如 std::make_signed<unsigned short>::type 展开后就是 short；std::make_unsigned<char>::type 通常是 unsigned char（但注意：char 符号性不固定，取决于平台）。
常见误用是把它当成 static_cast 的替代品——它完全不参与值的转换，只帮你写出更泛化的类型名。
哪些类型能用，哪些会触发 static_assert 失败
这两个模板只对“整型类型”（integral）有效，且要求目标符号变体在当前平台上真实存在。标准明确禁止对非整型、bool、枚举（除非显式特化）、浮点类型使用。
立即学习“C++免费学习笔记（深入）”；
-
std::make_signed<int>✅ —— 得到int -
std::make_signed<unsigned int>✅ —— 得到int -
std::make_signed<float>❌ —— 编译失败，错误信息类似：static_assert failed due to requirement 'is_integral_v<float>'</float> -
std::make_signed<char>⚠️ —— 可能成功，但结果依赖char是否等价于signed char；建议改用std::make_signed<signed char>或std::make_signed<unsigned char>显式指定 -
std::make_unsigned<size_t>✅（通常）——但size_t是 typedef，最终依赖其底层类型（如unsigned long），所以std::make_signed<size_t>一般也合法
为什么不能直接写 signed/unsigned，而要用 make_*
当你写模板时，输入类型可能是用户传入的任意整型（T），你无法预知它是 uint16_t 还是 long long，更不能硬编码 int16_t 或 long long。这时 std::make_signed<T>::type 就成了唯一可移植的写法。
典型场景：实现一个通用的绝对值函数，内部需保证中间运算用有符号类型避免溢出；或序列化库中统一处理“同宽有符号/无符号字段”的位操作。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
示例：
template <typename T>
auto safe_abs(T val) -> typename std::make_signed<T>::type {
using S = typename std::make_signed<T>::type;
return (val < 0) ? static_cast<S>(val) : static_cast<S>(val);
}
注意：这里仍需 static_cast 完成值转换，std::make_signed 只负责提供 S 类型。
容易忽略的平台和标准差异
最常踩的坑是假设 std::make_signed<char> 总是 signed char。实际上：char 是独立类型，与 signed char 和 unsigned char 三者互不相同；它的符号性由编译器决定（GCC/Clang 默认 signed，MSVC 默认 signed，但可通过 -funsigned-char 改变）。
另一个坑是 std::make_signed<std::byte> —— std::byte 虽底层是整型，但标准明确将其排除在 make_signed 支持范围外，用即报错。
还有：C++17 起，std::make_signed 对 bool 的特化被移除，之前某些旧标准库允许，现在一律不合法。
如果你在跨平台项目里看到类型推导异常，优先检查是否误用了 char 或 bool，而不是怀疑模板本身。
