C言语と机械语-TauraLaboratory.ppt

ポインタ捏造をさせないための二つの基本アプローチ 「動的に(実行時に)」保証する： 多くのスクリプト言語, Lisp, Schemeなど 動的な型検査を行う 「静的に(実行前に)」保証する： Java, ML, Haskellなど 静的な型付けを行う 動的な保証 Foo o = new Foo();if (…) { o = 918; }o.f = 10; 実例: Python, Ruby, Lisp, Scheme, Prolog, JavaScript, … 動的な型検査 実行時にoがfというフィールドを持つデータでなければエラー 動的な保証(動的型検査)の仕組み 最低の基本: X番地に割り当てられたデータ(アドレスX)と 整数のX が実行時に区別できるようにするデータのタグ付け 例 X番地: 整数のX X X 1 0 動的型検査 より一般には, 実行時に「そのデータの型(種類)」が分かるようにデータを表現しておく あらゆる操作が「正しい型」のデータに対して行われているかどうかを実行時に検査する 行われていなければ実行時に「型エラー」がおきる 静的な保証 Foo o = new Foo();if (…) { o = 918; }o.f = 10; Foo f = new Foo();Bar b = new Bar();f = b; /* これも同様にエラー */ 実例: Java, ML, etc. 静的な型安全保証 そもそもこういう代入をさせない 実行前(コンパイル時)に検出, 「禁止」 静的型検査(静的な型付け) (理想的には)目的: 実行時に型エラーが起きないことを実行前に保証する 型エラーを起こす可能性があるプログラムはそもそも実行させない 静的型付けの基本的仕組み 最も単純な静的型付け: すべての変数には一種類の型の値しか代入できない 配列や構造体の要素も同様 ? プログラム中に現れるすべての式の型が静的に(実行前に)一通りに決まる 代入文(や引数渡し)は, 両者の型が一致しなければ実行前にエラーとする 例 class Foo { int x; }class Bar { Foo f; } Bar b = …;if (…) { b = 918; } /* Bar = int ? エラー */b = new Foo(); /* Bar = Foo ? エラー */b.f = new Foo(); /* Foo = Foo ? OK */ Bar[] a = …;a[i].f.x = 13; /* int = int ? OK */ 動的保証 vs. 静的保証 動的 … 遅い 間違ったプログラムに対する「安全網」にはなるが, そもそもの間違い防止にはならない 静的 … 理想的には実行時の型検査不要 ある部分の間違い(型の間違い)を自動的に発見 一見理想的(Cなみに速い, だが安全) 欠点は?? 単純な静的型付け言語の弱点 柔軟性の欠如: 制約が厳しすぎる(実行すればエラーを起こさないプログラムも静的な型エラーとなることがある) 再利用性の欠如: 静的な型エラーを起こさないようにすると, 無駄な重複の多いプログラムになってしまう 「すべての式の型が静的に(実行前に)一通りに決まる」という制約から生ずる 例 Fooの配列とBarの配列を整列する関数は例えアルゴリズムが同じでも別々に書かなければならない Sort(Foo[] a) { … } Sort(Bar[] b) { … } 同様の例: 可変長配列, ハッシュ表, etc. 「型によらず共通なアルゴリズム」を一つのコードで書く方法がない ?もう少し複雑な静的型システム 柔軟性と安全性の両立 多相型 オブジェクト指向言語における継承?部分型 型変数による多相, テンプレート 継承?部分型 class Point2D { int x; int y; }; class Point3D extends Point2D { int z; }/* 許してもOKなのは? */Point2D a = new Point3D(); /* 2D = 3D */Point3D b = new Point2D(); /* 3D = 2D */a.x + a.yb.x + b.y + b.z 部分型による多相 Pont2D の変数 p に入っているのは今や実際には, Point2Dおよびそれを継承(extends)したクラスのオブジェクト なんであれ p.x, p.y を持つことが保証される p.z は静的型エラー(たとえ偶然 Point3D であっても実行前にエラーとなる) Quiz Point2D[] p = …; /* Poi