.NET Framework 1.x

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

はなおかじった — 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;               // セッターでもコピーするので、これは変わらない
... 後ろも省略 ...

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

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

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 にして呼び出して、その中のプロパティを呼ぼうとしたら、そりゃ、落ちるよ。

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

[dNF1.1] Windows Form でコントロールをドラッグする

はなおかじった — Wed, 20 Feb 2008 22:26:00 GMT

次のアプリケーションの提案がてら、興味本位で。

ドラッグアンドドロップについては、Control.DoDragDrop の説明などに書いてあるので、詳しいことは割愛。私が参考にしたのは、Drag&Drop（ドラッグ&ドロップ）を行う（DOBON.NET）

MSDN ライブラリや DOBON.NET には、ListBox に表示された項目の D&D について、書かれています。ここで行いたいのは、コントロールです。なので、違いを中心に書き留めます。

まず、準備。


// マウス ボタンを押し込んだところ。
private Point mouseDownPoint = Point.Empty;
// ドラッグするコントロールの親コントロール座標での、コントロールの配置座標とマウス座標の差。
private Point pickedPoint = Point.Empty;
// ドラッグするコントロールの大きさ。
private Size controlSize = Size.Empty;

pickedPoint と、controlSize が、追加したもの。コントロールは、描画されるオブジェクトの左上の座標を指定します。しかし、押し込むことができるのは、コントロール全体です。この、左上座標とマウスボタンが押し込まれた座標との差を、保存します。controlSize は後述。

次、MouseDown イベントハンドラ。


private void button1_MouseDown(object sender, System.Windows.Forms.MouseEventArgs e) {
    Button btn = sender as Button;
    if (btn == null) { return; }
    if (e.Button == MouseButtons.Left) {
        mouseDownPoint = new Point(e.X, e.Y);
        Point sp = this.PointToClient(btn.PointToScreen(new Point(e.X, e.Y)));
        pickedPoint = new Point(btn.Left - sp.X, btn.Top - sp.Y);
    } else {
        mouseDownPoint = Point.Empty;
        pickedPoint = Point.Empty;
        controlSize = Size.Empty;
    }
}

とりあえず、ここでは Button を動かすことにしています。まぁ、この辺は適宜アレンジが必要ということで。

mouseDownPoint に、マウスボタンを押し込んだ座標を格納するところは同じですが、その後に、ボタン上のクライアント座標からスクリーン座標に、そこからフォーム（ドラッグしたいコントロールの親コントロール）のクライアント座標に変換したものを、sp に入れています。その座標を、コントロールの左上座標からの差を計算し、pickedPoint に格納しています。あれ？e.X, e.Y をそのまま持っていて、後で補正すればいいのでは？

次、MouseMove イベントハンドラ。


private void button1_MouseMove(object sender, System.Windows.Forms.MouseEventArgs e) {
    if (mouseDownPoint == Point.Empty) { return; }
    Rectangle moveRect = new Rectangle(
        mouseDownPoint.X - SystemInformation.DragSize.Width / 2,
        mouseDownPoint.Y - SystemInformation.DragSize.Height / 2,
        SystemInformation.DragSize.Width,
        SystemInformation.DragSize.Height);
    if (moveRect.Contains(e.X, e.Y)) { return; }
    mouseDownPoint = Point.Empty;
    Button btn = sender as Button;
    controlSize = new Size(btn.Width, btn.Height);
    DragDropEffects dde = btn.DoDragDrop(btn, DragDropEffects.Move);
    if (beforeRect != Rectangle.Empty) {
        // フォームの外にドロップされたときも、トラッカーを消す
        ControlPaint.DrawReversibleFrame(beforeRect, Color.Black, FrameStyle.Dashed);
        beforeRect = Rectangle.Empty;
    }
    btn.Refresh();
}

同じく前半の説明は省略。btn 以降。

controlSize に、ドラッグ対象のコントロールの Width, Height を保存します。これを、トラッカーに使います。「トラッカー」は、ここでは「ドラッグ中に移動対象の大きさを示す枠」の意味で使います。「トラックレクト」とか、「ラバーバンド」とか、そんな言葉が使われるかもしれません。

