fc2ブログ

C++/CLI文法リファレンス - 値型の定義

概要
 スタック領域に確保される値型を定義します。

使用に適した状況
 参照型のように、継承を伴う複雑なオブジェクトを定義したくない場合、値型の検討をしましょう。ただし、頻繁に使用するのは参照型であり、値型が適している状況の方が少ないです。

サンプル

/*----------------------------------------------------
 * 
 *  値型
 *  
 ----------------------------------------------------*/
using namespace System;

value struct ValueTypeSample
{
    //内部クラス
    ref class InnerClass{ };

public:
    //定数
    static const int ConstValue = 1;

    //リテラル値
    literal int MIN = -1;

    //読み取り専用フィールド
    initonly int Value;

    //静的フィールド
    static int StaticValue = 100;
    
    //スカラプロパティ
    property  int PropertyValue
    { 
        int get(){ return this->m_value; }
        void set( int newValue ) { this->m_value; }
    }

    //クラス レベルのインデックス付きプロパティ 
    property int Default [int]
    {
        int get( int index ) { return 0; }
        void set ( int index, int newValue ) { }
    }

    //インデックス付きプロパティ
    property int NamedIndexProperty [int]
    {
        int get( int value ){ return 0; }
    }

    //静的プロパティ
    static property int StaticProperty
    {
        int get() { return ConstValue; }
    }

    //トリビアル・スカラ・プロパティ
    property int TrivialProperty;

    //デフォルトコンストラクタは定義でき機内
    //ValueTypeSample( ) {  }

    //静的コンストラクタ
    //動作が難しいのでお勧めできない
    static ValueTypeSample() {  } 

    //メソッド
    void Method( ) { }

    //イベント
    event EventHandler< EventArgs^ >^ Event;

private:
    //フィールド
    int m_value;
};

//こっちでもOK
//アクセス修飾子が規定でprivateになる
value class Foo
{
};

//値型(構造体)は継承できない
//value struct Bar : Foo {};

int main()
{
    //gcnewを使わない点に注意
    ValueTypeSample obj = ValueTypeSample();
    return 0;
}


文法
 value structもしくはvalue classキーワードを指定します。どちらを使ってもよいのですが、参照型でclassを使用したら、値型ではstruct を使用するとよいでしょう。そうすると、値型と参照型が判別しやすくなります。
 個人的には、値型をvalue structで定義でしています。理由は、データを強調したのが構造体だと考えているからです。オブジェクトというよりも、データと呼んだ方が良いような単純なオブジェクトは、命令型のイメージを持つ構造体を使用するとしっくりします。

解説
 .NETでは型が、参照型と値型に大別されています。違いはメモリ管理の方法と、アクセス修飾子および定義できるメンバーです。また、値型は継承ができない点も忘れてはなりません。つまり値型は、参照型と比べると単純なオブジェクトを実装するのに使用するとよいでしょう。
 注意しなくてはならいのは、スタック領域に確保されるからと言って、パフォーマンス上の早とちりだけで値型に決定してはならないという事です。スタック領域に確保され、ガベージコレクションの管理対象とならないと聞けば誰しも、パフォーマンスが向上すると考えるでしょう。しかしながら、コンパイラやJITなどの最適化の効果もありますし、あらゆる状況でスタックに積むのが最善とは言えません。スタックに積むことにより、逆にパフォーマンスが低下する可能性があります。そうしたことから、基本的にパフォーマンスで考えるのではなく、オブジェクト指向設計に基づき、継承の有無などの特徴から値型にするのか、参照型にするのかを決定するべきだと思います。
スポンサーサイト



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

C++/CLI文法リファレンス - 参照型の定義

概要
 ガベージコレクションの対象となる参照型を定義する文法です。

使用に適した状況
 ほぼすべての状況で必要となる文法です。オブジェクト指向プログラミングをする以上、避けては通れない存在と言えるでしょう。

サンプル

/*----------------------------------------------------
 * 
 *  クラス
 *  
 ----------------------------------------------------*/
using namespace System;

