今まで同じものだと思ってた。 ( WindowsIdentity と IPrincipal の違いは置いといて。)
それぞれ違うユーザー情報を返してきた時は驚いた。
・WindowsIdentity クラス (System.Security.Principal) の GetCurrent メソッド
現在実行中の Win32 スレッドのセキュリティ コンテキストの ID 情報を返します。
・Thread クラス (System.Threading) の CurrentPrincipal プロパティ
Win32 スレッドの上位で、現在実行されている .NET スレッドのプリンシパルを返します。
なるほど、型の違いと、Thread.CurrentPrincipal だけが設定可能なのはこういう理由か。
通常、インスタンスを生成する際には必ずコンストラクタが呼び出されます。
でも実は、コンストラクタを実行せずにインスタンスを生成することができます。
方法はとても簡単です。
生成したいインスタンスの型情報を渡して FormatterServices クラス (System.Runtime.Serialization) の GetUninitializedObject メソッド を呼び出すだけです。
このクラスは、通常シリアル化で使用されるクラスですが、インスタンス化したいクラスに SerializableAttribute クラス (System) が付加されている必要はありません。
それと面白いことに、Void 構造体 (System) をインスタンス化することができます。 (Activator じゃできないのに)
ただし、String クラス (System)、 ContextBoundObject クラス (System) はこの方法でインスタンス化することができません。
下記のコードでは、コンストラクタの処理中に例外をスローするクラスのインスタンスを生成できることが確認できます。
using
とりこびとさんの記事を読んでいて、そういえば VB のイベント定義って C# と違うんだよなぁと思い出したことがきっかけで、久々に VB のコードを書いてみました。そしたら、ちょっとした問題に気づきました。
とりあえず、C# でのイベント定義から。
C# でイベントを定義する場合、通常は以下のように記述します。
public
JavaScriptはオブジェクト指向言語である。
ただし、”クラスベース”のオブジェクト指向言語 （ C#やJavaなど ） ではなく、”プロトタイプベース”のオブジェクト指向言語である。
以下、JavaScriptでのOOPについての簡単な解説。
【 コンストラクタ 】
オブジェクトの雛形は ” コンストラクタ ” と呼ばれる関数として定義する。これは、クラスベース オブジェクト指向言語の ” クラス ” に相当する。コンストラクタは関数なので、普通の関数と同じように呼び出すこともできる。 （ 普通、そんな使い方はしないけど。 ）
コンストラクタからオブジェクトを生成するには、new 演算子を用いる。
//
何かと言うと、usingブロック内で得た値を戻り値で返す場合です。
例えば、
public
最近、というか今日から、HTML や ASPX と対になる JS ファイルの書き方を変えてみた。
こんな感じ。
HogePage.js
//
public static void Example() {
System.Timers.Timer tm = new System.Timers.Timer();
tm.Elapsed += new System.Timers.ElapsedEventHandler(tm_Elapsed);
tm.Interval = 1000;
tm.Enabled = true;
Console.ReadLine();
Console.WriteLine("end");
}
static void tm_Elapsed(object sender, System.Timers.ElapsedEventArgs e) {
try {
Console.WriteLine("Hello World!");
Thread.Sleep(1010);
throw new Exception("1");
} finally {
Thread th = Thread.CurrentThread;
Console.WriteLine(
th.ManagedThreadId + " " +
th.IsThreadPoolThread);
}
}
というコードで試してみる。
あえて、tm.Interval よりも、em_Elapsed メソッドの方が時間がかかるようにしてある。
これを実行すると、今までのプログラムと違って、強制終了されない。
このコードを動かすと、当然だが、IsThreadPoolThread は、常に trueだ。
一方、ManagedThreadId は、４，５，６の値が何度も表示され、７以上の値が表示されることはない。
スレッド内で例外を処理しなくても、スレッドが自動的にスレッドプールに返却されているようだ。
さらに、興味深い？のは、AppDomain.UnhandledExceptionで例外がキャッチできないことだ。tm_Elapsed 内で未処理の例外があると、この例外は行方不明になってしまう。
これまでの結論は、AppDomain.UnhandledExceptionで は使えないってこと。
それと、繰り返しになるが、Timerの場合は、例外をキャッチしなくてもプログラムが強制終了してしまうことは無い。
一方、Threadの場合は、強制終了されてしまう。
この２つの違いは、スレッドプールと、通常のマニュアルスレッドの違いから来るのかな？
それとも、Timer独自の仕様なのだろうか？
ThreadPool.QueueUserWorkItem や DelegateのBeginInvoke についても調べないといけないな。
http://msdn2.microsoft.com/en-us/library/fs2xkftw.aspx
のコードをみて、以下のように書いたら、base.Dispose() が呼ばれない可能性があるということで、FxCopの警告が出た。
protected override void Dispose(bool disposing) {
if(!this.disposed) {
try {
if(disposing) {
addedManaged.Dispose();
}
this.disposed = true;
} finally {
base.Dispose(disposing);
}
}
}
なので、以下のように書き換えた。
protected override void Dispose(bool disposing) {
try {
if(!this.disposed) {
if(disposing) {
addedManaged.Dispose();
}
this.disposed = true;
}
} finally {
base.Dispose(disposing);
}
}
この場合は、base.Dispose(true)が複数回呼ばれる可能性がある。でも基底クラスのDispose()もパターンに則って書かれているはずだから、問題はでないはず…
僕の好みは、前者なんだけど、まあいいか。
今までは、C#でGetEnumerator()を使うときって、
var enumerator = list.GetEnumerator();
while (enumerator.MoveNext()) {
var obj = enumerator.Current;
...
}
て書いてたけど、GetEnumerator()の戻り値であるIEnumerator
using (var enumerator = list.GetEnumerator()) {
while (enumerator.MoveNext()) {
var obj = enumerator.Current;
...
}
}
て usingを書かなくちゃいけないんですね。
今までほとんど意識してませんでした。
えっ、foreach使えばGetEnumeratorは使わないって？
でも、ときどき、GetEnumeratorが必要になるときがあるんです。
Regex rx = new Regex(@”(@”"([^""]|”"”")*”")|(“”([^\\""]|\\.)*”")”);
Match strMatch = rx.Match(s);
…
“(@”"([^""]|”"”")*”"
と
“”([^\\""]|\\.)*”")”
を or で繋げているけど、
もっと簡単に書くことはできないのかな。
考えてみたけど難しすぎて諦めた。
Powered by WordPress