fc2ブログ

C#文法リファレンス ー 書き込み専用メソッド

概要
 処理内容を明かすことなく、実行状態を変えます。

日常でたとえると
 秘密の任務を行う。おもてなしをする。

使用に適した状況
 オブジェクトの利用者に意識させることなく、何らかの処理を行いたい場合。イミュータブルオブジェクトのコストが高い場合。

サンプル

/*----------------------------------------------------
 * 
 *  書き込み専用メソッド(副作用を伴う処理)
 *  
 ----------------------------------------------------*/
using System;

class Foo
{
    private int _value;
    public void SetValue( int newValue )
    {
        this._value = newValue;
    }

    public int GetValue()
    {
        return this._value;
    }
}

class Sample
{
    static void Main( )
    {
        //呼び出しの順序で結果がわかる
        Console.WriteLine( "順序に値を変える処理を実行します・・・" );
        Foo obj = new Foo();
        obj.SetValue( 10 );
        Console.WriteLine( "現在の値は{0}です。", obj.GetValue() );
        obj.SetValue( 20 );
        Console.WriteLine( "現在の値は{0}です。", obj.GetValue() );
        Console.WriteLine();

        Console.WriteLine( "順序を変えて処理を実行します・・・" );
        Foo obj1 = new Foo();
        obj1.SetValue( 20 );
        Console.WriteLine( "現在の値は{0}です。", obj1.GetValue() );
        obj1.SetValue( 10 );
        Console.WriteLine( "現在の値は{0}です。", obj1.GetValue() );

        //終了
        Console.ReadLine();
    }
}


文法
 書き込み専用メソッドという名前の文法はありませんが、戻り値の型を「void」にすることにより、利用者にその意図を伝えるのが一般的です。

解説
 イミュータブルなオブジェクト(変更不可能なオブジェクト)における、インスタンスの生成コストが高い場合、変更可能なオブジェクトを作ることになります。変更不可能で透過性がないオブジェクトの実装は、オブジェクト内部に持つフィールド値、コンピューター内部の情報、カーネルオブジェクトなどといったものを変更する形で行います
 イミュータブルオブジェクトのコストが高いという後ろ向きの理由だけではなく、変更可能なオブジェクトには、メリットがあります。それは、処理内容をカプセル化し、利用者の負担を減らせることです。オブジェクトの内部で、利用者に無断でいろいろな状態を変え、結果を、プロパティや専用のメソッドなどで最終結果だけど知らせることができます。こうすると、オブジェクトの利用者は、複雑なアルゴリズムを考えずとも、常に正しい結果だけを受け取ることができます。
 ただし、並列処理の一般化により、この手間を省けるというメリットも難しくなってきました。変更可能なオブジェクトの値は、時間と状況により変わるので、実行順序が変更されると、意図した処理結果を得ることができなくなります。従って、並列しやすいイミュータブルオブジェクトをカプセル化する目的で、変更可能なオブジェクトを用意するといった、より高度な戦略が求められています。
 変更可能なオブジェクトと、変更不可能なオブジェクトをうまく使い分けましょう。なお、書き込みプロパティと、書き込み専用メソッド(副作用を伴うメソッド)の違いは、プロパティが属性、メソッドが振る舞いである点です。大きな差はないように見えるでしょうが、この意味の違いが設計に大きく影響を与えます。両者の違いにも十分に注意してください。
スポンサーサイト



テーマ : プログラミング
ジャンル : コンピュータ

C#文法リファレンスの目次

このブログで書いてあるC#文法リファレンスの目次を用意しました。
項目は分類わけしました。

変数とインスタンス
繰り返し文
分岐処理

ジェネリック
メソッドとパラメーター
コンストラクタ
カプセル化
継承
オーバーロード(多重定義)/演算子のオーバーロード
ネイティブ
その他

テーマ : プログラミング
ジャンル : コンピュータ

C#文法リファレンス - 書き込み専用プロパティ

概要
 書き込み専用のプロパティを実装できます。書き込み専用プロパティは、主にオブジェクトの役割を明確化したいときに使用します。

日常でたとえると
 会議中議事録を書くことに専念する。

