.NET Framework 2.x

WinSNMP をラップ

はなおかじった — Fri, 24 Jun 2011 22:06:00 GMT

　ちょっと使いたかったのだが、探すと無かったので、作ってみた。

　使う場合は、自己責任で。

メモ：XmlSerializer で、名前空間の出力を抑制する

はなおかじった — Wed, 19 Jan 2011 22:02:00 GMT

XmlSerializer.Serialize メソッドを使うと、ルート要素に名前空間が追加されます。


<?xml version="1.0"?>
<root xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
</root>

これを、抑制する方法。

オーバーロードされた Serialize メソッドに、XmlSerializerNamespaces クラスのインスタンスを受け取るものがあります。ここに null を指定したり、何も追加していないインスタンスを指定しても、やはり規定の名前空間が出力されます。ステップインしてコードを見ると、null や Count が0の時は、規定の名前空間に置き換えるというコードが書かれていました。

ところが、XmlSerializerNamespaces クラスへの名前空間の追加については、なんのチェックもされていないようです（未確認）。ということで、空文字列の名前空間を追加したインスタンスを指定してあげます。


XmlSerializerNamespaces ns = new XmlSerializerNamespaces();
// null または、個数が0個だと、規定の名前空間が追加されるので、1個にする。
ns.Add("", "");
XmlSerializer xs = new XmlSerializer(typeof(TYPE));
using (StreamWriter writer = new StreamWriter(fileName, false)) {
    xs.Serialize(writer, object, ns);
    writer.Flush();
    writer.Close();
}


<?xml version="1.0"?>
<root>
</root>

「xmlns:xsd="http://www.w3.org/2001/XMLSchema"」を、「xmlns="http://www.w3.org/2001/XMLSchema"」の様に出力させたいと思って、「ns.Add("", "http://www.w3.org/2001/XMLSchema");」としたら、なんにも出力されなくなったので気がついたのでした。

ボックス化／ボックス化解除って、なに？

はなおかじった — Wed, 03 Jun 2009 22:35:00 GMT

先のエントリで言及したけど、意識したことがなかったので、意識してみるエントリー。

Visual C# 2008 をインストールすると、インストールしたディレクトリの下（C:\Program Files\Microsoft Visual Studio 9.0\VC#\Specifications\1041）に、Word 形式の言語仕様があります。まず、これに尋ねます。

『C# 言語仕様 Ver.3.0』「4.3 ボックス化とボックス化解除」より：

ボックス化とボックス化解除は、C# の型システムの中心的な概念です。これは、value-type のすべての値と object 型間の変換を可能にするため、value-types と reference-types との橋渡しの役目を果たします。ボックス化とボックス化解除の機能により、型システムを統一的に見ることができるようになり、すべての型の値を最終的にオブジェクトとして扱うことができます。

なるほど。中心的な概念なのだそうです。うむむ。知らなかった。。。

C# では、object 型は、全ての型の派生元であるとされています。派生元への変換は、暗黙の内に行えます。全ての型の派生元であるが故に、int や double などの値型からも暗黙の内に変換できなければなりません。この、値型から参照型への変換をしているのが、ボックス化、ってわけですね。

何が行われるかについては、「4.3.1 ボックス化変換」に書いてあります。オブジェクトインスタンスの割り当てと、値のコピーが行われます。値のコピーが行われます？値のコピーですって？！

はい、元のものとは別の、コピーされたものが作られます。コピーされるということは、コピーを書き換えても、オリジナルは書き換わらないということです。

ではこれ、どういうところで問題になるのでしょう？

と、、、思いつかないので（意識したことがないのだから、当たり前ですね）、ボックス化の問題ではないが、値型が関係する問題を紹介。

Windows アプリケーションを作ります。System.Windows.Forms.Form クラスです。フォームの位置は、Forms.Location プロパティで参照できます。Location は、System.Drawing.Point を返します。この中には、X 座標と Y 座標が入っています。では、次のようなコードで、フォームの位置を変えることができるでしょうか。


... 省略して、何かのメソッドの中 ...
    form1.Location.X += 100;     // 位置を右へ100ずらす
... 後ろも省略 ...

わざわざ「問題を紹介」といっているのだから、変えることはできない、というのが正解です。なぜでしょう？

プロパティは、アクセスメソッドを扱いやすくしたものです。メソッドに分解すると、先のコードは、次のコードのようになります。


