Is there a 'catch' with FastFormat?

Question

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:<

Answer 1

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 expect printf to be wasteful. Moreover, GCC provides static type-checking on printf-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.

Answer 2

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.

Answer 3

Although FastFormat is a good library there are a number of issues with it:

• Limited formatting support, in particular the following features are not supported:
  • Leading zeros (or any other non-space padding)
  • Octal/hexadecimal encoding
  • Runtime width/alignment specification
• The library is quite big for a relatively small task of formatting and has even bigger dependency (STLSoft).

Answer 4

Is there a 'catch' with FastFormat?

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_t and char are the same -- which type is used is a compile time switch.)

With iostreams, stdio or Boost.Format you can use both.

Answer 5

Found one "catch", though for most people it will never manifest. From the project page:

Atomic operation. It doesn't write out statement elements one at a time, like the IOStreams, so has no atomicity issues

The only way I can see this happening is if it buffers the whole write() call's output itself, then writes it out to the ostream in one step. This means it needs to allocate memory, and if an object passed into the write() 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:

Highly portable. It will work with all good modern C++ compilers; it even works with Visual C++ 6!

So it won't work with an old C++ compiler, like cfront, whereas iostreams is backward compatible to the late 80's. Again, I'd be surprised if anyone ever had a problem with this.

Answer 6

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.