使用に適した状況
 処理が複雑でオブジェクトの役割分担が必要な場面で使用します。

サンプル

/*----------------------------------------------------
 * 
 *  書き込み専用プロパティ
 *  
 ----------------------------------------------------*/
using System;
using System.IO;

class Writer
{
    private StreamWriter writer;

    public string Data
    {
        set 
        {
            writer.WriteLine( value );
        }
    }

    public Writer( )
    {
        FileInfo file = new FileInfo( "data.txt" );
        this.writer = file.CreateText();
    }

    public void Close( )
    {
        writer.Close();
    }
}

class Reader
{
    StreamReader reader;

    public string Data
    {
        get
        {
            return this.reader.ReadLine();
        }
    }

    public Reader( )
    {
        FileInfo file = new FileInfo( "data.txt" );
        this.reader = file.OpenText();
    }

    public void Close( )
    {
        this.reader.Close();
    }
}

class Sample
{
    static void Main( )
    {
        //何らかの文字列をメモリ内に書き込む
        Writer writer = new Writer();
        writer.Data = "書き込み専用プロパティの実験";
        writer.Data = "1、2、3、ピョーッ!";
        writer.Data = "書き込み専用プロパティの使いどころが難しい";
        writer.Close();

        //書き込んだデータを読み取る
        Console.WriteLine( "秘密のデータを読み取ります・・・" );
        Reader reader = new Reader();
        string data = null;
        while ( ( data = reader.Data ) != null ) {
            Console.WriteLine( data );
        }
        reader.Close();
        Console.WriteLine("データの読み取り終了");

        //後片付け
        File.Delete( "data.txt" );

        //終了
        Console.ReadLine();
    }
}


文法
 プロパティの定義の際に、ゲッター(get{}の部分)を書かかないと書き込み専用プロパティになります。

解説
 普通にプログラミングをしていると、読み取り専用プロパティの方を多用します。次に多いのが、読み書きの両方ができるプロパティです。しかしながら、業務システムのように、処理内容が複雑で、オブジェクトのリファクタリングが必要になった時、読み取り専用のオブジェクトと、書き込み専用のオブジェクトを分けて定義する場合があります。また、利用シーンがわかれている場合、オブジェクトを分けて定義したほうが使いやすいです。
 たとえば、.NETライブラリのSystem.IO名前空間に用意されているオブジェクト群は、読み書きが別のオブジェクトとなっています。この例でわかると思いますが、利用シーンが分かれているときは、読み書きを別のオブジェクトとして定義したほうが使い勝手がいいです。
 他にはセキュリティ関係のオブジェクトが、書き込み専用プロパティを使用する可能性があります。例えば、パスワードをすぐに読み取れたら問題です。書き込み専用オブジェクトを用意しても、ハッキングすれば取得できますが、小さな積み重ねが大切です。
 書き込み専用プロパティは、普通の読み書きの両方ができるプロパティよりも活用できる場面が少ないですが、利用するべき状況が来たとき便利です。

テーマ : プログラミング
ジャンル : コンピュータ

