C++0x 4 - 暇つぶし2ch

C++0x 4 ..

175:デフォルトの名無しさん
08/07/12 17:36:56
たらいまわし関数なんてはじめてきいたんでぐぐるとこんなのでてきた

/*
再帰的に定義された次のような関数。特に用途はない。
*/
int tarai(int x, int y, int z)
{
if (x <= y) return y;
return tarai(tarai(x - 1, y, z), tarai(y - 1, z, x), tarai(z - 1, x, y));
}

たった数行なのに何が起こるか想像できないのは、おれだけ？
大学の時、再帰で書けばエレガントになる、ループで書くのは素人、と刷り込まれたので
再起が出てくるたびに自分はセンスがないと思わされた苦い思い出。

176:デフォルトの名無しさん
08/07/12 18:33:13
おまえだけ。
わからないことを自慢しなくていいよ

177:デフォルトの名無しさん
08/07/12 18:38:27
引数評価の順番がわからんので俺もどう動くか想像できない

178:デフォルトの名無しさん
08/07/12 23:37:27
>>177
別に副作用ないんだから引数評価の順番は結果に関係ないだろう

179:デフォルトの名無しさん
08/07/13 15:25:45
計算量の例題という趣旨から外れるが、
再帰定義がなぜわかりにくいかがよくわかる例だなと思った。
筋のいいやつは数学的定義がそのまま書けるようなメリットがあるが、ほんの一握りだなと
アプリとか分析エンジンとか作ってて感じる。

180:デフォルトの名無しさん
08/07/13 16:00:59
ただ>>175はループに書き直すと更にわけわからなくなる気がする。

181:デフォルトの名無しさん
08/07/13 16:06:24
しかしD言語ではたらい関数もコンパイル時に評価できるのに、
0xのconstexprはほんとがっかりだなあ。

182:デフォルトの名無しさん
08/07/13 17:57:38
>>181
関数が提唱された本来の趣旨を考えると、コンパイル時にたらいをまわしても
意味ないような気がするんだが、気のせいか？

183:デフォルトの名無しさん
08/07/13 18:02:33
コンパイル時に
int tarai(int x, int y, int z){return x<=y ? y<=z ? z : x : y}
に最適化して欲しいって話だろ

184:デフォルトの名無しさん
08/07/13 18:03:40
違った
int tarai(int x, int y, int z){return x<=y ? y : y<=z ? z : x;}

185:デフォルトの名無しさん
08/07/13 18:08:45
>>182
そりゃあ、そもそもたらい関数自体に意味がないから、
コンパイル時にたらいをまわせても意味がないのは自明なんだけど、
言いたいのはそういうことじゃなくて、

再帰ができないとか、return一文で書かないといけないとか制約が多すぎて使い勝手が悪い。

186:デフォルトの名無しさん
08/07/13 18:27:37
そりゃまあコンパイル時評価したけりゃTMPで十分だし
わざわざ新予約語作ってまでconstexprなんて仕組みを作る理由もよくわからない

187:デフォルトの名無しさん
08/07/13 18:34:54
constexprは普通のコードで書けることや実行時にも実行できることに価値があるんじゃないの？

従来だとコンパイルタイムにもランタイムにも欲しい値がある場合、
普通の関数とテンプレートで二つ同じ処理を書かないといけなかった。

それが制限があるとはいえ普通のコード一つで済むようになるのは、
プログラマの負担の観点から言うと大きな進歩だと思う。

とはいえ、再帰ができないんじゃテンプレートの代わりにはならないよなあ…

188:デフォルトの名無しさん
08/07/13 23:05:38
いらない機能は使わなけりゃいい
禿もそう言っている

189:デフォルトの名無しさん
08/07/18 01:04:53
ぶっちゃけauto以外の新機能は全部いらない
最終的にはautoだけ取り入れられてあとはガン無視されるだろう
C99がlong longとか以外ガン無視されているように

190:デフォルトの名無しさん
08/07/18 01:17:36
ぷ

191:デフォルトの名無しさん
08/07/18 01:19:27
ぷ

192:デフォルトの名無しさん
08/07/18 13:30:51
autoに食いついてる時点で素人丸出し
普通autoなんて使わない

193:デフォルトの名無しさん
08/07/18 15:07:21
まじで?
型指定子としてのautoはいるだろ。

194:デフォルトの名無しさん
08/07/18 15:33:34
auto int x;

195:デフォルトの名無しさん
08/07/18 15:46:22
signedかunsignedか自動的に判断するのかな?
そんな風に考えるようになりました。

196:デフォルトの名無しさん
08/07/18 15:46:55
馬鹿じゃねーの？

197:デフォルトの名無しさん
08/07/18 15:48:17
>>195
型名が後に続く場合は自動変数の宣言になります。

198:デフォルトの名無しさん
08/07/18 15:52:21
馬鹿なことやってないで、コンパイラに型推論要求すりゃいい話じゃねぇの？

199:デフォルトの名無しさん
08/07/18 15:54:44
それがautoなんです（＞＜）

200:デフォルトの名無しさん
08/07/18 16:44:24
>>199
C++ の言語仕様でどこまでトレースきるのさ？

201:デフォルトの名無しさん
08/07/18 16:58:46
C++ の言語仕様にも手を入れたのでへっちゃらですよ

202:デフォルトの名無しさん
08/07/18 18:36:15
ムーブセマンティクスとかコンセプトとか、とりあえずライブラリ実装者が使ってくれれば、
利用者は何もしなくても恩恵を被れるって機能も多いぞ。

203:デフォルトの名無しさん
08/07/18 19:02:45
ムーブセマンティクスは微妙だな。
また頭ひねることになりそう。
constくらいは。

204:デフォルトの名無しさん
08/07/18 21:23:06
いやいやあれは超便利だろ。

205:デフォルトの名無しさん
08/07/18 21:34:59
美少女中学生が呼吸をするたびに形のいいおっぱいがオートムーブ

206:デフォルトの名無しさん
08/07/18 21:41:16
ムーブの概念はコピーより自然
今までなかったのが不思議

207:デフォルトの名無しさん
08/07/19 09:57:13
そりゃ一般的な機械語にムーブがなかったからだろうよ。

208:デフォルトの名無しさん
08/07/19 23:39:30
autoなんて、0x新仕様の中でも一番利用者として理解しやすい機能の1つなんだから
少しは勉強してからカキコしろよ。だってここ0xのスレなんだぜ。
という漏れも、Move Semanticsはよく理解してないので、えらそうなこと言えないけどさ。ごめん。