ref class ClassType
{
    //内部クラス
    ref class InnerClass{ };

public:
    //定数
    static const int ConstValue = 1;

    //リテラル値
    literal int MIN = -1;

    //読み取り専用フィールド
    initonly int Value;

    //静的フィールド
    static int StaticValue = 100;
    
    //スカラプロパティ
    property  int PropertyValue
    { 
        int get(){ return this->m_value; }
        void set( int newValue ) { this->m_value; }
    }

    //クラス レベルのインデックス付きプロパティ 
    property int Default [int]
    {
        int get( int index ) { return 0; }
        void set ( int index, int newValue ) { }
    }

    //インデックス付きプロパティ
    property int NamedIndexProperty [int]
    {
        int get( int value ){ return 0; }
    }

    //静的プロパティ
    static property int StaticProperty
    {
        int get() { return ConstValue; }
    }

    //トリビアル・スカラ・プロパティ
    property int TrivialProperty;

     //コンストラクタ
    ClassType( ) {  }

    //静的コンストラクタ
    static ClassType() {  } 

    //メソッド
    void Method( ) { }

    //イベント
    event EventHandler< EventArgs^ >^ Event;

private:
    //フィールド
    int m_value;
};

//こっちでもOK
//アクセス修飾子が規定でpublicになる
ref struct Foo
{
};

int main()
{
    ClassType^ obj = gcnew ClassType();
    return 0;
}

 参照型の定義と、メンバーの定義法をサンプルプログラムにしました。ちょっと長く圧倒されるかもしれませんが、参照型の定義そのものは、ref class ClassType{}の部分だけです。
文法
 ref classキーワードとコードブロックを使用します。もしくは、ref structキーワードを使用する方法もあります。違いはアクセス修飾子の規定値です。どちらを使用するのかは好みで分かれると思いますが、個人的にはref classの方が良いと思います。何故ならば、アクセス規定値がprivateな点と、構造体という言葉とオブジェクト指向プログラミングがマッチしないと考えているからです。どちらを使うのかにしても、プロジェクトでは混乱を防ぐために統一することをお勧めします。
 この構文自体は簡単で問題ないと思います。「ref」と指定する点に注目してください。参照型であることを明確にしています。

解説
 .NETの型を大別すると、ガベージコレクションが管理し、ヒープ領域に確保される参照型と、スタック領域に確保される値型に分けられます。今回紹介した文法は、そのうち参照型を定義するものです。参照型は基本的に使用する型です。C++/CLIでオブジェクト指向プログラミングをしていると、必ず必要となりますので、頻繁に目にすることになると思います。
 参照型の詳細については長くなるので今回は解説しません。ひとまず、ガベージコレクションの管理対象となっている点を心にとどめてください。詳細については少しずつ学ぶとよいと思います。

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

C++/CLIのアクセス修飾子が面白い

そういえば、C++/CLIのアクセス修飾子の効果が面白いです。

using namespace System;
public enum class Foo
{
    Zero,
    One,
    Two,
    Three
};

enum class Bar
{
    Zero,
    One,
    Two,
    Three
};

void Print( Type^ t )
{ 
    Console::WriteLine( "{0}の値を表示します・・・", t->Name );
    Array^ a = Enum::GetValues( t );
    for( int i = 0; i < a->Length; ++i ) {
       Console::WriteLine( a->GetValue( i ) );
    }
    Console::WriteLine( );
};

int main()
{
    //メタデータを取得できる
    Print( Foo::typeid );

    //メタデータが取得できない
    Print( Bar::typeid );
}

型のアクセス修飾子がprivateだと、メタデータを取得できないんですね。ネイティブプログラムと混合できるC++/CLIならではの仕様です。C++/CLIあまり使わないから、ちょっとびっくりしました。2012以前は呼び出せたような気が・・・今日過去のプログラムで遊んでいて、動作しない理由がわからないから出力されたILを調べて、メタデータが出力されていない事に気づきました。それで、アクセス修飾子が影響していると分かりました。
初めてリフレクションを知ったとき私は、セキュリティ的に大丈夫かなと思いました。何故ならば、ある程度ユーザーの権限が影響するけど、開発者でないユーザは全て管理者権限で実行するなんてことざらにあるからです。また、解析したい人は管理者権限でも実行するでしょう。そういった理由から、ユーザーアカウントの権限に依存するセキュリティは不十分です。その点、開発者が指定できるという点で、C++/CLIの発想は面白いです。セキュリティ技術は、もっと開発者がコントロールする部分を増やすべきだと思います。そうすれば、開発者の負担は増しますし、同時に意図しない結果も増えるでしょうが、より強固なセキュリティが確保できるでしょう。
それにしても、いつそうなったんだろう?C++/CLIはお仕事では使わないから変更された時期はわかりません。もし、ただのバグだったらいやだな。

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