ネタつつき199 - 記憶するコツは記憶しようとしない事

 私はよく人から記憶力がいいといってもらえます。そして、記憶するコツを聞かれます。その答えは「記憶しようと意識しない」です。逆説的ですが、記憶しようとしないほうがかえって記憶できます。私は何かを覚えようと意識せず、丸暗記のための行為は何もしません。
 私自身は記憶力について、あまり高い評価をしていません。もちろん、記憶力がないよりもある方がいいのに決まっていますが、別にあったからと言って、そのことにだけに高い価値を感じていません。何故ならば、ただ丸記憶するだけならば機械でもできるからです。いえそれどころか、丸暗記の力では、人は機械に勝てません。それ故に、丸暗記には価値がないのです。
 日本の教育は儀式化しており、社会は丸暗記に過剰な評価をしていると私は考えています。記憶して悪いということはありませんが、PCや本などの媒体に保存しておけば、丸暗記をしなくても済みます。従って、丸暗記という行為に価値を感じません。それどころか、その行為は学問に対する侮辱だと感じます。
 どのような学問の事象であっても、それらの物事は先人たちが命を賭けて創造したものです。それをただ単に丸暗記するというのは、先人たちの努力を冒涜する行為であり、人間としてやってはならない行為ではないでしょうか?
 たとえば、誰か親切な人が、助言してくれたとします。その時言葉を文字通りに丸暗記だけして、言葉に秘めた思いを無視し、内容を何も理解しなければ、失礼ではないでしょうか?
 私にとって学問を学ぶ行為は人との対話でもあるのです。ただ丸暗記するのではなく、子孫への知的財産を残してくれた先人たちを思い、深く味わいます。その結果、自然と覚えてしまうだけです。私にとって記憶は二次的効果にすぎません。
 私は専門書などに書かれている文字をそのまま覚えようとはしません。内容を深くかみしめ、文字の深層に潜む思いや真実をくみ取ろうとします。どうやら、そういった学習行為が、自然と記憶となって表れるようです。
 皆様は何かを丸暗記しようとしていませんか?でも、それでは覚えるのに限界がありますし、すぐに忘れてしまいます。丸暗記するのではなく、恋人と話しをするように、深く物事を考え抜きましょう。そうすれば、丸暗記では手に入れることができない、機械が持ちえない価値あるものが得られます。

テーマ : 文明・文化&思想
ジャンル : 学問・文化・芸術

C#文法リファレンス - イミュータブルオブジェクト(変更できないオブジェクト)の作成法

概要
 各種文法を組み合わせ、変更不可能なオブジェクトを実装します。

日常でたとえると
 俺の意思は揺るがない。

使用に適した状況
 ほぼ全ての状況で使用できます。例外は作成が高くつくオブジェクトです。その場合、管理しているオブジェクトにアクセス権を持たして、変更できるオブジェクトを実装するべきです。

サンプル

/*----------------------------------------------------
 * 
 *  イミュータブル(変更不可能)オブジェクト
 *  
 ----------------------------------------------------*/
using System;

class Foo
{
    private readonly int _addValue;

    public Foo( int addValue )
    {
        this._addValue = addValue;
    }

    public int GetValue( int value )
    {
        return value + this._addValue;
    }
}

class Sample
{
    static void Main( )
    {
        //変更する方法がないイミュータブルオブジェクトを試す
        Foo obj = new Foo( 10 );
        int value = 100;
        Console.WriteLine( "指定値{0}の戻り値は{1}です。",
            value, obj.GetValue( value ) );

        //変更したい場合新しく作る
        Foo obj1 = new Foo( 0 );
        int value1 = 914;
        Console.WriteLine( "指定値{0}の戻り値は{1}です。",
            value, obj1.GetValue( value1 ) );

        //終了
        Console.ReadLine();
    }
}


文法
 コンストラクタで初期値を指定し、リードオンリーのフィールドに記憶して管理します。こうしておけば、一度作成したインスタンスの状態が変更できなくなります。

解説
 各インスタンスが持つ状態を、自由に変更できるようにすると、そのプログラムは、実行順序および時間に依存することになります。実行順序と時間に依存するプログラムは、個々に見れば簡単です。しかし、プログラム全体に不確定要素をもたらします。プログラムに不確定要素があると、エラーを発見し難く、保守査証も複雑化します。
 特に並列処理プログラミングになると、正しい結果を常に得られるようにするのが難しくなってしまいます。また、順序と時間を常に意識しなければならないので、テストの複雑化してしまいます。
 個々のオブジェクトのふるまいを簡潔に保ち、組み合わせて複雑な処理をするのがオブジェクト指向プログラミングの思想なので、不必要に複雑な変更可能なオブジェクトは、理由がない限り使用するべきではありません。一度作成したら変更ができないイミュータブルなオブジェクトにするのが賢明です。ただし、イミュータブルオブジェクトにも弱点があります。
 イミュータブルオブジェクトの弱点は、新しい結果が欲しいときに、必ずインスタンスを生成しなければならない事です。普通のオブジェクトは問題ありませんが、処理回数が多かったり、オブジェクトの作成が複雑で重かったりした場合、変更可能なオブジェクトにするしかないでしょう。その際は、アクセスを工夫し、変更できるオブジェクトを限定するとよいでしょう。

