c++ - C++ fmt::print 与 fmt::format_to 命名的技术背景?

标签 c++ api-design fmt

为什么是这样fmt::format_to(OutputIt, ...)而不是 fmt::print(OutputIt, ...) ??

我目前正在熟悉 {fmt} , 一个/现代 C++ 格式库。
在浏览 API 时,我发现命名有点不连贯,但鉴于我对库几乎没有经验(以及我对 API 设计的兴趣),我想支持这些命名选择:( fmt core API reference )

  • fmt::format(...) -> std::string这是有道理的,它返回一个格式化的字符串。
  • 然后我们有 void fmt::print([stream, ] ...)这在命名方面也是有意义的(当然考虑到 printf 遗产)。
  • 但是我们有 fmt::format_to(OutputIt, ...) -> OutputIt除了返回类型之外,它类似于 print与流有关。

  • 现在很明显,一个人可以整天骑自行车棚,但这里的问题不在于我们为什么有 format对比 print (这对我来说很容易解释),但是为什么一个明显(?)表现得像写入流类型的函数已经与 format_... 捆绑在一起了。命名风格。
    所以,正如问题标题已经问到的,是否有 技术差异怎么样fmt::print(stream, ...)格式化为流时的行为与如何 fmt::format_to(OutputIt, ...)格式化为输出迭代器时的行为?
    或者这纯粹是一种风格选择吗?另外,鉴于 GitHube repo明确列出 在这里标记,我希望我们可以从原始 API 作者那里得到权威的答案。

    最佳答案

    虽然可以命名 format_to print ,前者在概念上更接近 format比到 print . format_toformat 的推广通过输出迭代器而不是 std::string 写入输出.因此,命名反射(reflect)了这一点。print另一方面,没有流参数写入 stdoutprint使用参数将其推广到任意流。写入流与写入输出迭代器根本不同,因为它涉及额外的缓冲、同步等。其他语言通常使用“打印”来实现此类功能,因此 {fmt} 遵循此约定。
    这变得模糊,因为您可以有一个写入流的输出迭代器,但即使在那里,当前的命名也反射(reflect)了正在使用的高级 API。
    换句话说 format_to基本上是一个花哨的STL算法(甚至还有 format_to_n 类似于 copy/copy_n )而 print是格式化输出函数。

    关于c++ - C++ fmt::print 与 fmt::format_to 命名的技术背景?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/68200618/

    相关文章:

    c++ - 如何从构造函数捕获异常而不处理整个函数?

    c++ - 为什么编译结果是 "undefined reference to ' function'”?

    c - VkApplicationInfo 有什么意义?

    c++ - fmt::dynamic_format_arg_store 替换/实现 std::format

    c++ - 我在 C++ 中收到的每个错误都有 4 个相同的无用错误

    c++ - Visual Studio 2008,运行时库使用建议

    c++ - Qt类的私有(private)部分不安全

    java - 请求之间的 JAX-RS REST API 变量共享

    swift - 设计 Swift API 时的可选项

    c++ - 不能将规范与 fmt 库混合