D言語 Part 6

Elephantって標準では(build.exeでは)コンパイルオプションに-gがつけられないのか？

>>927
　a[0..a.length] = i++;
が
　for(int i=0; i<a.length;){
　　a[i] = i++;
　}
になると思うのは間違い。

　int tmp = i++;
　for(int i=0; i<a.length;){
　　a[i] = tmp;
　}
どちらかといえばこっち。

Child
{
　this()
　{
　　(i)C=3
　}
}

>>934
意図に気づくのに48時間費やした

その間わずか15分

ヒント：相対性理論

>>933
どっちかと言うとこうだろ？

for(int j=0; j<a.length;j++)
　a[j] = i;
i++;

っていうか、思いっきり無限ループしてるじゃないか。

>>938
jはiと見間違えるからkとか使ってくれよ。
というかj使うヤツ久しぶりに見た。

ハァ？jぐらい普通に使うわ。
どんなフォントだ

>>939みたいに言う香具師はさすがに初めて見たなｗ

MS Pゴシックとか使ってるとアレだけどな。
プログラマなら、0に斜線の入ったフォント使ってるだろ、という意見もあるが。

Bitstream Vera使っとけ

いや、これが仕様だっていうなら納得するんだけど
本家の定義では

In general, (a[n..m] op e) is defined as:
for (i = n; i < m; i++)
　　a[i] op e;

ということらしいから、>>927の結果は
a[0] = 0
a[1] = 1
　　：
a[7] = 7
となるのが筋だと思うのよ
eが複数回評価されるのか、最初に1回だけ評価されるのかについては記述がないし

記述がないなら筋もへったくれもないだろ

右辺値の評価が終わり、左辺値の評価が終わり、インクリメント
って
オペレータの優先順位の話だから
代入の定義と関係ないんでないかな。

｢一般に｣であって｢絶対に｣なわけじゃないし

だからって右辺に左辺と同じ長さ・型の配列があったら右辺を毎回評価、
数値だけなら最初の1回だけ評価というのは不自然じゃないですかそうですか。

とか書こうとしたけどよく見たらこのあたりはまだ実装してないのね。
今後どうにかなってしまうことを期待します。

>>948
一つ聞きたいけど、右辺が左辺と同じ長さ・型の配列なら毎回評価すると判断してる理由は何？
右辺が配列でも評価は一度しかしていないと思うけど。
int[]f(){printf("a\n");return new int[2];}
void main(){int[2]s;s[] = f();}
こういうコードを書いても一度しか表示しないし

変に展開された形を想像するから毎回評価されるとか思うんだ。
見た目通り、式は1つなんだから評価後に1回インクリメントでいいじゃないか。
毎回評価させたければforなりで明示的にそう書けばいい。

公式で挙げられてる例だと

b[] = a[] + 3;

というのが

for (i=0; i<a.length; i++)
　　b[i] = a[i] + 3;

と「同等」なのであれば、これは右辺を毎回評価してることになりなせんか？
ってこの例、今のdmdではコンパイルできないんだけど。

あとforで明示的に書けばいいというのなら、配列のスライシング等を言語機能にする
意義がなくなると思う。

問題なのはインクリメントがどうこうじゃなくて、クラスオブジェクトの配列を作りたいときに

SomeClass[8] a;
a[] = new SomeClass();

と書いたとき、実際にはインスタンスは一つしか作成してなくて
配列の要素は全部同じオブジェクトを指してるというのが感覚的に納得いかないのんです。
いたずらにfor文を書くより、最初から複数回評価される実装のほうが有益じゃないですか？
一回だけ評価させたいんであれば

SomeClass[8] a;
SomeClass t;
t = new SomeClass();
a[] = t;

と書けばいいわけだし

変則的な式評価をするのは&& || , ?: だけでいいじゃん。
これ以上増やされると気持ち悪くてかなわん。
俺は右辺を複数回評価をするとか変な仕様になるよりも、
自分でfor文でも書くほうが明示的で分かりやすいと思う。

>>944
>　配列へのデータセット
>　代入式の左辺にスライス、 右辺に要素型と同じ型の値が来ると、 左辺の配列の内容が全て 右辺の値にセットされます。
>
>　int[3] s;
>　int* p;
>
>　s[] = 3;// s[0] = 3, s[1] = 3, s[2] = 3 と同じ意味
>　p[0..2] = 3;// p[0] = 3, p[1] = 3 と同じ意味
配列へのデータセットについては rvalue について書かれているが、
「一般には」 a[] = e とあるように右辺は expression として扱われるということだと思う。
a[1..3] = b[4..7] は配列要素のコピーだし、ごっちゃごちゃだね。

>>952
それがそーいう機能じゃないのは結局そーいう機能がないのが悪いんだろ。
　foreach(3){
　　arrayA[#] = arrayB[$-#-1];
　}
か
　array.foreach = { new Hoge };
ってのを今から仕様に追加しよーぜ。

よう分からんけど
foreach(inout Hoge h;array)
    h = new Hoge;
で十分と思うけどなぁ。

>>955
　foreach(inout Hoge h;array)
が長いのと、arrayの要素に対して操作しているということが
Hoge h のせいで直感的じゃないのが嫌な感じ。

927ｷﾓｲ。あとセンスがない。

俺はそうは思わなかったけどな。

a[10..20] = new Hoge;

とかはスライシングで出来た方が良くないか？

>>957
どっちにも同意・・・

いろんな書き方が
出来るようになるのは、いいんじゃないの？

俺は、perl厨なので
for (1..3){$_}
for(arry){$_}系が
出来ると楽でいいんだけどな

927が責任をもってリクエストしておいてね

一つの式の右辺値が複数回評価されるなんて、気色悪すぎなんだが、
そう思わない人もいるんだな、と思った。

複数回評価する場合はこうするのはどうだろうか
a[10..20] = {new Hoge;};

…とかD学び始めたばかりの漏れが言ってみる

そりゃ気持ち悪いけど、気持ち悪いってだけで判断しちゃだめだろ。
慣れれば普通かもしれないしな。

Rubyならそこらへんの問題はとっくに解決してるのにね。
後発のくせにDって運子だね。

akIDE 0.296が出てるね。

>>964
evalのあるインタプリタと一緒にすんな

･･･と言いたいが便利そうだな､複数評価構文

しかし#defineと同様の欠点を引きずるのはどうかと。＜複数評価構文

a[10..20] = new Hoge[10];
みたいなのはどうだろう

>>968
ほほぅ

文脈によってnew Type[n]の意味が変わるのは...
New!(Type).array(n)とかrange(n)みたいな
配列生成関数を作って使うのはだめなの？
字面はいまいちだけど。

なんかもう収拾つかなそうだねこの言語は。
大切なのはバランス感覚なんだよ。

>>971
収拾つかないのは、おれら
つくってる人はしっかりしていると思う

そのうち導入する予定の配列リテラルに期待しよう。

結論：JavaかC++でＯＫ。

>>974
馬鹿発見

>>975
馬鹿発見

>>974=976
m9(^д^)ﾌﾟｷﾞｬｰｯ
空気嫁ねー奴はすっこんでろ

話戻すが

>>973
連想配列リテラルのこと？

公式の項future
> 3. Array literal expressions.
どんなものかは知らない。

一般的な a[] op e; のことでしょ。多分。

>>980

Newsgroupsの提案記事で読んだ記憶があるのは、例えば、
a[] = [1,2,3,4]とか、b[3..6]=[i,j,k]とかそんな感じのものだった。