... 省略して、何かのメソッドの中 ...
    System.Drawing.Point loc = form1.GetLocation();
    loc.X += 100;
... 後ろも省略 ...
... おそらく、Form.GetLocation() は、次のように実装されている ...
Point GetLocation()
{
    return this.location;
}

ここで、Point が値型であることが重要です。Point は値型なので、GetLocation が返す値は、呼び出し元へコピーされます。コピーなので、いくら loc の値を変化させても、Form が持っている location の値は変化しません。変化させるためには、値型のプロパティそのものを書き換える必要があります。


... 省略して、何かのメソッドの中 ...
    Point loc = form1.Location;
    loc.X += 100;               // ここでは変化しない
    form1.Location = loc;       // ここで変わる
    loc.X -= 100;               // セッターでもコピーするので、これは変わらない
... 後ろも省略 ...

これは、プロパティへのアクセスで値型の値渡しが行われ、値がコピーされることにより発生します。繰り返しますが、この例はボックス化による問題ではありません。しかし、ボックス化では、オブジェクトインスタンスの割り当てと、値のコピーが行われるため、ボックス化したときに元の値型変数が持つ値にアクセスすることはできなくなります。そのため、同じように、「値を変更したのに、変わってない」という問題が発生するでしょう。

で、ボックス化が、どういうときに問題になるか。。。例えば、「変更することができる」というインターフェイスを作成します。このインターフェイスを実装する値型をつくります。「変更することができる」なので、変更をするメソッドを作ります。このとき、「変更する」メソッドを使う方は、インターフェイスからアクセスするでしょう。そうすると、値型をインターフェイスにキャストしたときに、実はボックス化が行われるので、「変更する」メソッドではボックス化された値型にアクセスすることになります。すると、これはボックス化の過程でコピーが行われているため、本来の値は変更されないことになります。

レーティングをお願いします。

はなおかじった — Tue, 29 Apr 2008 22:24:00 GMT

VS2005 SP1をマージしたものを希望

ライブラリや OS 機能の追加、変更、削除を RSS として配信して欲しい。

VB 使うな、開発者なら。

はなおかじった — Wed, 02 Apr 2008 22:40:00 GMT

せめて、Option Strict On にしてくれ。。。

件名：join でフリーズ（Insider.NET 会議室）より：

コードはこんな感じです。


class TestA
    dim obj as object
    public sub new()
        obj = new object()
    end sub
    public sub main()
        dim t as thread
        t = new system.threading.thread(new system.threading.threadstart(address of do))
        t.start()
        t.join()
    end sub
    public sub do()
        obj.start()
    end sub
enc class

件名：Validatingでは（Insider.NET 会議室）より：


Private Sub txtTCD_Validating(ByVal sender As Object, ByVal e As System.ComponentModel.CancelEventArgs) Handles txtTCD.Validating
    Dim blnSUTI As Boolean
    Dim sb As New StringBuilder
    '*****
    If ActiveControl Is sender OrElse ActiveControl.CausesValidation = False OrElse sender.Text.Length = 0 Then
        Exit Sub
    End If
    '*** 入力ﾁｪｯｸ **************
    blnSUTI = Int32.TryParse(txtTCD.Text, mlngKEYTCD)
    If Trim(sender.Text).Length = 0 OrElse mlngKEYTCD = 0 Then
        MessageBox.Show("得意先を正しく入力して下さい", _
        Me.Text, MessageBoxButtons.OK, MessageBoxIcon.Exclamation)
        e.Cancel = True
        Exit Sub
    End If
    '*** ﾃﾞｰﾀ取得 **************
    Call mData()
    '*** ﾃﾞｰﾀ表示 **************
    Call mDisplay()
End Sub
'***
Private Sub 索引ﾎﾞﾀﾝｸﾘｯｸ
    Dim frmSAKUIN = New frmSAKUIN
    '*****
    If frmSAKUIN .ShowDialog = Windows.Forms.DialogResult.OK Then
        txtTCD.Text = frmSAKUIN .pTCD
        Call txtTCD_Validating(Nothing, Nothing)
    End If
    '*****
    frmAEIGS020.Dispose()
End Sub

勘弁してくれ。。。

上の方。obj は Object なので、start メソッドを持っていません。Strict Off にしているから実行時まで「start メソッドがあるかどうか」が延期され、、、って、おい！これ、なに？まさか、Thread.Start をしているとか？延々と自己呼び出しをやってんじゃないの？…StackOverflow で落ちるか？何にしても、動かないコードを出して「これが動かない」といわれても、そりゃ、動きませんよ、と。