ここで、DoDragDrop メソッドにはまりました。これ、ドラッグ開始をマークして、すぐに抜けてくるんだと思っていました。しかし、ドラッグ中はこの中から他のイベントハンドラが呼び出されています。そのため、このメソッドから抜けてきた後に、トラッカーを消す処理を入れています。また、対象のコントロール上にトラッカーの跡が残るので、リフレッシュさせています。

次、あまり説明するもののない、MouseUp, DragOver, DragEnter イベントハンドラ。


private void button1_MouseUp(object sender, System.Windows.Forms.MouseEventArgs e) {
    mouseDownPoint = Point.Empty;
    pickedPoint = Point.Empty;
    controlSize = Size.Empty;
}

private void Form1_DragEnter(object sender, System.Windows.Forms.DragEventArgs e) {
    if (e.Data.GetDataPresent(typeof(Button))) {
        e.Effect = DragDropEffects.Move;
    } else {
        e.Effect = DragDropEffects.None;
    }
}

private void Form1_DragOver(object sender, System.Windows.Forms.DragEventArgs e) {
    if (e.Data.GetDataPresent(typeof(Button))) {
        e.Effect = DragDropEffects.Move;
    } else {
        e.Effect = DragDropEffects.None;
    }
}

見てわかるように、MouseUp はドラッグ対象コントロールのイベントですが、DragOver, DragEnter は、ドロップが実行されるコントロールのイベントです。

次、ドロップが実行される、DragDrop イベントハンドラ。


private void Form1_DragDrop(object sender, System.Windows.Forms.DragEventArgs e) {
    if (e.Data.GetDataPresent(typeof(Button))) {
        Button target = e.Data.GetData(typeof(Button)) as Button;
        if (target == null) {
            e.Effect = DragDropEffects.None;
            return;
        }
        ControlPaint.DrawReversibleFrame(beforeRect, Color.White, FrameStyle.Dashed);
        beforeRect = Rectangle.Empty;
        Point newPoint = this.PointToClient(new Point(e.X, e.Y));
        target.Left = newPoint.X + pickedPoint.X;
        target.Top = newPoint.Y + pickedPoint.Y;
        mouseDownPoint = Point.Empty;
        pickedPoint = Point.Empty;
        controlSize = Size.Empty;
    } else {
        e.Effect = DragDropEffects.None;
    }
}

ListBox の項目を移動させる時、項目を引いて足したのと同じようなことを行います。ここでは、コントロールの新しい場所を指定しています。また、トラッカーの表示などに使った変数をクリアします。

最後、トラッカーを表示するための QueryContinueDrag イベントハンドラ。


private Rectangle beforeRect = Rectangle.Empty;
private void button1_QueryContinueDrag(object sender, System.Windows.Forms.QueryContinueDragEventArgs e) {
    if ((e.KeyState & 2) == 2) {
        e.Action = DragAction.Cancel;
    }
    // トラッカー表示
    if (controlSize == Size.Empty) { return; }
    Point loc = new Point(Control.MousePosition.X + pickedPoint.X, Control.MousePosition.Y + pickedPoint.Y);
    Rectangle rect = new Rectangle(loc, controlSize);
    if (beforeRect.Equals(rect)) { return; }
    if (beforeRect != Rectangle.Empty) {
        ControlPaint.DrawReversibleFrame(beforeRect, Color.Black, FrameStyle.Dashed);
    }
    ControlPaint.DrawReversibleFrame(rect, Color.White, FrameStyle.Dashed);
    beforeRect = new Rectangle(rect.Location, rect.Size);
}

rect には、今ドラッグを終了するとどこにコントロールが置かれるかを示す範囲情報が入ります。beforeRect は、描いたトラッカーを消すために、前回表示した範囲情報を入れます。loc は、マウスカーソルの現在位置から pickedPoint の補正を加えた、コントロールの Left, Top 情報が入ります。Rectangle は値型なので、メンバを変更することができません。そのため、毎回 new します。

わかっている問題

時々、トラッカーが残る。
ドラッグ中、コントロール上にトラッカーが残る。

