2

かなり古いアプリケーションを更新しています。コード全体でINIファイルアクセスを使用し、あちこちでINIアクセスクラスインスタンスを作成して解放しました。

これを、使用するファイルごとに1つずつ、複数の単一インスタンスに集中させたいと思います。したがって、どこにでもコピー貼り付けされたインスタンスを作成/解放し、それらのクラスを完全に置き換える自由を得ることができるので、INIから他の設定ストレージに切り替えることが決定されます。

変更を適用するには、WritePrivateProfileString（NULL、NULL、NULL ...）を呼び出す必要がありますか？次のことを想定します。1）アクセスは、レジストリにマップされたファイルではなく、実際のINIファイルに直接アクセスします。2）OSはNTファミリです（おそらくWin2000、おそらくWinXP以降）。Win9x / ReactOS / WinE / Odin/etcは気になりません。

では、iniの貯蓄を明示的にフラッシュする必要がありますか？

NTはレジストリキーの書き込みをキャッシュしません。今すぐregFlushKeyを実行する必要はありません。しかし、INIファイルはどうですか？

WritePrivateProfileStringに関するMSDNページでは、Win9xおよびNTファイルからRegへのマッピングによるフラッシュ手法についてのみ説明しています。実際のINIファイルについては沈黙しています。

4

1 に答える 1

2

ドキュメントはそれ自体と矛盾しています（私の太字）：

システムは、パフォーマンスを向上させるために、最新のレジストリファイルマッピングのキャッシュバージョンを保持します。すべてのパラメーターがNULLの場合、関数はキャッシュをフラッシュします。システムがファイルのキャッシュされたバージョンを編集している間、ファイル自体を編集するプロセスは、キャッシュがクリアされるまで元のファイルを使用します。

Windowsはマッピングまたはファイル（どのファイル）をキャッシュしていますか？しかし、サンプルコードのコメントはそれを明確にしています：

// Force the system to read the mapping into shared memory 
// so that future invocations of the application will see it 
// without the user having to reboot the system

キャッシュされるのはレジストリファイルマッピングです。レジストリのマッピングを変更する場合は、Windowsにキャッシュを更新するように指示する必要があります。

これは、何もフラッシュする必要がなかったWindows3.1でのAPIの使用法とも一致しています。WindowsがAPIの使用法を根本的に変える可能性は低いです。

再確認するために、 ProcessMonitorWritePrivateProfileStringの実行中に呼び出しました。予想どおり、WindowsはINIファイルを開き、更新してから再度閉じます。

フラッシングは必要ありません。

于 2012-06-07T19:49:44.700 に答える