Spec#では、ポインタ型に2種類あって、
nullableなポインタ型か、non nullなポインタ型を宣言できます
(C#では値型Tのnullable型をT?と書けますが、それと反対に、Spec#では参照型Tのnon null型をT!と書けます)。
この二つは、コンパイル時の型チェックにより、混ざらないようになっているので、
non nullポインタ型については、
実行時にnullかどうかのチェックをする必要はありません。
参照先に有効な値が存在することは、コンパイル時に保証されているわけです。
non-null型を使うのをサボってnullableなポインタばっかりにしたら、
結局今までと同じじゃん、という気もしますが。
詳しくはDeclaring and Checking Non-null Types in an Object-Oriented Language [microsoft.com](注: PDFです)参照、ということで。
実はこのようにポインタ型を2種類持つ言語はSpec#が最初というわけでもなく、
他にも例えば
Ada [adaic.org]の
参照型も、"not null"を指定するかどうかで、2種類の参照型を区別できます。
NULLがない世界 (スコア:0)
# え?NULLがあっても、NULLなんかでは初期化しませんか。そうなんですか。
Re:NULLがない世界 (スコア:0)
私もその辺がよく分からないのですが、
初期化されたか=保持されている値が有効か否かのフラグを
アドレス値とは別に持たせるべきだったとでもいうのでしょうか?
Re:NULLがない世界 (スコア:5, 参考になる)
そうではなくて、 (non-nullな)参照型が決してnullになり得ない言語仕様にしておけば良かった、 ということでしょう。
といっても、nullに慣れ親しんでしまった人には、 なかなか想像し難いものがあるかもしれません。 例えば、こう考えてみてはどうでしょう。 Javaにそもそもnull定数が無く(nullが予約語でなく、 たとえnullと書いてもコンパイル時に未定義変数エラーになる)、 すべての変数に初期化が必要で、 nullを返すようなライブラリ関数も無かったとしたら? 参照型変数が必ず有効なオブジェクトを参照するように初期化され、 オブジェクトを明示的にfree()/deleteで開放できないとしたら、 ポインタの先を参照した時、そこには必ず値があります。 ポインタをそもそもnullにする方法が用意されていないとしたら、 ポインタがnullかどうかのチェックをする必要もありません。
「えー、でも、それじゃどうやって、値が無いことを示すのさ?」
値が無いかもしれないことを示す必要がある時だけ、 nullableな型を使いましょう、というのが、答のようです。
少なくとも、 ホーア氏のプレゼンテーション概要 [qconlondon.com]にある Spec# [microsoft.com]は、 そのようになっています。
Spec#では、ポインタ型に2種類あって、 nullableなポインタ型か、non nullなポインタ型を宣言できます (C#では値型Tのnullable型をT?と書けますが、それと反対に、Spec#では参照型Tのnon null型をT!と書けます)。 この二つは、コンパイル時の型チェックにより、混ざらないようになっているので、 non nullポインタ型については、 実行時にnullかどうかのチェックをする必要はありません。 参照先に有効な値が存在することは、コンパイル時に保証されているわけです。 non-null型を使うのをサボってnullableなポインタばっかりにしたら、 結局今までと同じじゃん、という気もしますが。 詳しくはDeclaring and Checking Non-null Types in an Object-Oriented Language [microsoft.com](注: PDFです)参照、ということで。
実はこのようにポインタ型を2種類持つ言語はSpec#が最初というわけでもなく、 他にも例えば Ada [adaic.org]の 参照型も、"not null"を指定するかどうかで、2種類の参照型を区別できます。
Spec#は、独自の革新的なアイデアが入っているというわけではないものの、 過去の様々な言語の良いとこ取りを目指しているようですね。 Eiffel風の契約プログラミング [wikipedia.org]向きの 書法があったりして、なかなか面白いです。
件のホーア氏のプレゼンについては、 以前Lambda the Ultimate [lambda-the-ultimate.org]でも取り上げられていました。 そこでもいくつか興味深いコメントが付いていたので、参考にどうぞ。 Adaでもnot null指定ができるというネタはここから頂きました。 「nullableばっかり使ったら同じじゃん問題」に対応した言語については 別のコメント [srad.jp]に書いたのでそちらもどうぞ(長文ばかり(_ _))。
Re:NULLがない世界 (スコア:1, 興味深い)
C++ にも、nullable な (type*) と、not nullable な (type&) がありますよね?
その仕様のおかげで、様々な問題を抱えるに至りました。
どの様な問題が起こったのかといいますと、
例えば、
(type*)->hoge と (type&).hoge が混在して気持ち悪くなりました。
# それはアクセサの問題じゃないか
std::string& hoge() とか意味もわからずに書いてバグらせる奴がでました。
# それはスタックの問題じゃないか
int hoge(const int &hage) とか、何をしたいかわからん事かかれました。
# 結局はバカなのが問題じゃないか
つまり、何がいいたいのかというと、
nullable であるかどうかは、私の問題にはなんら関係がないって事です。
# 違った
Re: (スコア:0)
初期化状態では参照禁止、
参照するためには有効な値を入れてください。
使い終わったら再初期化して参照禁止にできます。
というような感じになるのではないでしょうか。
Re:NULLがない世界 (スコア:1)
そんな事をしたらアクセス出来るメモリが半分になってしまうか、ポインタを格納するのに2ワード必要になってしまいます。
それよりポインタを作成した時に、中身が自動的にNULLの値になっている様な言語仕様にした方が良いかと。実際、Javaが似た様な事をしてます(Javaにはポインタ自体は無いけどオブジェクトのレファレンスが似た様な格好なので)。
Re: (スコア:0)
>アクセス出来るメモリが半分になってしまうか
一番上じゃなく一番下のBITをフラグに使えばいいじゃん。
(今時の大抵のCPUは)メモリのアライメントとかごにょごにょしてるから、N(2とか4とか)で割り切れないアドレスのメモリは必ず「割り切れるアドレスなデータの続き」として扱う傾向が強い。1byte単位でイテレートして舐めるときならともかく、遠くから名指しで飛び込まれるときは必ずNで割り切れるアドレスだということになり、普通のポインタは下の1bitなり2bitなりが遊ぶことになる。
と、ruby(MRI)の解説の受け売りでした。4byte境界を前提とし、最下位BITが立っているものは小さいInt、最下位は寝てるけどその次が起きてる奴はSymbolの内部番号、に割り当ててるんだってね。もちろん両方寝てる奴は普通のObjectを参照。
#これが出来ないくせに普通に性能出てるJRubyナニモノ?ていうか逆にいえばそれに時々負けるMRIって何?
Re: (スコア:0)
ともかくじゃねーだろwww
char *p = buff;
while (*p++!='\0') {
なんとか
}
みたいな処理は「ともかく」でごまかせるほどレアな処理だと思ったか?
Re: (スコア:0)
Re:NULLがない世界 (スコア:1)
1bitなんて使わなくても
0 = NULL
1 = 未初期化
それ以外 = 有効なポインタ
みたいなのでいいじゃない。Win32APIにもINVALID_HANDLE_VALUEとかありますし。
Re: (スコア:0)
1bit犠牲にする意味は?
そうするぐらいならNULLなら参照禁止
でいいじゃない。