テーマ : プログラミング
ジャンル : コンピュータ

C#文法リファレンス - 読み取り専用メソッド(参照透過性がある関数)

概要
 返される値が定まっているメソッドを定義することができます。インスタンスごとに返される値が決まっていると、テストがやりやすくなり、並列プログラミングがやりやすくなります。

日常でたとえると
 あの人は有言実行だな。

使用に適した状況
 基本的にあらゆる状況で使用できます。また、並列プログラミングが一般的となった今となっては、デフォルトのテクニックということができます。

サンプル

/*----------------------------------------------------
 * 
 *  読み取り専用メソッド(参照透過性がある関数)
 *  
 ----------------------------------------------------*/
using System;

class Foo
{
    private int _value;

    public Foo( int saveValue )
    {
        this._value = saveValue;
    }

    //返される値が必ず決まっている
    public int LoadValue( )
    {
        return this._value;
    }
}

class Sample
{
    static void Main( )
    {
        //インスタンス初期化時に基準値を設定する
        Foo obj = new Foo( 10 );
        Foo obj1 = new Foo( 20 );
        Console.WriteLine( "オブジェクト0の値:{0}", obj.LoadValue() );
        Console.WriteLine( "オブジェクト1の値:{0}", obj1.LoadValue() );

        //終了
        Console.ReadLine();
    }
}


文法
 特別な文法は用意されていません。人間が定められた値を返すようにプログラミングします。

解説
 新人研修で、読み取り専用プロパティとフィールドを、教えた時によく聞かれる質問が、読み取り専用メソッドはあるのかということです。結論としては、該当する概念があります。ただし、読み取り専用メソッドは呼ばず、参照透過性がある関数といいます。
 参照透過性を簡潔に表現すると、一度値が定まったら(束縛されたら)後は変更されないことです。プロパティの書き込みや、メソッドを通じて、インスタンスが保持す値を変更すると、そのプログラムは時系列に処理をすることに依存してしまいます。つまり、更新する順番で返される値が変わってしまうのです。
 実行する順番で返される値が違うということは、テストをする際に、テストパターンが増えることを意味します。また、並列処理プログラミングでは、実行する順番は変化するので、プログラミングするのが困難になります。そうしたことから、参照透過性がある関数が望ましいといえます。
 メソッドではなく、関数と呼ぶ理由は、メソッドは値を返さない場合があるからです。関数は必ず値を返す事が原則です。メソッドは、値を返さない手続きと、値を返す手続きを合成した概念です。ですから、正式に表現すると、参照透過性がある関数となります。参照透過性がある関数を使用すると、テストがやりやすく、並列度が高いプログラムになるでしょう。

テーマ : プログラミング
ジャンル : コンピュータ

C#文法リファレンス - 読み取り専用プロパティ

概要
 プロパティのセットを禁止し、読み取り専用にします。

日常でたとえると
 消費税は大概同じ。だけど、たまに増える。だから、経理課の人から聞くことにした。
※データベースから取得するようにしたということ


使用に適した状況
 長期間値が変わらないインスタンスの値に対して使用します。

サンプル

/*----------------------------------------------------
 * 
 *  読み取り専用プロパティ
 *  
 ----------------------------------------------------*/
using System;

class Foo
{
    public int ReadOnlyValue
    {
        get { return 10; }
    }
}

class Sample
{
    static void Main( )
    {
        //定数なのでどのインスタンスも値が同じになる
        Foo obj = new Foo();
        Foo obj1 = new Foo();
        Console.WriteLine( "オブジェクト0の値:{0}", obj.ReadOnlyValue );
        Console.WriteLine( "オブジェクト1の値:{0}", obj1.ReadOnlyValue );

        //終了
        Console.ReadLine();
    }
}


文法
 プロパティのゲッター、「get」キーワードを付けて、波カッコでコードブロックだけ記述します。読み書き自由なプロパティは、セッターも同時に記述しますが、指定しないと読み取り専用になります。

