4

私は何年にもわたって、次の問題パターンに頻繁に遭遇しました。

  • 私は、スタンドアロン アプリケーションと、人々が他のアプリ内から使用できるコアのライブラリ バージョンで構成されるパッケージの複雑なコードを書いています。

  • 私たち自身のアプリと、おそらくユーザーがコア ライブラリを使用して作成したアプリの両方が、バッチ モード (オフライン、スクリプト、リモート、および/またはコマンド ラインから) と対話型の両方で実行される可能性があります。

  • ライブラリ/アプリは複雑で大量のランタイム入力を受け取り、重大なエラー メッセージ、入力構文の警告、ステータス メッセージ、実行統計など、さまざまなエラーのような出力が発生する可能性があります。これらはすべて付随的な出力であり、別の方法で別の場所に表示または保存されるアプリケーションの主な目的ではないことに注意してください。

  • これらのいくつか (おそらく非常に深刻なもののみ) は、対話的に実行する場合、ダイアログ ボックスが必要になる場合があります。ただし、バッチ モードで実行する場合は、ユーザー入力を停止せずにログに記録する必要があります。また、ライブラリとして実行する場合、クライアント プログラムは明らかに、発生したエラーをインターセプトおよび/または調査する必要があります。

  • Linux、Windows、OSX など、すべてクロスプラットフォームである必要があります。また、どのプラットフォームでもソリューションが奇妙にならないようにしたいと考えています。たとえば、stderr への出力は Linux では問題ありませんが、Windows では GUI アプリにリンクすると機能しません。

  • ライブラリのクライアント プログラムはメイン クラスの複数のインスタンスを作成する場合があり、クライアント アプリが各インスタンスで個別のエラー ストリームを区別できると便利です。

  • ライブラリ メソッドが単純な呼び出し (エラー コードや重大度、エラー メッセージを出力する printf のような引数) でエラーをログに記録するだけで十分であることに誰もが同意すると仮定します。論争の的となる部分は、これがクライアント アプリによってどのように記録または取得されるかです。

私はこれを何年にもわたって何度も行ってきましたが、解決策に完全に満足することはありません. さらに、実際にはユーザーにとってそれほど重要ではない種類のサブ問題です (ユーザーは何か問題が発生した場合にエラー ログを見たいと思っていますが、それを実装するための私たちの手法についてはあまり気にしていません) が、トピックはプログラマーを興奮させます。そして、彼らは常にこの詳細に途方もない時間を浪費し、完全に満足することは決してありません.

この機能を C++ API に統合する方法について知恵を持っている人はいますか、または受け入れられたパラダイムまたは優れたオープン ソース ソリューション (GPL ではありません。商用のクローズド アプリや OSS で使用できるソリューションが必要です) はありますか?プロジェクト)?

4

2 に答える 2

1

Log4Cxxが機能するはずです。ライブラリユーザーがコールバックでログ出力をキャッチできるようにするプロバイダーを実装する必要があります。ライブラリは、コールバックをインストールする関数をエクスポートします。この関数は、舞台裏でlog4cxxxを再構成して、すべてのアペンダーを削除し、「カスタム」アペンダーを設定する必要があります。

もちろん、ライブラリユーザーには、コールバックをインストールせず、log4cxxをそのまま使用するオプションがあります。

于 2008-09-04T18:55:32.623 に答える
1

ログ記録にはApache のLog4cxxを使用しますが、これは完全ではありませんが、多くのインフラストラクチャとプロジェクト間で一貫したアプローチを提供します。Windowsでしか使用していませんが、クロスプラットフォームだと思います。

ログファイルの出力方法を制御できるiniファイルを介して実行時の構成を提供し、特定の動作が必要な場合は独自のアペンダーを作成できます(UIの下のエラーダイアログなど)。

ライブラリのクライアントもそれを採用する場合、ログ出力を同じログ ファイルに統合します。

メイン クラスのインスタンス間の区別は、ネストされた診断コンテキスト (NDC) 機能を使用してサポートできます。

于 2008-09-02T14:56:47.753 に答える