下の方。sender.Text って、そりゃないよ。。。きっと、On Error Resume Next とかも指定してあるに違いない。Sender に Nothing にして呼び出して、その中のプロパティを呼ぼうとしたら、そりゃ、落ちるよ。

開発者なら。コンピュータと対話をする人なら。もっと、自分がコンピュータに対して何をお願いしようとしているか、自覚をしてください。

Windows Form：警告の表示

はなおかじった — Sat, 15 Dec 2007 22:06:00 GMT

件名：[VB2005] Validating イベント内で MsgBox を使えないジレンマ（Insider.NET 会議室）より：

>項目ごとにダイアログが出るとうっとうしいと苦情を言うユーザー

　項目毎にダイアログを出せ、というですよ
　たとえば、0～100 の範囲で入力しないといけない場合に、範囲外は「0～100の範囲で入力してくださいよ！」的なダイアログ（e.Cancel = True）を出せ、というですよ。

　更に80以上だったら「え？本当に80以上なの、すごいね！」みたいなダイアログ（e.Cancel = False）で御節介を焼いて欲しいそうな。

なるほどねぇ。。。

入力中に、ダイアログでメッセージを表示するのは、基本的に賛成できません。入力の流れを妨げるからです。よくある質問で、「Enter キーでフォーカスを移動させるには？」というのは、これに似た理由ですね。[Tab] キーはテンキーにはありませんので、手の移動が大きい＝入力の流れが妨げられる、と。この場合、Windows 標準のキー操作と衝突を起こすわけですが、どちらかというと、流れを妨げる方が大きな問題となるでしょう。フォーカス移動を「テンキーの [Enter] キーのみ」に絞れるなら、その方がいいとも思いますけど。

あるいは、わかってやっている場合もあります。例えば、伝票入力です。伝票はすでにどこかで作られていて、それをコンピュータに入力するのかもしれません。このとき、エラーはともかく、警告で入力の流れを妨げられると、ユーザはイライラするでしょう。特に、公共事業などではデータの入力を業者が行う場合があります。業者さんは指示されたとおりに入力するのが仕事なので、指示元のデータの正誤については責任がありません。このとき、指示元のデータと違うことを指摘するならともかく、入力値が正常な範囲でありながら入力の流れを阻害するような動作は、集中力を欠かせることになります。

特に、発注者と使用者が同じでない場合は、注意する必要があります。システム課などが業務の流れを知らず、「こうしてあればいいだろう」「こう使って欲しい」と思って発注しても、実際に使う場面にそぐわなければ、使われないシステムの仲間入りをする可能性が高くなります。

と、だめだめ言っていてもなんなので、提案です。

ToolTip を使ってみました。エラーメッセージは、ErrorProvider を使いました。

Visual Studio 2005 にて、Windows アプリケーションを作成します。
Form に、TextBox を2つ置きます。（ひとつは、フォーカスを遷移させるためだけのもの）
ToolTip と ErrorProvider も置きます。
ToolTip の、ToolTipTitle プロパティに、「警告」と入力します。また、IsBaloon プロパティを True にしておきましょう。ただの ToolTip だと、どこのコントロールに対して表示されたのかわかりにくいので。
TextBox1 にフォーカスし、プロパティウインドウで稲妻ボタンをクリックします。Validating イベントをダブルクリックします。
できたイベントハンドラに、後述のコードを書きます。
さて、実行してみましょう。

Validating コードの例:
private void textBox1_Validating(object sender, CancelEventArgs e) {
    Int32   chk;
    errorProvider1.Clear();
    toolTip1.Hide(textBox1);
    if (Int32.TryParse(textBox1.Text, out chk) == false || (chk > 100 || chk < 0)) {
        e.Cancel = true;
        errorProvider1.SetError(textBox1, "0以上100以下の数値を入力してください。");
    } else {
        if (chk >= 80) {
            //　see: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=98281
            toolTip1.Show("", textBox1);
            toolTip1.Show("80以上です。本当にいいですか？", textBox1);
        }
        e.Cancel = false;
    }
}

ErrorProvider は、規定では設定したコントロールの右側に、Icon プロパティで指定したアイコンを表示します。ここで指定したアイコンが表示できるだけの幅を、コントロールの右側に確保しておく必要があります。う～ん、ErrorProvider に、「ベルを鳴らす」機能があれば良かったのに．．．