解説
 オブジェクト指向プログラミングに慣れてくると、プロパティは基本的に読み取り専用にしておき、どうしても変更する必要があるときのみ、読み書き自由な普通のプロパティにしたほうがよいと気付きます。何故ならば、変更されないほうが、テストも行いやすく、並列プログラミングも行いやすいからです。また、カプセル化の観点から言っても、インスタンスが生成された後、極力値を変えないほうが望ましいといえます。
 読み取り専用フィールドと、定数フィールトド違い、読み取り専用プロパティは使用頻度が非常に高いです。特にテストファーストで、並列プログラミングをしていると、読み取り専用プロパティが基本になります。
 巷ではプロパティは読み書き自由が普通だと誤解されていますが、書き込むのにはそれなりの理由が必要です。オブジェクト指向設計をし、その結果、どうしても書き込みたいときのみ使用します。プロパティを使用するときは、極力読み取り専用にするのをお勧めします。

テーマ : プログラミング
ジャンル : コンピュータ

C#文法リファレンス - 読み取り専用フィールド

概要
 フィールド変数の変更を禁止し、読み取り専用にします。

日常でたとえると
 消費税は大概同じ。だけど、たまに増える。

使用に適した状況
 長期間値が変わらないフィールドに対して使用します。

サンプル

/*----------------------------------------------------
 * 
 *  読み取り専用フィールド
 *  
 ----------------------------------------------------*/
using System;

class Foo
{
    public readonly int ReadOnlyValue = 10;
}

class Sample
{
    static void Main( )
    {
        //定数なのでどのインスタンスも値が同じになる
        Foo obj = new Foo();
        Foo obj1 = new Foo();
        Console.WriteLine( "オブジェクト0の値:{0}", obj.ReadOnlyValue );
        Console.WriteLine( "オブジェクト1の値:{0}", obj1.ReadOnlyValue );

        //終了
        Console.ReadLine();
    }
}


文法
 フィールドの定義時に「readonly」キーワードを付けます。

解説
 プログラミングでは、消費税のように長期間変更されない読み取り専用の値が存在します。このような変更がほぼない値を、readonlyキーワードを使って読み取り専用にすると、エラーを防げて便利です。何故ならば、集団でプログラミングをしていると、事情を知らない人がフィールドの値を変更してしまう可能性があるからです。readonlyキーワードを付けておくと、誤って値を書き換えるとコンパイラが教えてくれます。
 とはいえ、オブジェクト指向プログラミングを知っている人ならば、読み取り専用フィールドをほとんど使用しません。というのも、読み取り専用プロパティの方がよいからです。理由は、後で内部ロジックを変更しやすいからです。データのカプセル化の観点から言っても、極力読み取り専用フィールドを使用せず、読み取り専用プロパティを使用しましょう。
 フィールド定数との違いは、バイナリ値としてコンパイルされない点にあります。読み取り施用フィールドは独立して変更できます。ただし、読み取り専用プロパティの方がプログラムを変更しやすいので、やはり、よほどのことがない限り、読み取り専用プロパティを使用するべきだと思います。

テーマ : プログラミング
ジャンル : コンピュータ

C#文法リファレンス - フィールド定数

概要
 フィールド変数の変更を禁止し、定数として扱えるようにします。

日常でたとえると
 円周率の値は普遍だ。

使用に適した状況
 ごくまれに、絶対に変更されない値があります。そのような場合に使用しますがまれで、普通はリードオンリーフィールドの方を使用します。

サンプル

/*----------------------------------------------------
 * 
 *  定数フィールド
 *  
 ----------------------------------------------------*/
using System;

class Foo 
{
    public const int ConstValue = 10;
}

class Sample
{
    static void Main( )
    {
        //定数なのでどのインスタンスも値が同じになる
        Console.WriteLine( "オブジェクトの値:{0}", Foo.ConstValue );

        //終了
        Console.ReadLine();
    }
}

文法
 フィールドの定義時に「const」キーワードを付けます。

解説
 ローカル変数同様、フィールドも定数にすることができます。しかしながら、フィールド定数は、ローカル変数の定数ほど使用頻度が多くありません。何故ならば、バイナリ値としてコンパイルされるからです。
 バイナリ値に直接書いてしまうと、オブジェクトの変更時に、定数フィールドを持つオブジェクトも全てコンパイルし直さなければならなくなります。従って、絶対に変更されない値に対して指定します。
 フィールド定数のメリットは、バイナリ値として直接書かれるのでパフォーマンスが上がることです。internal キーワードを付けて、アセンブリ内のオブジェクトのみ参照するようにするとよいでしょう。

