首页 > 解决方案 > 跨平台 C++ 异常和基本日志记录工具的首选字符类型是什么?

问题描述

前言:

在过去的 20 年里,我主要在 Windows 上进行编程。在那段时间里,我开发了广泛的字符串转换、日志记录和异常报告机制,这些机制依赖于 Windows API 的 utf-16le 字符串转换工具和底层 I/O 服务来捕获运行时异常上下文以进行调试、日志记录、报告等。

当我们回到 Windows utf-16le 本机代码时,我不得不简单地做出选择,以更改大多数基本服务以将它们全部表达为 wchar_t 基础(或 std::wstring,即 Windows 上的 utf-16le)。我说“必须”是因为它们很好地结合在一起——在 WinAPI 本身、文件 I/O 和控制台 I/O 之间实现了高度一致,它们都可以在 utf-16le 中正常工作。

Windows 提供了窄字符串 I/O 和当前代码页支持——但这永远不会像将所有内容保存在 utf-16le 中一样有效,然后它可以跨各种系统移植并保持连贯——没有“在转录中丢失”。

目标:

我希望概括我的库,但我对 Windows 下的简单(呃)之间的这种根本脱节感到困惑:使用wstring对于所有日志记录和异常数据,它们保证我的跟踪捕获和包含特定于语言环境的字符串(例如,特定于语言环境的文件名或用户命名的元素)的错误保留在它们的本地字符串中,并且在我的英语系统上加载时不会受到降级- 与似乎更喜欢 utf-8 作为其核心字符串编码的 Linux 系统相比,后者通常更紧凑 - 但对于基于 Windows 的应用程序来说很难工作(这是一个复杂的话题 - 但我只想说Windows 没有充分支持 utf-8 用于控制台 I/O 或任何其他文件 I/O,并且无论如何您都必须不断转换为 utf-16le 以进行 WinAPI 调用——对于基于 GUI 的应用程序来说,这绝对是不断的- 因此,将 utf-16le 作为您的“标准”字符串类型并从那里建立起来更容易)。

但是,我希望有一组对程序员友好的异常类,它们以一种对 Unix 和 Windows 上的 c++ 程序员同样“自然”和方便的方式捕获上下文。

所以这会产生一些难以回答的问题——尤其是因为我缺乏在 Linux 上编程 c++ 的知识:

问题:

  1. 我是否提供在 Windows 上始终捕获 utf-16le 而在 Unix 上捕获 utf-8 的基本异常类?
  2. 如何在允许任一字符串类型的 API 之间进行转换(好吧,从技术上讲,我想提供 std::string 和 std::wstring - 在 Windows 和 Linux 上可能是 utf-16le 或 utf-32) .

进一步的考虑:

对于#2,我看到 c++ 11 标准机构创建std::wstring_convert<std::codecvt_utf8_utf16<char16_t>>但不推荐使用 c++17。

在为该平台编译时,我当然可以依赖 Windows API,但我真的想要像异常类层次结构这样基本的东西——其全部目的是让程序员更容易捕获运行时错误上下文——必须依赖本机服务。我真的希望我的库的核心部分只依赖于 C++ 标准库服务——我宁愿避免使用 C 运行时库服务(注意:我不介意标准库是否依赖于 C 运行时- 这与我的担忧无关,并且将是一个特定于平台的问题,而不是我的库创建的依赖项)。

所以,我很好奇其他在基于 Linux 和 Mac OS 的系统方面有更多经验的 C++ 专业人士认为,他们最容易在写出异常的便利性和能够轻松捕获和操作跟踪和日志文件或其他诊断 I/O?

更正:C++11 引入了转换器,而 C++17 弃用了它。

标签: c++utf-8api-designwstring

解决方案


推荐阅读