toolTip1.Show メソッドを2つ並べて書いているのは、修正されていないバグのためです。こうしていても、たまに表示されるツールチップの位置がずれます。

表示されたツールチップを消すためには、フォーカスを他のフォームに移してやる必要があります。ツールチップをクリックしてもいいです。

ツールチップが表示された状態で、フォームを動かすと、ツールチップが付いてきません。その後、ツールチップにフォーカスを移してツールチップを消し、もう一度ツールチップが表示されるような操作をすると、表示される場所がずれますorz あはは。。。バグ見つけちゃったよ。

Validating イベントではこんな感じにしておいて、登録のアクションで、エラーなら登録させない。警告なら登録する、しないを選べるようにしておく。そんな感じかな。でも、ToolTip のバグのおかげで、使いにくいやorz

VB マイグレーション ByRef と ByVal - その２

はなおかじった — Thu, 31 May 2007 22:28:00 GMT

参照型については刈歩菜良さんに振ったので、参照渡しと値渡しを行きましょう。

ByRef, ByVal で渡したプロシージャ内で、変数そのものを書き換えた場合、ByRef と ByVal がどのような結果を返すか、です。実行結果はどのようになるでしょうか。

その前にですね、この前のコードを、C++ で書いてみます。C++/CLI でも Managed C++ でもない、C++ です。Visual Studio 2003 のプロジェクトの追加で、「C++ コンソールアプリケーション」を選択しました。

#include "stdafx.h"
#include <iostream>

class HogeClass {
public:
    int Value;
    HogeClass() {
        Value = 0;
    };
};
void ByValFunc(HogeClass hage);
void ByRefFunc(HogeClass* hage);

int _tmain(int argc, _TCHAR* argv[])
{
    HogeClass hoge1;

    hoge1.Value = 1;
    std::cout << hoge1.Value;  // [A]

    ByValFunc1(hoge1);
    std::cout << hoge1.Value;  // [B]

    ByRefFunc1(&hoge1);
    std::cout << hoge1.Value;  // [C]
}

void ByValFunc1(HogeClass hage)
{
    hage.Value = 2;
    //hage = new HogeClass();    // [イ]
    //hage.Value = 3;
}

void ByRefFunc1(HogeClass* hage)
{
    hage->Value = 4;
    hage = new HogeClass();
    hage->Value = 5;
}

なんと、[イ]のところで、コンパイルエラーが出ます。ということで、“全く同じ”ではないのですが、実行してみます。

結果は、114 です。

やっとスタート地点だよ。。。

「値渡し」は、引数「の値」を渡します。この場合、新しい HogeClass の為にメモリが確保され、全く同じ内容になるようにコピーされたものが、ByValFunc の hage になります。
hage は hoge のコピーなので、ByValFunc 関数内で変更した内容は、ByValFunc で宣言された hage にのみ適用され、_tmain に伝わることはありません。このため、ByValFunc 関数の中での変更は反映されず、[B] では "1" が出力されます。

「参照渡し」は、引数「への参照」を渡します。この場合、新しい HogeClass の為のメモリは確保されず、全く同じ場所を参照するものが、ByRefFunc の hage になります。
hage は hoge と同じ場所を指すので、ByRefFunc 関数内で変更した内容は、_tmain で宣言された hoge と同じ場所を変更するため、hoge の内容も変わります。つまり、ByRefFunc 関数の中での変更は、hoge を直接操作したのと同じとなり、[C] では "4" が出力されます。

では、なぜ[イ]の部分がコンパイルエラーになるのでしょうか。

C++ では、変数の宣言時に、値を保持するもの、アドレスを保持するものとして宣言できます。HogeClass hage; という宣言では、HogeClass という入れ物の、値を保持する変数と宣言します。しかし、new HogeClass(); は、HogeClass という入れ物を保持するために用意した場所を指す値を返します。
入れ物と、入れ物のある場所。
言い換えれば、「コーヒーカップ」と、「コーヒーカップは戸棚にあるよ」。この２つに互換性はありません。互換性がないことをコンパイル時に検出し、エラーとします。

ざっくりと。変数宣言に "*" が付いていたら、「場所」を指す。付いていなければ「そのもの」を指す。こんな感じで。C 言語で必ず躓くポイントなので、さらっと次に進む。