テーマ : プログラミング
ジャンル : コンピュータ

計算機の基本原理を味わおう23 - 名前に注目して論理エラーを直そう

 この記事は、計算機の基本原理を味わおう22 - どこまでリファクタリングするのか考えようの続きです。前回は、リファクタリングのゴールについて解説しました。今回は、命名の大切さと論理エラーについて解説します。
  プログラミングのエラーは大別すると、物理エラー論理エラーの2つです。物理エラーは、文法間違いなどの間違いで、大変はコンパイラが指摘してくれます。一方の論理エラーは、アルゴリズム間違いなどの人間の認識そのものの間違いです。厄介なのはこの論理エラーです。
 テストファーストとリファクタリングを駆使してプログラミングをすると、論理エラー減らせます。しかしながら、論理エラーはテストで検出し難いものです。他の手段も必要です。
 具体例として、前回のサンプルプログラムの論理エラーを挙げます。前回のサンプルプログラムは、Assertを仕込んでいるので、処理結果としては間違いではありません。しかしながら、もっと深い部分の論理エラーがあります。それがどこなのかわかりますか?
 答えは、「メソッド名と処理内容が一致していない」です。プログラムは、処理結果が正しければいいというものではありません。人間が読んで誤解を与えないようにしなければなりません。そういった論理エラーはテストによる検出が難しいです。
 論理的な間違いがあるサンプルプログラムを掲載します。

namespace MiniBitMachine.V3
{
    //inc(インクリメント)命令
    public sealed class Inc : IfCode
    {
        //関係のないプログラムは省略

        //比較対象が真の場合に実行するコードを取得する。
        protected override CompareMove[ ] GetTrueCodes()
        {
            CompareMove[] result = new CompareMove[ 2 ];
            result[ 0 ] = new CompareMove(
                this._targetAddress,
                this._info.OneAddress,
                "対象を1に設定" );
            result[ 1 ] = new CompareMove(
                this._carryFlagAddress,
                this._info.ZeroAddress,
                "桁上がりフラグを0に設定" );
            return result;
        }

        //比較対象が偽の場合に実行するコードを取得する。
        protected override CompareMove[ ] GetFalseCodes()
        {
            CompareMove[ ] result = new CompareMove[ 2 ];
            result[ 0 ] = new CompareMove(
                this._targetAddress,
                this._info.ZeroAddress,
                "対象を0に設定" );
            result[ 1 ] = new CompareMove(
                this._carryFlagAddress,
                this._info.OneAddress,
                "桁上がりフラグを1に設定" );
            return result;
        }
    }
}

メソッドの名前と処理内容を比べてみてください。処理内容が逆になっています。
 この論理エラーは、実際にありがちな仕様の解釈を間違った場面を想定して作りました。このプログラムを作った人は、次のように考えて作っていると仮定しています。

//比較部分
cmov 2, 3 //手順0:実行フラグの場所に対象データを移動
cmov 0, 96 //手順1:手順6へジャンプ

//真のコードブロック
cmov 2, 1 //手順2:比較フラグを真に設定
cmov 3, 1 //手順3:対象を1に設定
cmov 4, 0 //手順4:桁上がりフラグを0に設定
cmov 0, 128 //手順5:手順8へジャンプ

//偽のコードブロック
cmov 3, 0 //手順6:対象を0に設定
cmov 4, 1 //手順7:桁上がりフラグを1に設定

//最終
cmov 1, 0 //手順8:プログラムの終了。

この解釈は真偽が逆です。何故ならば、2行目の比較移動命令がある以上、下のほうが真のコードブロックだと考えるべきだからです。現場で起こるエラーのうちの多くが、この手の論理エラーです。
 この厄介な論理エラーを検出するには、テストプログラムだけではなく、人間のチェックが必要です。具体的には、先ほど述べたように、名前が鍵になると思います。リファクタリングで改名があるのはこういった時のためです。適切な命名をしていると、名前から処理内容の間違いが分かります。他にも資料の整理整頓や、仕様の認識についての確認作業などが論理エラーに対して有効です。
 今回はこれで終わりです。プログラミングでありがちで、検出が難しい論理エラーの解決の参考資料になれば幸いです。次回はもう少し難しい概念について解説します。お楽しみに。