C++/CLIで拡張メソッドが扱えない件

 突然ですが、C++/CLIでは拡張メソッドが扱えません。これは、LINQプログラミングをする上で非常に不利です。拡張メソッドは、System::Runtime::CompilerServices::Extension属性を使用する事を知っていれば、VB.NETと同様に拡張メソッドを扱えないか試す事でしょう。ですが、それは叶いません。その理由を考えるには、属性について考えないとなりません。
 そもそも、属性とは何でしょうか?属性の概念は、COMの契約記述形式を拡張できないという問題点が露呈した時に誕生しました。具体的に言いますと、1990年代前半にMTSで実現されました。トランザクションのように、横断的関心事を記述するにはアスペクトが定義できなくてはなりません。そこで、アスペクトを定義する技術が生み出されたのです。
 ここに問題の答えがあります。C++/CLIでref classのメソッドにSystem::Runtime::CompilerServices::Extension属性を適用する事は出来ますが、コンパイラがその情報を活用しなければ意味がありません。すなわち、属性はメタ情報を記述する為の手段であり、それだけでは何も実現しないのです。
 ある言語が他の言語にある機能をサポートしていない時、その背景を考える事により技術力を高められます。「C++/CLIには拡張メソッドがない」と騒ぐだけに終わらず、何故実現できないのかまで考える事をお勧めします。背景を考える行為は良い鍛錬になります。鍛練のチャンスを見逃さずに活かしましょう!

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

C++/CLIのラムダ式に関する感想

 C++/CLIのラムダ式は、デリゲートに直接対応していません。それに加えて、マネージ型の変数をキャプチャ出来ません。その理由は、C++/CLIのラムダ式が値型だからです。他の理由もあるかもしれませんが、ひとまず私はそれが直接的な原因だと考えております。C#やVBのラムダ式は、デリゲートに対応していますが、その実態は、コンパイラが生成したメソッドです。.NETのメカニズムを考えれば、スタックに確保される値型がデリゲートに対応していないのは仕方がないと思います。
 C++/CLIのラムダ式が何故値型なのかについては、恐らくC++の関数ポインタの概念と関係していると思われます。C++/CLIは、マネージプログラミングとネイティブプログラミングの混合が想定されています。それを考慮すると、ラムダ式が値型なのは避けられないでしょう。
 しかしながら、将来もそうなるとは決まっていません。例えば、コンパイラオプションにclr:pureが指定されたら、C#とVB同様メソッドを自動生成するなどと言った対応が想像できます。私はC++/CLI開発チームの一員ではないので詳しい事情は分かりませんが、将来C++/CLIのラムダ式がデリゲート対応になるという希望は、あるのではないでしょうか?

注意:この記事は、私が過去にC++/CLIのラムダ式を独自調査した結果考えた事です。調査時間は10分ほどですし、私はC++/CLIの開発チームの一員ではないので、正しいという保証はどこにもありません。

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

C++/CLIの事例から考える構文のあり方

 先日、久し振りにC++/CLIをやって、思い出したので書きます。C++/CLIは、Managed C++と比べて、非常に読みやすくなっています。ですがどうにもならない事もあります・・・

// Managed C++
public __gc __abstract class AbstractClass{ /*省略*/ };

// C++/CLI
public ref class AbstractClass abstract { /*省略*/ };

どこか違和感がありませんか?先に言っておきますが、C++/CLIとコメントが混じって見にくいとかはなしです。
 気付いたと思いますが、abstractキーワードの位置が違います。その理由は明記されていませんが、恐らく字句解析&構文解析と互換性がらみの問題が原因だと思います。
 ref classは2つで一つのキーワードです。refだけでは意味を持ちませんし、classだけだったらネイティブな型になってしまいます。という事は、字句解析&構文解析する時に、abstractが混じったら面倒だという想像がつきます。
 ref abstract class にされても嫌ですし、class abstract ref にされても嫌です。それに、一つのキーワード混入を許せば、「じゃあsealedもいいよな」、「virtualの位置もフリーでいいんじゃね?」などと多くの注文が発生しそうです。
 こうした事を色々考えるのが非常に面白いです。

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

C++/CLIでは基本型を.NETの型で明示する方がいい

 前から思っていたのですが、C++/CLIの基本型は扱いづらいです。例えば、符号なし64ビット整数型は静的フィールドにアクセスしにくいです。

unsigned __int64 value64 = 
    unsigned __int64.MaxValue; //出来ない!
unsigned __int64 value64_2 = 
    unsigned __int64::MaxValue; //これも出来ない!

C#と同じ感覚でUInt64型の静的フィールドにアクセスできません。
 一応整数リテラルを指定すれば出来ます。

unsigned __int64 value64 = 0ULL.MaxValue; //一応アクセスできる

ですが、この方法を使用すると余分な値が生成されてしまいます。それに加えて読み辛いです。
 もっと自然に、静的フィールドにアクセスするには、System.UInt64を直接指定します。

System::UInt64 value64 = System::UInt64::MaxValue; //アクセスできた♪

