ToDo:
http://d.hatena.ne.jp/ytqwerty/20090122#p1
C 言語擁護派の僕としては、 配列の operator[] とポインタの operator[] が オーバーロードされてたとして、 そして C が今同様に普及していたとすると、 それはそれで初心者の混乱とかを招いていて、 「C の言語仕様は糞」とか言われてる気が… とか思ったけど、 冷静に考えてみてそのオーバーロードで 混乱を招く例は特に思いつかなかった。 確かに無害っぽい。
ただ、
foo[0] == (&foo)[0]
になっちゃうのはちょっとキモいか。
その場合関数 func == &func 問題を考えるに func も値として扱えるようにしないとなんだなぁ…とかも。
D 言語なんかだと &foo は &foo[0] と別の型なので、 これで foo[0] == (&foo)[0] 問題もなくなるけど、 かわりに配列を単なるバッファとして使いたい時に、
&foo[0] + offset
とかしなきゃならなくなるのがちょっと 長いなーという感じもしなくもない。
これはいいと思うんですよね。 なんで C は構造体返せるのか不思議なくらい。 コンパイラの実装ラクになるし。
ただ . と -> を統一しちゃうのはどうなんだろう。 D とか統一されてるわけだけど、
struct C {
void f() {}
}
void main() {
C c;
c.f();
printf("%d\n", c.sizeof); // 1
C* cp = &c;
cp.f();
printf("%d\n", cp.sizeof); // 4
C** cpp = &cp;
//cpp.f(); // error
}
とかキモいなーと感じるんですよね。
(22:08)
| 前 | 2009年 1月 |
次 | ||||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。
> foo[0] == (&foo)[0]
&fooは配列全体へのアドレスになるので、(&foo)[0] == *&foo == foo ≠ foo[0]になりますね。foo[0] == (&foo[0])[0]ならそこまでキモくない気が。
バッファとして使いたいときは……D言語同様に.ptrを……げふ。
.と->の統一は、統一というよりは値としての構造体が無くなるので式中に.を書ける場面が無くなると書いた方が正しかったですね。cpp.fについては->->を(ry
どうもコメントありがとうございます。なんともわかりにくい書き方しててすいませんが、
foo[0] == (&foo)[0] になってしまう、ってのは配列を値として扱えるようにする前の C で operator[] をオーバーロードさせるとすると、そうなってしまうかなぁと。
で、配列を値にしちゃえばご指摘の通り foo[0] != (&foo)[0] となるでしょうから、「 foo[0] == (&foo)[0] 問題もなくなる」としました。
.ptr に関しましては、残念ながら、1バイトも短くなっていないのでゴルフ的には略ですね。まぁ foo.ptr の方が &foo[0] よりも心理的には3バイトくらい短いですが。
あと、値としての構造体がなくなっても、まぁ . はあってもいいんじゃないかなぁとかなんとなく思います。 C 脳でしょうか。
えー。配列を値として扱えるようにする前のCでも、&fooは配列全体へのアドレスなのでそうはならないような。
.ptrが1バイトも短くなってないのは言われて初めて気付きました。それならいっそ.begin()とか書かせた方が良さそうですね。
なんか「&fooを先頭要素のアドレスじゃなくて配列全体へのポインタである」という変更と「配列を値として扱う」という変更は不可分のように考えていました。何故こう考えたかというと、まぁなんとなく、値でない配列に対して、「配列全体へのポインタ」というものを考えるのが難しい、と考えたのでないかと思います。
まぁ僕の直感に依って立った議論なので説得力がイマイチですけど