さて、今回のエントリの C++ によるコードと、前回のエントリの VB7.0 によるコードを比べてみましょう。
まず、結果を比べます。おっと、VB7.0 での結果をまだ書いてなかったですね。VB7.0 では "125" となります。VB7.0 のコードをもう一度書きますね。

Public Class HogeClass
    Public Value As Integer
End Class

Private Sub ByValAndByRef(ByVal sender As Object, ByVal e As EventArgs)
    RemoveHandler Application.Idle, AddressOf ByValAndByRef
    Dim hoge As New HogeClass

    hoge.Value = 1
    TextBox1.Text = hoge.Value.ToString()    ' [A] 1 を表示

    ByValFunc(hoge)
    TextBox1.Text += hoge.Value.ToString()   ' [B] 2 を表示

    ByRefFunc(hoge)
    TextBox1.Text += hoge.Value.ToString()   ' [C] 5 を表示
End Sub

Sub ByValFunc(ByVal hage As HogeClass)
    hage.Value = 2         ' [B] で表示される
    hage = New HogeClass   ' [あ]
    hage.Value = 3
End Sub

Sub ByRefFunc(ByRef hage As HogeClass)
    hage.Value = 4
    hage = New HogeClass   ' [い]
    hage.Value = 5         ' [C] で表示される
End Sub

ここで注目なのは、変数 hoge を宣言しているところにある、New というキーワードです。C++ のコードには、 _tmain 関数での宣言にこのキーワードがありませんでした。

ということで、C++ のコードにこのキーワードを入れようとすると、あっちこっちでコンパイルエラーが出るようになりますorz

そして、コンパイルエラーをとって、VB7.0 のコードと等しい動きをするようになったのが、次のコード。

#include "stdafx.h"
#include <iostream>

class HogeClass {
public:
    int Value;
    HogeClass() {
        Value = 0;
    };
};

void ByValFunc2(HogeClass* hage);
void ByRefFunc2(HogeClass** hage);

int _tmain(int argc, _TCHAR* argv[])
{
    HogeClass* hoge2;
    hoge2 = new HogeClass();

    hoge2->Value = 1;
    std::cout << hoge2->Value;

    ByValFunc2(hoge2);
    std::cout << hoge2->Value;

    ByRefFunc2(&hoge2);
    std::cout << hoge2->Value;
}

void ByValFunc2(HogeClass* hage)
{
    hage->Value = 2;
    hage = new HogeClass();
    hage->Value = 3;
}

void ByRefFunc2(HogeClass** hage)
{
    (*hage)->Value = 4;
    *hage = new HogeClass();
    (*hage)->Value = 5;
}

まず、hoge2 の宣言が、"*" 付き、すなわち「場所」を指すように変わりました。

ここです。

VB7.0 では、というより、共通型システム（CTS）では、ですね。CTS では、System.Object を継承した型はすべて、参照型となります。つまり、「場所」を指すようになっています。ここ、突っ込むと刈歩さんのセッションとバッティングするので、これくらいにしておく。

ByVal で引き渡す場合、引き渡すのは変数の値なのですが、その「値」とはつまり、「参照」なのです。「この変数の実体は、この場所にあるよ」という場所への参照情報を値渡しするので、引き渡された関数からでも、引数の内容を変更することができるのです。

そして、C++ のコードと見比べていただきたいのですが。あっと。ここには VB7.0 でのコードを載せましたが、C# でもそう変わらないコード内容になります。気をつけるのは、ByRef が、ref になることくらいでしょうか。

さて、強調してあるところが違うところだと、気づいていただけたかと思います。気づいて欲しいから強調しているわけですが。

hoge2 の宣言に "*" がついて、場所を指すようになったのと同様、ByValFunc, ByRefFunc の引数にも "*" がついて、ByRefFunc なんか２つも付いちゃってます。引き渡すところも、"&" が付いていたりしています。つまり、こうやって変数の内容を、値そのものなのか、値が格納してある場所なのか、人が指定しているわけです。ややこしいですね。

VB7.0 や C# では、このようなややこしいことを、言語仕様によって人が指定しなくていいようにしてあります。便利ですね。

え？なに？
「どうして、わざわざ int 型を持つクラスを定義するの？int 型を直にやればいいんじゃない？」
ですって？その辺は、刈歩さんがたっぷり説明してくださるでしょう。そうすると…

私が考える、部分定義のメリット

はなおかじった — Sat, 07 Apr 2007 21:03:00 GMT

部分型定義（その２）（R.Tanaka.Ichiro's Blog）より：

ところで、