これで余分な値を生成する必要がなくなりますし、型名が短いので打ちやすいです。
 それ以外にも、.NETの型を明示した方が良い理由があります。それは、.NETプログラミングとネイティブプログラミングが判別しやすいからです。
 符号なし64ビットは分かりやすいのですが、符号なし16ビットの場合unsigned shortです。これでは、どの部分が.NETなのか一目で分かりません。特に他の.NET言語を使っている方には分かり難いでしょう。また、.NETプログラミングをしている時は、.NETの基本型を扱いたいはずです。
 C++/CLIで.NETプログラミングを行う際は、.NETの基本型を明示しましょう。

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

C++/CLIを咥えてLINQをつつく0-まずは簡単なところから。本当に簡単?

今回はLINQをつつくピヨ。この記事はLINQをつつく1-IEnumerableから始まるLINQ♪の記事と連動しているから詳しい説明はそっちを見てね。
じゃあ早速シンプルなコードご覧あれ!


#pragma once

using namespace System;
using namespace System::Collections::Generic;
//System.Core.dllへの参照を自分で追加する必要あり(泣き
using namespace System::Linq;

ref class Wankuma {
public:
    static bool Where(String^ name) {
        return name->Length > 5;
    }

    static String^ Order(String^ name) {
         return name;
    }

    static String^ Select(String^ name) {
        return name;
    }
};

int main(array< System::String ^> ^args) { 
    array< String^>^ wankumas = gcnew array< String^> {
        "中博俊さん",  	"じゃんぬねっとさん",
        "夏椰さん", "なおこ(・∀・)さん",
        "まゆりんさん", "はなおか じったさん"
    };

    //WHERE句を実行
    IEnumerable < String^ > ^ iwankuma = 
        (IEnumerable< String^ > ^)wankumas;
    Func< String^, Boolean > ^ func = gcnew 
        Func< String^ ,Boolean > (Wankuma::Where);
    IEnumerable< String^ > ^ wresult = 
        Enumerable::Where< String^ > (iwankuma, func);

    //ORDER句を実行
    Func< String^, String^ > ^ func1 = gcnew 
        Func< String^, String^ > (Wankuma::Order);
    IEnumerable< String^ > ^ oresult = 
        Enumerable::OrderBy< String^, String^ > (wresult, func1);

    //SELECT句を実行
    Func< String^, String^ > ^ func2 = 
        gcnew Func <  String^, String^ > (Wankuma::Select);
    IEnumerable <  String^ > ^ result = 
        Enumerable::Select <  String^, String^ > (oresult, func2);

    //結果を出力
    Console::WriteLine(L"名前が五文字以上のわんくま同盟の方は・・・");
    for each (String^ str in result) Console::WriteLine(str);
    return 0;
}


正直言っていい?HTMLではこんな大量のC++/CLIプログラムは辛い・・・
それはさておき、このコードはね・・・おっと、詳しい説明は
LINQをつつく1-IEnumerableから始まるLINQ♪
を見てね。疲れた・・・

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

C++/CLIをつつく28-Null許容型。白黒つけられない時もある。

今回はNull許容型をつつくピヨ。Null許容型というのは、その名の通りNullを許す値型の事なんだ。値型というのは、System.Int32、System.Int16、System.Booleanなどのシステム型(組み込み型)の事なんだ。じゃあなんでこんなのが必要なのかというと、主な理由はDataBaseでNull値を結構使うからなんだ(トラブルの元だけどね)Null値を使うことの意義について分かりにくいと思うので、例を挙げて説明するピヨ。
例えば、付き合っている異性からいきなり「私と結婚する?YesかNoで答えなさいぃ!」と言われたら慌てるよね?そりゃ、好きだから付き合っているんだけど、いきなり結婚といわれてもYesと言えないし、かといって、将来結婚するかもしれないからNoと断言できないし・・・こんな白黒つけられないSystem.Boolean型な時は、現状ではどちらとも言えない(Null)と答えよう♪それがNull許容型なんだ。 こんな時はこう宣言するといいピヨ。


//結婚するかまだわからない
Nullable< System::Boolean >^ marry = nullptr;


Nullable< 値型名 >^ で宣言するピヨ。
これでゆっくりと結婚について考えられるピヨ♪そして時が経てば・・・


//時が経って
Console::WriteLine( "私の答えは・・・{0}だ。", marryFlag->Value );
if ( marryFlag->HasValue == true ) {
    Console::WriteLine( "さあどっち?" );
    Console::WriteLine( "私の答えは・・・{0}だ。", marryFlag->Value );
}
else {
    Console::WriteLine( "優柔不断な人ね!" );
}