ウェブでアニメーションっぽい表示

はなおかじった — Fri, 20 Jul 2007 06:24:00 GMT

元ネタは、mixi の ASP.NET コミュにある質問。

複数枚の、動的に生成される画像を、一定時間毎に切り替えて、アニメーションのように表示したい、とのこと。出遅れたので、ここに書いておく。

表示したいところ
<div style="position:relative;">
    <p style="position:absolute; top:0; left:0; display:none;" id="p1">あいうえお</p>
    <p style="position:absolute; top:0; left:0; display:none;" id="p2">かきくけこ</p>
    <p style="position:absolute; top:0; left:0; display:none;" id="p3">さしすせそ</p>
</div>

面倒なので文字列にする。

まず、div で囲む。このとき、style で position を relative にする。こうすることで、この中の要素の absolute 指定が、この要素の座標を基準にすることになる。

表示するものは、まずは display を none にしておく。これで表示されない。そして、id として、同じ文字列に序数をつけたものを指定する。これで、後から検索しやすくなる。

JavaScript
<script language="javascript">
<!--
    var cnt = 1;
    function parapara() {
        for (i = 1; i <= 3; i++) {
            var pid = "p" + i;
            var cntrl = document.getElementById(pid);
            if (cntrl != null) {
                if (i == cnt) {
                    cntrl.style.display = "block";
                } else {
                    cntrl.style.display = "none";
                }
            }
        }
        cnt++;
        if (cnt > 3) {
            cnt = 1;
        }
        setTimeout(parapara, 1000);
    }
    setTimeout(parapara, 1000);
    // -->
</script>

cnt が、何番目を表示するかを保持する。for 文でぶん回して、片っ端から display を変更していく。このとき、ループの回数と cnt が同じものは block に。違うものは none にする。

cnt をインクリメントして、用意している最大数だったら最小数に戻す。最後にもう一度呼ばれるようにタイムアウトを設定する。

mixi の方には AJAX を利用したり、reload させて．．．という案で進んでいたのですが、そうすると表示を変えるタイミングで通信が発生します。もちろん、セッションを保つという大きな効用もあるのですが、それよりも、セッションが切れないことをセキュリティリスクと考えました。また、ネットワークに余計な負荷をかけることもないかと思います。

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 型を直にやればいいんじゃない？」
ですって？その辺は、刈歩さんがたっぷり説明してくださるでしょう。そうすると…

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

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

ちょっと気になったので調べてみた（HTML でフォーカス移動）

はなおかじった — Mon, 26 Feb 2007 22:25:00 GMT

某所を見ていて、ちょっと気になったので調べてみた。

W3C による、HTML 4.01 の仕様→ http://www.w3.org/TR/html4/

17章が FORM に関する仕様→ http://www.w3.org/TR/html401/interact/forms.html

ここの11項に、tabbing navigation が定義されている。

で、その原文。

Tabbing keys. The actual key sequence that causes tabbing navigation or element activation depends on the configuration of the user agent (e.g., the "tab" key is used for navigation and the "enter" key is used to activate a selected element).

User agents may also define key sequences to navigate the tabbing order in reverse. When the end (or beginning) of the tabbing order is reached, user agents may circle back to the beginning (or end).

フォーカス移動は HTML の仕様では決められておらず、ユーザーエージェントに任せられている。

つまり、「タブキーでフォーカス移動」は、InternetExplorer の仕様ということ。

そして、「tabbing navigation」だから、[TAB]キーが割り当てられたのではなかろうか。

ASP.NET で悲観的ロック

はなおかじった — Mon, 05 Feb 2007 22:10:00 GMT

ふと思ったんだけど、出来るんじゃないだろうか。以下、断定形で書くけど、想像だけで検証はしていません。

ログイン後に、フレームを作成する。仮にユーザに見せて遷移を行うフレームを「普通フレーム」、ロック情報を保持するためのフレームを、「ロックフレーム」とする。

ロックフレームは、幅1とかで見せないか、あるいは「ログアウト」ボタンのみを置いて、遷移をさせない。このフレームに表示する HTML で、body の onunload にて、ログアウトなどのロック解除を行う。これで、「ブラウザを閉じられたら？」に対応できる。

