我正在开发跨平台引擎代码，用于存储和传输文本数据 unsigned Short 是一种最好的类型，在 Windows 上与 wchar_t 相同，在 mac 上作为 NSString 中继的 unichar （出于某种原因，mac 上的 wchar_t 大小为 32 位） ）。随着新的 C++ 20 和 char16_t 的出现，我用它替换了我的通用无符号短类型，并开始尽可能优化代码，并且只要有可能就为两个操作系统（Mac 和 Win）使用相同的代码。新的 char16_t 工作得很好，直到我开始格式化部分并看到 std::format 还不支持它。
尝试了很多解决方案，最终使用支持格式化 char16_t 的 FMT 库，结果发现它的代码与 std::format 代码非常相似（同一个人完成了两者），所以这让我想知道是否可以使 std::适用于所有字符类型的格式。
经过一些工作并提供缺失的代码（其他字符类型的格式化程序模板）只会让我遇到著名的错误>> C2491：'std :: numpunct<_Elem> :: id'：不允许定义dllimport静态数据成员<<....
最后也是最后的方法是将 std format.h 文件中的所有代码复制到新文件（将其命名空间更改为 fmt，这样它就不会与 std 版本冲突），并从 xlocnum 头文件复制类 numpunct 并使其正常工作，我的新 fmt::std__format 现在正在格式化所有字符类型，并且似乎没有任何明显的问题。
说实话，我没想到我会让它工作，所以现在想知道我是否错过了任何东西，好像这个更改只是使 std::format 适用于所有字符类型所需要的，那么我不知道为什么他们不这样做'最后添加这个支持..
我所做的添加很简单，并且都已经在现有代码中，只是为新字符类型添加新的函数和类的模板版本，例如 std format.h 文件中的函数 _Decode_utf 有 char、wchar_t 和 char32_t 的版本所以只需要新的 char8_t 和 char16_t 。并且解决方案可以简单地重用 char8_t 函数的 char 版本（由于某种原因 char 函数版本正在执行完整的 UTF 8 编码/解码，可能是因为 char 用于 UTF 8 时的向后兼容性）和 ofc 的 char16_t 函数是 wchar_t 的版本完美运行（至少在 Windows 上，Mac 有待测试）....
我的问题是，我在这里浪费时间了吗？ std::format 不适用于我在代码中看不到或检测不到的新字符类型（因为 std format.h 中的大量代码）文件肯定支持新的字符类型）？
std::format()charwchar_tstd::localecharN_tstd::format()std::localeSG16 在跟踪扩展对
charN_t