有没有什么“陷阱”？ 与快速格式？
我刚刚读到FastFormat C++ i/o 格式化库，它看起来好得令人难以置信：甚至更快比 printf、typesafe 以及我认为令人愉悦的界面：
// prints: "This formats the remaining arguments based on their order - in this case we put 1 before zero, followed by 1 again"
fastformat::fmt(std::cout, "This formats the remaining arguments based on their order - in this case we put {1} before {0}, followed by {1} again", "zero", 1);
// prints: "This writes each argument in the order, so first zero followed by 1"
fastformat::write(std::cout, "This writes each argument in the order, so first ", "zero", " followed by ", 1);
这看起来好得令人难以置信。 有什么问题吗？ 你有过好的、坏的或无关紧要的经历吗？
I just read about the FastFormat C++ i/o formatting library, and it seems too good to be true: Faster even than printf, typesafe, and with what I consider a pleasing interface:
// prints: "This formats the remaining arguments based on their order - in this case we put 1 before zero, followed by 1 again"
fastformat::fmt(std::cout, "This formats the remaining arguments based on their order - in this case we put {1} before {0}, followed by {1} again", "zero", 1);
// prints: "This writes each argument in the order, so first zero followed by 1"
fastformat::write(std::cout, "This writes each argument in the order, so first ", "zero", " followed by ", 1);
This looks almost too good to be true. Is there a catch? Have you had good, bad or indifferent experiences with it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
上次我检查时，有一个恼人的问题：
您只能使用此库的窄字符串版本或宽字符串版本。 （
wchar_t和char的函数是相同的——使用哪种类型是编译时开关。）对于 iostreams、stdio 或 Boost.Format，您可以同时使用两者。
Last time I checked, there was one annoying catch:
You can only use either the narrow string version or the wide string version of this library. (The functions for
wchar_tandcharare the same -- which type is used is a compile time switch.)With iostreams, stdio or Boost.Format you can use both.
发现了一个“陷阱”，尽管对于大多数人来说它永远不会显现出来。 从项目页面：
我能看到这种情况发生的唯一方法是它缓冲整个
write ()调用的输出本身，然后一步将其写入ostream。 这意味着它需要分配内存，并且如果传递到 write() 调用的对象产生大量输出（几兆字节或更多），它可能会消耗内部缓冲区中两倍的内存（假设它使用每次将其大小加倍来增长缓冲区的技巧）。如果您只是使用它进行日志记录，而不是转储大量 XML，那么您将永远不会遇到此问题。
我看到的唯一的其他“陷阱”是：
因此它无法与旧的 C++ 编译器一起使用，例如
cfront，而iostreams向后兼容 80 年代后期。 再说一次，如果有人遇到这个问题，我会感到惊讶。Found one "catch", though for most people it will never manifest. From the project page:
The only way I can see this happening is if it buffers the whole
write()call's output itself, then writes it out to theostreamin one step. This means it needs to allocate memory, and if an object passed into thewrite()call produces a lot of output (several megabytes or more), it can consume up to twice that much memory in internal buffers (assuming it uses the grow-a-buffer-by-doubling-its-size-each-time trick).If you're just using it for logging, and not, say, dumping huge amounts of XML, you'll never see this problem.
The only other "catch" I'm seeing is:
So it won't work with an old C++ compiler, like
cfront, whereasiostreamsis backward compatible to the late 80's. Again, I'd be surprised if anyone ever had a problem with this.尽管 FastFormat 是一个很好的库，但它也存在许多问题：
Although FastFormat is a good library there are a number of issues with it:
看起来确实很有趣！ 无论如何，很好的小费，+1！
我已经玩了一段时间了。 我看到的主要缺点是 FastFormat 支持较少的输出格式化选项。 我认为这是实现更高类型安全性的直接结果，并且根据您的情况进行良好的权衡。
It looks pretty interesting indeed! Good tip regardless, and +1 for that!
I've been playing with it for a bit. The main drawback I see is that FastFormat supports less formatting options for the output. This is I think a direct consequence of the way the higher typesafety is achieved, and a good tradeoff depending on your circumstances.
如果您详细查看他的性能基准测试页面，您会发现良好的旧 C
printf系列函数在 Linux 上仍然获胜。 事实上，它们唯一表现不佳的测试用例应该是静态字符串连接的测试用例，我认为 printf 是浪费的。 此外，GCC 对 printf 风格的函数调用提供静态类型检查，因此类型安全的好处被削弱了。 因此：如果您在 Linux 上运行并且如果您需要绝对最佳的性能，FastFormat 可能不是最佳解决方案。If you look in detail at his performance benchmark page, you'll notice that good old C
printf-family functions are still winning on Linux. In fact, the only test case where they perform poorly is the test case that should be static string concatenations, where I would expectprintfto be wasteful. Moreover, GCC provides static type-checking onprintf-style function calls, so the benefit of type-safety is reduced. So: if you are running on Linux and if you need the absolute best performance, FastFormat is probably not the optimal solution.该库依赖于几个环境变量，如文档中所述。
对于某些人来说这可能没什么大不了的，但我希望我的代码尽可能独立。 如果我从源代码管理中检查它，它应该可以工作并编译。 如果它需要您设置环境变量，则不会。
The library depends on a couple of environment variables, as mentioned in the docs.
That might be no biggie to some people, but I'd prefer my code to be as self-contained as possible. If I check it out from source control, it should work and compile. It won't, if it requires you to set environment variables.