画面遷移は普通フレームだけで行い、ロックフレームは書き換えない。あるいは、これが書き換えられるときはログアウトするときだよ、と。

あとは、タイムアウト。チケットの有効期間とセッションの有効期間を同じ長さにしておけば、対応できるんじゃないかと。んで、ログインフォームは、_top に必ず一度リダイレクトするようにしておく、と。

やってみたいんだけど、分類の振り分けが、あと30近く残っているんだなぁ。。。全然減らないよぉ(T^T;)

今だから書いておく

はなおかじった — Fri, 29 Dec 2006 19:29:00 GMT

ネタもと：件名：ドット単位で印刷-プリンタの解像度に合わせて

売り言葉に買い言葉で返したのは、「送信」ボタンを押した瞬間に後悔した。

しかしね。それでも、やっぱり、腹立ったのよ。

某所で、「チラシの裏にでも」ってのを見て、なんじゃらホイ？と見てみたわけですが。でも、なんか、面白そうじゃないですか。

んで、まず、最初。プリンタの解像度に合わせて、ドット単位で、線をGraphicsに描画して、印刷したいと思っております。と、あるわけですが、ここで、「ドット単位って、プリンタ側の？グラフィックオブジェクトの？」と、疑問が発生するわけです。そして、GraphicsUnit.Documentを見て、これを MSDN で調べて、描画している単位を間違っているんじゃないか？と、思ったわけです。

まぁ、まず、「ドット」が、プリンタ側のものなのか、グラフィックオブジェクト側のものなのか、それを確認したいかな、という思いから、ここで言われている「ドット」って、なんですか？と、聞いてみました。で、答えがピクセルです。だけですか。。。

まぁ、こちらの意図は伝わらなかっただろうな、と思ったので、だから、なんの？まず、あなたが思っているであろう、1ドットがインク1滴から構成されているのか、確認が必要ではないですか？と、続けました。

ここで、私は「インク１滴による１ドットは、プリンタの最小描画単位ではない」と、考えています。ここで「最小描画単位」は、フルカラーを表現するために必要なデバイス（紙）上の大きさ、を意味します。なぜなら、インクは４色有り、３原色の組合せで色は表現されるからです。

CRT （カソードレイチューブ）の場合、１描画単位は、３つの光点から出来ています。つまり、Red/Green/Blue です。白を表示しようとすると、必ず３光点が光らなければなりません。したがって、グラフィックオブジェクト上の白１ドットは、CRT では３ドットで構成されます。PC-6001 等を触ったことがある方なら、SCREEN 4 でカラーを表示する方法を思い出していただければよいかと。

古いカラーインクジェットプリンタも同じです。最近のものも、粒子は細かくなっただろうけど、同じように、複数のインクから構成されているだろうから、「１ドット」の定義が必要だろう。そういう思いがあったわけです。

さて、ここで、対象のプリンタが、レーザーや白黒、熱転写（感熱紙）、インパクト、昇華型、プロッタ（まぁ、これはないか）である可能性を、わざと、考えていません。はい、わざとです。だって、そんなこと、質問文に書いてへんやん。

しかし、その返答は、ドットや、ピクセルが、プリンタの解像度の最小単位を、指していることは、わかっていての逆質問なのですね？ということなので、私が疑問に思っていることを、まったく疑わず、「グラフィックオブジェクトの１ドットはプリンタの１描画点である」と、考えられていたようです。

はい。思いこみの１点目。

で、次に、出来ました報告があって、そこには、こう書かれています。e.Graphics.PageUnit = GraphicsUnit.Millimeter;

おい。単位はミリメートルかよ。

ツッコミ点はまだあります。
IntPtr hDC = g.GetHdc();
MoveToEx(hDC, 100, 500, IntPtr.Zero);
LineTo(hDC, 100, 1000);

まて。これで、GDI+ と、gdi32 の共存ですって？つか、要は、プリンタのデバイスコンテキストを捕まえて、そこに直接描画。すれば、いいって事なんですかね？ってのが、これで出来たって？

白状すると、PageUnit の設定については、数時間悩みました。

