Equals, GetHashCode を定義しているインターフェース。
両方ともObjectクラスにオーバーライド可能なメソッドとして存在しているにもかかわらず、わざわざインターフェースとして2.0で定義し直しているところが面白い。 同一性ではなく値として等しい、ということを強調したかったのだろうか。
Equals しかない IEquatable の方は何であるんだろ。
大文字と小文字を区別しない Hashtable または SortedList のfactory。 当初はもうちょっと増やすつもりだったのかもしれないが、これしかないと CollectionUtil の存在にたどり着くのが難しいような。
32bitの整数をbitのかたまりとして使うためのクラス。でも普通は Flags 属性つけたenumで実装するだろ。
複数のフラグの組み合わせに対してマスク操作したいとかいう時にenumから変換して使うとかそういう感じか? そういう時に速いコードになるかどうかも含めて微妙なクラス。
DeepCopyかShallowCopyか、インターフェース仕様で決めておいて欲しかったなあ。
とはいえShallowCopyでいいんだったら Object.MemberwiseClone があるわけで。 俺方針としては、全部DeepCopyってのは無理だとは思うけど、メンバーICloneableだったらDeepCopyする、という基準になるかな。
書式指定可能な ToString(string format, IFormatProvider formatProvider) を実装する。
書式指定コード "G" の実装は必須。一方で独自の書式指定を拡張することが可能。 DateTimeに対する yyyy-MM-dd みたいのを自分で定義したい場面は確かにあるな。 ログ出力の時に書式指定はconfigに追い出すような場面で活躍すると思われる。
同期モデルを設定するための基本機能なのだが、 SetSynchronizationContextを使ってスレッドに対する同期モデルを後から設定できるところがすごい。
変数間の代入、変数のIncrement,Decrement をアトミックに行うためのヘルパークラス。 自分でlockすりゃいいじゃんという気もするが、Interlocked の方が速いかもしれない。
32bitシステムでは64bit値の扱いがアトミックでない、という話題が興味深い。 というかこの話はかなり気をつけていないとはまりそうだ。
EventWaitHandle クラスにこんなサンプルコードがあるな。
private static long threadCount = 0;
...
while (Interlocked.Read(ref threadCount) < 5)
{
Thread.Sleep(500);
}
(追記)プログラミング .NET Framework 第2版によるとInt64の扱いは安全ではないので「使うな」と書いてある。やはり基本は自分でlockだな。
C# lock ステートメントは裏でMonitorクラスを使っている。普通は lock ステートメント。
ロックを取得出来なかった場合に別処理をする TryEnter を使うような場合に登場するクラス。 OSちっくなものを開発するんでなければあんまり使わないと思うが…
プロセス間でも使える同期オブジェクトを作る時に。
Mutex と Semaphore の違いがよくわからん。 ググってみた。ほほう。
Semaphoreは同時実行数を制限するような場合に使うのね。
ガベージコレクションの並列実行を抑制できる。 抑制した場合は自分でGCを起動するスレッドを書いて、自分でヒマそうなタイミングでキックするとかそういうことだろうか。
しかしGCの実行タイミングまで制御しなきゃいけないシビアなアプリケーションはそうそうないと思うが。 ゲームの場合はあるか。
Installer クラスの説明を読んでもさっぱり分からなかった。
VisualStudioにより自動生成されるコードであるところの DataSet.Designer.cs みたいな奴は DebuggerNonUserCodeAttribute がついている。
DebuggerNonUserCodeAttribute において、自動的にStepThroughなんだけどマルチスレッドの影響でそれでは困る(F5によるRunに自動的に切り替えたい)場合に利用する。
WMI Explorer を見たところ、WMIのイベントは __InstanceCreationEvent, __InstancDeletionEvent ぐらいしか使い道がない感じがする。
