C++0x

1 名前：デフォルトの名無しさん [2006/06/05(月) 02:04:07 ] どんな感じになるの？ 321 名前：デフォルトの名無しさん mailto:sage [2007/03/05(月) 09:26:00 ] containerの場合は、>>310のcbegin()で、今のところwファイナルアンサーです。 出典は、www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1865.pdf 二バージョンないケースでは、何か工夫する必要があるね。 322 名前：デフォルトの名無しさん mailto:sage [2007/03/05(月) 10:13:24 ] 一文字の接頭辞が複数続くのってなんかいやん crend とかなにって感じー 323 名前：デフォルトの名無しさん mailto:sage [2007/03/07(水) 00:05:13 ] 何だかんだで、const auto& cv(v); してから、cv.begin(), cv.end() が一番読みやすいかも 324 名前：デフォルトの名無しさん mailto:sage [2007/03/07(水) 16:48:34 ] 数学の関数とかみたいに コンパイル時に式自体 を計算・展開できるような式関数導入して欲しい。 325 名前：デフォルトの名無しさん mailto:sage [2007/03/07(水) 18:43:00 ] 実装も添えて提案して頂かないとイメージが沸かない 326 名前：デフォルトの名無しさん mailto:sage [2007/03/07(水) 20:01:57 ] >>324 つまり int a = 5+1; は、コンパイラが int a = 6; としてコードを生成してくれるってことか。 inline int func(int x) { return x*2; } int c = func(5); をコンパイラが int c = 10; にしてくれるとか。 sinはコンパイラではなくコンパイル後に リンクするライブラリにある処理だから難しいな。 LUTを作るの面倒だから判らなくもない。 327 名前：デフォルトの名無しさん mailto:sage [2007/03/07(水) 20:07:41 ] 今時のコンパイラならそのくらいは最適化の範囲内でやるだろ。 328 名前：デフォルトの名無しさん mailto:sage [2007/03/07(水) 20:43:12 ] >>326 少なくとも 5+1 を 6 にするほうは、コンパイラは必ずやらなければならない(must)と 規定されている。インライン関数のほうもほとんどのコンパイラがやると思う。 329 名前：デフォルトの名無しさん mailto:sage [2007/03/07(水) 23:01:37 ] がんばってtemplateでsinを実装するんだ(w 330 名前：デフォルトの名無しさん mailto:sage [2007/03/07(水) 23:04:59 ] 整数演算だけでか？ｗ 331 名前：デフォルトの名無しさん mailto:sage [2007/03/07(水) 23:15:43 ] 前に、どこかのスレで、nontype templateのメタプログラミングで、浮動小数点数を実装したという猛者がいた気がする。 332 名前：デフォルトの名無しさん mailto:sage [2007/03/07(水) 23:26:01 ] コンパイル時変数と実行時変数を明示的に区別して定義できるようにならないかなあ。 いっそのことプログラムの実行そのものをコンパイル時と実行時で分けて、 コンパイル時実行ではインタプリタ型で動いて、コンパイル時変数にのみアクセス可能で JavaScriptばりにクラスのメンバ関数の追加や削除、関数の構成、evalができて、とか。 333 名前：デフォルトの名無しさん mailto:sage [2007/03/07(水) 23:29:13 ] D 言語でいいよ、もう。 334 名前：324 [2007/03/08(木) 00:03:20 ] 同様にmy_cos,my_tanを作って my_tan:=my_sin/my_cos; という関係を作っておく。 my_sin(x)/my_cos(x)という式を使ったときは左記の関数はCallされずに my_tan(x)がCallされて計算されるといった感じのもの。 //いいかげんなmy_sinの例 template <typename T> T my_sin(T x) where Type(T,Re) //T：実数 { calc{return x(1-x*x/6);}//計算値 expr(T a){my_sin(a);}//計算式 } 335 名前：デフォルトの名無しさん mailto:sage [2007/03/08(木) 00:05:30 ] スクリプトでも使ってジェネレートした方がはやくね？ 336 名前：デフォルトの名無しさん mailto:sage [2007/03/08(木) 00:40:01 ] プリプロセッサ強化だな。 337 名前：デフォルトの名無しさん mailto:sage [2007/03/08(木) 01:35:03 ] ttp://video.google.com/videoplay?docid=-1790714981047186825 コンセプト今まで知らなかったけれど、かなりよさそう。 コンパイル時間が気になるけれど。 338 名前：デフォルトの名無しさん mailto:sage [2007/03/08(木) 09:01:29 ] templateの処理をプリプロセッサの役割とする ↓ Cでもtemplateできるようにする。 339 名前：デフォルトの名無しさん mailto:sage [2007/03/08(木) 09:50:31 ] Cfrontみたいだな 340 名前：デフォルトの名無しさん mailto:sage [2007/03/08(木) 11:46:16 ] もう終わった言語なんだから、なるべく互換性保持に努めてくれたまえ　 341 名前：デフォルトの名無しさん mailto:sage [2007/03/08(木) 16:12:16 ] >>340 「バカヤロウ、まだ始まってもいねえよ。」 342 名前：デフォルトの名無しさん mailto:sage [2007/03/08(木) 16:34:10 ] 互換性はあるんじゃないか？今までのが非推奨になる感じで 343 名前：デフォルトの名無しさん mailto:sage [2007/03/08(木) 16:35:46 ] old style cast とかどうするんだろ 344 名前：デフォルトの名無しさん mailto:sage [2007/03/08(木) 18:25:58 ] >>324 再帰はできないわ，まともな制御構文はないわ，で良ければ一応 C++0x に向けて active に動いているっぽい提案 www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2116.pdf いずれにしろ，元々が traits などに使われるのを想定した提案ですので非力極まりない もっと抜本的な提案なら www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1471.pdf ですけれど，こちらは C++0x には間に合わない様子 345 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 20:34:06 ] C++0a になりそうな気配が濃厚になってまいりました 346 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 00:49:43 ] C++0x2010でいいからもう 347 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 23:22:40 ] それは勘弁してw 348 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 00:23:13 ] C+(+0x2010) → 0x201C いや、わかっているよ、こう解釈されないことくらい。 349 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 15:02:28 ] >>346 8208www 350 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 18:39:26 ] C++2008 351 名前：デフォルトの名無しさん mailto:sage [2007/03/28(水) 02:06:06 ] 可変個引数テンプレート(Variadic Templates)だけど、template の specialization を使って一つづつ取り出していくだけかと思ったらなかなかすごいことになってるのね。 こんな展開が可能だったり、 --- template<typename...> struct Tuple {}; template<typename T1, typename T2> struct Pair {}; template<typename... Args1> struct zip {   template<typename... Args2> struct with {     typedef Tuple<Pair<Args1, Args2>...> type;  }; }; typedef zip<short, int>::with<unsigned short, unsigned>::type T1;　// T1 is Tuple<Pair<short, unsigned short>, Pair<int, unsigned> > --- これで任意引数個の perfect forwarding function になったり(rvalue reference利用) --- template<typename T> struct allocator {   template<typename... Args>   void construct(T* ptr, Args&&... args) { new (ptr)(static cast<Args&&>(args)...); } }; --- Variadic Templates の概要は↓がわかりやすい www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2080.pdf ↓は規格の変更点について www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2152.pdf GCC 4.3 の experimental c++0x mode で、また ConceptGCC では >217 で机上の空論と書かれていた rvalue reference、さらに decltype とともに実装されたそうで。 conceptgcc.wordpress.com/2007/02/15/decltype-and-rvalue-references-and-variadic-templates-oh-my/ おまいらもヒトバシラーしてみませんか？ 352 名前：デフォルトの名無しさん mailto:sage [2007/03/28(水) 08:47:26 ] Variadic Templates、入るかねえ? 353 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 22:08:44 ] >352 何か具体的な懸念が？ 提案者自身は >Variadic templates seem to be moving smoothly, と言ってるけどね。 ttp://conceptgcc.wordpress.com/2007/02/15/decltype-and-rvalue-references-and-variadic-templates-oh-my/#comment-131 354 名前：デフォルトの名無しさん mailto:sage [2007/04/12(木) 07:04:47 ] www.devsource.com/article2/0,1895,2061095,00.asp によれば、template aliases が入ることになっているなあ。嬉しい。 355 名前：デフォルトの名無しさん mailto:sage [2007/04/16(月) 20:57:47 ] nameof(type) とか nameof(value) で型名のリテラルが取れたら便利だと思うんだけど そういうのはないんかな 356 名前：デフォルトの名無しさん mailto:sage [2007/04/16(月) 21:18:55 ] #define nameof(x) typeid(x).name() 357 名前：デフォルトの名無しさん mailto:sage [2007/04/16(月) 21:21:15 ] typeid(hoge).name()があるでしょ。 マングルされてたりいろいろ面倒だけど。 358 名前：デフォルトの名無しさん mailto:sage [2007/04/16(月) 22:08:34 ] typeid().name()は正直使えない 359 名前：デフォルトの名無しさん mailto:sage [2007/04/16(月) 22:13:47 ] まあ保証されている事と言えば同一の型のname()も同一である という事だけだからな リフレクションのような事は正直無理 360 名前：デフォルトの名無しさん mailto:sage [2007/04/27(金) 00:24:43 ] >352 ttp://conceptgcc.wordpress.com/2007/04/24/variadic-templates-are-in-c0x/ だそうな。 361 名前：デフォルトの名無しさん mailto:sage [2007/04/27(金) 07:28:21 ] まじか。 機能的にはC++0xに入る必然性があるけれど、 さらにデバックしにくくなりそう… variadic templatesを直接使う人じゃなくて、 variadic templatesが使われたlibraryを使う人ね。 エラーメッセージがさらにハナモゲラ化w 362 名前：デフォルトの名無しさん mailto:sage [2007/04/27(金) 12:49:13 ] >>361 現状でも Boost.Function とか Boost.Variant とか BOOST__PP_* で T0,T1,T2,... を生成してるやつは エラーメッセージがハナモゲラ化してるわけで その部分が T0... みたいに可変長ぽく省略表示されるだけで だいぶ見やすくなると思うんだが 363 名前：デフォルトの名無しさん mailto:sage [2007/05/14(月) 14:22:20 ] concept が入ればエラーメッセージはかなりましになるのでは？ 364 名前：デフォルトの名無しさん mailto:sage [2007/05/14(月) 14:24:15 ] www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/#mailing2007-05 365 名前：デフォルトの名無しさん mailto:age [2007/05/28(月) 01:09:30 ] ほ 366 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 00:47:25 ] とりあえずC99準拠で 367 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 01:59:00 ] C99はC++の精神に反しているのに 実装にはC++の機能が必要というトンデモ言語 368 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 03:13:42 ] C++の精神自体がトンデモの塊だから問題ない 369 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 06:35:41 ] Javaのキャストみたいなもんだな 370 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 06:43:51 ] c99にc++の機能が必要とは初耳だな。 371 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 06:56:08 ] コードに1000個のバイナリを埋め込む行為自体に問題があるとは思わないかね？ 372 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 07:09:44 ] 内容的には>>360>>364で既出ですが、herbsutter.spaces.live.com/より New Language Features Voted Into (Draft) C++09 ・Template aliases (aka typedef templates, generalized typedefs) [N2258] ・Variadic templates (aka "type varargs" for templates) [N2242; see N2087 for a more readable description and rationale] ・Unicode characters and strings [N2249] ・Rvalue references [N1952] 373 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 16:54:12 ] へー、N2249入るかもしれないんだ。 とうとうC++の世界でも明示的にユニコード文字列が扱えるようになるのか。 374 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 17:46:31 ] すると現実の実装では、事実上wchar_tがchar16_tまたはchar32_tと同じ大きさを持つ型 （当然整数型とwchar_tのようにtypedefではない）という扱いになるんだろうなと思う。 375 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 19:57:46 ] これですな ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2249.html そのうちstd::u16stringとかstd::u32stringとかもできるんだろか 376 名前：373 mailto:sage [2007/06/01(金) 00:57:02 ] 入るかもしれないじゃないや。もう最新のドラフトに入ってるわ。 377 名前：デフォルトの名無しさん [2007/06/01(金) 01:12:11 ] L"文字列" はどういう扱いになるん？ 378 名前：デフォルトの名無しさん mailto:sage [2007/06/01(金) 01:36:05 ] こんな感じかな？ wchar_t wc = L'あ';　// wcの値は実装依存 (今と同じ) char16_t c16 = u'あ';　// c16は0x3042 char32_t c32 = U'あ';　// c32は0x00003042 379 名前：デフォルトの名無しさん mailto:sage [2007/06/01(金) 01:39:40 ] UTF-8 は使えないの？ UTF-16BE と UTF-16LE （32も）の選択は環境依存？ 380 名前：デフォルトの名無しさん mailto:sage [2007/06/01(金) 01:40:47 ] あ、BE と LE はこのレベルでは関係ないか？ 実用上面倒くさい事になりそうな気はするが。 381 名前：デフォルトの名無しさん mailto:sage [2007/06/01(金) 01:44:07 ] UTF-8の型も用意するか、逆にUTF-32だけにするか してほしい気もする 382 名前：デフォルトの名無しさん mailto:sage [2007/06/01(金) 08:22:04 ] >>379 UTF-8は、 ・ソースコードで使って、処理系が変換。例えばU'A'などを。(規格外) ・今後Unicode系mbsライブラリが充実させる。 って感じなんじゃないの? 383 名前：デフォルトの名無しさん mailto:sage [2007/06/01(金) 08:22:49 ] >>376 もう規格の外に出ることはないでしょ。修正が入るだけで。 384 名前：デフォルトの名無しさん mailto:sage [2007/06/01(金) 08:35:43 ] 下地になったCのn1040には、utf-8はchar型を使ってどうのこうのって 書いてあるけど、charはビット数を保証してないよなあ 385 名前：デフォルトの名無しさん mailto:sage [2007/06/01(金) 09:07:21 ] uint8_tと読み直せばいいんじゃない。 386 名前：デフォルトの名無しさん mailto:sage [2007/06/01(金) 09:09:30 ] uint8_t って optional だったよね。 387 名前：デフォルトの名無しさん mailto:sage [2007/06/01(金) 13:30:21 ] 何年か経ったらwchar_tはいらない子扱いされてそうだ 388 名前：デフォルトの名無しさん mailto:sage [2007/06/01(金) 15:19:52 ] tcharでいいじゃん 389 名前：デフォルトの名無しさん mailto:sage [2007/06/01(金) 16:02:57 ] >>387 Unicode依存コードじゃなければ、wchar_t推奨でしょ。 >>384 char8_tのドラフトを書けw 390 名前：デフォルトの名無しさん mailto:sage [2007/06/01(金) 16:43:08 ] >>386 つuint_least8_t ちなみにchar16/32_tはそれぞれuint_least16/32_tと同じ大きさと規定される>>375 391 名前：デフォルトの名無しさん mailto:sage [2007/06/01(金) 17:00:04 ] どうせウニコードなんか窓しか使わないのにイラネ 392 名前：デフォルトの名無しさん mailto:sage [2007/06/01(金) 17:05:18 ] >>389 何年か経ってもUnicodeでないOSが残ってるかどうかｗ 393 名前：デフォルトの名無しさん mailto:sage [2007/06/01(金) 17:14:12 ] LinuxもUTF-8なご時世になんて寝言を…… 394 名前：デフォルトの名無しさん mailto:sage [2007/06/01(金) 17:43:00 ] ふつーにEUC 395 名前：デフォルトの名無しさん mailto:sage [2007/06/01(金) 18:46:06 ] Unicode関連のロケールが標準に入ると考えていいんだろうか・・ 396 名前：デフォルトの名無しさん mailto:sage [2007/06/01(金) 20:20:04 ] CHAR_BIT >= 8 だから、UTF-8 は char を使ったんで別にいいんでない？ 397 名前：デフォルトの名無しさん mailto:sage [2007/06/01(金) 20:53:50 ] 8は保証されてるの？ 398 名前：デフォルトの名無しさん mailto:sage [2007/06/01(金) 21:14:54 ] 下限が 8 なのは保証されている。 別に 9 だろうが 16 だろうが問題ないが、7 とかはない。 399 名前：デフォルトの名無しさん mailto:sage [2007/06/02(土) 11:33:29 ] 世の中のプログラマのほとんどが >どうせウニコードなんか窓しか使わないのにイラネ と思っていたはずなのに >LinuxもUTF-8なご時世になんて寝言を…… になってしまったのはいつから？なぜ？ 400 名前：デフォルトの名無しさん mailto:sage [2007/06/02(土) 11:43:17 ] >>399 いつからかは知らんが、そうでもせんとまともな国際化対応できんだろうが。 401 名前：デフォルトの名無しさん mailto:sage [2007/06/02(土) 11:44:01 ] そんなこと思ってもいませんでしたよ。 今も昔もUnicode onlyは早計すぎると思っているだけ。 なんだかんだ言ってもUnicode周辺には、 "Technical Notes", "Technical Reports"その他に、 ノウハウがたまってきているので、強力にサポートすべき。 wchar_tの実装をUnicode onlyにするなんてのには大反対。 n2249はGJ。 402 名前：デフォルトの名無しさん mailto:sage [2007/06/02(土) 11:55:15 ] じゃぁ、wchar_t はTRON用ということでおｋ？ 403 名前：デフォルトの名無しさん mailto:sage [2007/06/02(土) 12:29:48 ] TRONはwwchar_tです。 404 名前：デフォルトの名無しさん mailto:sage [2007/06/02(土) 13:10:56 ] でも、Windows は UTF-16 なんだよな？ 405 名前：デフォルトの名無しさん mailto:sage [2007/06/02(土) 13:31:23 ] >>404 Windows のは WCHAR であってその実装は wchar_t とは限らず unsigned short int の場合なんかもある。 406 名前：デフォルトの名無しさん mailto:sage [2007/06/02(土) 13:41:47 ] どちらにしろ UTF-16 だろ？ 407 名前：デフォルトの名無しさん mailto:sage [2007/06/02(土) 15:39:01 ] つWM_UNICHAR msdn2.microsoft.com/en-us/library/ms646288.aspx 408 名前：デフォルトの名無しさん mailto:sage [2007/06/02(土) 18:51:20 ] char(16|32)_t用の関連関数のドラフトはc++0xに間に合うのかねえ。 is系とかprintfとかfacetとか、結構ありそうだが。 409 名前：デフォルトの名無しさん mailto:sage [2007/06/02(土) 19:15:39 ] C95みたいに後から追補出せばいいよ 410 名前：デフォルトの名無しさん mailto:sage [2007/06/02(土) 19:44:42 ] streamやfacetsは対応しないみたい ttp://www2.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2238.html あとUTF-8の案もあった 今のところWDには含められていないけど ttp://www2.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2209.html プリフィックスは E で、1バイト8ビット以上を保証すると 411 名前：デフォルトの名無しさん mailto:sage [2007/06/02(土) 21:41:23 ] >streams of non-char types have not attracted wide usage, so it is not clear >that there is a real need for う〜ん…8bit圏の人にとっちゃそうかもしれんけどさ。 412 名前：デフォルトの名無しさん mailto:sage [2007/06/02(土) 22:39:06 ] まあその辺はゆっくりやって、後から補完でいいんじゃないの? Primitive typeとして導入されたわけだから、 いろいろ実装してみるための最低限のことは決まるわけだからさ。 typedefやマクロに比べて出きることが多すぎるから、慎重になるんでしょ。 413 名前：デフォルトの名無しさん mailto:sage [2007/06/02(土) 22:59:52 ] Windows が UTF-16 だし、 デフォで UTF-16 が扱えるなら そういう意味であちらさんにも価値はあるように思うんだけどな。 414 名前：デフォルトの名無しさん mailto:sage [2007/06/02(土) 23:14:12 ] WCHARあるからねー 415 名前：デフォルトの名無しさん mailto:sage [2007/06/03(日) 00:28:53 ] >>413 意味が分からない。 どれに対するレス? 416 名前：デフォルトの名無しさん mailto:sage [2007/06/03(日) 00:29:10 ] Windowsなんかうんこ 417 名前：デフォルトの名無しさん mailto:sage [2007/06/03(日) 00:29:51 ] >>415 >>411 418 名前：デフォルトの名無しさん mailto:sage [2007/06/03(日) 00:35:57 ] char16_tやchar32_tのストリームを実装するとしたら 現状のワイド文字ストリームのようにマルチバイトに／へ変換するようなもんだと思ったんだが 419 名前：デフォルトの名無しさん mailto:sage [2007/06/03(日) 00:35:59 ] それはWindowsにはニュートラルな話。 420 名前：デフォルトの名無しさん mailto:sage [2007/06/03(日) 00:37:38 ] Windowsとか持ち出してるのはただの馬鹿だろ 421 名前：デフォルトの名無しさん mailto:sage [2007/06/03(日) 00:46:50 ] >>418 wifstream, wcin辺りができたばかりだし、 char16_tなら、ほとんどの処理系は(sizeof(wchar_t)>2だろうから )codecvtでなんとかなるし、 char16ifstreamとかchar16cinとか乱発する前に、ちょっと考えてみるだけでしょ。 急いで、うんこライブラリを標準に入れるわけにいかないし。

---

---

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

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