C#や.NET Frameworkがやっていること

C# や .NET Framework がやって

いること

岩永信之

++C++; // 未確認飛行 C

自己紹介

C# でぐぐれ++C++; // 未確認飛行 C

こんなロゴのサイトの中の人プログラミングの魔導書 Vol.3 にも何か書いてるよ

今日の内容

• C# や .NET Framework がやっていること• どうしてそういう機能がある• ( 自前で実装するなら ) どうやればできる• ( 自前でやる上で ) 気を付ける必要がある点

趣旨

• 言語的に機能がないからって、やらなくていいわけじゃない。• C# とかが持ってる機能は必要だから追加されて

る• 自前で同様のことをやる方法も知ってて損ない

• 例えば…• C 言語でも OOP やってる人はやってた

• C 言語でも仮想関数テーブル自前で書いたり

注意

• 本来、 1 時間で話す内容じゃない• 置いてきぼる気満々• あんまり細かい説明しない（というかできない）

１ 7 ０ページ

まずは.NET Framework といえば

“Managed”

• .NET Framework の管理下にある• メモリ管理

• メモリ解放• 境界チェック• ドメイン分離

• 型の管理• メタデータ• JIT• PCL

Garbage Collectionメモリリークをなくすために

.NET Framework の GC

• .NET Framework の GC は Mark & Sweep• 世代別 (3 世代、 Gen0 ～ 2)• Compaction あり• Background スレッドで並列実行

Mark & Sweep

• ルート†から参照をたどる

ヒープルート

† スタックや静的フィールド中のオブジェクト

使用中オブジェクト

未使用オブジェクト

Compaction

• GC 時にオブジェクトの位置を移動

使用中オブジェクト

未使用オブジェクト

隙間をなくすように移動

後ろが丸ごと空くので次のメモリ確保が楽

Generation

• GC 時にオブジェクトの位置を移動

Gen1 Gen0

しばらくここはノータッチ

この範囲でだけメモリ確保・

オブジェクトの寿命統計的に• 短いものはとことん短く• 長いものはとことん長い

一度 GC かかったオブジェクトはしばらく放置

C++ での GC

• 通常、参照カウント• shared_ptr• 循環参照に気を付けて適宜 weak_ptr を

• Mark & Sweep GC ライブラリもあるけども• 型がはっきりしないので保守的にならざるを得な

い• すべての数値をポインターとみなして Mark

Mark & Sweep と参照カウント• 比較• 一長一短ある

Mark & Sweep 参照カウント

メモリ確保 ○ 末尾を見るだけ × 空いている場所を探す× カウント用の領域が追

加で必要

変数のコピー ○ ポインターのコピー × ポインターのコピーに加え、参照数のカウントアップ

メモリ解放 × Mark や Compactionに時間がかかる

× 負担が 1 か所に集中

○ カウントが 0 になった時に delete するだけ

Throughput

• トータルの性能 (throughput) は Mark & Sweep の方がいい

加で必要

まとめてやる方がバラバラにやるより効率がいい

頻度が高い操作なのでここの負担が大きいと

全体の性能落ちる

特に、スレッド安全を求めるときついたかがインクリメントでも、 atomic 性保証するとそこそこの負担

参照局所性も高くなってキャッシュが効きやすい

短所の軽減

• 短所も、まったく打つ手がないわけじゃない

加で必要

.NET 4以降、 Background スレッ

ド実行してる C++ 11 的には「move semantics活用してね」

自前メモリ管理との混在

• スコープが短いならスタックにとればいいのに• C# は class は必ずヒープ、 struct はスタックに

なる• 使い分けれない

• Mark & Sweep 管理領域内のポインターを管理外に渡すときには注意が必要• Compaction でメモリ移動しないように「ピン止め」が必要• 結構ガベージコレクションのパフォーマンス落とす

おまけ

• Python とか• 参照カウントと Mark & Sweep の併用

• ○ 循環参照問題避けつつ、負担を 1 か所に集中させない

• × 性能的には悪いとこどり

• Go• 割当先を自動判別

• スコープ内で完結していたらスタックに• そうでなければヒープに• これはこれでスタックの浪費激しそうなんだけども…

• なので、可変長スタック持ってる

境界チェック意図しないメモリ領域にはアクセスさせない

配列の境界チェック

• .NET の配列は厳しい• 常に境界チェックしてる

• 要は buffer overrun防止• ちなみに JIT の最適化で、明らかに境界を侵さない

ものは境界チェックを消す

配列 a

OutOfRange

a[-1] a[length+1]

unsafe

• C# にもポインターあるんだけども

var x = new[] { 1, 2, 3, 4, 5 };unsafe{ fixed(int* px = &x[0]) { Console.WriteLine(px[100]); }}