209:デフォルトの名無しさん
08/07/20 00:10:16
mov ebx, eax

210:デフォルトの名無しさん
08/07/20 00:28:24
>>209
俺それ書くの我慢したのに……。

211:デフォルトの名無しさん
08/07/20 01:12:06
copyだし

212:デフォルトの名無しさん
08/07/20 01:15:12
その点、Z80ニーモニックは正しいな

213:デフォルトの名無しさん
08/07/20 02:47:49
conceptのところ読んでみたけど
late_checkとaxiomの意味がわからん・・
何がうれしくなるんだろう

214:デフォルトの名無しさん
08/07/20 04:24:04
>>208
勉強してから書くのは大変だ。
読んで書くくらいなら、かなりの割合で達成してるだろう。

だからみんな単語にだけ詳しいんだよｗｗ
特に俺ｗｗｗ
読んで分かるのは大変だろ。
言い訳にならないのは承知だが。

215:デフォルトの名無しさん
08/07/20 04:38:01
autoの便利さとコンセプトの強力さとラムダ式の醜悪さと0bが却下されたことさえ知ってれば
このスレでは充分

216:デフォルトの名無しさん
08/07/20 05:03:03
個人的には initializer_list に地味に可能性を感じる

217:デフォルトの名無しさん
08/07/20 05:23:33
xchg eax,ebx

218:デフォルトの名無しさん
08/07/20 08:05:19
>>213
late_check:
あるインターフェースに適合するかどうかを
C++ではシグネチャーベースで判定するので、
テンプレート引数が決定して、
テンプレートインスタンスを生成する時にしか、
全体の適合性を判定できない場合が多い。
かといって、テンプレートの定義時に判定できる部分も、
インスタンス生成時まで判定できないのでは、
テンプレートのプログラミングがやりにくい。
だから、late_checkブロックの部分だけ、インスタンス生成時、
後は定義時に整合性のチェックを行う。
axiom:
条件式を最適化で利用して良い。
つまり型に対する論理的な制約になる。
Eiffelの「不変条件」みたいなもの。

219:デフォルトの名無しさん
08/07/20 11:18:40
>>218
concept が与えられてなお

＞テンプレート引数が決定して、
＞テンプレートインスタンスを生成する時にしか、
＞全体の適合性を判定できない場合が多い。

な場合についてｋｗｓｋ

220:デフォルトの名無しさん
08/07/20 11:50:12
>>208
知ってるかもしれないけど、
Move semantics(右辺値参照)に関しては禿がThe C++ Sourceに記事書いてたよ。
結構分かりやすい説明だった

221:デフォルトの名無しさん
08/07/20 13:15:29
Move Semanticsは内部にコンテナとか持っているclassの
operator書いてればありがたみが分かるだろう。

222:デフォルトの名無しさん
08/07/21 01:59:02
Extensible Literals が Proposed wording under review in Core にあるんだけど
まだ欲張るのか？
マジで09年に仕上げるつもりあるのか？

楽しい機能だから入るんなら歓迎だけどさぁ

223:デフォルトの名無しさん
08/07/21 02:24:34
提案者にBjarne Stroustrupの名前があるので無下にできそうにないな

224:デフォルトの名無しさん
08/07/21 02:46:24
>>222
だから2000+0xF年まではセーフだと…

225:デフォルトの名無しさん
08/07/21 06:33:47
0x200F　旧西暦8207年　宇宙暦308年ついにC++0xの完成をみた。銀河の歴史がまた一頁。

226:デフォルトの名無しさん
08/07/21 06:45:23
>>222
だいぶ前からその段階だから、今はもうほとんど、
"Integrated into working paper"に近いんじゃないのかな?

しかしこれliteralじゃねーだろ。
literalと組み合わせられるコンストラクタだ。

"こんにちわ、世界！"ISO2022JP

とかなんでもありだ。二進数リテラル問題も解決。
'_'で4桁ごとに区切るようなoperator"b"を書きたきゃ書けばいい。

227:デフォルトの名無しさん
08/07/21 09:16:16
もう永久に0xでいいよ

228:デフォルトの名無しさん
08/07/21 09:57:19
>>226
Cooked literalですw

229:デフォルトの名無しさん
08/07/21 10:26:02
>>226
>"こんにちわ、世界！"ISO2022JP
>とかなんでもありだ。
それはどうかな？そもそも "..." の ... 内に非アスキー文字を書くと
未定義なんでは？ (実際上はべつとして。)
operator "ISO2022JP" に渡る以前にエンコーディングが
どうなってるかわからないとどうしようもないべ。

230:デフォルトの名無しさん
08/07/21 10:39:17
さすがに未定義ってことは…
処理系に依存するくらいでは

231:デフォルトの名無しさん
08/07/21 10:40:45
char32_tで受け取れるようになればいいんだよ。

232:デフォルトの名無しさん
08/07/21 10:59:13
やるとしても、
L"こんにちわ、世界！"ENCODING
だな。

233:デフォルトの名無しさん
08/07/21 11:01:43
失礼しました、undefined じゃなくて implementation-defined ぽいですね。
char32_t は Unicode だと決まってるから、
U"こんにちわ、世界！"ISO2022JP
と書いておけば問題ないわけですね。なんか先頭のU が気持ち悪いけど。

234:デフォルトの名無しさん
08/07/21 11:18:14
operator "suffix"(char32_t const*, size_t)がinvokeされるわけですね。

>>226
つ constexpr

235:デフォルトの名無しさん
08/07/30 07:55:42
URLﾘﾝｸ(www.open-std.org)
News 2008-07-28: The 2008-07 mailing is available
News 2008-07-28: The C++ Standard Library Issues List (Revision 58) is available
News 2008-07-28: The C++ Standard Core Language Issues List (Revision 57) is available

236:デフォルトの名無しさん
08/08/01 01:37:54
誰も反応しないのは英語読めないからですね

237:デフォルトの名無しさん
08/08/01 01:39:08
自己紹介乙

238:デフォルトの名無しさん
08/08/01 01:43:12
そんなことより0bをだな

239:デフォルトの名無しさん
08/08/01 04:28:43
というか詰めの作業に入っているから、
そんな勢い良くリアクションするようなことはない。
ただ思った以上に書き直しが多かったので驚いた。> Concept Rev.7

240:デフォルトの名無しさん
08/08/02 14:25:37
今さら変えられないんだろうけど、
ストリーム関連の命名規則がぐちゃぐちゃすぎる。
書式を変更すると保存されるのも使いにくい。
cout << hex(123); みたいにしてほしかった。
これじゃあprintfの方が便利とか言われても仕方ない。