デザイナ

を使ってフォームを作るとファイルが二つに分かることはご存じでしょうか？

実は、これもパーシャルクラスによるものです。
以下は、C# で Form1 というフォームクラスを追加した時に、自動的に作成されたファイルのサンプルです。

ファイル名：Form1.cs
　　public partial class Form1 : Form
　　{...

ファイル名：Form1.Designer.cs
　　partial class Form1
　　{...

さて、話を元に戻します。

私としては、フォームだけで終わって欲しくなかったので、私が考えるメリットを書きます。

Visual Studio.NET、および 2003 にも、DataSet デザイナがあります。こいつでデザインすると、XML Schema と、DataSet, DataTable, DataColumn, DataRow クラスを生成してくれます。便利ですね。でも、ちょっと待ってください。このクラス、かゆいところに手が届かないのです。

たとえば、「このテーブルに定義されている列名の一覧が文字列配列で欲しい」と思ったとします。すると、外部から DataTable を取り出し、そこから DataColumn クラスを引き出して、列挙してやらなければならない。ちょっと待ってください。オブジェクト指向は「自分のことは自分でする」が基本じゃないですか？DataTable の中に定義されている列名の一覧を、DataTable 自身が提供せずにどうします？

もちろん、生成されたコードを修正すれば、そういうことも可能です。しかし。そうしてしまうと、今度はデザイナで修正するごとに、コードを修正し直さなければならない。

ああ、面倒くさい！！

ここに有効に働くのが、パーシャルクラスです。

フォームの修正をしても、そんなのは所詮、Initialize メソッドと宣言あたりですんでしまいます。つまり、7.x バージョンでは region で囲まれていた範囲ですね。しかし、DataSet デザイナや CrystalReports は、ファイルを書き直してしまいます。こういうものに対しても、独自の宣言を追加できてしまうのです！！

もちろん、ここで止まりません。独自のコードビルダーを作ったとしても、そのコードビルダーの使用者は、あなたが生成部分をどのように実装していようが、あなたにお構いなしに独自の宣言を追加できるのです。

ね？便利でしょ？

επιστημηさんが危惧されているように、やり過ぎると「いったいこのクラスは、いつ完成するの？！」ということになります。私は、「自動生成コード」と、「そこに手動追加するコード」くらいの切り分けにしておく方がいいんじゃないかと思います。

月日は百代の過客にして行き交う技術もまた旅人なり

はなおかじった — Mon, 12 Mar 2007 22:38:00 GMT

先日の「再帰呼び出しの代わり」ですが。。。

すみません。思いっきり間違いを含みまくっています。一つに、古い情報を更新せずに、そのままの感覚で書いていました（タイトルは、ここにかけてみた）。一つに、書きながら、ほかのことを考えていました。シャノンさんのつっこみをベースに、修正。

プログラムポインタ → PC レジスタというので、「プログラムカウンタ」の方が正しく、Pentium では「EIPレジスタ」。

プログラムポインタのスタック領域→これは、書き方が悪かった、かな？これだと EIP レジスタ専用のスタック領域があるように理解できますね。そういうつもりではありません。「スタックセグメント」ですか。あ、IL ベースではなく、ネイティブベースです。って、例外を生成するのは IL ベースじゃないかorz

CL → IL が正しい。CL だと、コンパイルされてないじゃないか。
あれ？「共通言語」って、「共通言語仕様」という言葉でしか使わないの？
そういえば、CLR と CLI の違いもよくわからなかった。CLI は「共通言語基盤」。CLR が「共通言語ランタイム」。マイクロソフトによる CLI の実装が CLR、という理解でよかったはず。
いや、だから、頭文字略語はやめてほしい。。。あ、ここで使っているのは、acronym 要素を使っています。ポイントしてみてください。

ngen.exe → JIT コンパイラ。何を考えていたんだろう？たぶん、「どうやってアセンブリを見ようかなぁ？」とか考えていたんだと思う。で、何で「アセンブリを見よう」なんて考えていたかというと、チラホラ話題にあがっている「"=" は等号か、代入演算か」のスレに書いているコメントを考えていたから。

再帰呼び出しの代わり

はなおかじった — Fri, 09 Mar 2007 21:28:00 GMT

関数（メソッド）が、自分自身を呼び出すことを「再帰呼び出し」といいます。ディレクトリの一覧を取得するときなどに重宝します。

// 指定したディレクトリを再帰的に表示
[STAThread]
static void Main(string[] args) {
 if (args.Length == 0) {
  Console.WriteLine("ディレクトリを指定してください。");
 } else {
  OutputDirectory(args[0], 0);
 }
}
static void OutputDirectory(string directoryName, int depth) {
 if (Directory.Exists(directoryName) == false) {
  return;
 }
 DirectoryInfo dir = new DirectoryInfo(directoryName);
 PrintLeader(depth);
 Console.WriteLine("-{0}",dir.Name);
 DirectoryInfo[] dirInfo = dir.GetDirectories();
 foreach (DirectoryInfo item in dirInfo) {
  OutputDirectory(item.FullName, depth + 1);
 }
 FileInfo[] fileInfo = dir.GetFiles();
 foreach (FileInfo item in fileInfo) {
  PrintLeader(depth + 1);
  Console.WriteLine(item.Name);
 }
}
static void PrintLeader(int depth) {
 for (int level = 0; level < depth; level++) {
  Console.Write("｜");
 }
}

// 実行結果
D:\DataFolder\Projects\TestSolution\tree\bin\Debug>tree ..\..
-tree
｜-bin
｜｜-Debug
｜｜｜tree.exe
｜｜｜tree.pdb
｜-obj
｜｜-Debug
｜｜｜-temp
｜｜｜-TempPE
｜｜｜tree.exe
｜｜｜tree.pdb
｜｜｜tree.projdata
｜App.ico
｜AssemblyInfo.cs
｜Tree.cs
｜tree.csproj
｜tree.csproj.user

このプログラムの考え方の一例を示します。

指定されたディレクトリに存在する、ディレクトリの一覧を取得します。取得したディレクトリ一覧について、それぞれのディレクトリでまた存在するディレクトリの一覧を取得します。ディレクトリ内にディレクトリが存在しなければ、ファイルの一覧を取得し、表示します。そして、上のレベルへ制御を戻します。

ところが、この方法は少し注意が必要です。

ここの例では C# でコードを作っていますが、コンピュータは C# を理解できません。そこで、コンピュータにわかる言語にコンパイルします。C# の場合、コンパイルした結果は CL という言語になりますが、この言語を直接実行することは出来ません。実行時に、ngen.exe というツールでもう一度、今度はネイティブ（コンピュータが直接理解できる言語）にコンパイルされます。

ネイティブ言語、すなわち CPU が理解できる言語を実行するとき、“プログラムポインタ”（または、プログラムカウンタ）というレジスタがあり、このポインタで、次に実行するべき命令の位置を示します。関数呼び出しを行うと、このプログラムポインタの現在の値（および、他のレジスタの現在値）をスタックへ積み、呼び出される関数のアドレスで上書きします。そして、関数の実行が終わったら、プログラムポインタの値をスタックから取り出し、元の処理を続けます。

関数の呼び出しが多くなって、スタックする領域がなくなると、「スタックオーバーフロー」という実行時エラーが発生することになります。

反対に考えると、「スタックオーバーフロー」が発生したら、どこかで関数呼び出しがループしていると考えられます（あるいは、単に深すぎる）。このエラーは次のようなプロパティ設定をすると、簡単に発生させることが出来ます。

// スタック オーバーフローが発生する例
private int someValue;
public int SomeValue {
    get { return SomeValue; } // 大文字と小文字を間違えた！！
}
// SomeValue プロパティへのアクセスは、SomeValue プロパティを呼び出すため、無限再帰する。

このように再帰呼び出しは、ある処理をするためには必要なのですが、プログラムポインタのスタック領域という、比較的小さなエリアの大きさによって制限されます。また、CPU の実行レベルで考えても、レジスタ群のスタックやプログラムポインタの書き換えは、コストがかかる方法です。

そこで、再帰呼び出しと同じ結果を、別の方法で実現します。

こういう時に用いるのが、System.Collections.Stack クラス／System.Collection.Queue クラスです。スタックは、後入れ先出し（LIFO）の記憶領域を提供してくれます。キューは、先入れ先出し（FIFO）の記憶領域を提供してくれます。

どうするかというと、もう一度コードを見ます。ここで、再帰呼び出しをしているのは、foreach ブロックの中です。このループで、再帰呼び出しをしているところで、ループ内で使っている変数のスナップショットをとり、そのスナップショットをスタックに待避、新しい値で変数を上書きして処理をやり直せば、再帰処理をしているのと同じ動きをすることになります。

・・・面倒です。

なので、使いません。（おい）

ケースバイケース。ものは使いようなのです。

このコードでは、ディレクトリ構造を表示しました。表示するためには、今表示している内容がなんなのか、覚えておかなければなりません。覚えておかなければならないものがあるため、自分で覚えておかなければならないものを待避させなければならない場合は、再帰の方が楽です。

しかし、「ディレクトリ中のすべてのファイルを、{アタッチしたい | 更新日付が知りたい | フルパス名が知りたい}」という場合、ファイルにアクセスする順番は関係ありません。順番が関係ないなら、覚えておくものはありません。こういう場合、再帰呼び出しよりも低コストなので、使います。

// Main を少し変更
static void Main(string[] args) {
    if (args.Length == 0) {
        Console.WriteLine("ディレクトリを指定してください。");
    }
    else {
        DateTime start = DateTime.Now;
        OutputDirectory(args[0], 0);
        DateTime t1 = DateTime.Now;
        Console.WriteLine("----------");
        OutputDirectory(args[0]);
        DateTime t2 = DateTime.Now;
        Console.WriteLine("{0} / {1}", t1.Subtract(start), t2.Subtract(t1));
    }
}
// 指定したディレクトリ以下のフルパス名を表示
static void OutputDirectory(string directoryName) {
    // Queue に、次に列挙したいディレクトリを放り込むことにする
    System.Collections.Queue q = new System.Collections.Queue();
    DirectoryInfo dir = new DirectoryInfo(directoryName);
    // 初回が回るように、トップを放り込む
    q.Enqueue(dir);
    while (q.Count > 0) {
        // キューから取り出して、書く
        DirectoryInfo info = q.Dequeue() as DirectoryInfo;
        Console.WriteLine(info.FullName);
        // ディレクトリ内のディレクトリを、キューに放り込む
        DirectoryInfo[] dirs = info.GetDirectories();
        foreach (DirectoryInfo item in dirs) {
            q.Enqueue(item);
        }
        FileInfo[] files = info.GetFiles();
        foreach (FileInfo item in files) {
            Console.WriteLine(item.FullName);
        }
    }
}

// 実行結果
-tree
｜-bin
｜｜-Debug
｜｜｜tree.exe
｜｜｜tree.pdb
｜-obj
｜｜-Debug
｜｜｜-temp
｜｜｜-TempPE
｜｜｜tree.exe
｜｜｜tree.pdb
｜｜｜tree.projdata
｜App.ico
｜AssemblyInfo.cs
｜tree.cs
｜tree.csproj
｜tree.csproj.user
----------
D:\Visual Studio Projects\TestSolution\tree
D:\Visual Studio Projects\TestSolution\tree\App.ico
D:\Visual Studio Projects\TestSolution\tree\AssemblyInfo.cs
D:\Visual Studio Projects\TestSolution\tree\tree.cs
D:\Visual Studio Projects\TestSolution\tree\tree.csproj
D:\Visual Studio Projects\TestSolution\tree\tree.csproj.user
D:\Visual Studio Projects\TestSolution\tree\bin
D:\Visual Studio Projects\TestSolution\tree\obj
D:\Visual Studio Projects\TestSolution\tree\bin\Debug
D:\Visual Studio Projects\TestSolution\tree\bin\Debug\tree.exe
D:\Visual Studio Projects\TestSolution\tree\bin\Debug\tree.pdb
D:\Visual Studio Projects\TestSolution\tree\obj\Debug
D:\Visual Studio Projects\TestSolution\tree\obj\Debug\tree.exe
D:\Visual Studio Projects\TestSolution\tree\obj\Debug\tree.pdb
D:\Visual Studio Projects\TestSolution\tree\obj\Debug\tree.projdata
D:\Visual Studio Projects\TestSolution\tree\obj\Debug\temp
D:\Visual Studio Projects\TestSolution\tree\obj\Debug\TempPE
00:00:00.0312500 / 00:00:00.0781250

表示されている順番を見ると、再帰の例のように、ツリー表示には向かないことがわかると思います。何度かトライして、できなかったというわけでは、断じてあります。

しかし。。。実際に実行してみると、再帰処理の方が速かったorz...

K&R 本あたりに、関数を呼び出すことによる、プログラムポインタの書き換えと、ローカル変数の待避、および再生成のオーバーヘッドの方が大きい、と書いてあったと思うんだけど。すると・・・キューやスタックを使うメリットがない？？？