D言語 Part16

1 名前：デフォルトの名無しさん mailto:sage [2007/11/18(日) 23:00:35 ] プログラミング言語 D (D Programming Language) について語るスレッドです。 過去スレは >>2 ■本家 ttp://www.digitalmars.com/d/ ttp://www.kmonos.net/alang/d/ (和訳) ■コンパイラ ttp://www.digitalmars.com/d/dcompiler.html (DMD, 本家) ttp://dgcc.sourceforge.net/ (GDC, gccフロントエンド) ttp://gdcmac.sourceforge.net/ (GDCのmac用バイナリ) ■参考URL ttp://f17.aaa.livedoor.jp/~labamba/ (D言語研究) ttp://dsource.org/ (dsource) ttp://tinyurl.com/3da5oa （C/C++に疲れた人のD言語） ttp://www.kmonos.net/alang/wnd/ （わかったつもりになるD言語） ttp://shinh.skr.jp/d/ （SDL, SDL_*, OpenGL, GLU, glutのポーティングとか） ttp://shoo.s20.xrea.com/shoo/programing （D言語とTangoの入門講座） 85 名前：デフォルトの名無しさん mailto:sage [2007/11/26(月) 22:22:53 ] じゃあこれで心置きなくTangoに移れそうだね 86 名前：デフォルトの名無しさん mailto:sage [2007/11/27(火) 00:53:14 ] 伝説のIDEができるまでにこけそうな勢いだなこりゃ 87 名前：デフォルトの名無しさん mailto:sage [2007/11/27(火) 00:56:57 ] ここのみんなで日本語化しちゃおうか 88 名前：デフォルトの名無しさん mailto:sage [2007/11/27(火) 01:21:29 ] >>86 >>49 89 名前：デフォルトの名無しさん mailto:sage [2007/11/27(火) 02:26:37 ] >>87 やりたいんだがなあ 90 名前：デフォルトの名無しさん mailto:sage [2007/11/27(火) 13:03:57 ] NewsGroup盛り上がってるな 直前の流れは知らないんだがTangoとPhobosを統合するのかな？ 「両方のコーディングスタイルの違いはどうするの？」とか言ってるし あとまだ運用がよくわからないから 「誰が全体の設計の管理を受け持つの？」とか話しているようだ 91 名前：デフォルトの名無しさん mailto:sage [2007/11/27(火) 13:37:11 ] > 「誰が全体の設計の管理を受け持つの？」 今までのTangoの人じゃ駄目なの？ 92 名前：デフォルトの名無しさん mailto:sage [2007/11/27(火) 18:26:33 ] TangoってDっぽくないんだよなあ。そこがあまり好きになれない。 93 名前：デフォルトの名無しさん mailto:sage [2007/11/27(火) 18:27:48 ] 俺に十分な時間があればもっと素晴らしいライブラリ作って見せるんだが 94 名前：デフォルトの名無しさん mailto:sage [2007/11/27(火) 19:03:28 ] 俺も俺も ニートでやってくれる人いないのかな？ 95 名前：デフォルトの名無しさん mailto:sage [2007/11/27(火) 19:54:31 ] >>94 よんだ？ っと冗談はおいといて、スレようにレンタルのWikiでも取る？ 96 名前：デフォルトの名無しさん mailto:sage [2007/11/27(火) 20:11:20 ] 既にある奴で足りてるだろ。 情報が分散するだけだから何個もいらんよ 97 名前：デフォルトの名無しさん mailto:sage [2007/11/27(火) 20:17:58 ] それもそうか。 98 名前：デフォルトの名無しさん mailto:sage [2007/11/27(火) 22:05:29 ] つまりboostがやってるみたいに新規ライブラリを受け付けて acceptしたりrejectしたりする機構があればいいのか はてなスターが積み上がる光景が見えたが 母体が2chじゃ投票制にしたら破綻するかなｗ 99 名前：デフォルトの名無しさん mailto:sage [2007/11/27(火) 22:08:15 ] >>92 俺はconduitの概念がしっくりこないんだよね ようはstreamなのか？ だったらstreamでいいだろ条項とか思っちゃって 100 名前：デフォルトの名無しさん mailto:sage [2007/11/27(火) 22:43:06 ] >>98 創始者のカリスマ性によると思う 101 名前：デフォルトの名無しさん mailto:sage [2007/11/28(水) 00:36:08 ] static foreachまだかなあ それとCTFEでForeachRangeが使えないのを早く直して欲しい 102 名前：デフォルトの名無しさん mailto:sage [2007/11/28(水) 00:38:19 ] >>99 streamというよりstreambufのような感じなんじゃないかな。 streamはstreamで別にあるし… 103 名前：デフォルトの名無しさん mailto:sage [2007/11/28(水) 13:06:35 ] Phobosのtrunkが熱すぎる件について std.functional std.algorithm その他もろもろ 104 名前：デフォルトの名無しさん mailto:sage [2007/11/28(水) 13:39:35 ] まじかよｗｗｗ 105 名前：デフォルトの名無しさん mailto:sage [2007/11/28(水) 13:44:26 ] >>103 ちょ、これから落としてくるｗ 2.0専用？　1系列でも使えると嬉しいんだが……。 106 名前：デフォルトの名無しさん mailto:sage [2007/11/28(水) 13:45:07 ] Phobosはじまったな 107 名前：デフォルトの名無しさん mailto:sage [2007/11/28(水) 13:46:43 ] >>103 見たとこあんまり面白い変更無いような…。 108 名前：デフォルトの名無しさん mailto:sage [2007/11/28(水) 16:37:13 ] 1.024/2.008 109 名前：デフォルトの名無しさん mailto:sage [2007/11/28(水) 16:57:50 ] バグフィックスとphobosの拡張がメインか。 typeof(return)とか実際使う場面なさそうだし 110 名前：デフォルトの名無しさん mailto:sage [2007/11/28(水) 18:55:22 ] Assertion failure: 't->deco' on line 608 in file 'mtype.c' abnormal program termination コンパイラバグってるな。@2.008 111 名前：デフォルトの名無しさん mailto:sage [2007/11/28(水) 22:57:41 ] >>36ってdsss.confあたりから設定できない？ budだと-Xあたり？　が似たようなオプションになってるっぽいんだけども。 112 名前：デフォルトの名無しさん mailto:sage [2007/11/29(木) 01:04:03 ] なんか今回のバージョンアップ微妙に反応少ないけど Added const and invariant to IsExpressions これはなんか嬉しい。 あと、 Added const/invariant structs, classes and interfaces. これが気になっている。何に使えるんだろう？ 113 名前：デフォルトの名無しさん mailto:sage [2007/11/29(木) 01:07:19 ] budだと version(build) pragma(nolink); でobj作らないようにして version(build) pragma(lib, "tx.lib"); などとする 114 名前：デフォルトの名無しさん mailto:sage [2007/11/29(木) 07:34:05 ] wxDでかすぎｗｗｗｗｗｗｗ わなDのテストやってみたら3.12MB^q^ これは・・・ 115 名前：デフォルトの名無しさん mailto:sage [2007/11/29(木) 09:12:21 ] >>112 おれも気になった。 迷走って言葉が頭をよぎった 116 名前：デフォルトの名無しさん mailto:sage [2007/11/29(木) 16:27:53 ] たしか、constメンバってstaticに配置されるんだよな？ 117 名前：デフォルトの名無しさん mailto:sage [2007/11/29(木) 16:47:51 ] structとclassでは使い道が思い浮かばんけど、 interfaceなら使いどころもあるんじゃなかろうか。 const interface ICountable { size_t count(); } みたいな。 118 名前：デフォルトの名無しさん mailto:sage [2007/11/29(木) 17:55:18 ] インターフェースって頭にIつけたほうがいいの？ 119 名前：デフォルトの名無しさん mailto:sage [2007/11/29(木) 18:24:38 ] MSハンガリアンだよね。頭にIつけるの。 でも、Iつけてる人は多いねえ。 120 名前：デフォルトの名無しさん mailto:sage [2007/11/29(木) 18:48:41 ] 俺は、インターフェイス名と同名でインターフェイスの標準の実装を 作りたくなることが結構あるから、名前重ならないようにIつけてる。 121 名前：デフォルトの名無しさん mailto:sage [2007/11/29(木) 19:04:36 ] 同名のプロパティ作りたいからプライベート変数の尻にアンダースコアつけてるけど、似たようなもんか。 122 名前：デフォルトの名無しさん mailto:sage [2007/11/29(木) 19:49:31 ] 俺もそのへんなやみつつハンガリアン的とか尻_とかしてるけど、 一般的になにがいいのかねぇ 123 名前：デフォルトの名無しさん mailto:sage [2007/11/29(木) 20:06:51 ] メンバーならm 124 名前：デフォルトの名無しさん mailto:sage [2007/11/29(木) 20:21:16 ] 個人的に@インスタンス変数は好き 125 名前：デフォルトの名無しさん mailto:sage [2007/11/29(木) 23:59:55 ] Dじゃ@は使えないからなぁ。 VC++だと$使えたりする。使わんけど。 126 名前：デフォルトの名無しさん mailto:sage [2007/11/30(金) 02:23:22 ] const変数にコンパイル時に決定されない値を入れられるんだけど、 これって仕様に適ってるの？ const l = readln; 127 名前：デフォルトの名無しさん mailto:sage [2007/11/30(金) 07:18:24 ] digital marsのサイトからの引用だけど int x = 3; const int *p = &x; *p = 4; // error, read-only view const int *q = &x; int z = *q; // z is set to 3 x = 5; // ok int y = *q; // y is set to 5 ってなコードがある、仕様だと思う。 Cでもローカルのconst変数宣言時にコンパイル時に決定されない値入れれるし、 その辺の仕様を引き継いでるんじゃない? 128 名前：デフォルトの名無しさん mailto:sage [2007/11/30(金) 16:24:13 ] >>127 そっかー phobos見てても本来ならfinal使うべきところでconstって書いてたりするから仕方ないのかな。 129 名前：デフォルトの名無しさん mailto:sage [2007/11/30(金) 17:18:10 ] 数カ月おきにやる気を補充した所で細かい仕様が変わってるから困る 130 名前：デフォルトの名無しさん mailto:sage [2007/11/30(金) 19:09:58 ] へ？finalあるのにconstがその仕様なんだｗ そのうちreadonlyとかできたりして 131 名前：デフォルトの名無しさん mailto:sage [2007/11/30(金) 19:16:20 ] initonlyﾏﾀﾞｧ-? （･∀･ ）っ/凵⌒☆ﾁﾝﾁﾝ 132 名前：デフォルトの名無しさん mailto:sage [2007/11/30(金) 19:39:36 ] constって型がconst型になるfinalだろ？ 133 名前：デフォルトの名無しさん mailto:sage [2007/11/30(金) 22:49:36 ] D1.0のconstはコンパイルタイム定数だったよなあ D2.0のconstはそれプラスreadonlyなのかな？とか漠然と思ったまま放置してた俺 D2.0になってconstがどういう意味なのかがわかりにくくない？ 134 名前：デフォルトの名無しさん mailto:sage [2007/11/30(金) 23:18:47 ] >>133 おれもそう思う。>>132の解釈でいいのかな？ あとinvariant型とconst型の使い分けがよくわからん。 関数の引数にconst型を使ったとして、「俺は書き換えない」と宣言しても、その関数を実行しているときに 誰かに書き換えられちゃったら読み込んだりとかした時に予期しないエラー起こさない？マルチスレッドのときとか。 関数の戻り値は「書き換えるな」という意味でconst型でいいような気もするけど。 135 名前：デフォルトの名無しさん mailto:sage [2007/11/30(金) 23:30:14 ] www.kmonos.net/alang/d/const.html ここ読んでから書き込もうよ。 136 名前：デフォルトの名無しさん mailto:sage [2007/11/30(金) 23:40:22 ] 昔はconst変数をコンパイル時定数以外で初期化しようとしたらエラーなってた気がするんだが 137 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 00:59:27 ] >>135 を改めて読み直してみたのだが C++のconstにはコンパイル時定数とreadonlyの2つの意味があって， C++とD1.0のコンパイル時定数としてのconstはD2.0ではinvariantが請け負って， C++のreadonlyのconstをD2.0ではconstが請け負うってことかな /* D2.0 コンパイル時定数 => invariant readonly => const */ 138 名前：127 mailto:sage [2007/12/01(土) 01:06:50 ] >>135 トン >>126 ごめん、これC++の場合のコードですね、>>127のレスは忘れてください。 そして7時の俺、目を覚ませ。 139 名前：134 mailto:sage [2007/12/01(土) 01:07:51 ] >>135そこは読んだよ。結構前だけど。 それでなお、具体的にはconst型とinvariant型の引数の使い分けがわからん。 たとえばPhobosのstd.string.splitの引数がconst型じゃないのは何でだ？ その辺の明確な指針がほしい。 140 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 04:59:17 ] void func(D)(in D dg) { dg(); } void main() { func({printf("test");}); } //(7): Error: cannot implicitly convert expression (__dgliteral1) of type void delegate() to const void delegate() あれ？私何か間違えたましたか＞＜ inにconstが入るからダメっぽいんだけどinってこういう使い方じゃないの？ 141 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 05:24:21 ] どうして readonly なのに書き込めるのはなぜ？ 142 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 08:06:15 ] 1.020でコンパイルできてたSHA512のライブラリが2.007でコンパイルしたらフリーズした semantic2で止まってるらしいけどsemantic2が何かわからね 143 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 13:41:05 ] >>139 splitは文字列のスライスの配列を返すから、 もとの文字列が変更されてしまうと、結果がおかしくなる。 144 名前：143 mailto:sage [2007/12/01(土) 13:49:14 ] コードであらわすとこんな感じ。 import std.stdio, std.string; void main() { auto s = "aaa bbb ccc".dup; auto a = split(cast(invariant)s); // 危険なキャスト writeln(a.join("-")); s[0..5] = "ddddd"; writeln(a.join("-")); } 145 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 13:52:09 ] それは危険なのはキャストであってidupを使えば解決ってことにはならないの？ 146 名前：デフォルトの名無しさん [2007/12/01(土) 13:59:59 ] >>126たしかに www.kmonos.net/alang/d/final-const-invariant.html >const 宣言は、以下の違いを除いて、 invariant とほぼ同じです： >const宣言された変数を通してデータを書き換えることはできないが、 同じデータを参照する別の箇所がデータを書き換えることは あるかもしれない >const宣言された変数の型は、const とあるから、この文章から判断するとconstもinvariantと同様にコンパイル時決定変数なはず。 だからその式が通るならおかしいと思う。 147 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 14:07:04 ] >>143-145 もしsplitの引数の型がin char[]だったら、普通に auto a = split(s); とできてしまう。 invariant(char)[]だからこそ、危険なキャストのような無茶をしない限り安全。 と言ったほうが分かりやすいかな。 148 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 14:10:43 ] >>142 semantic2はsemanticが全て呼び出された後呼び出されるフェーズ。 詳しくはソース嫁 149 名前：デフォルトの名無しさん [2007/12/01(土) 14:21:36 ] >>141 >const宣言された変数を通してデータを書き換えることはできないが、 同じデータを参照する別の箇所がデータを書き換えることは あるかもしれない constからはreadonlyだから書き込めない。だけど、他のconstでない参照からは書き込める。 150 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 14:36:38 ] 今までinvariant,const,finalの違いや使い道が分からなかったんだけど、理解できたかも。 まとめると invariant->コンパイル時定数,書き換え不可 const->readonly,他の参照から書き換え可能 final->初期化以降は書き換え不可,invariantやconstと違ってfinalな変数の指す値は書き換え可能 あれ、じゃあ"初期化以降は書き換え不可"かつ"指している値も書き換え不可"はどう表現するんだ？ 151 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 14:40:37 ] >>150 final constでok 152 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 14:43:34 ] >>151 サンクス 自分のレベルの低さを痛感したorz 153 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 14:47:53 ] >>150 こういうことかな？ import std.stdio; void main(){ 　　int a = 1; 　　int b = 2; 　　final const int* p = &a; 　　*p = 10;//a.d(8): Error: *p is not mutable 　　p = &b;//a.d(9): variable a.main.p cannot modify const/invariant variable 'p' } 154 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 14:48:43 ] あれ被ったか 155 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 14:52:17 ] final const(int)* p;と書くべき。 156 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 15:10:50 ] 普通にconst int* p = &a;でいいんじゃないの？ 157 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 16:42:51 ] >>156 多分実質はそれでもいいけど、>>146でも言ってるように仕様としてはコンパイル時未決定でもいいのか怪しいし、 finalみたいに"コンストラクタ内では何度も書き換えられる"性質を持ったものを考えてた。 ついでに初歩的なことですまんが、 final const int* p; と final const(int)* p; の違いって？ 158 名前：134 mailto:sage [2007/12/01(土) 17:12:18 ] >>143,>>147 なるほど。確かにstd.string.splitだとinvariant型のほうがいい気がするな。 もしconst型だったら、 > 必要なのは、データを絶対に書き換えないという保証のもとにモジュールから関数にデータを読み取らせるプロトコルです。 を満たすための条件(戻り値のデータに書き換えが起こらない条件)が関数の定義からだけでは読み取れず、 ドキュメントを参照して注意しなければならない、という面倒なことが起こるからな。 じゃあ、std.string.countならどうだろう？関数の実引数にしてから関数が終了するまでの間だけ 他から書き換えられないように注意すれば引数がconst型でもいいような気がするんだけど。 これならドキュメント見なくてもconst型の使い方から終了まで書き換えちゃいけないということは判断可能だし、 戻り値がuintだから関数が終了した後まで面倒を見なくてもいい。 char[]型を実引数にするために.idupによる無駄なコピーもしなくていいし、cast(invariant)みたいな無茶なキャストも使わないですむ。 159 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 17:25:31 ] >>157 たぶん、こうだと思うよ。 const(int*) p = &a;　　//p「int*」が書き換え禁止 int x = *p; //○ *p = 10; //○ p++; //× const(int)* p = &a;　　//pの指し示す先の「int」が書き換え禁止 int x = *p; //○ *p = 10; //× p++; //○ final const int* p = &a;　　//p「int*」書き換え禁止、かつpは初期化後は固定。（冗長？） int x = *p; //○ *p = 10; //○ p++; //× final const(int)* p = &a;　　//pの指し示す先の「int」が書き換え禁止、かつpは初期化後は固定。 int x = *p; //○ *p = 10; //× p++; //× 160 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 17:47:53 ] >>159 なるほど ところでいちいち.dupするの面倒なので mutable to immutable(const/invariant) : deep copy immutable to immutable(const/invariant) : shallow copy となるのはどうだろう？ 161 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 17:50:00 ] >>159 const(int*) は const(const(int)*) と同じ。 const Type var; は final const(Type) var; と同じ。 ただ、2.008ではfinal記憶クラスが正しく機能していない。 162 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 18:34:50 ] 記憶クラス周りは結構複雑だなぁ。 invariantメンバ関数は、コンパイル時に定数に置き換えられそうだな。 使いこなせれば強力だけど、そこまでが大変だぁ。 163 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 19:01:19 ] ん？invariant void foo()で実現できる事って何があるんだろう？ 164 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 19:05:15 ] >>161 なるほど。 www.kmonos.net/alang/d/final-const-invariant.htmlも読み直して理解できたかも。 「const(int)* p」は「(const(int))* p」って意味で、pの指す先は書き換え不可だけど、p自体はconstじゃなくて書き換え可能。 「const(int*) p」は「const(const(int)*) p」って意味で、pも書き換え不可になる訳か。 constの推移性って便利だけど、理解するまでは複雑だな。どこからconstなのか少しわかりにくい。 特に「const int* p」はどこにconstがかかるのか分かりにくいね。 165 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 19:17:22 ] >>162-163 を見て気になったけど、 >invariant メンバ関数では、 this参照経由で参照される全てのデータがinvariantであることが保証されます。 struct S { int x; invariant void foo() { x = 4; // エラー。x は invariant this.x = 4; // エラー。x は invariant } } これはつまりS.xはコンパイル時決定変数？ そうなるとSのメンバ変数はすべてコンパイル時決定って意味になるけど、それは使い道がない気がする... 166 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 19:19:43 ] >>165 invariantでないメンバ関数を追加すればいいじゃない。 167 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 19:23:00 ] const int* p; って宣言で、constはストレージクラスのはずなのに、 typeof(const int*) が、typeof(const(int*)) と同じように働くのが気持ち悪い。 168 名前：165 mailto:sage [2007/12/01(土) 19:34:50 ] えーと、 たとえばSを struct S{ 　　int x; 　　int y; 　　invariant void foo(){ 　　　　x = 4; //エラー、xはinvariant 　　} 　　void var(){ 　　　　x = 4; //これはNG? 　　　　y = 5; //これはOK? 　　} } とした場合どうなる？ xはfooでinvariantとして扱われているから、varで書き換えたら怒らるんじゃないかと心配してるんだけど。 で、yはfooからは参照されてないからvarからは普通に書き換え可能？ テストすれば分かることを聞いてすまん。時間あったらテストするんだけど。 169 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 19:41:32 ] 時間あるじゃんｗ 170 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 19:43:55 ] >>168 invariantメンバ関数はinvariantな型に対してしか呼び出せないから、 fooを呼び出せる場合は、varは呼び出せない。 171 名前：147 mailto:sage [2007/12/01(土) 19:49:48 ] >>158 countについては、俺もconstでいいと思う。 172 名前：165 mailto:sage [2007/12/01(土) 19:54:15 ] >>170 "invariantな型に対してしか呼び出せない"というのはどういうこと？ invariant void foo()があることでSのメンバ変数がすべてinvariantになるという認識は間違いでしょうか。 173 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 20:02:37 ] static関数はインスタンスのメンバ変数にアクセスできないのと同じ理屈を書いてるだけでしょ。 invariantはコンパイル時に解決できなければならないってのを意識すれば分かりやすいかな。 174 名前：165 mailto:sage [2007/12/01(土) 20:09:08 ] >>173 つまり S s1; invariant S s2; s1.foo(); //呼び出せない s2.foo(); //呼び出せる ということ？これなら納得できる。 175 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 20:15:25 ] 俺の説明が悪かったのかな？時間あるんだから、テストしようね。 176 名前：165 mailto:sage [2007/12/01(土) 20:18:42 ] そうですね。すみません。 本当は今パソコンつけてる暇無い時期なんですけどね。これだけインターネットしてたら確かに同じだな； 177 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 20:33:37 ] つまり、 invariant変数はコンパイル時に決定され、ROMに配置される可能性があり、ポインタをとってはならない invariant型の変数は実行時に決定でき、書き換えられることはないと保障される invariantメンバ関数はコンパイル時に解決できる const変数は実行時に決定できる const型の変数は実行時に決定でき、書き換えてはならない constメンバ関数は実行時に解決される static変数はコンパイル時に決定され、実行時に変更することができ、スコープによらずデータが保持される こうか？ 178 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 21:06:23 ] >>177 > invariantメンバ関数はコンパイル時に解決できる これが仕様呼んでる限りだとよくわからん。 普通にモジュールスコープにある関数とか呼べるし 179 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 21:26:59 ] invariantメンバ関数から参照できるのは、invariantなメンバのみってことでは。 180 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 21:29:38 ] いかん。誤解をまねく。 invariantメンバ関数から参照できるメンバは、invariantのみ。 のほうが正しい。 181 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 21:36:46 ] invariantメンバ関数からthisポインタを通じて参照されるオブジェクトはinvariantと仮定される、 じゃないか？ 182 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 21:44:55 ] このエラーはいったい？ test.d(3): statement expected to be { }, not int struct S { int x; invariant int y; } 183 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 21:46:12 ] ここらへん明日整理してみるか。 184 名前：182 mailto:sage [2007/12/01(土) 22:02:29 ] 公式サイトの方しかDL2.0のコンパイラはないのね 185 名前：デフォルトの名無しさん mailto:sage [2007/12/02(日) 01:32:52 ] ttp://d.hatena.ne.jp/haru-s/20070622/1182484497

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef