带有外部模板的自定义类型 {fmt} 格式化程序，有什么缺点吗？答案

【问题标题】：Custom type {fmt} formatters with external termplates, any drawbacks?带有外部模板的自定义类型 {fmt} 格式化程序，有什么缺点吗？
【发布时间】：2020-07-24 14:29:12
【问题描述】：

我有一个标题，它为我的自定义类型定义了所有 {fmt} 格式化程序。

为了缩短编译时间，我想减少这个自定义格式化程序头的依赖，并决定将所有格式化程序定义为外部模板，其中实现放在.cpp中，头文件中的声明如下：

template<>
struct formatter<MyType> : formatter<std::string>
{
  auto format(const MyType& t, format_context& ctx);
};

extern template struct formatter<MyType>;

...以及.cpp 文件中的定义：

auto formatter<MyType>::format(const MyType& t, format_context& ctx)
{
  return format_to(ctx.out, "MyType: {}", ...);
}

主要优点是头文件变得不那么繁重，所有自定义类型都可以前向声明，并且我不再包含世界，以防我想在某个翻译单元中自定义单一类型的格式。

但是，大多数使用 {fmt} 实现自定义格式化程序的示例将 format() 函数定义为模板化 format_context 类型的模板函数：

template<typename FormatContext>
auto format(const MyType& t, FormatContext& ctx);

这实际上不适用于外部模板，因为我需要预先为所有可能的FormatContext 类型声明format()。这很容易出错。目前，仅使用 fmt::format_context 有效，编译器会告诉我何时不再满足要求。

我想知道在FormatContext 类型上没有模板化格式函数会造成什么损失？在什么情况下fmt::format_context 不够用？有没有更好的方法来定义这些自定义类型格式化程序，而不必将完整的实现放在头文件中？我正在考虑采用 std::ostream 路线，然后只要我想用 {fmt} 格式化我的类型，就简单地包括 <fmt/ostream.h>，但这部分违背了首先使用 {fmt} 的目的。

【问题讨论】：

标签： c++ fmt

【解决方案1】：

由于没有在 FormatContext 类型上模板化格式函数，我失去了什么？

您将失去通过输出迭代器进行格式化的能力。以前这意味着您将无法使用 format_to[_n]。但是在当前的master 中，这个限制有已被删除，format_to 和 format_to_n 都可以使用 format_context。现在只有format string compilation 可能需要自定义输出迭代器。

【讨论】：