あと、再帰のできないconstexprには失望した。
コンパイラの仕事は、実行時向けに最適化してループにするだけじゃね？

241:デフォルトの名無しさん
08/08/02 14:35:10
実行時にループしたらconstexprとは呼べない。

242:デフォルトの名無しさん
08/08/02 14:41:59
実行時はすでに定数じゃないが、
しかし現状で、テンプレートでコンパイル時再帰の定数ができる以上、
constexprも再帰できてほしかったなぁ。

243:240
08/08/02 14:47:06
>>241
N2235には変数を引数に取る例も載ってる。
実行時も使えるよっていうメリットを残しながら、
再帰できるようにするのは可能だと言いたかった。

244:デフォルトの名無しさん
08/08/02 15:31:10
>>243
仮にそうだとしても、再帰するconstexpr関数がどうせ実行時評価しかしないなら、constexpr付ける意味が無いのでは。

245:240
08/08/02 17:06:39
>>244
いやいや、もちろんコンパイル時も使う。
定数のみを引数に取ったらコンパイル時に展開すればいい。

constexpr int pow(int x, unsigned int n) { return n > 0 ? x * pow(x, n - 1) : 1; }
...
char buffer[pow(2, 8)]; // 定数
unsigned int n; std::cin >> n; std::cout << pow(2, n); // 変数

constexprを取ったら、配列のサイズが定数式じゃないから通らない。
テンプレートでメタ関数として書くと、今度は変数が使えない。

246:デフォルトの名無しさん
08/08/02 17:39:31
>>245
可能かどうかで言えばまあ可能なんだろうな。

N2235も「今はまだそのときじゃない」って感じだし。

247:デフォルトの名無しさん
08/08/02 20:36:23
constexprは「実行時にも使いまわせる型厳密なマクロ」だよな。
お世辞にもコンパイルタイム関数実行とは呼べない。

248:デフォルトの名無しさん
08/08/02 21:55:46
再帰がやりたければtemplate使えばいいって考えがあったから
constexprは再帰禁止にしたのではないかと思う。

249:デフォルトの名無しさん
08/08/02 23:39:28
C++の拡張の目的としてあげられている
ユーザー定義型に組み込み型と同等の待遇を与える
っていうのを実現するのには今のconstexprで十分っていう判断だと推測

250:デフォルトの名無しさん
08/08/02 23:56:41
テンプレート引数は小数使えないしな・・・。

251:デフォルトの名無しさん
08/08/03 01:54:32
俺は>>245の愚案には反対。
constexprの狙いから外れすぎ。

252:デフォルトの名無しさん
08/08/03 04:05:47
浮動小数点演算テンプレートを作ればいい

253:デフォルトの名無しさん
08/08/03 11:50:11
コンパイル時のものと実行時のものは明確に区別して欲しいな
両方使えるとか紛らわしい

254:デフォルトの名無しさん
08/08/03 12:06:56
>>253
D言語なんかは現状ではどの関数がコンパイル時実行できるかさっぱりだけれども、今後関数属性のpureで解決するようだねぇ。

255:デフォルトの名無しさん
08/08/03 12:08:49
マクロとテンプレートとinlineとconstexprの関係でパニックになる初心者続出の予感

256:デフォルトの名無しさん
08/08/03 13:59:53
commonlisp よろしく
#eval_when (<評価するタイミング1> <評価するタイミング2> ...) {
<評価する式>
}
みたく、しちまえよw

257:デフォルトの名無しさん
08/08/03 20:48:23
すっきりしないねぇ。標準委員会に入って考え抜くと、これが最もエレガントな解と思えるようになるのかな。
おれがC++が好きだったのは、Modern C++にもあったけど、
各目的で用意された諸機能が、有機的に相互作用(ハーモナイズ)しあって、
1+1=2以上の機能体系を生み出してたところが、実用的でかつアーティスティックで好きだったんだ。
おれが入門したころの、templateがあってRTTIないくらいのころのC++は美しかった。

258:デフォルトの名無しさん
08/08/03 21:10:05
昔はよかった
K&Rの頃のCが一番だと思っている

259:デフォルトの名無しさん
08/08/03 21:19:46
D言語マンセー

260:デフォルトの名無しさん
08/08/03 21:36:26
ここでC++0xの文法があーだこーだ議論するような奴がD言語使うと、
自分で言語仕様を拡張したい病にかかるからやめたほうがいい。

261:デフォルトの名無しさん
08/08/03 21:43:18
>>257
互換性やメリット、デメリットの狭間に立って考えると良い線じゃないの？
既に巨大なC++の仕様を拡張するのは常にデメリットが大きいし
互換性を考えると不要なものも捨てられないし

262:デフォルトの名無しさん
08/08/03 21:47:13
互換性か…嫌な言葉だな

263:デフォルトの名無しさん
08/08/03 22:45:51
>>260
ありすぎて困るww

264:デフォルトの名無しさん
08/08/03 22:59:52
とすると、そろそろ寿命なんだね。
C++がぐんと存在感伸ばしたころ(おれがC++始めたころ)はC++の青年時代。
引きしまってたし、かといって機能が少ないわけでもないくて先駆的機能たくさんあった。
今は余計についた贅肉自体にもフォローしなくちゃいけなくて悪循環。
(後継の人たちが)どうがんばっても老廃物が老廃物を呼ぶ。
初代ガンダムは筋が通ってておもしろかったけど、
それみて育った子供達が作った後継のガンダムはちっともおもしろくないのと同じ。

265:デフォルトの名無しさん
08/08/03 23:15:28
寿命なのはそうなんだろうけど、後継がサッパリ出てこないから老兵が頑張るしかないんだよな

Java？論外ですわ

266:デフォルトの名無しさん
08/08/03 23:22:19
Dの出番ですね

267:デフォルトの名無しさん
08/08/03 23:32:25
言語はともかく、処理系がいまいちな気がするのは偏見だろうか＞Ｄ

268:デフォルトの名無しさん
08/08/03 23:33:04
>>266
個人が趣味で作ってる程度のものをC++やJavaと同列に扱うのはどうかと思う

269:デフォルトの名無しさん
08/08/03 23:33:23
俺的にはC++0xでやっと「使える」様になってきてこれからな感じなんだが・・・
template無い頃のC++はこりゃダメだと思ってたよ

270:デフォルトの名無しさん
08/08/03 23:48:18
>>268
今でこそ標準化されてるけどC++だって昔は似たようなものだったよ。