メモリ移動の防止（ピン止め）

範囲チェックなし

安全でないコードこの中でだけポインター利用可能

buffer overrun やりたい放題

unsafe でも制限付き

• class ( 参照型 ) はアドレス取れない• 仮想メソッドテーブル (vtable) とか入ってるし• 親クラス側のレイアウト変更の影響受けるし

class Class{ public int x; public int y;}

var c = new Class();fixed (void* p = &c) { } // errorfixed (void* p = &c.x) { } // OKfixed (void* p = &c.y) { } // OK

ピン止め必須 • 値型のメンバーのアドレスは取れる

• オブジェクト自体のアドレスは取れない

• struct ( 値型 ) はアドレス取れる• ただし、メンバーが全部値型の時のみ• ↑「 unmanaged 型」と呼ぶ

struct UnmanagedStruct{ public int x; public int y;}

var u = new UnmanagedStruct();void* p1 = &u; // OKvoid* p2 = &u.x; // OKvoid* p3 = &u.y; // OK

メンバーが全部値型

無制限にアドレス取れる

• struct ( 値型 ) であっても制限付き• メンバーに 1 つでも参照型を含むとダメ• ↑「managed 型」と呼ぶ

struct ManagedStruct{ public int x; public string y;}

var u = new ManagedStruct();void* p1 = &u; // errorvoid* p2 = &u.x; // OKvoid* p3 = &u.y; // error

メンバーに参照型が 1

値型のメンバーのところだけはアドレス取れる

ポイント

• unsafe• 危険なことは基本認めない

• 面倒な追加の構文を要求• コンパイルオプションでも /unsafe の明記必須

• fixed• ガベージコレクションとの兼ね合い

• Compaction阻害になるので注意