こんなグラフを描きました。

分散を描けるグラフコンポーネントはあっても、そこに閾値を引くことが出来るコンポーネントは、見つけることが出来なかった。しょうがない、作ろう、ってなって。

いや、焦ったよ。最初、同じように GraphicsUnit.Millimeter を指定していて、単位５の太さの線と１０の太さの線を引いたら…５ドットと１０ドットを期待していたのに、ディスプレイ上で５ミリメートルと１０ミリメートルですよ！！

数回 MSDN のその辺りの記述を読み直し、やっとこれが「描画するときの単位」を指定するものであり、それ以降の数値は、この単位を基準に描画されるということがわかりました。

なんでこんなことするんだ？

そっかぁ。紙に印刷するなら、単位指定できた方が、「このプリンタの解像度はいくらだから、何ドットで描かないと細くて見えない」なんてことを考えなくて済むんだ！！そういえば、このグラフも、ウェブで表示して、印刷もするんだから、両方を同じルーチンで、PageUnit だけ換えれば、「どっちだから何ドット」って計算をしなくてもいいんだ！！すっげ～！楽ちん！！

なんてことがあったので、「おいおい、単に PageUnit の指定を間違えているだけだろう？」ってのが、２点目。

あと、GDI に渡すグラフィックオブジェクトを、GDI+ から取っているんですよね。それで、どうしてプリンタのデバイスコンテキストを捕まえたことになるの？ってのが３点目。

これ書きながら気がついた。当時も気になっていたけど、今、確認した。GID で描くとき、Pen の指定をしてないやん！！デフォルトを使用ですか。たまたまデフォルトが、1ビット幅の黒だったのね。

これだけの疑問点を内包しながら、頭悪いんですか？とかいわれた日にゃ、そのまま返したくなりますよ。

いや、その後の怒濤のポストは、私の方が冷めた(^-^;

なので、携帯からコソコソ送ったんだけど。。。PageUnit=Pixel では、画像の解像度にしかならないでしょ？ってかorz

この時点で、送られてきているグラフィックオブジェクトが、何を基に作られたオブジェクトなのか、理解していないことがわかった。そう。プリンタから送られてきた情報を基に作られた画像なんです。「ここに描き込んだら、デバイスに送信しますよ」って、オブジェクトなんです。

つかね。

怒濤のカキコの中で、考える余裕なんてなかったんじゃない？？これは、ある意味可哀想だよ。

まぁ、１３ページのをもっと早く送れていれば、３～１２ページはなかったかもしれないね。

みんなが怒るのももっともだよ。だけど、勝手な思いこみで、本当の解決を得る機会を失うのは本人です。もう、放っておいて上げることにしませんか？

GDI と GDI+ でプリンタドライバから上がってくる数値が違うのか？という問いに「そう思う」と答えた後、うちとしては、お付き合いのある数社のプリンタ屋さんと、技術的な話をし始めました。とあります。

「あちゃ～。。。やっちゃいましたね」というのが、感想。

つまり、「これこれの実験をしたところ、こういう結果を得た。これはドライバの作りが悪いと思う。」って、やっちゃったんでしょうね。まぁ、ね。日本のドライバメーカーで、Windows Hardware Quality Labs 通しているメーカーって、ほとんどないから・・・あれ？これ、ハードウェア？ドライバは？ドライバは、署名するだけでいいのかな？あ、ドライバとハードウェア込みね。はい。WHQL 通してないから、ドライバ屋さんも最初は「え？そうなんですか？」って、聞くだろうね。

でもねぇ。GDI+ って、GDI のラッパーなんですよ。GDI で返ってくる値と GDI+ で返ってくる値が違うってことは、Microsoft に責任がある、つまりフレームワークのバグってことですよ。そこを、プリンタ屋さんと話を…って。絶対叩かれるぞ、と思って、ちょっと可哀想になりました。で。案の定、叩かれたみたいで。。。

でもね。すごいですよね。その後、ちゃんと謝罪と、検証結果の報告をしてくださっているんですよ。すごい、勇気の要ることですよ。絶対、見習わなきゃいけないところですね。