271:デフォルトの名無しさん
08/08/04 00:01:36
最近はもう、言語も大きな会社がバックについて
結構な規模の開発体制でやってないとまともなものできないんじゃないか。
Java も .NET も企業主体だし。

272:デフォルトの名無しさん
08/08/04 00:39:18
>>270
cfrontの頃は使いにくかったな。GCC(G++)が革命的だった。

273:デフォルトの名無しさん
08/08/04 10:18:21
Javaも最近はcontrol abstractionとかやり始めて、
以前の保守的なJavaと違って面白くなってきた。

けどconcept, move semanticsなど、
言語機能の本質的なところで実験を続けてるのはC++だと思う。

JCPはEnterpriseな人の便利機能指向が面白味を削いでいる。
実用向けの言語としてはそうでなくては困るのだろうけど。

274:デフォルトの名無しさん
08/08/04 23:31:50
>>273
いよいよ言語マニアだけのためのおもちゃ感が出てきたなぁという気がする。

275:デフォルトの名無しさん
08/08/05 00:47:16
conceptもmove semanticsもライブラリ製作者だけが知ってればいい機能だから、
言語マニアと普通のC++ユーザとはちゃんと住み分けできるよ。

276:デフォルトの名無しさん
08/08/05 00:52:02
ライブラリ制作者がすべからく言語マニアで普通のC++ユーザではない、と言うのは暴論だ。

277:デフォルトの名無しさん
08/08/05 01:04:39
むしろ境界の曖昧性、というかシームレスであることが C++ だと思う

278:277
08/08/05 01:05:30
ちょっと端折った
× むしろ境界の曖昧性、というかシームレスであることが C++ だと思う
○ むしろ境界の曖昧性、というかシームレスであることが C++ の利点だと思う

279:デフォルトの名無しさん
08/08/05 01:41:07
コンセプトはC++プログラマは全員が知る必要のある機能です。
テンプレートと同じです。駆使するのは一部の人だけでいい。

280:デフォルトの名無しさん
08/08/05 09:52:01
>>276
まあべつにコンセプトしらずにテンプレートライブラリを作る人がいてもいいのでは... ってそれは良くない気もするな。

281:デフォルトの名無しさん
08/08/05 10:07:31
それよりも「すべからく」の誤用が気になる。

282:デフォルトの名無しさん
08/08/05 13:21:30
当然の意味でも取れるから必ずしも誤用とはいえないな。
書いた当人がどういう意図で使ったかによる。

283:デフォルトの名無しさん
08/08/05 13:34:26
「須らく」は「～～するべき」と受けるんじゃないのか?
どうしても>276で使うなら
--
ライブラリ制作者は須らく普通のC++ユーザではない言語マニアであるべき、と言うのは暴論だ。
--
となると思う。

284:デフォルトの名無しさん
08/08/05 21:30:06
it's an absurd statement that librarians are always language-mania
and not usual C++ users.

てきなニュアンスに読める。原文に「べき」とかがないので。。

285:デフォルトの名無しさん
08/08/05 21:50:20
原文に「須らく」もないね。

286:デフォルトの名無しさん
08/08/05 23:00:32
このスレには、プログラミング言語のみならず、
自然言語ヲタも多いのか？

287:デフォルトの名無しさん
08/08/05 23:19:46
教養があるだけの話

288:デフォルトの名無しさん
08/08/05 23:37:35
自分で言うか。

289:デフォルトの名無しさん
08/08/05 23:53:40
須らくの使い方は中高で習うだろ

290:デフォルトの名無しさん
08/08/06 00:13:39
しかし自然言語には標準の規格もないし方言が強すぎるし、
時間と共に文法や意味が変化していく。

よほどの猛者しか自然言語の批判はできないが。

291:デフォルトの名無しさん
08/08/06 12:42:20
だからエスペラント語をだな、

292:デフォルトの名無しさん
08/08/06 13:41:33
Esperantoも開発されてから現在まででかなり語彙が変わってるわけだが

293:デフォルトの名無しさん
08/08/06 13:47:06
>>291
形式言語理論が確立される前に設計されているので、他の自然言語と大差ない。

294:デフォルトの名無しさん
08/08/06 16:23:20
そこでイド語をだな、

295:デフォルトの名無しさん
08/08/06 16:31:32
挙げるならロジバンだろ
イドはエスペラントと大差ない

296:デフォルトの名無しさん
08/08/09 09:18:36
コンパイル時の最適化用として
副作用なしで同一引数なら同一の値を返すみたいなヒントとか
同一内容の引数なら同一内容の値を返すみたいなヒントが欲しかった。

297:デフォルトの名無しさん
08/08/09 12:01:38
つ #pragma
つ memorize

298:デフォルトの名無しさん
08/08/09 14:05:55
Ｃ＋＋みたいな理屈っぽい言語はもういい。

グループによる開発に向いた言語じゃない。C++のややこしい
仕様をよく理解していない人間がグループの中に混じっていれ
ば、そいつがバグを仕込むテロリストになってしまう。

もちろん、どんな言語でもバグは入り込むが、C++は特に仕様
が複雑で、誤解にもとづくバグが簡単に入り込み易い。

禿がC++0xをいつの時期、どういう仕様で発表するのか
しらんが、こんな呪文みたいな言語、もういい。

C#に乗り移ろうかな。

299:デフォルトの名無しさん
08/08/09 14:13:28
悪意の無いテロリストはどんな言語でも爆弾仕込むけどな。

300:デフォルトの名無しさん
08/08/09 14:19:22
C++が言われる程複雑じゃないと感じる俺は毒されてるんだろうか

301:デフォルトの名無しさん
08/08/09 14:22:00
C++を取り巻く環境が複雑なのだろう。

302:デフォルトの名無しさん
08/08/09 14:24:49
馬鹿を基準に物事を決めたら進歩は止まるよ

303:デフォルトの名無しさん
08/08/09 14:29:18
↑こういう鼻持ちならない馬鹿がうじゃうじゃいるのがC++の世界

304:デフォルトの名無しさん
08/08/09 14:31:36
>>298
バージョンアップするたびにライブラリレベルで後方互換性が問題となるような、
理屈がない言語も困ったもんだが…

305:デフォルトの名無しさん
08/08/09 14:54:06
>>303
君には縁のない世界だって事よ。

306:デフォルトの名無しさん
08/08/09 15:45:35
>>299
ﾒﾁｬﾜﾛﾀ
うまいこと言うねw