テーマ : プログラミング
ジャンル : コンピュータ

プロフィール

インドリ

Author:インドリ
みなさん、はじめまして、
コンニチハ。

ボクは、無限の夢(infinity dream)を持つネタ好きな虹色の鳥インドリ(in dre)です。
色々な情報処理技術を啄ばむから楽しみにしてね。

http://twitter.com/indori
は別人による嫌がらせ行為です。
私とは関係ないので注意して下さい。
次はなりすましブログなどをするかもしれませんが、ここ以外でブログをするつもりがないので、ここ以外にインドリのブログがあったとしても無視してください。


何度言っても分からない人がいるので、ここにコメント欄へ書き込むときの注意事項を書きます。


一、社会人としてのマナーをわきまえましょう。
一、妄想に基づく書き込みを止めてください。
一、暴言の類は書かないで下さい。
一、某誹謗中傷サイトの書き込みは彼らの妄想に基づく書き込みですから無視して、ここへ書き込まないで下さい。
一、コメント書く前に他のコメントよく読んでから行って下さい。
一、言いがかかり等の行為を禁止します。
一、その他常識的に考えて迷惑なコメントはしないで下さい。


以上のルールを守れない人のコメントは削除します。



利用上の注意
ここに紹介してある文章およびプログラムコードは正確であるように心がけておりますが、内容を保証するものではありません。当サイトの内容によって生じた損害については、一切の責任を負いませんので御了承ください。


執筆したCodeZineの記事


【VB.NETで仮想CPUを作ろう】

  1. VB.NETで仮想CPUを作ろう
  2. レジスタの実装
  3. 仮想CPUのGUI化
  4. テストドライバの改良
  5. CPUの基礎動作の実装
  6. MOV命令の実装
  7. ADD命令実装
  8. SUB命令実装
  9. INC命令&DEC命令の実装と命令長
  10. MLU命令の実装とModR/Mについて
  11. DIV命令の実装とイベント設計について
  12. 機械語駆動式 関数電卓を作ろう!
  13. 機械語駆動式 関数電卓を作ろう! 解答編(前半)
  14. 機械語駆動式 関数電卓を作ろう! 解答編(後半)


【仮想ネットワーク実装でTCP/IPを学ぼう】
  1. TCP/IPの基礎と勘所
  2. ネットワークアクセス層の勘所
  3. インターネット層の勘所
  4. トランスポート層の勘所
  5. アプリケーション層の勘所
  6. セキュリティの基礎と仮想ネットワークの仕様
  7. GDI+と独自プロトコルの定義



【並列化】
インテル Parallel Studioを使って並列化プログラミングを試してみた
並列プログラミングの効率的なデバッグを実現する「Parallel Inspector」


【TBBシリーズ】
  1. インテル スレッディング・ビルディング・ブロックの概要
  2. インテルTBBから学ぶループの並列化
  3. スレッドセーフとインテルTBBのコンテナ
  4. インテルTBBのスレッドクラス


【OpenMPシリーズ】
  1. OpenMPの基礎構文
  2. OpenMPの実行時ライブラリと並列ループ
  3. OpenMPのメモリモデルとfork- joinモデル

最近の記事
最近のコメント
月別アーカイブ
カテゴリ
Ada (9)
COBOL (5)
C (9)
C++ (11)
C# (370)
D (25)
Java (8)
Perl (1)
Ruby (14)
PHP (2)
Boo (2)
Cobra (2)
LISP (6)
F# (33)
HTML (0)
XHTML (0)
CSS (0)
XML (0)
XSLT (0)
Scala (4)
WPF (0)
WF (2)
WCF (0)
LINQ (4)
MONO (5)
Linux (0)
MySQL (0)
ブログ内検索
リンク
最近のトラックバック
RSSフィード
ブロとも申請フォーム

この人とブロともになる

QRコード
FC2カウンター