この二人のプログラムをつつこう♪まずNullかどうかを判定するのは HasValueピヨ。このプロパティの値がTrueならばnullでなくて、Falseならばまだnullなんだ。 Null許容型を扱う際にはHasValueをチェックしよう。 まだ決断していないかもしれないからね。チェックしないと・・・

InvalidOperationException
Null 許容のオブジェクトには値を指定しなければなりません。

って言われるよ。二人の仲は破談だね。最初に言ったけどbool型以外の値型もNull許容型が使えるピヨ。この場合はまだ決定してない値と考えるといいピヨ。 例えば、給与の手取り額がまだわからない時がある。そんな時はNull許容型を使用しよう。 他にもNull許容型を使用する理由として、指定されたのか判定するためという事もあるんだ。もし、0とかだと、0と指定したのか、そもそも指定していないのかがわからないピヨ。そんな時はNull許容型の出番だピヨ。
ただし、Null許容型はパフォーマンスが劣化 する事に注意してね。だから多用せずに絶対に必要なときだけ使用しよう。インドリからのお願いだよ。

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

C++/CLIをつつく27-インターフェイス。約束は守ろう。

今回はインターフェイスをつつくピヨ。インターフェイスとは、オブジェクトが持つべき要素を定義したものなんだ。一説によるとこの概念はCOM(Componet Object Model)から受け継いだものらしい。でも、Javaとか既存言語からある概念だから、.NETのインターフェイスはCOMと既存のインターフェイスの融合だと思うピヨ。
じゃあ、早速インターフェイスの定義方をつつくピヨッ!


//実用的でない例
interface class IFoo
{
    //実装するべきプロパティ
    property Object^ FooProperty;

    //実装するべきメソッド
    void FooMethod( Object^ obj );
    void FooMethod1( Object^ obj );
    Object^ FooFunction( );

    //実装するべきイベント
    event EventHandler^ FooEvent;
};


どう?難しくないよね♪インターフェイスの定義はinterface classキーワードを使用するところと、Publicとかのアクセス修飾子は必ずpublicな点と、実装を書かない点がが特徴ピヨ。何故実装を書いたら駄目なのかというと、.NETではインターフェイスは実態がない契約(約束事)だからなんだよ。
この定義したインターフェイスを実装するクラスは次のようにするピヨ。


public ref class FooClass : IFoo
{
public:
    virtual property Object^ FooProperty;
    virtual void FooMethod( Object^ obj ) { }
    virtual void FooMethod1( Object^ obj ){ }
    virtual Object^ FooFunction( ){ return nullptr; }
    virtual event EventHandler^ FooEvent;
};


C++/CLIではクラス名 : インタフェース名で指定して実装するんだ。VB.NETみたいに、一々各要素でどのインタフェース要素を実装するのかを宣言しなくてもいいピヨ。さらに、VB.NETと同じく複数に対応する事が不可能なんだ。その方法は後述するピヨ。その代りvirtualキーワードを必ずつけなくてはならないんだ。仕方ないよね。 話しは変わるけど、インターフェイスは複数指定できるからこんな状況に遭遇する場合があるピヨ


interface class IBar
{
    //メソッド名がかぶっている!
    void FooMethod1( Object^ obj );
};

//IBarのメソッドをどうしよう・・・
public ref class FooClass : IFoo, IBar
{


このように名前が偶然同じだった場合明示的実装という手法を使用するんだ。やり方は次の通りだピヨォ。


//明示的実装
virtual void FooMethod1( Object^ obj ) = IFoo::FooMethod1 { }


このように、メソッドの宣言の後に
=対応するインターフェイスの要素
を書けばいいんだちょっと違和感あるけど簡単だね。さらに、この機能を利用すればVB.NETと同じく一度に複数のインターフェイスが実装できるんだ。


virtual void FooMethod1( Object^ obj ) = IFoo::FooMethod1, IBar::FooMethod1 { }


こんな具合にピリオドで複数指定出来るんだ。これは便利。余り使いどころがないけどね・・・

最後に、インターフェイスとクラスの使い分けについて囀るピヨ。クラスは縦に継承されていくけど、インターフェースは横に継承される点が違うピヨ。 クラスの場合、親から子へと意味ある継承をするけど、全ての状況に対応できるわけじゃないんだ。 何故かというと、直接的には関係ないけど同じ要素を持つことがあるからなんだ。 クラスの継承は親子の遺伝。 インターフェイスの継承は師弟関係と覚えたらいいよ。
今回はこれで終わり。

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

プロフィール

インドリ

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カウンター