307:デフォルトの名無しさん
08/08/09 15:48:33
>>300
理解という意味では、今のC++の各機能をすべて同じ温度で見つめたら、複雑と思えるんだろうな
昔からやってれば、ここはよく使う主流機能、これはうさんくさい互換性向け機能、とかわかるし

使いこなすという意味では、地雷が増えた気がする。オブジェクトコピーがらみとか。
ただJavaとかのゴミ拾いがらみ機能とか、文字コード変換とか、も地雷いっぱいあった気がする。
一本筋を通してきれいに言語設計・処理系実装してほしいね。それがElegance

308:デフォルトの名無しさん
08/08/09 16:04:17
>>307
ふむ、ならば Scheme でも使いたまへ。

309:デフォルトの名無しさん
08/08/09 16:24:06
いやいやここはunlambdaで

310:デフォルトの名無しさん
08/08/09 16:32:03
>>309
やっぱ、初心に帰ってアセンブラだろう？

311:デフォルトの名無しさん
08/08/09 16:52:55
美少女中学生の汗ブラ！(*´Д`)

312:デフォルトの名無しさん
08/08/09 16:57:20
>>311
美少女中学生シリーズの中では出色の出来だなw

313:デフォルトの名無しさん
08/08/09 18:29:29
>>296
D言語にはもうすぐ純粋関数くるよ

314:デフォルトの名無しさん
08/08/10 15:27:50
>>296
実際どのくらいパフォーマンスを向上できるのだろう
副作用なしで出来ることはたかがしれているし
メリットが小さすぎるんじゃないの？

315:デフォルトの名無しさん
08/08/10 15:32:26
＞副作用なしで出来ることはたかがしれているし
マジすか

316:デフォルトの名無しさん
08/08/10 15:34:44
ものによるだろ
すっごいでかい配列の長さをいちいち求めてたけど実は固定長でしたみたいなのだったら
かなり速くなるかもしれない

まあそんなケースは少ないだろうが

317:デフォルトの名無しさん
08/08/10 15:42:32
>>316
それは>>296とは関係ないけどね

318:デフォルトの名無しさん
08/08/10 16:37:17
そりゃconst size(void); だからね。

sparse arrayのアクセスなんかが相当すると思うけれど、
Cでnoaliasが排除されて以来、
そういう最適化用ツールは言語に組み込まない方向でしょう。
constは意味も規定しているから、重要だけど。

319:デフォルトの名無しさん
08/08/10 16:46:10
>Cでnoaliasが排除されて以来
え？C99のrestrictは？

320:デフォルトの名無しさん
08/08/10 16:50:10
restrict 忘れておった orz

321:デフォルトの名無しさん
08/08/11 10:47:23
restrictって本当にコンパイラにヒントやるだけで
実はエイリアスあったとしてもコンパイラも実行時も何も言ってくれないんだろ

322:デフォルトの名無しさん
08/08/11 10:58:13
当たり前だろw
やりたきゃコードで書けよ。

323:デフォルトの名無しさん
08/08/11 19:43:41
自動的にassertを追加できそうなものだが。

324:デフォルトの名無しさん
08/08/11 22:23:27
URLﾘﾝｸ(gcc.gnu.org)

知らない間にInitializer listsが来てる件について
libstdc++がついてくるのに当分かかるだろうけど、4.4 alpha入れてみよう

325:デフォルトの名無しさん
08/08/11 23:51:55
>>323
assertかよw

326:デフォルトの名無しさん
08/08/12 02:44:32
char a[10], *p;
p=a;
memcpy(p,a,10);

こんな露骨なのにも警告すら出せないrestrictって何なの

327:デフォルトの名無しさん
08/08/12 02:53:42
警告を出すような（素晴らしい）コンパイラを作るのは（コンパイラ屋の）自由じゃね？

328:デフォルトの名無しさん
08/08/12 03:17:27
restrictがC++に入ると、やっぱりスマポもrestrictに出来なきゃならんって事で
クラスのrestrictインスタンスやrestrictメンバ関数が作れるようになるんですね

こんなもんをコンパイラはちゃんと最適化で有意義に使いこなせるのかね

329:デフォルトの名無しさん
08/08/12 03:35:34
>>326
仕様を勘違いしてます。

330:デフォルトの名無しさん
08/08/13 07:09:32
まじめに疑問なんだけど、整数に2の補数を使ってない処理系ってあるの？

atomic周りを読んだら、atomicに限りsignedな整数型とアドレス型は2の補数となりオーバーフローによる不定動作はないと書いてあるけど、
もし仮に、すべての整数型を、2の補数としてしまっても、現実として問題は起こらないと思うんだけど、
なぜC/C++の規格は2の補数だと規定してしまうのを避けているんだろう。

331:デフォルトの名無しさん
08/08/13 08:48:34
>>330 ハード含めて処理系って言うんならそれでもいいんだが...

かつて、実際に2の補数表現を使用しないCPUが存在していたし、
「今後とも2の補数表現以外の整数表現をもつCPUが開発される
事はない」って、保証はどこにもない

からじゃないのか？

332:デフォルトの名無しさん
08/08/13 11:51:31
特殊用途では符号ビット＋絶対値の方が都合がいいことがある

333:デフォルトの名無しさん
08/08/13 13:10:58
最近の言語は2の補数表現を仮定した整数型の仕様で、
そうじゃないCPUはエミュレートしろって立場だね。Java, ECMAscriptなど。
けどCの時代はまだそういう時代じゃなかった。
2の補数表現を仮定しない最後の言語のひとつかもしれない。

334:デフォルトの名無しさん
08/08/13 14:27:24
>>330
DSPなどでは存在してたと思う。とりあえず C++ はそういうアーキテクチャも対象にしてる
ってことだろうね。

もし、2の補数に規定するなら語長（intは必ず32bitとか）も規定するのが良いだろう。
最近の言語ではそのほうが普通かな。

335:デフォルトの名無しさん
08/08/13 14:34:17
美少女中学生のおっぱいは2つだから2の補数！
美少女中学生のおっぱいは2つだから2の補数！

336:デフォルトの名無しさん
08/08/13 14:40:37
>>335 がいいこと言った!!

337:デフォルトの名無しさん
08/08/14 10:39:04
ちょっと聞きたいけど、右辺値参照(Rvalue reference)
が導入されると、(a+b)*(c+d)*eみたいな行列演算も効率化されるの。
それとも、やはり無理？

338:デフォルトの名無しさん
08/08/14 10:44:05
無理じゃないお

339:デフォルトの名無しさん
08/08/14 11:28:32
文脈によるんじゃないんですかね？

加算か乗算かによって違いますし，
右辺値をどの演算の operand に使うのかによっても違いますし，
式テンプレートによる実装と比べてどうなのかについても比較が複雑ですし．

ただ，右辺値参照を用いない実装に比べて
効率的な場面が生じるのは確かだとは思います．

340:デフォルトの名無しさん
08/08/14 11:42:20
長いけど>>338と同じこと

341:デフォルトの名無しさん
08/08/14 12:33:31
せっかく説明してくれてるんだからそう言わんでも

342:デフォルトの名無しさん
08/08/14 14:37:36
単なる計算や初期化の場合は、
右辺値参照を使わない方が
戻り値最適化のおかげで swap が無い分効率的になる。

その結果を代入したいような場合も、
代入の代わりに swap すれば
右辺値参照を使わなくても効率よく実行が可能。
((a+b)*(c+d)*e).swap(f);

結局のところ、それほど右辺値参照の必要性があるとは思えない。

343:デフォルトの名無しさん
08/08/14 14:45:49
まともに機能する実装が登場するまであと10年ってところですかね

344:デフォルトの名無しさん
08/08/14 16:40:05
>>342
どうやってrvalueに対して安全にswapするんだよ？
だからこそ必要なんじゃないか。

345:デフォルトの名無しさん
08/08/14 16:40:44
10年後ね…。この先は厳しいね。
C++が台頭してした当時は、高速バイナリ吐けるオブジェクト指向言語なんて他になかった。
すでに基礎的な部分はC++が築いてしまったし、
個人ですらちょちょいと次世代オブジェクト言語とか作っちゃう時代なので、
今の時代のCのように、Legacy的に古い機能だけ使われる道しか残ってなさそうな気がしてきた。
<=> 実験するなら別の言語

346:デフォルトの名無しさん
08/08/14 16:44:04
今他にあんの？＞高速バイナリ吐けるオブジェクト指向言語

347:デフォルトの名無しさん
08/08/14 16:44:30
えーと…… D…？

348:デフォルトの名無しさん
08/08/14 16:46:40
Dwwwwwwwwww

349:デフォルトの名無しさん
08/08/14 16:54:29
>>342
モチベーションの1つに、そのswapのような変な書き方ではなく
直観的に=演算子でやれるようにするっていうのは無かったっけ？

350:デフォルトの名無しさん
08/08/14 16:55:37
Ocamlとか？

351:デフォルトの名無しさん
08/08/14 16:56:46
Solaris、Windows、Linux　＋　FreeBSD、Mac、Haiku OS

x86ならバイナリも吐けなくないJava
実行速度でC++に引けを取らないJava
対応OSも互換性を重視すれば圧倒的にC++　＜＜　Java

352:デフォルトの名無しさん
08/08/14 17:01:04
最近のjavaは好きな言語だけど、C++とは全然違うよ。
C++の代りの言語はない。近いものすらない。

353:デフォルトの名無しさん
08/08/14 17:01:45
Javs厨の寝言来ちゃった

354:デフォルトの名無しさん
08/08/14 17:02:53
GCを使わされる時点でDもJavaも論外

355:デフォルトの名無しさん
08/08/14 19:08:11
DってDelphiのことじゃないよね

356:デフォルトの名無しさん
08/08/14 19:14:06
そうだよ

357:デフォルトの名無しさん
08/08/14 20:08:48
俺がこれから作る(　・∀・)ｲｲ!!言語ならあるいは・・・！！

358:デフォルトの名無しさん
08/08/14 20:46:24
URLﾘﾝｸ(dn.codegear.com)
C++Builder 2009はC++0xサポートするってさ

俺は買ったことないけど

359:デフォルトの名無しさん
08/08/14 20:51:00
そいつはすげぇ！

でも2009年じゃまだ仕様が決まって無いんでは…

360:デフォルトの名無しさん
08/08/14 21:11:56
いや、その年に仕様を決めようということでC++0xと呼ばれているのではないだろうか。

361:デフォルトの名無しさん
08/08/14 21:16:44
>359
先行して実装するってことらしい。まーどうせ規格が決まったところでフル実装は先になるんだろうし、しばらくは一部実装でしょ。
とりあえず動画中で取り上げられていたのは、スコープ付き enum (および enum のベース型指定)と static_assert。
move semantics については名前が挙がってたし、プロジェクト中にもそれっぽいファイルが見えるけど実際の紹介はなかった。

でもここ最近の Borland/CodeGear の標準準拠度を考えるとあんまり期待できないような気がするなぁ。

362:デフォルトの名無しさん
08/08/14 21:38:19
VCだって6は酷かったけど今はまあ使えるじゃないか。
BCBだってやってくれるかもしれない、なんて期待は甘い？

363:デフォルトの名無しさん
08/08/14 21:42:36
ヘッジがM$に移籍したのが痛いよな

364:デフォルトの名無しさん
08/08/14 21:43:46
>>360
0xF年までおｋ

365:デフォルトの名無しさん
08/08/14 21:59:01
Comeauがどこまで実装するか楽しみ

366:デフォルトの名無しさん
08/08/14 22:15:19
0x200f年までok

367:デフォルトの名無しさん
08/08/14 22:17:58
0xff0f年までおｋ

368:デフォルトの名無しさん
08/08/15 03:22:55
>>363
Hejは規格コーダ屋じゃないからあんまり関係ないでしょ。
得意なのが言語設計とRAD設計だから。

369:デフォルトの名無しさん
08/08/15 12:00:18
>>344
f.swap((a+b)*(c+d)*e); は無理だが
((a+b)*(c+d)*e).swap(f); は問題ない。

370:デフォルトの名無しさん
08/08/15 12:33:32
ああ、なるほど

371:デフォルトの名無しさん
08/08/16 19:17:19
gcc 4.4.0_alpha20080725にてテスト
ソース
#include <map>
#include <string>
#include <iostream>
#include <boost/foreach.hpp>
int main()
{
　　typedef std::map<std::string,int> Map;
　　Map anim{ {"bear",4}, {"cassowary",2}, {"tiger",7} };
　　BOOST_FOREACH (Map::value_type v, anim) {
　　　　std::cout << v.first << ':' << v.second << std::endl;
　　}

　　return 0;
}

結果
bear:4
cassowary:2
tiger:7

とりあえずN2672の例の1つが動くことを確認。そろそろautoが欲しいなー。

372:デフォルトの名無しさん
08/08/17 06:44:55
ダメだ。どうしても分からんから教えてくれ。
N2710のコンセプトのドラフト、
14.9.1.4
>A concept-definition that starts with auto defines an implicit concept, otherwise it defines an explicit concept.

implicitとexplicitで何が違うんだ？
あちらこちらによく分からない記述が散らばっているだけでさっぱり分からん。

373:372
08/08/17 07:49:49
自己解決
N2081に書いてあった。

374:デフォルトの名無しさん
08/08/24 03:54:18
>>342
それじゃ部分式の演算子関数呼び出しでコピーが発生するじゃない。

375:デフォルトの名無しさん
08/08/26 13:45:43
nullptr があっても printf() とか可変長引数にヌルポインタ渡す時のキャストが
要らなくなったりしないよね？

376:デフォルトの名無しさん
08/08/26 15:15:42
void*を渡すならいらない。

377:デフォルトの名無しさん
08/08/26 18:51:22
tyep safe な printf まーだー？

378:デフォルトの名無しさん
08/08/26 22:34:35
ばらでぃっくなアレを使うんじゃ

379:デフォルトの名無しさん
08/08/26 23:55:53
つboost::format

380:デフォルトの名無しさん
08/08/29 01:03:01
こんなの見つけたけど次回ってもう今日だな。
URLﾘﾝｸ(d.hatena.ne.jp)

381:デフォルトの名無しさん
08/08/29 09:18:07
2008-08 mailing (pre-San-Francisco)

382:デフォルトの名無しさん
08/08/29 09:34:19
細かい議論が多くて面白いですね

383:デフォルトの名無しさん
08/08/31 19:34:02
decltypeに関数を与えると関数を表す型じゃなくて関数の戻り値を表す型になるのか。
なんだか非直感的でやだな。

384:デフォルトの名無しさん
08/08/31 21:35:59
関数の型と言えばsignature

385:デフォルトの名無しさん
08/09/04 12:16:19
.>>383
decltypeのやっていることはsizeofとほとんど同じだからな。
むしろ、sizeofの型を返す版が欲しいっていう話だし。

386:デフォルトの名無しさん
08/09/04 13:35:48
typedef F decltype(f);
arity<F>::value; // 引数の数
result_of<F>::type ; // 戻り値の型
arg_types<F>::type ; //引数の型リスト

のようにできれば俺は満足ですよ

387:デフォルトの名無しさん
08/09/04 13:52:44
何か違和感があると思ったら一行目だ。
decltypeが型としての関数を返すものだったとしてもだ、順番が間違っているぞ。

388:デフォルトの名無しさん
08/09/04 14:09:52
typedef FROM TO;の順番なのに…
C++を使ってないのバレバレですね失礼しました

389:デフォルトの名無しさん
08/09/04 14:56:36
つusing TO = FROM;

390:デフォルトの名無しさん
08/09/04 15:54:11
383を見て、decltype(printf)がintになっちゃうのかと思った。

391:デフォルトの名無しさん
08/09/04 18:55:33
違うの？
decltype(printf)がint(*)(const char*,...)じゃなくてintになるから
非直感的で気持ち悪いって言ってるのかと思った
decltype(printf("..."))だったら当然intに決まってるし

383どういう意味？

392:デフォルトの名無しさん
08/09/04 19:09:39
関数呼び出しせずに関数名を渡したら関数の型になるんじゃないの？

393:デフォルトの名無しさん
08/09/04 19:17:41
当たり前。スルーで。

394:デフォルトの名無しさん
08/09/04 20:15:12
じゃ結局decltype(printf)は普通にint(*)(const char*,...)型なのね

395:デフォルトの名無しさん
08/09/04 20:22:28
いや、ポインタじゃないだろ？

396:デフォルトの名無しさん
08/09/04 20:22:58
当たり前。スルーで。

397:デフォルトの名無しさん
08/09/04 20:44:52
>>395
アホ？
C/C++の式にポインタじゃない関数型なんて存在しねえよ

398:デフォルトの名無しさん
08/09/04 20:51:58
存在しなかったら関数呼べないだろｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

399:デフォルトの名無しさん
08/09/04 20:56:59
関数呼び出し演算子のオペランドの規定読んでから出直してこい

400:デフォルトの名無しさん
08/09/04 21:21:28
ConceptGCC 4.3.0 alpha7 でテスト
#include <cstdio>
#include <typeinfo>
int main() {
std::puts(typeid(int(const char*,...)).name());
std::puts(typeid(int(*)(const char*,...)).name());
std::puts(typeid(std::printf).name());
std::puts(typeid(decltype(std::printf)).name());
}
結果
FiPKczE
PFiPKczE
FiPKczE
FiPKczE

401:デフォルトの名無しさん
08/09/04 21:28:00
>>397
坊やにはまだ早いよ。
C++03を学びなおしてきな。

402:デフォルトの名無しさん
08/09/04 21:34:35
えー？
関数型って&演算子のオペランド（結果は関数ポインタ）の場合しか存在しないんじゃないの？
関数ポインタには*演算子効かないから関数型って単独で取り出せないんじゃないの？
(**************printf)("...")とか書けるのは何なの？
()のオペランドって関数ポインタじゃないの？

わかんなくなってきた

403:デフォルトの名無しさん
08/09/04 21:36:41
>>402
スレチ

404:デフォルトの名無しさん
08/09/04 21:40:42
みんなが関数名と呼んでいるものは実は関数ポインタリテラルで、
関数ポインタというものは*や&付けても自分自身に戻る変な型で、
みんなが引数列と呼んでいる(...)は関数ポインタ（と多重定義したクラス）だけに作用する特別な演算子で
「関数」なるものはコンパイラの世界には存在しないんだよって

そう教わって信じてきたのにまさかC++に関数型が存在するなんて…
カルチャーショック

405:デフォルトの名無しさん
08/09/04 21:44:45
>>404
ポインタにはすべて「そのポインタが指す先の型」というものが概念的に存在する。
そういう型の変数が作れるかとか、そういう型のリテラルが書けるか、は別の問題。

406:デフォルトの名無しさん
08/09/04 21:45:41
まーC++の関数って、関数ポインタに特別な文法なしで代入できるし、
型としての関数なんて、テンプレートメタプログラミングでもしない限り扱わんし、
紛らわしいよな。

407:デフォルトの名無しさん
08/09/04 21:55:20
待て、やっぱり変だ

void foo(void(*)()){std::cout << "foo(void(*)())";}
void foo(void()){std::cout << "foo(void())";}

これ定義しようとしたら怒られたぞ（片方にするとどっちも通る）
つまりvoid(*)()とvoid()は同じ型ってことじゃないの

408:デフォルトの名無しさん
08/09/04 22:00:37
>>407
引数の型（というか、変数の型）としては関数ポインタしかあり得ない。
そういう場所に「関数」を書いた場合は「関数ポインタ」とみなす、という規則があるため、
結果的に同じ型の引数を取る関数を宣言しようとしたと解釈されエラーになる。

409:not 408
08/09/04 22:05:19
その引数の型矯正ルールが8.3.5.3な。
とりあえずC++0xはまだ早いんじゃないのかね?

410:デフォルトの名無しさん
08/09/04 22:13:35
1.処理系すらできてない規格に触るのなんてまだ早い
2.その程度の知識ならまずC++03の規格に一通り目を通してから、まだお前のような素人には早い

dotchi?

411:デフォルトの名無しさん
08/09/04 22:24:47
調べた

なんだ&とsizeofとtypeid（と多分decltypeも）のオペランドの中が特殊なだけで
その外では404の通りでいいんじゃん
関数型は出てきたそばから関数ポインタに変えられるから
&とsizeofとtypeid以外の世界にはやっぱり関数型は存在しないんだ
俺は大体合ってた

412:デフォルトの名無しさん
08/09/04 22:28:55
俺がこっそり望んでいたsealedは入りませんか？

このクラスは継承するなってソースにもドキュメントにも書いてあるのに
勝手に継承されてデストラクタ呼ばれないとか文句垂れられます

413:デフォルトの名無しさん
08/09/04 22:29:39
D&Eに継承の禁止の仕方載ってる

414:デフォルトの名無しさん
08/09/04 22:31:15
3.

415:デフォルトの名無しさん
08/09/04 23:19:54
>>411
boost::function<R(A)> とか boost::result_of<R(A)> とか見たこともないの？

416:デフォルトの名無しさん
08/09/04 23:22:47
>decltype
オーバーロードしてる関数の型ってのはやっぱ無理なのか
例えばstd::fabsを引数double xで呼び出したときの（戻り値ではなく）関数の型が分かると便利なんだけど

decltype( static_cast<decltype(x)(*)(decltype(x))>(std::fabs) )
てのは本末転倒な気がする

417:デフォルトの名無しさん
08/09/04 23:32:10
>>411
関数型をtypedefすると、
シグネチャが同じ関数を大量に宣言するときに便利だよｗ
typedef double F(double);
F sin,cos,tan,asin,acos,atan,…;
ってこれC言語だからC++0x関係ないな

418:デフォルトの名無しさん
08/09/05 01:45:31
>>415
function, result_ofはTR1にも入っていて、
C++0xにまんま入ることが決定済み。

419:デフォルトの名無しさん
08/09/05 06:33:58
sizeofは『式を評価して』その式の型のサイズを返す。
decltypeも『式を評価して』その式の型を返す。
だから関数を入れたらその関数が評価されて関数の戻り値の型が返るに決まっている。
どこも非直感的ではない。

420:デフォルトの名無しさん
08/09/05 08:42:21
>>419
×関数を入れたら
○関数呼び出しを入れたら

421:デフォルトの名無しさん
08/09/05 09:12:37
おいおい、"unevaluated operand"ってやつで、「評価」されないよ。
typeid, sizeof, decltypeの三つな。

422:デフォルトの名無しさん
08/09/05 13:12:11
仮に評価したときに返ってくるであろう型、と言うべきだね

423:デフォルトの名無しさん
08/09/05 14:42:50
つ「式の型」

424:デフォルトの名無しさん
08/09/05 18:25:23
なるほど、
int i = 0;
std::cout<<sizeof(i++)<<std::endl;
std::cout<<i<<std::endl; //prints 0
なわけね

>>416が気になるからage

425:デフォルトの名無しさん
08/09/05 18:28:06
ageてないｗ

426:デフォルトの名無しさん
08/09/05 19:16:48
平気で未定義になるような病的な式をsizeofの中に閉じこめたりするのは
TMPではよくやることだな

427:デフォルトの名無しさん
08/09/05 21:21:04
sizeof(0 / 0) は警告が出るな＠gcc

428:デフォルトの名無しさん
08/09/05 21:57:58
0除算だからな

429:デフォルトの名無しさん
08/09/05 22:35:53
昔のコンパイラってTMPで0除算したら落ちたりしてたんだろうか
今でもboost vaultにあるキワモノ(例:eggとかphoenix)使ってたらエラー時に落ちるものは結構あるようだけど

430:デフォルトの名無しさん
08/09/05 23:39:59
>>418
？？？そんなことは百も承知だが
関数型がテンプレートの引数一つで取り扱える例を出しただけ

そういや、boost::function は昔は <R, A1, A2> みたいに書いてたころも
あったけな

431:デフォルトの名無しさん
08/09/06 10:22:30
自意識過剰の変な奴…

432:デフォルトの名無しさん
08/09/06 13:36:46
美少女中学生スレたるこのスレにはふさわしくないな

433:デフォルトの名無しさん
08/09/06 13:45:09
美少女中学生の話は↓でやれ。ここでするな。
ｽﾚﾘﾝｸ(tech板)

434:デフォルトの名無しさん
08/09/12 19:27:25
0xの可変個引数テンプレートがDのそれとよく似てるけど、どっちが先なのかな？
それとももっと古くからあった？

435:デフォルトの名無しさん
08/09/12 20:49:36
>>434
va_argって知らないの?

436:デフォルトの名無しさん
08/09/12 20:55:47
>>434
先に実装したのはDだが、発想自体は別に新しいものじゃないだろ

437:デフォルトの名無しさん
08/09/12 21:22:38
>>435
可変個引数関数のことを言ってるんじゃないよ
>>436
そうなのか。作ったタプルを転送して展開して…とか初めて見たとき、何じゃこりゃすげぇと思ったんだけどな～

438:デフォルトの名無しさん
08/09/12 21:24:06
C++0xを使いこなせる自信がない。
無理だろあんなもの。疲れるだけ。

439:デフォルトの名無しさん
08/09/12 21:27:23
大丈夫、苦労するのはライブラリ実装者だけだから

440:デフォルトの名無しさん
08/09/12 21:31:14
>>437
> 何じゃこりゃすげぇと思ったんだけどな～

かわいいねえ。

441:デフォルトの名無しさん
08/09/12 22:53:23
美少女中学生がいるな・・・

442:デフォルトの名無しさん
08/09/12 23:35:28
auto以外は普通の利用者には関係ないね

次ページ