C++0x

1 名前：デフォルトの名無しさん [2006/06/05(月) 02:04:07 ] どんな感じになるの？ 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とか乱発する前に、ちょっと考えてみるだけでしょ。 急いで、うんこライブラリを標準に入れるわけにいかないし。 422 名前：デフォルトの名無しさん mailto:sage [2007/06/03(日) 00:56:23 ] GCC だと wchar_t は 4 だったな。 423 名前：デフォルトの名無しさん mailto:sage [2007/06/03(日) 01:00:45 ] >>422 現在ではプラットフォーム依存。たとえば Cygwin の wchar_t は2バイト。 あと、-fshort-wchar なんてオプションもあるので、gccだからという判定は危険。 424 名前：デフォルトの名無しさん mailto:sage [2007/06/03(日) 01:27:10 ] char16_t, char32_tの入った処理系では、 typedef char16_t wchar_t か、typedef char32_t wchar_t で、 wchar_tなライブラリも使えるし、char*_tなライブラリも構築していけるし、 とりえあえずは問題ないんじゃない? >>423 utf-32が扱える処理系では、 wchar_tが2 byteだと規格違反だけどね。 >Type wchar_t is a distinct type whose values can represent distinct codes for all members >of the largest extended character set specified among the supported locales (22.1.1). 425 名前：デフォルトの名無しさん mailto:sage [2007/06/03(日) 01:32:30 ] なるほど。その環境で扱える最大の文字セットも格納できる事が必要なんだ。 426 名前：デフォルトの名無しさん mailto:sage [2007/06/03(日) 02:03:02 ] wchar_tがUnicodeじゃない処理系ってあるのかな？ 427 名前：デフォルトの名無しさん mailto:sage [2007/06/03(日) 02:10:30 ] >>426 *BSDやSolarisのi18nフレームワークがそうなんじゃないの? 428 名前：デフォルトの名無しさん mailto:sage [2007/06/03(日) 04:26:58 ] GCC 4.3にC++0xの実験的サポート gcc.gnu.org/gcc-4.3/cxx0x_status.html 429 名前：デフォルトの名無しさん mailto:sage [2007/06/03(日) 04:55:14 ] >>428 ﾜｸﾜｸﾃｶﾃｶしつつDLしてregexを見てみた。 @todo Implement this function. @todo Document this function. だらけだった。 430 名前：デフォルトの名無しさん mailto:sage [2007/06/03(日) 05:36:10 ] w 431 名前：デフォルトの名無しさん mailto:sage [2007/06/04(月) 22:53:08 ] MSも試験実装すればいいのに。 Cの_s系関数はフライングで取り入れたんだから。 432 名前：デフォルトの名無しさん mailto:sage [2007/06/05(火) 01:37:14 ] C#.NET以外は捨てなんだろう C++/CLIは後方互換性だけなんだろうし。 433 名前：デフォルトの名無しさん [2007/06/05(火) 22:01:36 ] 久しぶりにスレ伸びたな〜 434 名前：デフォルトの名無しさん mailto:sage [2007/06/05(火) 23:26:19 ] まあ全部俺の一人芝居なんだけどな 435 名前：デフォルトの名無しさん mailto:sage [2007/06/06(水) 01:57:38 ] 同感 436 名前：デフォルトの名無しさん mailto:sage [2007/06/06(水) 10:51:13 ] 全部俺の独り芝居だったら同感って思う必要も無かったかな、とちょっと反省してみた。 437 名前：デフォルトの名無しさん mailto:sage [2007/06/06(水) 12:41:13 ] それがまさに独り芝居というものでは？ 438 名前：デフォルトの名無しさん mailto:sage [2007/06/06(水) 13:20:54 ] 自問自答++ 439 名前：デフォルトの名無しさん mailto:sage [2007/06/06(水) 14:47:48 ] そうか、僕はここにいてもいいんだ！ 440 名前：デフォルトの名無しさん mailto:sage [2007/06/06(水) 16:22:24 ] おめでとう 441 名前：デフォルトの名無しさん mailto:sage [2007/06/06(水) 16:54:37 ] >>431-432 まあでもC++0xに全く無関心でない様子は伺える blogs.msdn.com/vcblog/archive/2007/06/04/update-on-the-c-0x-language-standard.aspx 442 名前：デフォルトの名無しさん mailto:sage [2007/06/06(水) 17:40:42 ] そりゃSC22/WG21の中の人たちがやっているからなあ。 VC++はC++/CLIオンリーじゃないし。 443 名前：デフォルトの名無しさん mailto:sage [2007/06/06(水) 17:56:40 ] struct S { 　　int m; }; sizeof(S::m) これが規格外だったなんて知らなかった。 そういえばこれは合法になるのかな？ template < typename T > class Foo { 　　friend T ; } 444 名前：デフォルトの名無しさん mailto:sage [2007/06/06(水) 18:38:36 ] >>443 nondirivableかなんかで話題にあがったが、確か違法だったと思う 445 名前：デフォルトの名無しさん mailto:sage [2007/06/06(水) 18:48:08 ] いや、C++0xではどうなるかという話なんだけど。 446 名前：デフォルトの名無しさん mailto:sage [2007/06/06(水) 22:03:04 ] friend のはこれ？ (PDF) www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1791.pdf 447 名前：デフォルトの名無しさん mailto:sage [2007/06/07(木) 03:54:58 ] 443の上は通らないけど下が普通に通る… マジ意味不明 しかもなまじ役に立ちそうなのが一層もどかしさを増幅させる 448 名前：デフォルトの名無しさん mailto:sage [2007/06/07(木) 05:25:03 ] sizeof(S().m)みたいに一時インスタンス化すればおｋ？ 449 名前：デフォルトの名無しさん mailto:sage [2007/06/08(金) 12:09:52 ] OKでしょ。 450 名前：デフォルトの名無しさん mailto:sage [2007/06/17(日) 22:03:19 ] ところで、wchar_tとい不細工なネーミングは、 どうにかならんのかね。 short charとか、long charとかの方が自然だ ろうし、文法上追加の余地はあるだろうに。 451 名前：デフォルトの名無しさん mailto:sage [2007/06/17(日) 22:07:28 ] いっそUnicode str;を入れようぜ 452 名前：デフォルトの名無しさん mailto:sage [2007/06/17(日) 22:57:31 ] >>450 少なくとも極自然なネーミングなんだがね。 これが極自然なネーミングだとお前が思えないなら それはお前が勉強不足で且つ経験不足なお子ちゃまってだけな話だ。 453 名前：デフォルトの名無しさん mailto:sage [2007/06/17(日) 22:58:22 ] >>451 そんな既存のソースコードと衝突しそうな新しい予約語は却下 454 名前：デフォルトの名無しさん mailto:sage [2007/06/17(日) 23:00:08 ] じゃ、_Unicode str; えーい、いっそのことソースコードもUTF8強制して 文字 str = L"こんちには世界"; って書けるようにしようぜ？ 455 名前：デフォルトの名無しさん mailto:sage [2007/06/17(日) 23:23:48 ] まあでも始めからCにワイド文字型が組込型として存在したら、 単にwcharという名前になっていたとは思う 456 名前：デフォルトの名無しさん mailto:sage [2007/06/17(日) 23:30:08 ] >>455 俺はむしろいっそのこと、int_t, double_t, char_t てなネーミングで 統一されてたほうがよかったんじゃねぇかとすら思うけどなぁ。 457 名前：デフォルトの名無しさん mailto:sage [2007/06/17(日) 23:34:21 ] ワイドな文字ってよく考えると意味不明だよね

---

---

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

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