C++fmt::print与fmt::format_to命名的技术背景？
为什么是fmt::format_to(OutputIt, ...)而不是fmt::print(OutputIt, ...)？？
我目前正在熟悉{fmt}一个 / 现代 C++ 格式库。
在浏览 API 时，我发现命名有点不连贯，但鉴于我对库几乎没有经验（以及我对 API 设计的兴趣），我想支持这些命名选择：（fmt 核心 API 参考）
- 还有
fmt::format(...) -> std::string这是有道理的，它返回一个格式化字符串。 - 然后我们有
void fmt::print([stream, ] ...)这也有意义命名明智（当然考虑到printf遗产）。 - 但随后我们有
fmt::format_to(OutputIt, ...) -> OutputIt它类似于，除了返回类型，有什么print用数据流来实现。
现在很明显，一个人可以整天骑自行车棚的名字，但这里的问题不在于为什么我们有formatvs. print（这对我来说很容易解释），而是为什么一个明显（？）表现得像写入流的函数 - kind 已经捆绑了format_...命名风格。
所以，因为这个问题已经题问，有没有技术差异如何fmt::print(stream, ...)格式化到如何对数据流的行为时fmt::format_to(OutputIt, ...)格式化到输出迭代器时的行为？
或者这纯粹是一种风格选择吗？此外，鉴于GitHube 存储库在此处明确列出了fmt标签，我希望我们能从原始 API 作者那里得到权威的答案。
回答
虽然有可能命名format_to print，前者更接近概念来format比print。format_to是format通过输出迭代器而不是std::string. 因此，命名反映了这一点。
print另一方面，没有流参数写入stdout并print带有参数将其推广到任意流。写入流与写入输出迭代器根本不同，因为它涉及额外的缓冲、同步等。其他语言通常使用“打印”来实现此类功能，因此 {fmt} 遵循此约定。
这变得模糊，因为您可以有一个写入流的输出迭代器，但即使在那里，当前的命名也反映了正在使用的高级 API。
换句话说，format_to它基本上是一个花哨的 STL 算法（甚至format_to_n类似于copy/ copy_n），而它print是一个格式化的输出函数。