我是否应该为库中的类型提供 ostream <<运算符?

Should I provide ostream << operators for types in a library?

提问人:einpoklum 提问时间:2/28/2020 最后编辑:einpoklum 更新时间:11/15/2022 访问量:124

问:

我正在为某些 API 开发 C++ 包装器库。假设我已经实现了一些结构或类类型。我无法决定是否提供我的图书馆。Fooostream& operator<<(ostream& os, const Foo& x)

一方面:

  • 调试方便。
  • 它不会干扰代码的其余部分。
  • 除非在调试时,否则我不希望打印 s,因此这不应该与想要将 s 序列化为文件或类似活动的用户发生冲突。FooFoo

另一方面:

  • 这不是必需的,即包装器的功能不需要它来做任何事情。
  • 图书馆用户可能想要一些其他的调试打印格式,与我写的不同。或者,也许他们使用安东尼·波鲁欣(Antony Polukhin)的黑暗巫毒教自动结构打印(magic_get)。
  • 除非小心翼翼地与代码的其余部分分开,否则它会迫使库用户包含 ,这不是一件小事。<iostreams>

是否忽略了对任何选项的其他原始考虑?或者,换一种说法:将此类运算符包含在库中的合适标准是什么?

附加信息:

  • 所有成员都可以由用户获取,因此不需要成员或好友功能即可达到相同的效果。Foo
C++ IOSTREAM 习语 调试打印

评论

0赞 NathanOliver 2/28/2020
就我个人而言,我喜欢这个成语。公开一个字符串化对象的方法,用户可以根据需要使用它。to_string
0赞 einpoklum 2/28/2020
@NathanOliver: 1. 但是在我所知道的图书馆中,几乎没有任何东西有方法。我甚至怀疑有那么多独立式的超载......2. 根本的困境仍然存在,无论是 ostream'ing 运营商还是......3.还有.to_string()to_string()to_string()operator std::string()
0赞 Ted Lyngmo 2/28/2020
#ifndef NDEBUG <your operator<< overloads and necessary includes> #endif.就我个人而言,我喜欢库制造商提供它,即使它不会在生产中使用。
0赞 1201ProgramAlarm 2/28/2020
您的类中是否存在用户无法获取的某些特性或属性?换句话说,您的类的用户是否能够使用现有接口充分实现此运算符?
0赞 einpoklum 2/28/2020
@1201ProgramAlarm:这是一个很好的观点。用户可以获取我用于实现流式处理运算符的所有信息。此外,它是一个非朋友的独立功能,所以显然是的。

答: 暂无答案