•「 Unmanaged 型」に限る• 実装依存な部分 (vtable とか）や、

型の定義側の変更が利用側に極力影響しないように

AppDomain実行環境の分離セキュリティ保証

コンポーネントの連携

•他のアプリの機能を自分のアプリから呼びたい• Word とか Excel とかのドキュメントを出力

• サーバー上に自分のアプリを配置したい• IIS 上に（ ASP.NET ）• SQL Server 上に

• ( 必ずしも ) 信用できない• セキュリティ保証• 参照先のクラッシュにアプリ / サー

バーが巻き込まれないように• コンポーネントのバージョンアップ

AppDomain

•単一プロセス内で、分離された複数の実行領域 (domain) を提供

•「分離」• plugin: 動的なロード / アンロード• security: AppDomain ごとに異なる権限付与• isolation: 別メモリ空間

AppDomain 1

AppDomain 2

プロセス

必ずしも信用できないコードを安全に、動的に呼び出し

ドメイン間には壁がある

• 別メモリ空間に分離されてる

AppDomain 1 AppDomain 2

互いに独立

ドメイン間の通信

•マーシャリング (marshaling)• marshal (司令官、案内係 ) の命令通りにしか壁を超えれない

• 司令がダメといったら通れない• 司令の指示通りの形式にいったん

シリアライズしないといけない

•ダメな例

これを B に渡したいとして

あるオブジェクト

•ダメな例

shallow copy なんてしようもんなら

A側のメモリへの参照が残る

• よい例

serializedeserializ

{ {1, 2}, {3, 4}, {5, 6}}

この辺りがマーシャリング

一度シリアライズ必ず deep copy

.NET のマーシャリング

• 2種類• marshal by ref

• 参照を渡すんだけど、メモリ領域は直接触れない• メソッド越しにしか操作しちゃいけない• 「このメソッドを呼んでくれ」っていうメッセージだけ

がドメインを超えてわたって、実際の実行は相手側ドメインで

• marshal by value• 値をシリアライズして相手側に渡す• 規定では、 BinarySeralizer を使用

private フィールドまで含めてリフレクションで内部状態を取得してシリアライズ

.NET のマーシャリング (文字列 )• marshal by value の場合でも文字列は特殊扱

い• コピーしない• 参照をそのまま渡す

• immutable かつ range-check 付きに作ってある• COM (ネイティブ ) に対して文字列を渡す時すらこの方式（ただし、文字コード変換が不要な場合だけ）

その他のコスト

• いくらかコストが• 例えばライブラリの読み込み

Library X Library X

別ドメインに全く同じライブラリを読み込んでも、それぞれ別イメージが作られる

Global Assembly Cache (GAC) にある DLL だけは別GAC 中のは同じメモリイメージが共有される

(マーシャリングのコスト以外にも )

C++ でも

• COM なんかはマーシャリングやってる•逆にいうと、 COM くらい仰々しいものが必

要• さもなくば、プロセス分離してプロセス間通信と

かやらなきゃいけない• 安全だけどかなり高負荷• RPC とか一時期流行ったけども

• ただの関数呼び出しに見えるコードで、内部的にプロセス間通信するとか

メタデータ型情報動的リンクでのバージョン管理

メタデータ

• メタデータとは• DLL にどういう型が含まれるかという情報• 外部のどういう DLL を参照しているかの情報• バージョン情報

• メタデータがあると• プログラミング言語をまたげる• 動的リンクでのバージョン管理

動的リンク

• ライブラリは共有する

アプリ A

アプリ B

ライブラリ X

ライブラリ Y

version 1

動的リンク

• ライブラリ単体での差し替え• セキュリティホールや、致命的なバグの修正

アプリ A

アプリ B

ライブラリ X

ライブラリ Y

version 2

version 1

更新不要差し替え

いまどきの事情

• ライブラリはアプリのパッケージに同梱• バージョニングいるの？

アプリ A ライブラリ X

ライブラリ Y アプリ B

ライブラリ X

ライブラリ Y

アプリ Aパッケージアプリ Bパッケージ

別バイナリ

差分ダウンロード※ Windows ストアアプリはこの仕組み持ってるらしい

ライブラリ Y

アプリ Aパッケージ version 1

version 1アプリ A ライブラリ X

ライブラリ Y

アプリ Aパッケージ version 2

version 2

version 1 version 1

ライブラリ X

差分

version 2

ダウンロード

アプリ A ver.1インストール機

バージョンアップ時

アプリ B

ライブラリ X

ライブラリ Y

アプリ間でライブラリ共有※ Windows ストアアプリはこの仕組み持ってるらしい

ライブラリ Y

アプリ Aパッケージ

ライブラリ Y

アプリ Bパッケージ

差分

アプリ Aインストール機アプリ B

アプリ B インストール時

X 、 Y は同じものを共有（ハードリンク作るだけ）

version 1

version 1 version 1

version 1

メタデータの作成

• COM の頃• メタデータを自分で書いてた

( 自動化するツール使あるけど )• .tlb/.olb ファイル

• .NET Framework• .NET 自体ががメタデータの規格を持ってる• C# とかをコンパイルするだけで作られる

C++/CX

• C++ Component Extensions• マイクロソフトの C++拡張

C++/CX

素の標準C++ コード

COM コード

メタデータ(winmd)

コンパイル

C++ 内で完結して使う分にはオーバーヘッドな

COM を呼べる言語なら何からでも呼べる

.NET のメタデータと互換

.NET から簡単に呼べる

JIT(Just-in-Time compile)バージョンアップ時の変更の影響を吸収

中間コードと JIT コンパイル

• .NET Framework の中間言語

• 高級言語のコンパイラーを作る人と、 CPU ごとの最適化する人の分業化• セキュリティチェックしやすくなったり• 動的リンク時に、コード修正の影響を JIT で吸収

高級言語(C# など )

中間言語(IL)

ネイティブコード

ビルド時にコンパイル

Just-in-Timeコンパイル

JIT である必要ないLLVM とかでも中間言語介してコンパイルして

ストア審査ではじくとか他にも手段はある

• (C# で ) こんな型があったとして

• 整数のフィールドを 3 つ持つ

public struct Point{

public int X;public int Y;public int Z;

• こんなメソッドを書いたとする

• フィールドの掛け算

static int GetVolume(Point p){

return p.X * p.Y * p.Z;}

• C# コンパイル結果の IL.method private hidebysig static int32 GetVolue(valuetype Point p) cil managed{ .maxstack 8 IL_0000: ldarg.0 IL_0001: ldfld int32 Point::X IL_0006: ldarg.0 IL_0007: ldfld int32 Point::Y IL_000c: mul IL_000d: ldarg.0 IL_000e: ldfld int32 Point::Z IL_0013: mul IL_0014: ret}

型とかフィールドの名前がそのまま

残ってる

型情報メタデータ

• JIT結果 (x64 の場合 )

push ebp mov ebp,esp cmp dword ptr ds:[5011058h],0 je 00FE2A01 call 74B7AEA8 mov eax,dword ptr [ebp+8] lea edx,[ebp+8] imul eax,dword ptr [edx+4] lea edx,[ebp+8] imul eax,dword ptr [edx+8] pop ebp ret 0Ch

4 とか 8 とかの数値に

型情報は残らない

メモリレイアウト

• この 4 とか 8 の意味

4 バイト

8 バイト

※レイアウトがどうなるかは環境依存

メモリレイアウト

• この 4 とか 8 の意味

4 バイト

8 バイト

※レイアウトがどうなるかは環境依存

IL の時点までは名前で参照してる

ネイティブコードはレイアウトを見て数値で参照してる

数値でのフィールド参照

• C# で擬似的に書くとstatic int GetVolume(Point p){

return p.X * p.Y * p.Z;}

var pp = (byte*)&p;var x = *((int*)pp);var y = *((int*)(pp + 4));var z = *((int*)(pp + 8));return x * y * z;

4 とか 8 とかの数値に

※これ、一応 C# として有効なコード (unsafe)

変更してみる

• 大して影響しなさそうなほんの些細な変更をしてみる

public int X;public int Z;public int Y;

}フィールドの順序変更

その結果起きること

• メモリレイアウトが変わる※

※ この例（フィールド変更）以外でも、仮想メソッドテーブルとかいろいろレイアウトが変わるものがある

IL レベルでの影響

•影響なし

IL_0000: ldarg.0IL_0001: ldfld int32 Point::XIL_0006: ldarg.0IL_0007: ldfld int32 Point::YIL_000c: mulIL_000d: ldarg.0IL_000e: ldfld int32 Point::ZIL_0013: mulIL_0014: ret

名前で参照してるんだから特に影響ないJIT が吸収してくれる

ネイティブレベルでの影響

• ここで影響が出るpush ebp mov ebp,esp cmp dword ptr ds:[5011058h],0 je 00FE2A01 call 74B7AEA8 mov eax,dword ptr [ebp+8] lea edx,[ebp+8] imul eax,dword ptr [edx+4] lea edx,[ebp+8] imul eax,dword ptr [edx+8] pop ebp ret 0Ch

4更新が必要

利用側の再コンパイルが必要

ライブラリ側だけの差し替えじゃダメ

ただし…

• この役割に焦点を当てるなら…• 毎回毎回 JIT する必要ない• 全部が全部 IL な必要ない

• Ngen.exe• Native Image Generator• IL を事前にネイティブ化するためのツール• 自前管理が必要

• アプリのインストーラー※とかを作って明示的に呼び出し

• 参照しているライブラリが更新された時には呼びなおす必要あり •かなり面倒なのでアプリを

Ngen することはめったにない• .NET 自体が標準ライブラリ

の高速化のために使ってる※ 要するに、 JIT の負担を起動時じゃなくてインストール時に前倒しする

Auto-Ngen

• .NET Framework 4.5以降なら• Ngen が Windows サービスとして常に動いてる

• アイドル時に動作• 利用頻度の高いものを自動的に Ngen

• デスクトップアプリの場合は GAC アセンブリのみ• Windows ストアアプリの場合はすべてのアセンブリ

•よく使うアプリの起動はだいぶ早くなる•インストール直後の起動は相変わらず遅

MDIL (ネイティブのおさらい )•おさらい : ネイティブコードだと

参照しているライブラリのレイアウトが変

わった時に再コンパイルが必要

MDIL (部分的にネイティブ化 )• じゃあ、こんな形式があればいいんじゃ？

int32 Point::Xint32

Point::Yint32

Point::Z

ほぼネイティブレイアウトのとこ

ろだけ抽象的に型情報を残しておく

MDIL (Compile in the Cloud)• 実際、 Windows Phone のストアでは

そういう形式が使われている : MDIL(Machine Dependent Intermediate Language)C#コード

C# コンパイラー

MDIL コンパイラー

リンカー

開発環境で IL にコンパイル

Windows ストアサーバー上で IL を MDIL化(Compile in the Cloud)

Windows Phone 実機上ではレイアウトの解決 ( リンク ) だけ行う

•インストール直後の起動も安心

C++ だと

• 動的にやろうと思ったら、結局、 COM とかWinRT になってく• いったん QueryInterface みたいなの挟む• 結構でっかいオーバーヘッド†

† WinRT はオーバーヘッド解消の仕組みも持ってて、C++ で完結してる限りには普通の仮想関数呼び出しになる他言語から使う場合には COM アクセスになる

C++ だと

• 静的な話で言うと

ヘッダーファイルを変更したら利用側の再コンパイルが必要

struct Point{ double x; double y;};

Point.h

struct Point{ double radius; double theta;};

要再コンパイル

なので

• setter/getter 使う• pimpl 使う

struct PointImpl; class Point{public: double get_x(); double get_y();private: PointImpl* impl;};

Point.h

struct PointImpl{ double x; double y;}; double Point::get_x(){ return impl->x;}double Point::get_y(){ return impl->y;}

Point.cpp ( 実装その 1)

なので

• setter/getter 使う• pimpl 使う

struct PointImpl; class Point{public: double get_x(); double get_y();private: PointImpl* impl;};

Point.h

struct PointImpl{ double radius; double theta;}; double Point::get_x(){ return impl->radius * cos(impl->theta);}double Point::get_y(){ return impl->radius * sin(impl->theta);}

Point.cpp ( 実装その 2)

変更なし

こっちだけの変更なら、利用側の再コンパイル不要

Portable Class Library複数の「標準ライブラリ」いろんな実行環境の共通部分

標準ライブラリ

•マイクロソフト製品だけでも…

デスクトップクライアントアプリ

Phone/ タブレットクライアントアプリ

サーバーアプリ

共通部分

この共通部分だけを「標準」にすべき？

標準ライブラリ

• まして今、 Xamarin (Mono)• Xamarin.iOS 、 Xamarin.Android

WindowsデスクトップWindows

タブレット /Phone

Linuxサーバー

この共通部分だけを「標準」にすべき？

Windowsサーバー

Android

.NET Framework と Mono

Monoランタイム

.NET Fullプロファイル

.NET Coreプロファイル

.NET Full( サブセッ

ト )iOS向け

プロファイル

Android向けプロファイル

.NETFramework

コンパイラー実行環境ライブラリ

実行環境に互換性があっても標準で使える

ライブラリが違う

どこでも使えそうに見えても…• 例えばファイルシステム• 最近の Windows はいろんなプロパティを持って

る• 画像ファイルなんかだと :

サムネイル画像、撮影日時、画像サイズ、タグ• 検索インデックスも張ってる

• ストアアプリだとファイルシステムすら制限下• ユーザーの許可がないファイルには触れない

こういうものも標準に含めたいか？

一番制限がきつい環境に合わせて標準ライブラリを作るべき？

汎用 VS 特定環境どこでも動く• 最

大公約数

• 動作保証に時間がかかる

特定環境で動く• 高

機能

• 早く提供できる

汎用 VS 特定環境どこでも動く• 最

大公約数

• 動作保証に時間がかかる

特定環境で動く• 高

機能

• 早く提供できる

C++ だと• 標準化にかかってる時間• ライブラリのソースコードをとってきたは

いいけど自分の環境での動作確認も大変

Portable Class Library

• 実行環境ごとに別の「標準ライブラリ」メタデータを用意• ライブラリ側でどの

実行環境をターゲットにするか選ぶ

実行環境ごとに別メタデータを提供

ターゲット選択

• 例 : 2 環境

共通部分

• 例 : 3 環境

共通部分

• ターゲット広すぎてより一層大変だけど• メタデータ持ってない言語でやるのも厳しい• #ifdef？

さてもうすでに約 80 ページ

ここまで / ここから

• ここまで： .NET のインフラ的なところ• いわゆる“Managed”• C# 1.0 の頃からある基本機能

• 所詮、既存言語を Managed にした程度

• ここから： C# 2.0以降の追加機能

C# の歴史

C# 1.0• Man

C# 2.0• Generi

C# 3.0• LINQ

C# 4.0• Dynamic

C# 5.0• Async• WinRT

※VB 7 ～ 11 の歴史でもある

ジェネリックC# 2.0

C++ で言うところの template

C++ template と .NET Generics の違い

C++ template と C# genericsC++ template C# generics

高機能マクロみたいなもので、コンパイル時に全部展開される

.NET の中間言語 / 型情報レベルで対応JIT 時に展開

vector<T> と vector<U> で別コードが生成される

List<T> と List<U> で同じコードを共有 ( 参照型の場合 )

すべてヘッダーに書く必要がある変更すると利用側も再コンパイル

内部を変更しても (public なところが変わらない限り )利用側に影響なしコンパイル時に

すべてやる方針メタデータ /JIT で話した要件• 言語をまたげる• 動的リンク• バージョン管理• 利用側に影響与えない

.NET 的にはこれを守るのが最重要

もし C++ で generics やるなら• いったん汎用クラスを作るclass void_vector{public: void* operator[](int index); void add(void* item); void remove(void* item);… 後略 …

いったん void*な汎用クラスを

作る

( 動的には無理だけど、せめて静的に )

もし C++ で generics やるなら• キャストだけ template でtemplate<typename T>class vector<T>{private: void_vector impl;public: T* operator[](int index) { return static_cast<T*>(impl[index]); } void add(T* item) { impl.add(item); } void remove(T* item) { impl.remove(item); }};

キャストするだけの薄い template クラスを作る

要素の型が保証されるので static_cast でOK

さっき作った void* のクラス

( 動的には無理だけど、せめて静的に )

もし C++ で generics やるなら• このやり方 (汎用クラス +template でキャス

ト ) なら• vector<T> と vector<U> でコード共有可能

• バイナリサイズ小さくできる• (pimpl を併用すれば ) 内部実装を変更しても、利

用側の再コンパイル不要• コンパイル時間だいぶ短くできる

とはいえ、いろいろ窮屈

• generics では、インターフェイス制約かけないとメソッドすら呼べないstatic Type Max<Type>(Type a, Type b){ return a.CompareTo(b) > 0 ? a : b;}

static Type Max<Type>(Type a, Type b) where Type : IComparable{ return a.CompareTo(b) > 0 ? a : b;}

コンパイルエラーそんなメソッド知らな

い正しくは

インターフェイス制約

IComparable.CompareTo

• 特に困るのが演算子使えないこと• 実体は静的メソッドなので

static T Sum<T>(T[] array){

T sum = default(T);foreach (var x in array) sum += x;return sum;

} コンパイルエラー演算子定義されてない

• dynamic でごまかせなくはないけども…• 性能出ないので最後の手段

static T Sum<T>(T[] array){

dynamic sum = default(T);foreach (var x in array) sum += x;return sum;

} 実行時コード生成で+演算子が呼ばれる

C++/CX

• C++/CX はジェネリックを持ってる• generic キーワード• メタデータ (winmd) 上は .NET のジェネリックと互換• かなり制限きつい

• 実装 (generic なクラス ) は public にできない• private/internal なクラスは template で展開• ユーザー定義のインターフェイス、デリゲートも

generic な場合は public にできない

イテレーターC# 2.0

イテレーター生成用の構文

イテレーターブロック

• C++ 的な意味のイテレーターstd::vector<int> v{ 1, 2, 3, 4 }; for (auto p = v.begin(); p != v.end(); ++p)

std::cout << *p << std::endl;

こういうの

• 使う側 (for ループ側 ) は楽でいいんだけども• 実装側 (vector_iterator の中身 ) はめんどくさい

これを楽にする

の生成を楽にする

• substring の列挙

static IEnumerable<string> GetSubstrings(string s){ for (var len = s.Length; len >= 1; len--) for (var i = 0; i <= s.Length - len; i++) yield return s.Substring(i, len);}

foreach (var x in GetSubstrings("abcd")) Console.WriteLine(x);

実装側

使う側

イテレーターブロック†(= yield return を持つ関数ブロッ

内部実装 ( 全体像 )

• クラス生成

class SubstringEnumerable : IEnumerator<string>, IEnumerable<string>{ readonly string _s; int _len; int _i; int _state = 0; public SubstringEnumerable(string s) { _s = s; } public string Current { get; private set; } public bool MoveNext() { if (_state == 1) goto STATE1; if (_state == -1) goto END; _state = 1; _len = _s.Length; LOOP1BEGIN: ; if (!(_len >= 1)) goto LOOP1END; _i = 0; LOOP2BEGIN: ; if (!(_i <= _s.Length - _len)) goto LOOP2END; _state = 1; Current = _s.Substring(_i, _len); return true; STATE1: ; _i++; goto LOOP2BEGIN; LOOP2END: ; _len--; goto LOOP1BEGIN; LOOP1END: ; _state = -1; END: ; return false; } public void Reset() { throw new NotImplementedException(); } public void Dispose() { } object IEnumerator.Current { get { return Current; } } public IEnumerator<string> GetEnumerator() { if(_state == 0) return this; else return new SubstringEnumerable(_s).GetEnumerator(); } IEnumerator IEnumerable.GetEnumerator() { return GetEnumerator(); }}

内部実装 ( ローカル変数 )

• ローカル変数 → フィールド

class SubstringEnumerable : IEnumerator<string>, IEnumerable<string>{ readonly string _s; int _len; int _i; int _state = 0; public SubstringEnumerable(string s) { _s = s; } public string Current { get; private set; } public bool MoveNext() { if (_state == 1) goto STATE1; if (_state == -1) goto END; _state = 1; _len = _s.Length; LOOP1BEGIN: ; if (!(_len >= 1)) goto LOOP1END; _i = 0; LOOP2BEGIN: ; if (!(_i <= _s.Length - _len)) goto LOOP2END; _state = 1; Current = _s.Substring(_i, _len); return true; STATE1: ; _i++; goto LOOP2BEGIN; LOOP2END: ; _len--; goto LOOP1BEGIN; LOOP1END: ; _state = -1; END: ; return false; } public void Reset() { throw new NotImplementedException(); } public void Dispose() { } object IEnumerator.Current { get { return Current; } } public IEnumerator<string> GetEnumerator() { if(_state == 0) return this; else return new SubstringEnumerable(_s).GetEnumerator(); } IEnumerator IEnumerable.GetEnumerator() { return GetEnumerator(); }}

内部実装 (yield return)

• yield return → 状態記録、 return 、 case ラベル• 中断と再開 if (_state == 1) goto STATE1;

if (_state == -1) goto END; _state = 1; _len = _s.Length; LOOP1BEGIN: ; if (!(_len >= 1)) goto LOOP1END; _i = 0; LOOP2BEGIN: ; if (!(_i <= _s.Length - _len)) goto LOOP2END; _state = 1; Current = _s.Substring(_i, _len); return true; STATE1: ; _i++; goto LOOP2BEGIN; LOOP2END: ; _len--; goto LOOP1BEGIN; LOOP1END: ; _state = -1; END: ; return false; } public void Reset() { throw new NotImplementedException(); } public void Dispose() { } object IEnumerator.Current { get { return Current; } } public IEnumerator<string> GetEnumerator() { if(_state == 0) return this; else return new SubstringEnumerable(_s).GetEnumerator(); } IEnumerator IEnumerable.GetEnumerator() { return GetEnumerator(); }}

switch(_state){case 0: for (_len = _s.Length; _len >= 1; _len--) for (_i = 0; _i <= _s.Length - _len; _i++) { _state = 1; Current = _s.Substring(_i, _len); return true; case 1:; } _state = -1;}

内部実装 (yield return)

• yield return の部分、意味合いとしては†

yield return以外の場所はほぼ同じ

yield return x;

_state = 1;Current = x;return true;case 1:;

† for ループ内にラベル張れないからさっきみたいな複雑なコードになるけども

switch で囲う

内部実装 ( 中断と再開 )

• yield return の部分、意味合いとしては• 中断と再開

yield return x;

_state = 1;Current = x;return true;case 1:;

状態の記録

現在の値の保持

復帰用のラベル

機械的な置き換えでできる

• C++ でも割と簡単class substring_iterator{private: const std::string& _s; int _len; int _i; std::string _current; int _state;public: substring_iterator(const std::string& s) : _s(s), _state(0) {} std::string current() { return _current; } bool move_next() { switch (_state) { case 0:; for (_len = _s.length(); _len >= 1; _len--) for (_i = 0; _i <= _s.length() - _len; _i++) { _state = 1; _current = _s.substr(_i, _len); return true; case 1:; } _state = -1; default:; } return false; }};

goto とか case ラベルの制限がゆるいので、むしろ簡

機械的置き換えといえば

•マクロを定義#define BEGIN_ITERATOR\ switch(_state)\ {\ case 0:

#define END_ITERATOR\ _state = -1;\ default:;\ }\ return false;

#define YIELD(STATE, VALUE)\ _state = STATE;\ _current = VALUE;\ return true;\ case STATE:;

機械的置き換えといえば

•マクロを使ってbool move_next(){ BEGIN_ITERATOR for (_len = _s.length(); _len >= 1; _len--) for (_i = 0; _i <= _s.length() - _len; _i++) { YIELD(1, _s.substr(_i, _len)) } END_ITERATOR}

他の言語だと

•最近の言語は結構似た機能持ってる• ジェネレーター (generator) って呼ばれることが多い• 実装方式 :

• スタック丸ごとキャプチャしてしまうもの• 中断時に記録、再開時に復元

• 式を継続渡しスタイル (CPS) に変換してしまうもの• スレッド使う

• concurrent queue 使って、 yield return のところでenqueue

• さすがに性能的に論外だけども

ちなみに

• コーディング面接で有名な某社の社員さん曰く、

• 例に使ったの substring 列挙も割とよく出てくるパターン• 中断と再開って大事

アルゴリズムの問題はかなりの割合、イテレーターを使うとあっさり書ける

「」

C++ 1y

• C++ にもジェネレーターが載るかも• C++ 17 に向けて標準化案出てる• C++/CX向けの実装を元に MS が提案

• async/await のついで

sequence<int> range(int low, int high) resumable{ for(int i = low; i <= high; ++i) { yield i; }}

LINQ(Language Integrated Query)C# 3.0

データ処理の直行化

• データ処理を言語統合• ほとんどはライブラリで実現

• STL の <algorithm> とか Boost.Range の Adaptersみたいなもの

var source = new[] { 1, 2, 3, 4, 5 };var filtered = source .Where(x => x <= 3) // 1, 2, 3 .Select(x => x * x); // 1, 4, 9

System.Linq.Enumerable.Where メソッドと

System.Linq.Enumerable.Select メソッド

が呼ばれるだけ

• まあ、データの入力、加工、出力は分けましょうという話

ユーザー入力からConsole.Read…

配列から{ 1, 2, 3, … }

データベースからSELECT x FROM t

ファイルからFile.Read…

1, 2, 3変換x => x * x1, 4, 9

1, 2, 3選択x => x < 31, 2

1, 2, 3グループ化x => x % 2{1, 3},

{2}コンソールにConsole.Write…

配列にToArray()

データベースにINSERT INTO t

ファイルにFile. Write…

入力加工出力

•掛け算を足し算に

ユーザー入力からConsole.Read…

配列から{ 1, 2, 3, … }

データベースからSELECT x FROM t

ファイルからFile.Read…

1, 2, 3変換x => x * x1, 4, 9

1, 2, 3選択x => x < 31, 2

1, 2, 3グループ化x => x % 2{1, 3},

{2}コンソールにConsole.Write…

配列にToArray()

データベースにINSERT INTO t

ファイルにFile. Write…

入力加工出力

Lパターン Mパターン Nパターン

分けて作らないと L×M×N 通りのパターン

分けて作ると L＋M＋N 通り

C#や.NET Frameworkがやっていること

Technology

Transcript of C#や.NET Frameworkがやっていること

「関西」の「大学生」だからこそ ビブリオバトルをやってみよう!

ノベルゲームができるまでに ふたりでやったこと

こおりやま こころのバリアフリー ガイドブック · こおりやま こころのバリアフリー ガイドブック こおりやま こころのバリアフリーガイドブック

TBMU#33 ブログをやっててよかったこと

こんなときに やってみよう！ 心とからだのセルフケア

ププッてなることを真剣にやると、かっこ良くなるんですよププッてなることを真剣にやると、かっこ良くなるんですよ 2作連続シングル『神髄-FRONTIER-』、『神髄-THE

Play2 scalaを2年やって学んだこと

20150726 IoTってなに？ニフティクラウドmqttでやったこと

今月のNEWSな楽譜＆グッズ Piano Lesson › news88 › binder › 135.pdf · した。「ドレミのうた」から始まり、「やまびこごっこ」や「カ レーライス」などのまねっこソングやお話になっている歌、

· Web view2019-11-15 · （2） い行ってみたい ところ，さん参か加してみたい ところ，やってみたい ことを， ぜひ じっ実こう行してみましょう。

20140711 r4 rをやってわかったこと

フロントエンドエンジニア（仮） 〜え、ちょっとフロントやること多すぎじゃない！？〜

C#/.NETがやっていること 第二版

MySQL ガチBeginnerがやってみたことと反省したこと

エンジニアが Webを学ぶために やっててよかったこと

2 森の中に入っていこう (3)もやわけ（間引き）をやってみ ... · 2020. 6. 8. · 2 森の中に入っていこう (3)もやわけ（間引き）をやってみましょう

おれんじドア も～やっこなごや からの メッセージ · 3 「 できるまで、できてからおれんじドア も～やっこなごや」が 平成31年2月24日に西区役所で開催した「認知症も～やっこフェスティバル」の中で、「おれんじドア

なごやっこ葱ポップAkonegi.jp/popA.pdfTitle なごやっこ葱ポップA.psd Author かとう Created Date 7/7/2010 10:01:03 PM

健康創造都市やまと やまとげんきっこ体操 - Yamatoやまとげんきっこ体操 歌詞 1．あさおきて おはよう たべよう あさごはん モリモリ

スクラムやったらこうなった #AgileJapanOsaka

「関西」の「大学生」だからこそビブリオバトルをやってみよう!

ノベルゲームができるまでにふたりでやったこと

こおりやまこころのバリアフリーガイドブック · こおりやまこころのバリアフリーガイドブックこおりやまこころのバリアフリーガイドブック

こんなときにやってみよう！心とからだのセルフケア

今月のNEWSな楽譜＆グッズ Piano Lesson › news88 › binder › 135.pdf · した。「ドレミのうた」から始まり、「やまびこごっこ」や「カレーライス」などのまねっこソングやお話になっている歌、

· Web view2019-11-15 · （2）い行ってみたいところ，さん参か加してみたいところ，やってみたいことを，ぜひじっ実こう行してみましょう。

フロントエンドエンジニア（仮）〜え、ちょっとフロントやること多すぎじゃない！？〜

C#/.NETがやっていること第二版

エンジニアが Webを学ぶためにやっててよかったこと

おれんじドアも～やっこなごやからのメッセージ · 3 「できるまで、できてからおれんじドアも～やっこなごや」が平成31年2月24日に西区役所で開催した「認知症も～やっこフェスティバル」の中で、「おれんじドア

健康創造都市やまとやまとげんきっこ体操 - Yamatoやまとげんきっこ体操歌詞 1．あさおきておはようたべようあさごはんモリモリ