16

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?

4

6 に答える 6

6

FastFormat に「キャッチ」はありますか?

前回チェックしたとき、厄介なキャッチが1つありました。

このライブラリの狭い文字列バージョンまたは広い文字列バージョンのいずれかのみを使用できます。(との関数は同じです -- どちらの型が使用されるかは、コンパイル時のスイッチです。)wchar_tchar

iostreams、stdio、または Boost.Format を使用すると、両方を使用できます。

于 2011-10-07T09:24:15.377 に答える
5

ほとんどの人にとってそれが現れることはありませんが、1つの「キャッチ」を見つけました。プロジェクトページから：

アトミック操作。 IOStreams のようにステートメント要素を一度に 1 つずつ書き出さないため、原子性の問題はありません。

これが起こっていることを確認できる唯一の方法は、呼び出しの出力自体をすべてバッファリングしてから、 1 つのステップでwrite()に書き出すことです。ostreamこれは、メモリを割り当てる必要があることを意味し、write()呼び出しに渡されたオブジェクトが大量の出力 (数メガバイト以上) を生成する場合、内部バッファで最大でその 2 倍のメモリを消費する可能性があります (grow-a-buffer を使用すると仮定)。 -毎回そのサイズを2倍にするトリック）。

たとえば、膨大な量の XML をダンプするのではなく、ロギングのみに使用している場合、この問題は発生しません。

私が見ている他の唯一の「キャッチ」は次のとおりです。

携帯性に優れています。最新のすべての優れた C++ コンパイラで動作します。Visual C++ 6 でも動作します。

そのため、 のような古い C++ コンパイラでは動作しませんが、80 年代後半までの下位互換性がありますcfront。iostreams繰り返しますが、誰かがこれに問題を抱えたことがあるとしたら、私は驚くでしょう。

于 2009-12-14T16:56:23.707 に答える
4

FastFormatは優れたライブラリですが、いくつかの問題があります。

  • 限定的なフォーマットのサポート、特に次の機能はサポートされていません。
    • 先行ゼロ（またはその他のスペース以外のパディング）
    • 8進数/16進数エンコーディング
    • ランタイム幅/アライメント仕様
  • ライブラリは、フォーマットの比較的小さなタスクには非常に大きく、さらに大きな依存関係があります（STLSoft）。
于 2012-12-07T02:38:56.063 に答える
2

それは確かにかなり面白そうです！とにかく良いヒント、そしてそのために+1！

私はそれで少し遊んでいます。私が見る主な欠点は、FastFormat がサポートする出力の書式設定オプションが少ないことです。これは、より高い型安全性が達成される方法の直接的な結果であり、状況によっては適切なトレードオフだと思います。

于 2009-12-15T16:43:56.193 に答える
0

docsに記載されているように、ライブラリはいくつかの環境変数に依存しています。

一部の人にとっては大したことではないかもしれませんが、コードができるだけ自己完結型であることを望みます。ソース管理からチェックアウトすると、動作してコンパイルされるはずです。環境変数を設定する必要がある場合は、そうしません。

于 2010-05-20T12:26:17.383 に答える
0

彼のパフォーマンス ベンチマーク ページを詳しく見ると、古き良き Cprintfファミリの関数が Linux で依然として優れていることがわかります。実際、パフォーマンスが悪い唯一のテスト ケースは、静的な文字列連結であるはずのテスト ケースであり、printf無駄が多いと予想されます。printfさらに、GCC は 形式の関数呼び出しで静的な型チェックを提供するため、型安全性の利点が減少します。したがって 、Linux で実行していて、絶対的な最高のパフォーマンスが必要な場合、FastFormat はおそらく最適なソリューションではありません。

于 2009-01-15T14:25:05.750 に答える