0

DBResourceMonitorデータベースクラスのセットで使用される単純なクラスを作成しました。データベース クラスの 1 つのインスタンスが作成されると、それ自体が登録され、破棄されると、 のシングルトン インスタンスで登録が解除されますDBResourceMonitor。アプリケーションが終了すると、そのグローバル インスタンスDBResrouceMonitorが破棄されます。これにより、監視対象のクラスの登録済みインスタンスが残っていないことが確認され (つまり、登録ごとに unregister が呼び出された)、TRACE 出力が発行されます。不一致があった場合はアサートします。

これらのデータベース オブジェクトのいくつかをグローバル アプリケーション オブジェクトのメンバーとして配置するまでは、これで問題ありません。したがって、グローバル アプリケーション オブジェクトと は両方ともDBResourceMonitorグローバル シングルトンであり、アプリケーションは最初に構築されるため、最後に破棄されます。したがって、DBResrouceMonitorが破棄されるとき、アプリ オブジェクトのメンバーはまだ登録解除されていません。そのため、一致しない登録/登録解除呼び出しがあったことを示すエラーがスローされます。

私の知る限り、 がDBResrouceMonitorアプリケーション オブジェクトの前に構築される (したがって、後で破棄される) ことを保証する方法はありません。

これは正しいです？それを回避する賢い方法、または上記を再考して、最終スレッドが終了する前にすべてが処理されたかどうかを追跡できる方法はありますか?

4

2 に答える 2

2

コンストラクターでデータベース オブジェクトを「登録」し、(仮想) デストラクタでそれを「登録解除」する基本クラスを持つことにより、データベース オブジェクトをリソース モニターと同じにすることができます。このようにして、オブジェクトを作成するだけで、シングルトンや追加のモニター クラスについて心配する必要がなくなります。もちろん、オブジェクトのコレクションは、この基本クラスのプライベートな静的メンバーであり、マルチスレッドを使用している場合は保護される可能性があります。

std::unique_ptrまた、生のポインターの代わりに使用するか、場合によってはstd::shared_ptr.

于 2012-11-20T19:15:52.843 に答える