C++0x 2

1 名前：デフォルトの名無しさん mailto:sage [2007/10/08(月) 20:29:11 ] The C++ Standards Committee ttp://www.open-std.org/jtc1/sc22/wg21/ 前スレ pc11.2ch.net/test/read.cgi/tech/1149440647/ 666 名前：デフォルトの名無しさん mailto:sage [2008/01/06(日) 19:33:16 ] つか今更だがthreadすげえな。 何がすげえって、今までライブラリなりがガリガリ実装してたものを 言語が仕様だけ定めてあと実装はベンダに丸投げってその思想がすばらしい。 その手があったか、ってｗ 667 名前：デフォルトの名無しさん mailto:sage [2008/01/06(日) 19:35:38 ] >>666 意味不明。ベンダとかライブラリって具体的には何をイメージしてる？ 668 名前：デフォルトの名無しさん mailto:sage [2008/01/06(日) 22:12:07 ] 言わせとけよ いちいち突っ込んでスレを荒らすな 669 名前：デフォルトの名無しさん mailto:sage [2008/01/07(月) 02:01:59 ] ついでに言うと、threadに限ったことではないだろ、それ。 670 名前：デフォルトの名無しさん mailto:sage [2008/01/07(月) 11:56:29 ] C/C++自体が環境依存って言うことも無きにしも非ず。 671 名前：デフォルトの名無しさん mailto:sage [2008/01/07(月) 15:31:36 ] 今の環境（CPUとかOS）はほとんどC/C++と整合するように作られてるな。 昔のメインフレームはワードアドレスマシンとかあって整合性が悪そうだ。 672 名前：デフォルトの名無しさん mailto:sage [2008/01/07(月) 16:16:34 ] ほほぉ、CがPDP-11用に作られたと言う事実は無視かね。 673 名前：デフォルトの名無しさん mailto:sage [2008/01/07(月) 16:47:53 ] 知識自慢はよそでお願いしますよ・・・ 674 名前：デフォルトの名無しさん mailto:sage [2008/01/07(月) 16:54:43 ] そうだね、頭の足りていない>671はさておき、>672はスルーすべきだったね。 つーことで、>671-674 はまとめてスレ違い。 675 名前：デフォルトの名無しさん [2008/01/07(月) 17:47:35 ] ｶﾞﾍﾞｺﾚは本当に入るのでしょうか？ ｶﾞﾍﾞｺﾚ対象となるクラスはまた特別な クラスから継承しなければならないとか？ 676 名前：デフォルトの名無しさん mailto:sage [2008/01/07(月) 18:01:55 ] どっちにしても、何も特別なことをしなければGC対象にはならないから安心汁 677 名前：デフォルトの名無しさん [2008/01/07(月) 19:04:43 ] ｶﾞﾍﾞｺﾚｷﾀｺﾚ 678 名前：デフォルトの名無しさん mailto:sage [2008/01/07(月) 20:36:18 ] ガベコレくるの？ ユニークカウンタ（俺語です。）で処理すんの面倒なんでぜひ入ってほしい。 679 名前：デフォルトの名無しさん mailto:sage [2008/01/07(月) 21:25:38 ] 使うかどうかは選べるんだから、(typeinfoのように) とりあえず実装非依存な形で仕様に出来るかどうか研究して頂けると嬉しい。 680 名前：デフォルトの名無しさん mailto:sage [2008/01/07(月) 22:50:53 ] n2310をチラっと読んでみたけど新しいキーワード導入しすぎでしょ これは当分入らないと思う ちゃんと読めばそんなことない？ 681 名前：デフォルトの名無しさん mailto:sage [2008/01/07(月) 23:03:33 ] 以前ハゲの人が提案してた #scope #endscope みたいなのは入るのかな 682 名前：デフォルトの名無しさん mailto:sage [2008/01/08(火) 00:25:58 ] それ{}が打てない地域用？ 683 名前：デフォルトの名無しさん mailto:sage [2008/01/08(火) 03:53:57 ] >>682 トライグラフだっけ？それじゃだめなのか？ 684 名前：デフォルトの名無しさん mailto:sage [2008/01/08(火) 03:56:34 ] もうそろそろプリプロセッサには退場してもらいたい #includeだけでいいよ 685 名前：デフォルトの名無しさん mailto:sage [2008/01/08(火) 05:57:58 ] >>684 ifdefが無いとassertもできなくね？ ifdefなんて無いに越したことはないが、必要な部分はあると思うんだが。 686 名前：デフォルトの名無しさん mailto:sage [2008/01/08(火) 06:36:36 ] 今更プリプロセッサ廃止したらBoost.Preprocessor使いまくりの俺のコードが全滅する 687 名前：デフォルトの名無しさん mailto:sage [2008/01/08(火) 07:20:11 ] >>681 プリプロセッサ用のスコープか？ 688 名前：デフォルトの名無しさん mailto:sage [2008/01/08(火) 07:37:11 ] 世界はプリプロセッサで出来ている 689 名前：デフォルトの名無しさん mailto:sage [2008/01/08(火) 11:05:07 ] >>687 そうマクロを制限する。 scope外のマクロ全部無効になって、 scope内のマクロはscopeの外に定義が出ない。 ただし必要なものだけimport/exportできる。 #undefよりはスマートに書けるが、 泥縄的だから標準には入らないと思う。 namescapeを導入した時に、マクロ名も識別子と同様、 namespaceに入ることにしたら良かったんじゃないか。 690 名前：デフォルトの名無しさん mailto:sage [2008/01/08(火) 12:56:03 ] まあ「プリプロセッサ」である限り使い勝手は悪いわな。プリプロセッサを廃止して必要な機能を 言語側でちゃんと実装すべきだと思うが、そうするともう C++ とは呼べないだろう。 691 名前：デフォルトの名無しさん mailto:sage [2008/01/08(火) 12:58:26 ] >>689 コンパイルフェーズでプリプロセッサが分かれているんだから、 namespace を解釈させるってのは難しいだろうね。 692 名前：デフォルトの名無しさん mailto:sage [2008/01/08(火) 13:14:29 ] なーんちゃってプリプリー 693 名前：デフォルトの名無しさん [2008/01/08(火) 13:56:07 ] でもさ，プリプロセッサのおかげで あんなことやこんな変態プレイができるんだぜ？ 694 名前：デフォルトの名無しさん mailto:sage [2008/01/08(火) 21:20:10 ] プリプロセッサがチューリング完全だったらいいのに 695 名前：デフォルトの名無しさん mailto:sage [2008/01/08(火) 22:21:09 ] プリプリ中学生！ 696 名前：デフォルトの名無しさん mailto:sage [2008/01/08(火) 22:26:57 ] ttp://blogs.msdn.com/vcblog/ C++0x standard 697 名前：デフォルトの名無しさん mailto:sage [2008/01/08(火) 22:27:59 ] え？！チューリング完全じゃないの？ てっきりそうだと思ってた 698 名前：デフォルトの名無しさん mailto:sage [2008/01/08(火) 22:32:01 ] LISPのマクロはチューリング完全だけど C++のプリプロセッサがチューリング完全だとは聞いたことが無い。 テンプレートはチューリング完全だけどね。 699 名前：デフォルトの名無しさん mailto:sage [2008/01/08(火) 22:41:35 ] Boost.Preprocessor使えばチューリングマシンぐらい実装できそうな気もするけど 規格でネストのレベルの上限が決まってるとかかな まぁスレ違いか 700 名前：デフォルトの名無しさん [2008/01/09(水) 00:49:51 ] >>697 m4マクロみたいに再帰的定義ができません。 >>698 テンプレートは原始帰納関数しか計算できないのでは? 701 名前：デフォルトの名無しさん mailto:sage [2008/01/09(水) 10:03:02 ] ビョーン様をハゲと言うのはやめろ！ 702 名前：デフォルトの名無しさん [2008/01/09(水) 10:08:49 ] 権威を自分の下に置くことによって優越感を味わっているだけなんだよ 技術力の低い賎民の僻みなんだから気にしたら負けだ 703 名前：デフォルトの名無しさん mailto:sage [2008/01/09(水) 10:30:20 ] 禿は愛称です 704 名前：デフォルトの名無しさん mailto:sage [2008/01/09(水) 12:09:52 ] いじめではなくプロレスごっこです 705 名前：デフォルトの名無しさん mailto:sage [2008/01/09(水) 12:24:57 ] 禿は偉大だ・・・俺も禿るように頑張るよ。 706 名前：デフォルトの名無しさん mailto:sage [2008/01/09(水) 13:22:38 ] 禿かわゆす 707 名前：デフォルトの名無しさん mailto:sage [2008/01/09(水) 17:35:10 ] ビョーン・ザ・バルドヘッド 708 名前：デフォルトの名無しさん mailto:sage [2008/01/09(水) 17:41:43 ] Boost.Preprocessorはすげえよ Boost.MPLやBoost.Lambdaはがんばれば出来る (かもしれない) Boost.Preprocessorは絶対に無理だ 709 名前：デフォルトの名無しさん mailto:sage [2008/01/09(水) 19:52:30 ] >>700 アッカーマン関数なら計算できるけど。 template <unsigned long long m, unsigned long long n> struct Ack { %9static const unsigned long long value = Ack<m-1, Ack<m, n-1>::value>::value; }; template<unsigned long long n> struct Ack<0, n> { %9static const unsigned long long value = n+1; }; template <unsigned long long m> struct Ack<m, 0> { %9static const unsigned long long value = Ack<m-1, 1>::value; }; template <> struct Ack<0, 0> { %9static const unsigned long long value = 1; }; 710 名前：デフォルトの名無しさん mailto:sage [2008/01/09(水) 19:53:18 ] うわ、タブが文字化けした。 もっかい template <unsigned long long m, unsigned long long n> struct Ack { static const unsigned long long value = Ack<m-1, Ack<m, n-1>::value>::value; }; template<unsigned long long n> struct Ack<0, n> { static const unsigned long long value = n+1; }; template <unsigned long long m> struct Ack<m, 0> { static const unsigned long long value = Ack<m-1, 1>::value; }; template <> struct Ack<0, 0> { static const unsigned long long value = 1; }; 711 名前：デフォルトの名無しさん mailto:sage [2008/01/09(水) 20:31:57 ] >>700 チューリング完全だという論文がある。 d.hatena.ne.jp/earth2001y/20060929/p2 712 名前：デフォルトの名無しさん mailto:sage [2008/01/10(木) 01:24:42 ] 底学歴でさーせんwww チューリングなんてまったく知らないんだけど、勉強した方がいいかな？(;´Д`) 713 名前：デフォルトの名無しさん mailto:sage [2008/01/10(木) 02:04:31 ] 少なくとも勉強したほうが悪いということは無いと思うぞ 714 名前：デフォルトの名無しさん mailto:sage [2008/01/10(木) 02:05:07 ] 知らなくたってPGは務まる。ってか大多数の職業PGは知らないと思う。 715 名前：デフォルトの名無しさん mailto:sage [2008/01/10(木) 02:06:47 ] でも少なくとも情報工学科でたやつは習うでしょ 716 名前：デフォルトの名無しさん mailto:sage [2008/01/10(木) 02:08:28 ] 気になるなら調べりゃいい。それが勉強だ。 717 名前：デフォルトの名無しさん mailto:sage [2008/01/10(木) 02:17:03 ] >>715 情報系出身だけど一切授業ではやってないよ。 ja.wikipedia.org/wiki/%E8%A8%88%E7%AE%97%E7%90%86%E8%AB%96 ↑のページで授業で触れられたものはO記法くらいだなぁ。 718 名前：デフォルトの名無しさん mailto:sage [2008/01/10(木) 02:34:46 ] 情報系いうてもピンキリやな 719 名前：712 mailto:sage [2008/01/10(木) 03:32:48 ] ウィキペディア読んできたけど意味わかんね(;´Д`)w 720 名前：デフォルトの名無しさん [2008/01/10(木) 04:50:29 ] 授業でやった．しかし忘れた． その時教科書使ってない． センセのパワポだけ． SIに就職後だけど，情報系出てるのに恥ずかしい． いまさら何読めばいい？ 英語は何とか問題ないと思うので英語の教科書でも． 次のレスでエロい人が読み物を列挙してくれる予定． ↓ 721 名前：デフォルトの名無しさん mailto:sage [2008/01/10(木) 07:01:00 ] つttp://wiredvision.jp/news/200710/2007102622.html 722 名前：デフォルトの名無しさん [2008/01/10(木) 09:13:40 ] チューリング完全なんて数学の知識が要るから必要ないよ 723 名前：デフォルトの名無しさん mailto:sage [2008/01/10(木) 09:26:34 ] 知ってるに越したことはないけどね 724 名前：デフォルトの名無しさん mailto:sage [2008/01/10(木) 09:27:46 ] 美少女中学生と完全なチューをしている状態！(*´Д`)'`ｧ'`ｧ 725 名前：デフォルトの名無しさん mailto:sage [2008/01/10(木) 15:31:05 ] 数学の知識が無いのにそういう仕事してる時点で下流決定だろｗ 726 名前：デフォルトの名無しさん mailto:sage [2008/01/10(木) 16:00:31 ] 時点で、とか書く時点で厨レスだろｗ 727 名前：デフォルトの名無しさん mailto:sage [2008/01/10(木) 18:32:54 ] 2chやってる時点でｒｙ 728 名前：デフォルトの名無しさん mailto:sage [2008/01/10(木) 20:44:36 ] >>726 厨リング完全なレスだな 729 名前：デフォルトの名無しさん mailto:sage [2008/01/10(木) 21:36:30 ] >>728 誰がうまいことを（ｒｙ 730 名前：デフォルトの名無しさん mailto:sage [2008/01/11(金) 00:09:56 ] まあしかし、すでにプログラムをかけるひとはチューリング完全のあたりを勉強するのはぜんぜん難しくないと思う 数学の記法つかってかいてない本とかあれば、だけど。 731 名前：デフォルトの名無しさん mailto:sage [2008/01/11(金) 00:18:24 ] ありそうだな 732 名前：デフォルトの名無しさん mailto:sage [2008/01/11(金) 01:22:11 ] あるよ？ 733 名前：デフォルトの名無しさん mailto:sage [2008/01/17(木) 02:26:47 ] include guard書くのが馬鹿らしいので#includeのプリプロセスで勝手に弾いてほしい。 734 名前：デフォルトの名無しさん mailto:sage [2008/01/17(木) 09:55:47 ] #pragma once 735 名前：デフォルトの名無しさん mailto:sage [2008/01/17(木) 10:03:19 ] pragma onceがなかなか標準にならないのは いろいろ難しい問題があるらしい。 知らんけど 736 名前：デフォルトの名無しさん [2008/01/17(木) 11:50:48 ] #pragma once って gcc でも vc でも使えるよね． 737 名前：デフォルトの名無しさん mailto:sage [2008/01/17(木) 12:10:50 ] windowsのヘッダを通さなきゃならないコンパイラはみんなonceは通すよ 738 名前：デフォルトの名無しさん mailto:sage [2008/01/17(木) 13:00:20 ] #pragma twice 739 名前：デフォルトの名無しさん mailto:sage [2008/01/17(木) 13:55:22 ] >>735 一言で言えば、何で同一性を判定するのかという問題だね 740 名前：デフォルトの名無しさん mailto:sage [2008/01/17(木) 20:19:03 ] インクルードガードを内部的に自動生成したのと同じ形に動作する程度でいいと思うんだがなあ。 741 名前：デフォルトの名無しさん mailto:sage [2008/01/17(木) 21:33:07 ] その内部的に生成する際に、識別子をどうするかが問題なんでしょうが 742 名前：デフォルトの名無しさん mailto:sage [2008/01/17(木) 22:29:02 ] GUIDを使って後は神に祈る 743 名前：デフォルトの名無しさん mailto:sage [2008/01/17(木) 22:41:21 ] 内部的に自動生成したのと 「同じ形に動作する」 わけだからどうとでもなるべ。 744 名前：デフォルトの名無しさん mailto:sage [2008/01/17(木) 23:02:53 ] 同じファイルに複数の名前がついてるような場合とかどうするのって話。 745 名前：デフォルトの名無しさん mailto:sage [2008/01/17(木) 23:07:46 ] ローカルにあるファイルを、 直接と、ネットワーク越しにとでアクセスする場合とかか？ 746 名前：デフォルトの名無しさん mailto:sage [2008/01/17(木) 23:47:53 ] シンボリックリンクされてる場合とか。 747 名前：デフォルトの名無しさん mailto:sage [2008/01/18(金) 00:02:15 ] 「そういう場合は処理系定義とする」 でもういいじゃん 748 名前：デフォルトの名無しさん mailto:sage [2008/01/18(金) 00:16:03 ] いちいちヘッダを比較すればいい 違う名前だろうがなんだろうが一字一句同じなら同一としていいはずだからな 749 名前：デフォルトの名無しさん mailto:sage [2008/01/18(金) 00:17:23 ] 同じファイル名が別の場所にあって名前も内容も同じ場合ってのがシステムヘッダ などでよく起きる。さらに内容はほぼ同じ（バージョン違い）とか考えだすときりがない。 750 名前：デフォルトの名無しさん mailto:sage [2008/01/18(金) 00:20:26 ] それに関しては絶対パスで区別すりゃいい。 リンクされてる場合は、同一実体を指しているかもチェックする。 ただ、このあたりは環境依存な話が多く出てくるので もう 「処理系定義」 でいいと思う。 751 名前：デフォルトの名無しさん mailto:sage [2008/01/18(金) 00:31:00 ] 提案書を書いて委員会へ提出よろ 752 名前：デフォルトの名無しさん mailto:sage [2008/01/18(金) 00:31:06 ] そんならもう#pragma onceの扱いは処理系定義でいいじゃん。 753 名前：デフォルトの名無しさん mailto:sage [2008/01/18(金) 00:31:46 ] そもそも pragma の扱いは処理系定義だｗ 754 名前：デフォルトの名無しさん mailto:sage [2008/01/18(金) 00:53:37 ] #pragma onceってファイル内の中途半端な位置に書いてたり2か所に記述したりしたらどうなるんだろ 755 名前：デフォルトの名無しさん mailto:sage [2008/01/18(金) 00:56:32 ] 処理系定義だろ 756 名前：デフォルトの名無しさん mailto:sage [2008/01/18(金) 03:04:14 ] >>752 ﾜﾛﾀ 757 名前：デフォルトの名無しさん mailto:sage [2008/01/18(金) 07:42:44 ] #pragma once #pragma once は同一ファイルの二度目以降のインクルードを無効にする。 ファイルの同一性判定の方法は処理系定義とする。 ファイル A の中で #pragma once が処理される前に #include があり、 その中でファイル A がインクルードされている場合、 #pragma once は効力を発揮しない。 #pragma once はファイル中に１カ所にしか出現してはいけない。 758 名前：デフォルトの名無しさん mailto:sage [2008/01/18(金) 09:15:21 ] #pragma once(unique-id) ちょっとタイプ量は増えるけど、こう書くようにすればいいんじゃなかろうか。 従来のようにidを省略したら、 #pragma once(__FILE__) みたいになって、ファイルの同一性の比較は処理系定義と妄想 759 名前：デフォルトの名無しさん [2008/01/18(金) 09:19:30 ] >>748 じゃだめなん？ 760 名前：デフォルトの名無しさん mailto:sage [2008/01/18(金) 09:38:45 ] 全く同じファイルのコピーが二箇所にあって、両方ともincludeされてて、 なんかの拍子に片方を編集したら、コンパイルとおらなくなる。 鬱陶しくないか。 761 名前：デフォルトの名無しさん [2008/01/18(金) 09:41:35 ] >>758がいいな 同一性はプログラマが定義することもできるし、コンパイラに任せることも出来る 762 名前：デフォルトの名無しさん mailto:sage [2008/01/18(金) 10:10:44 ] 普通にインクルードガードでいいだろJK 763 名前：デフォルトの名無しさん [2008/01/18(金) 10:12:15 ] >>762 よく ifdef endif の対応関係がずれて あわわわ〜ってなる（笑 764 名前：デフォルトの名無しさん mailto:sage [2008/01/18(金) 10:55:05 ] >>763 それは言語仕様でフォローすることではないな 765 名前：デフォルトの名無しさん mailto:sage [2008/01/18(金) 12:13:46 ] >760 コンパイル通るようになったらなったで、 何からの拍子で、片方だけ、構造体の構成とか変更すると、 実行時に訳わかめなエラーになるんじゃねーの。 766 名前：デフォルトの名無しさん mailto:sage [2008/01/18(金) 13:48:01 ] こういう仕様を考える時は「やっちゃいけないこと」から考えるといいぞ 767 名前：デフォルトの名無しさん mailto:sage [2008/01/18(金) 16:34:02 ] include回りの問題の多くはModules in C++(N2316)が入れば解決じゃね？ 仕様が固まる頃にはC++20くらいになってそうだけど。 768 名前：デフォルトの名無しさん mailto:sage [2008/01/18(金) 20:45:37 ] もうプリプロセッサなくていいよ 769 名前：デフォルトの名無しさん [2008/01/18(金) 20:46:29 ] >>768 まぁそういう意見もあるよな． しかし過去の遺産のことを考えると プリプロセッサの挙動をもっと厳格に 規格化したうえで存続した方がいい． 770 名前：デフォルトの名無しさん mailto:sage [2008/01/18(金) 20:46:38 ] Cでプリプリ！なんていやらしい！ 771 名前：デフォルトの名無しさん mailto:sage [2008/01/18(金) 21:01:08 ] modulesを入れるとなあ、 exportどころじゃないぞ、実装の手間が。 templateもconceptも、実装をヘッダでincludeすること前提だしな。 必要な情報を全部中間言語に書き出すとなると大変。 772 名前：デフォルトの名無しさん mailto:sage [2008/01/19(土) 00:51:35 ] もはや C++ ではない気がするなあ 773 名前：デフォルトの名無しさん mailto:sage [2008/01/19(土) 02:29:00 ] D言語においでー 774 名前：デフォルトの名無しさん mailto:sage [2008/01/19(土) 08:41:03 ] DはC++0xの実験的な実装 775 名前：デフォルトの名無しさん mailto:sage [2008/01/19(土) 14:12:01 ] include guardも#pragma onceも、インクルードされる側のファイルに書く。つまり、読まれたかどうかはファイルを開かないと分からない。 なんつーか、Obj-Cのimportみたいのが欲しいんだよね。あれって多分開く前に同一性チェックをしてるでしょ。（#pragma onceもそうなのかな？） 776 名前：デフォルトの名無しさん mailto:sage [2008/01/19(土) 14:16:09 ] 美少女中学生のインクルードガードは固くないほうがいいなぁ もしくは自分で破っちゃったりしててアアーッ 777 名前：デフォルトの名無しさん mailto:sage [2008/01/19(土) 14:27:39 ] つttp://pc11.2ch.net/test/read.cgi/tech/1142089873/ 778 名前：デフォルトの名無しさん mailto:sage [2008/01/19(土) 14:38:18 ] 16.6.1 #pragma once 　　　　#pragma once po-identifier_opt new-line po-identifier: 　　　　identifier or 　　　　( identifier ) #pragma once は同一ファイルの二度目以降のインクルードを無効にする。 identifier が指定されている場合は、identifier が同一である場合に同一ファイルであると判定する。 identifier が指定されていない場合のファイルの同一性判定の方法は処理系定義とする。 ファイル A の中で #pragma once が処理される前に #include があり、 その中でファイル A がインクルードされている場合、 #pragma once は効力を発揮しない。 identifier の指定の無い、または同じ identifier を持つ #pragma once は、 ファイル中に１カ所にしか出現してはならない。 779 名前：デフォルトの名無しさん [2008/01/21(月) 01:06:40 ] Cプログラマ必須テキストです！ mori.eco.to/ 780 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 07:06:50 ] 俺はC++だから必要ないな 781 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 14:15:59 ] おまえがC++だったのか！ 782 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 14:20:59 ] >>780 お前のせいで！ 783 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 15:40:53 ] >>782 お前がハゲなのは親のせいだ。 784 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 15:56:56 ] C++のせいではなかったのか…orz 785 名前：デフォルトの名無しさん mailto:sage [2008/01/22(火) 14:41:57 ] >>779 普通のC言語入門書っぽいな。 経験のあるプログラミング言語をわざわざ列挙してるのが何か笑える。 786 名前：デフォルトの名無しさん mailto:sage [2008/01/22(火) 15:33:15 ] 「普通の」じゃないだろ。 寧ろ本人曰く、「世のCを教える立場の人間は押し並べてCを判っていない」とのことなんだから。 787 名前：デフォルトの名無しさん mailto:sage [2008/01/22(火) 15:34:09 ] >>785マルチ宣伝レスだから反応しないように 788 名前：デフォルトの名無しさん mailto:sage [2008/01/22(火) 15:42:40 ] まともな本ならこんな宣伝しないよ 789 名前：785 mailto:sage [2008/01/22(火) 16:00:22 ] ｽﾏｿ 790 名前：デフォルトの名無しさん mailto:sage [2008/01/22(火) 17:24:14 ] ハゲが怖ければ大豆イソフラボン摂れば良いよ。女性ホルモンに似た働きをして ハゲや不本意な勃起を抑えてくれる事が医学的に証明されている。 791 名前：デフォルトの名無しさん mailto:sage [2008/01/22(火) 23:32:49 ] >>790 ありがとう。さっそく試してみるよ。 792 名前：デフォルトの名無しさん mailto:sage [2008/01/22(火) 23:46:14 ] 結論は納豆というわけか 793 名前：デフォルトの名無しさん mailto:sage [2008/01/29(火) 17:40:14 ] やっぱ豆蔵がいちばんっしょ。 794 名前：デフォルトの名無しさん mailto:sage [2008/01/29(火) 17:43:55 ] >>790 俺の体で効果がない事は、俺の実体験により証明されている。 795 名前：デフォルトの名無しさん [2008/01/29(火) 21:17:36 ] 美少女中学生のいやらしいお豆！ 796 名前：デフォルトの名無しさん mailto:sage [2008/02/06(水) 10:18:26 ] あげるな危険。 797 名前：デフォルトの名無しさん [2008/02/06(水) 21:31:19 ] 最近C++0xを勉強中なんですが decltypeは静的な型を表すんでしょうか class Derived : public Base {} Base* pb = new Derived(); std::cout << typeid(decltype(pb)).name(); //Baseと表示?Derived? 798 名前：デフォルトの名無しさん mailto:sage [2008/02/06(水) 21:32:40 ] 静的な型を表す。 799 名前：デフォルトの名無しさん [2008/02/06(水) 21:48:43 ] >>798 ありがとうございます 実際に試せればわかるのに・・・ と思ったらconcept gccなんてのがあるんですね ちょっと遊んでみます 800 名前：デフォルトの名無しさん mailto:sage [2008/02/06(水) 22:34:07 ] decltype(pb)はBaseではなくBase*では？ 801 名前：デフォルトの名無しさん [2008/02/08(金) 17:25:38 ] operator[]　()　=　->　* C++0xでこれら演算子をグローバルに定義できるみたいですが、 どういう意図で導入したんでしょうか 802 名前：デフォルトの名無しさん mailto:sage [2008/02/08(金) 21:54:05 ] それは初耳。 803 名前：デフォルトの名無しさん [2008/02/10(日) 14:30:08 ] 右辺値参照でT & &&がT &になるというのが納得できない。 例えばN1377には右辺値を左辺値に変換する関数moveが載っているが、 template <class T> inline T&& move(T&& x) { return static_cast<T&&>(x); } moveを使った次のような(自然な)コードは動かない。 void foo(move_ptr<Bar> &d, move_ptr<Bar> &s) {     (何か例外を投げる可能性がある処理)     d = move(s); // 処理に成功したらsをdに移す } N1377やN1385で導入している型推論のルールによると、 Tはmove_ptr<Bar>ではなくmove_ptr<Bar> &になる。 するとmoveはmove_ptr<Bar> & &&型、つまりmove_ptr<Bar> &型を返すことになる。 上のような処理をしたければ、次のように直接static_castするしかない。 d = static_cast<move_ptr<Bar> &&>(s); 804 名前：デフォルトの名無しさん [2008/02/10(日) 14:43:44 ] T & && = T &とする根拠として、N1377では次の例を挙げている。 compressed_pair<T1, T2>::compressed_pair(compressed_pair&& x)     : first_ (static_cast<T1&&>(x.first_)),       second_(static_cast<T2&&>(x.second_)) {} が、そもそもpairのような値型オブジェクトが参照をメンバに持つこと自体 かなり特殊なことなんだから、こういうのはcall_traitsで処理すべきだろう。 805 名前：デフォルトの名無しさん mailto:sage [2008/02/10(日) 14:46:40 ] move_ptr<Bar> const&を引数に取るoperator =が無ければ大丈夫。ConceptGCCでやってみた。 struct c { c& operator =(c&&); private: // c& operator =(c const&); }; template <class T> inline T&& move(T&& x) { return static_cast<T&&>(x); } void f(c& x, c& y) { x = move(y); } また、N1690ではこのmoveの戻り値の型が typename remove_reference<T>::type&&になっている。 これなら、上のコメントアウトを外した状態でもコンパイルできた。 806 名前：デフォルトの名無しさん mailto:sage [2008/02/10(日) 16:31:07 ] >>803 最新の draft などでは>>805さんの書かれているように move の定義が変わっているので，単に d = move(s) の構文で大丈夫なはずです． >>804 そのように参照型を取る事例への対処を より汎化した規則で書こうとした結果が， 現在の reference collapsing rule じゃないんでしょうか？ 807 名前：デフォルトの名無しさん mailto:sage [2008/02/10(日) 16:43:41 ] >>804 あと，複数引数などの forwarding を pair や tuple の形で行おうとすると， 普通に pair や tuple が参照型のメンバを持つ場面はあるように思われます． そのような場合に，現在の reference collapsing rule だと pair<T1&,T2&&> && や pair<T1&,T2&&> & に対して自然に collapsing rule を分配して pair<T1&,T2&&> や pair<T1&,T2&> と同等に捉えられますので 割と自然なように思えます． 808 名前：803 mailto:sage [2008/02/10(日) 16:57:18 ] >>806 compressed pairはおまけ的な例で、真の目的は template <class T> inline T&& forward(typename identity<T>::type&& t) { return t; } template <class T, class A1, class A2> shared_ptr<T> factory(A1&& a1, A2&& a2) { return shared_ptr<T>(new T(forward<A1>(a1), forward<A2>(a2))); } のような転送を実現することみたいだね。 でも、だからといってT & && = T &のような直観に反する変換や C++98の考え方と全く違う異様な型推論を導入するのはどうかと思う。 今まで型推論でさんざん苦しんだのに、またバグの温床を生むことになる。 もっと明示的に、「右辺値か左辺値か教えてくれ」という演算子「&?」を導入して、 template <class T, class A1, class A2> shared_ptr<T> factory(A1&? a1, A2&? a2) { return shared_ptr<T>(new T(static_cast<A1>(a1), static_cast<A2>(a2))); } と書ければ、プログラマの意図もはっきりするしC++98から大きく離れることもない。 809 名前：803 mailto:sage [2008/02/10(日) 17:01:20 ] >>807 参照型のメンバを持つpairだのtupleだのは、 代入演算子を持たなかったりswapが参照先を入れ換えちゃったりするわけで、 そういうものを「自然」に扱える必要はないでしょう。 810 名前：デフォルトの名無しさん mailto:sage [2008/02/10(日) 17:08:36 ] >808 ＞C++98の考え方と全く違う異様な型推論 右辺値参照型をパラメタとする関数テンプレートの型パラメタの推論に関して 言及されてるならそれは同意します．もう template<class T> void f(T&&); の形は perfect forwarding のため (だけ) にあると理解したほうが早いと思います． 811 名前：デフォルトの名無しさん mailto:sage [2008/02/10(日) 17:21:37 ] >>809 参照型のメンバを持つ pair/tuple における代入や swap の semantics がどうなるかは 従来から散々議論されているのは承知しています． 結論が出ているかどうかは知らないのですが． ただ，自分は forwarding などの局面で参照型メンバを持つ pair/ tuple を使うこと 想定してそういうものは自然に扱いたいという趣旨で発言しました． 誤解があるとあれなので補足しておきたいのですが， tuple<T1,...> はあらゆる型 T1, ... に対して代入や swap が well-defined である必要はなく， T1, ... に対してどういう操作が行えるかによって tuple<T1,...> に対して行える操作が限定される場面があっても構わないと思っています． そうしたときに，たとえば T1,... の一部またはすべてが参照型であるとき， tuple<T1,...> に対して値としての代入や swap を well-defined な形で提供するのは難しいですが， たとえば construction などは依然 well-defined に定義できますから， construction などしか行えない tuple を提供することはできます． で，そのような制限のかかった tuple でも forwarding などには十分使えますので それを自然に扱いたいという motivation は排除してほしくないです． 812 名前：デフォルトの名無しさん [2008/02/10(日) 18:36:30 ] やべぇ高度過ぎてわからん 813 名前：デフォルトの名無しさん mailto:sage [2008/02/10(日) 19:07:34 ] へぼぐらまの俺にもいまいちわからん 0x の改修って一般のC++プログラマに受け入れられるのか？ なんか、実用する人たちから遊離した規格のような気が・・・ 814 名前：デフォルトの名無しさん mailto:sage [2008/02/10(日) 19:16:39 ] >>813 そんなに大変な非互換性は取り込まれないと思うから、一般のプログラマは現状の 規格に不満がなければ気にしなくてもいいでしょ。 受け入れられるかどうかっていう点では、規格の変更に対応するかどうかという話で コンパイラベンダの反応が問題だと思う。 815 名前：803 mailto:sage [2008/02/10(日) 19:30:15 ] >>811 それを言い出したら、参照型メンバを持つpair/tupleにoperator=を定義したいとき T & && = T &&になっていれば mypair &operator=(const mypair &src) { first = src.first; second = src.second; return *this; } mypair &operator=(mypair &&src); { first = static_cast<T1&&>(src.first); second = static_cast<T2&&>(src.second); return *this; } というふうに「自然に」定義できるよね、という議論もできる。 で、結局mypair<int, int>がPODになって欲しいという理由で 何らかのtraitsが必要になる、と。 816 名前：デフォルトの名無しさん mailto:sage [2008/02/10(日) 19:37:26 ] ライブラリ書くようなエロいプログラマさんが頑張って書いてくれれば、 使ってる側からはあんまり気にしなくてもメリットはあると思う。 あと、この辺のおまじないは std::forward とか、std::move とかの裏側に隠されるし。 >808 >でも、だからといってT & && = T &のような直観に反する変換や どうなるのが望ましい？ その辺をおいといても、&? の方が明快なのはそう思う(これ static_cast も必要なくね？)。 やってること自体は今の && の反転みたいなものだし、ルール的にも決めるのはそう難しくなさそう。 欠点は &? が増えるってことだけかな？ 今更無理だろうけど誰か提案書いてくれw 817 名前：803 mailto:sage [2008/02/10(日) 19:51:49 ] >>816 型の一番右側に&&が付いていれば、オブジェクトを移動してほしくて わざわざ&&を付けたんだから素直に言うことを聞いて欲しい、と思う。 逆にT && &は(出現する場面を思い付かないけど)T &になってほしい。 > (これ static_cast も必要なくね？)。 { return shared_ptr<T>(new T(static_cast<A1>(a1), static_cast<A2>(a2))); } のこと？a1, a2という名前が付いた時点で左辺値になってるからstatic_castは必要。 818 名前：811 mailto:sage [2008/02/10(日) 20:08:33 ] >>815 ＞mypair &operator=(mypair &&src); ＞{ first = static_cast<T1&&>(src.first); second = static_cast<T2&&>(src.second); return *this; } T & && -> T && という collapsing rule を仮定したときに， これがどういう意味で自然なのかいまいち理解できないです． おそらく template<class T1,class T2> class mypair{ T1 first; T2 second; ... }; という定義だと思うのですが， mypair のT1 が左辺値参照型であるとき， T & && -> T && という collapsing rule の下では first = static_cast<T1&&>(src.first); という構文が破壊的コピー (move) を呼ぶことになりますが， src.first は名前の付いた他のオブジェクトを指しているため，これはまずくないですか？ 819 名前：デフォルトの名無しさん mailto:sage [2008/02/10(日) 20:46:28 ] >>813 いま問題になっている右辺値参照。 それによってもたらされる一般的なムーブ・セマンティクスは、 例えば関数の戻り値や、vectorで内部バッファリサイズ時の移動などといったときに 無駄なコピーの削減に役立つ。 ＃もちろんそれだけにとどまらないけど、それはとりあえず置いておく。 820 名前：デフォルトの名無しさん mailto:sage [2008/02/10(日) 20:53:55 ] で、何が言いたいかって、各人がほっといたって、 ライブラリの中の人が頑張るために使うから、 気付かぬ内に恩恵を被るかもしれないよってこと。 821 名前：デフォルトの名無しさん mailto:sage [2008/02/10(日) 21:12:29 ] move　semanticsなんて全コンテナ修正だな T&&のオーバーロード足すだけでいいのかな 822 名前：803 mailto:sage [2008/02/10(日) 21:23:32 ] >>818 mypair &operator=(const mypair &src); mypair &operator=(mypair &&src); という一般的なオーバーロードを前提にすれば、 後者が呼ばれるのは故意にmoveする場合に限られる。 だから名前の付いた他のオブジェクトをmoveして正解。 823 名前：803 mailto:sage [2008/02/10(日) 21:26:48 ] ごめん大嘘。関数の戻り値として参照を含むmypairを値で返されたら 後者の方にマッチしちゃう。これは確かにまずい。 824 名前：デフォルトの名無しさん mailto:sage [2008/02/10(日) 21:53:55 ] アクロバティックな性体験を体験した美少女中学生のような気分になった 825 名前：デフォルトの名無しさん mailto:sage [2008/02/10(日) 23:36:37 ] 同じくヘボグラマの俺には、辛うじて意味は分かってもどうしても内容に関しては受動的にならざるを得ない。 826 名前：デフォルトの名無しさん mailto:sage [2008/02/21(木) 00:24:55 ] そろそろ移動するべきかなぁと思ったのでこっちで。 【C++】STL（Standard Template Library）相談室 8 pc11.2ch.net/test/read.cgi/tech/1198435319/843 でオーバーロード面倒という声があったけど、場合によってはこんな風にできるかも。 Widget func(const Widget&, const Widget&, const Widget&); // move しない // helper 実際には Variadic template 化？ template<typename T0, typename T1, typename T2> Widget&& select(T0&& t0, T1&& t1, T2&& t2, std::enable_if<!std::lvalue_reference<T0>::value || !std::lvalue_reference<T1>::value || !std::lvalue_reference<T2>::value>>::type *dummy = 0) {   return !std::is_lvalue_reference<T0>::value ? std::move(t0) : !std::is_lvalue_reference<T1>::value ? std::move(t1) : std::move(t2); } template<typename T0, typename T1, typename T2> Widget&& func(T0&& t0, T1&& t1, T2&& t2) {   Widget& w = select(std::forward<T0>(t0), std::forward<T1>(t1), std::forward<T2>(t2)); // w に対する処理   return std::move(w); } あんま自信ないけどどうだろ？ 827 名前：デフォルトの名無しさん mailto:sage [2008/02/21(木) 00:39:30 ] ムーブコンストラクタの呼び出しが最適化で削られるなら いいのかなあと思った。 828 名前：デフォルトの名無しさん mailto:sage [2008/02/21(木) 00:52:27 ] >>826 func の return 文の std::move は不要では？ >>827 move constructor は副作用を持つでしょうから これを参照で返すのと同じにまで最適化するのは結構厳しい要求かと 829 名前：デフォルトの名無しさん mailto:sage [2008/02/21(木) 00:55:27 ] 結局そんくらいのコストは勘弁してやれ、 それが嫌ならオーバーロードしろ、ということか。 830 名前：デフォルトの名無しさん mailto:sage [2008/02/21(木) 01:01:51 ] move は一般にリソースの確保・解放を伴わないでしょうから， そこまでシビアに move が重くなる状況はあまりないとは自分も思うのですけれど． ただ std::string においては，例えば短文字列最適化を採用していると move を使っても内部の文字列のコピーが発生するので， 4つのオーバーロードをまともに書く意義はあるのかなぁ，と． それに4つのうち2つは他の実装に forward すればよいだけですし そこまでオーバーロードが苦になることもないかと． 831 名前：デフォルトの名無しさん mailto:sage [2008/02/21(木) 01:14:22 ] そういう引数が４つあった１６個か。 832 名前：デフォルトの名無しさん mailto:sage [2008/02/21(木) 02:31:49 ] Boost.Operatorsに期待。 833 名前：デフォルトの名無しさん mailto:sage [2008/02/21(木) 19:43:22 ] 引数に関して言えば、 右辺値参照なんてものを導入するより、 右辺値→左辺値 変換演算子を導入した方がいいと思う。 どうせ戻り値はテンポラリオブジェクトとして作成されてて、 基本型でもなければ大抵メモリ上にあるわけで、 内部的には変換なんて行う必要はないはず。 基本型とかなら、テンポラリオブジェクトを作成して、 そのテンポラリオブジェクトへの参照を返せばいい。 const 参照へならここら辺勝手にやってくれるけど、 非 const 参照へもできる手段を与えてやるって感じ？ 自動的に変換されるのはおそらくマズそうなんで、 キャスト演算子の導入でなんとか。 834 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 02:09:34 ] 突発的！ちら裏!! １、SingleInt型かByte型を導入してくれ。。。 char型はiostreamで文字として解釈されてすごい不便。俺は文字じゃなくて１バイトの数字を書き込みたいんだ。。。 バイナリ指定してるはずなんだけどなぁ。@VC ２、Enumの名前ちゃんと考慮してクレイ。名前何のために付けてるんだか。。。 2種のEnum宣言したときの別々なのにメンバの多重定義できなくてメチャクチャ不便だ。 片方に宣言してもう片方に設定しようとすると型変換エラーでるし。 ゲームでステータス設定するときEnum重宝するんだがなぁ。 835 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 02:14:32 ] 2の方はC++0xになかったっけ enumにスコープがつくはず 836 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 04:11:22 ] charとsigned charとunsigned char 837 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 13:06:58 ] >>836 みんなbasic_istream/basic_ostreamに対するoprator >>/operator <<が定義されている。 838 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 14:01:38 ] >>834 ios::binaryってことじゃなくて？ 839 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 17:09:44 ] >>835 おぉ、ありがたい。 >>834 一応ｙってみたけど、なんか意図どおりにならなかったなぁ。 自分の不具合かもしれんが。。。 840 名前：839 [2008/02/22(金) 17:11:18 ] ミス。 >>834じゃなくて　>>838 841 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 18:14:50 ] foo(lvalue_cast(bar())); 842 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 19:42:00 ] integer semantics 843 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 19:55:46 ] template <typename T> 　T& lvalue_cast(const T& rvalue) { 　return const_cast<T&>(rvalue); } 何だ。今の C++ でも書けるじゃないか。 当然文をまたいで使う事はできないが、 move semantics なんて無くてもいいんじゃないか？ 844 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 21:30:21 ] >>843 ムーブとコピーの区別が付けられなくないか？ 845 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 23:12:30 ] >>844 引数は const 参照だが、 あくまでこれはテンポラリオブジェクトを作成するためのものであって、 引数には左辺値を渡してはいけない。 あくまで右辺値を左辺値に変換する際にしか使わない。 さらにメタプロ駆使すれば左辺値を禁止することもできるかもしれない？ 846 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 23:17:36 ] いや待て。 別に左辺値を渡してもいいのか。 単にそれがそのまま返されるだけで。 const な左辺値を渡してはいけない、だな。 847 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 23:26:40 ] >>845 ごめんわからない。例えばこういう区別はどうなるの？ class Hoge { public: Hoge(const Hoge&); Hoge(Hoge&&); }; Hoge f(); Hoge x; Hoge y = x; //コピー Hoge z = f(); //ムーブ 848 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 23:30:08 ] >>845 ＞さらにメタプロ駆使すれば左辺値を禁止することもできるかもしれない？ やめたほうがよいです．左辺値と右辺値の識別を現行規格でやろうとすると 非常にわずらわしいことを考えないとならないです． 個人的に徹底的に試行錯誤した経験があるんですが， 現行規格で右辺値・左辺値識別を行うのは自分としては絶対にお勧めしません． 実際やってみれば理解してもらえると思うのですが，たとえばGCCの実装における 現行規格の8.5.3/5の解釈にブチ切れたりすることになったりします． 一応，下の提案さえ通ればライブラリレベルで move を実装することはできますが…… www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1610.html 849 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 23:32:23 ] ごめんHogeの定義こっちにしておく。 欲しいのは、右辺値を参照にすることじゃなくて、ムーブセマンティクスそのもの。 class Hoge { public:   Hoge(const Hoge& y) : p(new int(*y.p)) {}   Hoge(Hoge&& y) : p(y.p) {y.p = 0;}   Hoge() : p(new int) {}   ~Hoge() {delete p;} private   int* p; }; 850 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 23:42:47 ] >>847 俺の案は RVO されることを前提としてるから、 ムーブなんて無くても十分ということになる。 面倒くさいから RVO を規格で要求したら？ とさえ思ってる。 851 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 23:48:40 ] >>848 識別は難しいのか・・・。 852 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 23:51:55 ] なるほど。 でもそれだとbindなんかで呼出時に右辺値を直に引数にできないのは 解決できないように見える。 lvalue_castがあるって言うのかもしれないけど、 それだったら今でもboost::crefを使えば引数に渡せる点で同じと思う。 853 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 23:54:11 ] まあ、実際の所現行規格で別に実現できなくてもいい。 && を単項演算子として、それを頭に付けるとかいう言語拡張でも。 854 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 00:14:35 ] 何でもかんでもオーバーロードで解決すべきかってのは微妙な所で、 ２つの関数を実装させる手間、 いや、複数引数があれば４つ、８つと指数関数的に増えていく手間がかかってしまうのは かなりの問題だと思う。 右辺値参照を導入するとしても、 オーバーロード不要の代替案は用意した方が良さげ。 855 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 00:18:34 ] それはもう variadic template で書いてしまって， 意図しない呼び出しを SFINAE と deleted function 宣言で阻止してしまえば いいんじゃないですかね 具体的にどういう複数引数関数書きたいのかによりますけれど 856 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 00:23:02 ] テンプレートは export が実質使えなくてヘッダに実装せざるを得ない以上、 使う必要の無いところでなるべく使いたくはない。 857 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 00:24:31 ] だが、もはやテンプレートのないC++も使いたくない。わがままだ。 858 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 00:27:29 ] ムーブは無駄なコストが発生する上に RVO みたいな最適化もできなさそうなのがな。 pimpl 使えばポインタの移動だけでいいから まあ大したコストでもないのかもしれないが・・・。 859 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 00:33:33 ] boost::noncopyable の他に boost::nonmovable も必要になるのかな 860 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 00:46:03 ] 非const参照に右辺値を渡せちゃう処理系もあるから、 いらぬお世話って思ってる人もいるかもね。 861 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 00:48:30 ] >>858 pimplでなくとも、ポインタくらいのやり取りですむ（深いコピーが発生しない） ってのがムーブの売りだろ。 862 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 00:49:19 ] RVO で済む状況なら、RVO はコスト０だぜ。 非０は０には敵わない。 863 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 00:51:02 ] メンバが５個くらいあったら５個ムーブする必要がある。 １つ１つはポインタくらいのやり取りでも、 個数が増えるとバカになんないかもしんない。 864 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 00:59:18 ] んー，別に move を導入しても RVO が適用できる場面では依然 RVO が適用されるでしょうから， たとえば>>858さんが何を問題にされているのかいまいち把握できていないんですが…… もう少し詳しく教えてもらえると個人的にはうれしいんですが． 865 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 01:02:44 ] 実際、このコードだとconceptg++では全くムーブ発動しない。 $ conceptg++ t.cpp && ./a constructor: 0x22ccd0 destructor: 0x22ccd0 #include <iostream> using std::cout; using std::endl; struct hoge { hoge() : p(new int) {cout << "constructor: " << this << endl;} hoge(hoge&& r) : p(r.p) {cout << "move constructor: from " << &r << " to " << this << endl; r.p = 0;} ~hoge() {cout << "destructor: " << this << endl; delete p;} private: hoge(hoge const&); //今回使わないので int* p; }; hoge f() { hoge obj; return obj; } int main() { hoge t = f(); } 866 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 01:04:02 ] RVO と右辺値→左辺値変換さえあれば、 文法を複雑にし、コストを必要とし、ライブラリを大きく書き換える move とやらを導入する積極的な理由はないんじゃないの？ という話。 867 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 01:05:26 ] RVO を規格で保証してないのに理由とかあるの？ コンパイラの実装コストの問題？ 868 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 01:16:45 ] >>866 関数からの戻り値のコピーを排除するのは move の応用の1つに過ぎないです． RVO は return と throw に限定された話ですけれど， move はより広い文脈 (たとえば std::vector におけるバッファの再配置) でも きわめて重要な意義を持つ操作で，これは RVO 云々では取り扱いきれないように思います． それから ＞コストを必要とし、 の部分は，上にもありますけれど， RVO が適用できてコストがかからない部分では move が導入されても依然 RVO が適用されてコストがかからないようになると 思われますので， (ただし，これはあくまでコンパイラの実装如何ですが) RVO と move を比較してどのコストを憂慮されているのかがちょっと理解できていないです． 869 名前：852 mailto:sage [2008/02/23(土) 01:19:43 ] >>866 俺の話はどうしてくれるの？ いや、このためだけに言語を大きく拡張する価値はないと言いたいのか。 870 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 01:20:15 ] だから、右辺値を非 const 参照に渡すまともな手段は用意されてるの？ って話。 871 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 01:21:01 ] >>869 それが lvalue_cast じゃないの？ 872 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 02:02:07 ] あと、RVO が規格で強制されるものではないという点も。 873 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 02:22:09 ] 右辺値左辺値判定、こりゃ確かに無理だな・・・。 874 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 04:42:12 ] >>870 「まとも」とか変な基準を持ち出すなよ。 875 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 05:25:18 ] >>859 move 系コンストラクタや代入演算子が自動生成されないなら、要らないと思うんだけど、 こいつらもコンパイラが勝手に作っちゃうの？ 876 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 10:52:20 ] d = move(s) の途中で例外が起こった場合、sとdの状態はどうなるんだろうか？ std::vectorの再配置にしても例外安全の強い保証 (メソッドの途中で例外が発生してもオブジェクトの状態は以前と同じ) を行うなら、結局 　１、新しいバッファを確保 　２、それにすべてのオブジェクト内容をコピー 　３、バッファ作成に成功したら、ポインタの挿げ替えを行う 　４、古いバッファの削除 という手順を踏む必要があるんだけど・・・ 　１、新しいバッファを確保 　２、オブジェクト内容をmoveで移動 　３、ポインタの挿げ替え＆古いバッファの削除 とやってしまうと２の途中で例外が発生したときまずいことにならないか？ 877 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 11:38:09 ] swapみたいにmoveコンストラクタは例外の非送出が必要ということになっていると思う。 878 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 13:14:28 ] >>875 いえ，今の提案では move constructor や move assignment は自動では生成されないことになってます． >>876 move で強い例外安全性の保証を行おうとすると， move の rollback 操作が move そのもので，これが例外非送出でなければならないため， 結局 move 自身が例外非送出である必要が出てきます． 879 名前：デフォルトの名無しさん [2008/02/27(水) 10:58:47 ] C++の標準外のライブラリが破綻する最大の理由は ライブラリ作成側が守るべきプログラミングモデルをユーザに示さないからだよ。 コードから読み取れるモデルでなく、 モデル宣言をするべきなんだよ。 その完全性を支援するためにコンパイラがそれによって挙動を変えてもいい。 最初は完全なるOOを実現しているように見えた。 しかし、あるバージョンではマルチパラダイムに変身し OOの完全性を崩壊させるとかNe-Yo。 880 名前：デフォルトの名無しさん [2008/02/27(水) 14:10:39 ] こないだ STL スレで挙がった話なんだけど、 copy_if() がどうなってるかだれか知らない？ 未だにドラフトにも載ってないんだけど。っていうか 2003 の改訂で入らなかったのはなぜ？ 881 名前：デフォルトの名無しさん mailto:sage [2008/02/27(水) 15:57:01 ] >>880 禿がまた忘れたんだろ 882 名前：デフォルトの名無しさん mailto:sage [2008/02/27(水) 19:25:26 ] rangeがどうなるかだな 883 名前：デフォルトの名無しさん mailto:sage [2008/02/27(水) 22:25:33 ] >>879 どっちかというとOOの世界に土足で上がり込もうとした 総称型プログラミングの要素の側が勝手に苦労してるだけに見える。 継承使ったら型推論できませんとか暗黙のキャストができませんとか。 マルチパラダイムになってOOサイドで何か問題起きてる？ むしろコンテナみたいな値系オブジェクトを下のレイヤに追い出すことで、 OOを純化できると思うんだけど。 884 名前：デフォルトの名無しさん mailto:sage [2008/02/27(水) 22:46:38 ] 完全なOOとか、OOを純化とかには興味無いんだと思うよ。ｗ 一言で言えば「宗旨が違う」 885 名前：デフォルトの名無しさん [2008/02/28(木) 00:09:21 ] C++はOO側が極端に少ない＝OOが蔑ろにされる という構図がある。 つまり、そのときOOが成立するコードという理由で OO前提のコードを書いてしまうと 将来OO否定派が紛れ込んだときに混乱の元になるということ。 886 名前：デフォルトの名無しさん mailto:sage [2008/02/28(木) 00:10:53 ] >>885 ３回読んだけど意味が判らん 887 名前：デフォルトの名無しさん mailto:sage [2008/02/28(木) 01:37:54 ] 対立問題にしてどうしたいんだ 888 名前：デフォルトの名無しさん mailto:sage [2008/02/28(木) 08:12:14 ] "virtual"を標準ライブラリから検索してみれば OOはC++自身に拒否されていると分かる 禿げ涙目である 889 名前：デフォルトの名無しさん mailto:sage [2008/02/28(木) 08:25:52 ] >>887 勝利したいんだろ ほっとこうぜ 890 名前：デフォルトの名無しさん mailto:sage [2008/02/28(木) 11:55:41 ] ふむ。OOをNGワードに登録、と。 891 名前：デフォルトの名無しさん mailto:sage [2008/02/28(木) 12:44:18 ] WO 892 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 00:48:00 ] 元々何の信念もなく便利だからって適当に機能ぶちこんだだけのグチャグチャ言語に 今更何を言ってるんだ 893 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 01:03:24 ] >>892 馬鹿にされるから他では言わないほうがいいよ、その脳内C++ヒストリー。 894 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 02:19:46 ] そうですか じゃあこのC++と呼ばれる雑多にぶち込まれた大量の機能が お互いひどい副作用を起こし合ってるグチャグチャ言語は 一体どんな高尚な理念で作られたものなんですか 895 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 02:32:47 ] DnE 読んどけ 896 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 03:18:54 ] 無知ゆえに思い上がった口をきく若いオタクが興奮すると、文体似るよな、どういうわけか。 897 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 03:54:17 ] C++を雑多と呼ぶのはよした方が良い。 JavaやRubyなんかと違って、ここまで基本的な部分から整合性の練られた言語は他にない。 多くの機能は基本的な構文から基本的に導出されるが、JavaやRubyはそれらのプロセスを すっ飛ばして機能が実装されている事が多く、とても自由と小回りの利く言語じゃない。 898 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 04:25:57 ] Javaは曲がりなりにも「現実世界で、現実をどうにかするために」歩みを進めてきたけど、 Rubyは話にならない。現実よりも白昼夢のほうが大事な、言語オタの妄想の産物。 前線には一切出ず、安全地帯で仲間とダベりながら延々「クールな匍匐前進」を模索してる兵士が、 「俺はこの最高の匍匐前進でこの戦争を生き抜いてるんだ」って真顔で言い張ってるみたいな言語。役立たず。 899 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 05:02:14 ] という話はスレ違いなのでよそでやろうな。 900 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 05:27:54 ] 技術レベルの低い話は華麗にスルーしましょうよ。 規格ドラフトを読むような人が集まってんだからさ。 901 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 09:52:56 ] 糞してくるわ 902 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 10:34:26 ] スルーなの? 具体的にどのようなひどい副作用があったのか聞きたいんだが 903 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 10:41:11 ] >>902 妄想を聞きたいならせめてマ板でやってくれ。 904 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 11:34:16 ] いい糞出たわ 905 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 12:28:11 ] 895 もかいてるが、Design&Evolution of C++ を読んでから出直してこいとしか言い様がない 906 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 13:20:10 ] ちゃんとした本を読むと、最初の意見（>>892）を変えなきゃいけなくなるから、 ここで文章の素人達に不完全で不足の多い文章を書かせて、それに向かって そんなの信念があるうちに入らない、適当でしかない、と言って初期設定を維持するつもりなのでは。 907 名前：デフォルトの名無しさん [2008/02/29(金) 14:21:08 ] ミスを犯すのは常に人。 初心者にはそれがわからんのです。 908 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 17:53:25 ] 同じ予約語に3つも4つもまったく違った意味を与えたり 機能を作るたびに別の目的に悪用されて、同じような機能を何度も付け足す羽目になったり 無節操に記号に新しい意味を与えまくってパースを複雑怪奇にしたり わざとミスさせようとしてるとしか思えませんが 909 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 17:55:11 ] マジレスすると無節操に記号に新しい意味を与えまくってもパースは複雑怪奇にはならない。 910 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 18:06:13 ] 例えば不等号なんぞを無理矢理カッコ的なものに仕立てたせいで どれだけの脳内パーサが誤作動してると思う？ includeで使ってるからってなんも考えずにプリプロセッサの世界からコンパイラの世界に 持ち込んだバカのせいじゃないか 違うか 911 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 18:08:29 ] 無知なまま何を「思っ」たところで的外れなだけだから、 無知でなくなるための行動を起こすべきだろうね。既に本も薦められているのだし。 「何故それはそうでなければならなかったのか」という話に関して、 C++ほどシリアスでプラグマティックな内容盛り沢山の言語もそうは無い。 他の言語が「だってそのほうがきれいなんだもん」くらいの理由で決めちゃうところでも、 C++は「現実」を相手に、全然別の戦いをし続けてきたからな。 今の君の頭からは、>>892を裏付ける話は一切出てこないから、マシな頭になる努力をまずしよう。 912 名前：デフォルトの名無しさん [2008/02/29(金) 18:11:01 ] 何も考えていないことにしたい人が 考えの跡をしこたま記した本をこわがってるスレはここですね 913 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 18:15:41 ] じゃあ何をどう考えてるのか教えてくれよ 例えばstaticという語がバラバラのまったく違う4つの意味を持っていた方がよいと考えた理由教えて その本に書いてあるんだろ 914 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 18:21:40 ] ああ、これが>>906の読んだ展開か 915 名前：デフォルトの名無しさん [2008/02/29(金) 19:09:57 ] >>911 Javaやスクリプト言語は「現場の実情」に応える方向で発展したけど、 C++はそれ以前に「数学的現実」に足をすくわれ続けているような。 slice_arrayが動かないとかvector<bool>がコンテナじゃないとか。 テンプレートなんて、パースできなくてtypenameキーワードなんてものが 必要になった時点で常識的には破綻したというべきだし、 チューリング完全性が明らかになった時点でもう一度破綻している。 こうなるくらいだったらC++コンパイラにMLインタプリタでも組み込んだ方がマシ。 916 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 19:17:25 ] >>913 残念ながら、無名名前空間でファイルスコープのstaticを排除して、 C++のstaticは静的メンバという意味しか持たないようになったという流れなんだが。 917 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 19:30:19 ] >>915 ＞テンプレートなんて、パースできなくてtypenameキーワードなんてものが ＞必要になった時点で常識的には破綻したというべきだし、 これは理解できるとして ＞チューリング完全性が明らかになった時点でもう一度破綻している。 こっちはなぜ？ 918 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 19:51:55 ] メタプログラミングなんて邪悪だしJavaに無いし要らないってこと。 C++ の利用者は喜んで便利に使ってるが、それはそいつらが悪趣味な せいであって、断じてテンプレートの利便性を証明するものではない。 919 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 19:53:11 ] テンプレートはあくまでもジェネリクス用の構文であって ありとあらゆることに悪用できる万能の箱として用意されたものではないだろ C++マニアはそれが嬉しいんだろうけど、やりたい放題出来ちゃうという意味ではgoto文と大して変わらん メタプログラミングをさせたいのなら、最初からそれ用の仕組みを作るべきなんじゃないのか 920 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 19:59:20 ] テンプレートメタプログラミングは「発見」されたのだ！とか誇らしげに言ってるC++信者とかたまにいるけど それって結局は自分らが加えた仕組みが何をもたらすのか、誰もわかってなかったってことじゃないの あ、C++は全てにおいて考え抜かれた言語だから当然DnEには想定の範囲内だったと書いてあるんですよね ｻｰｾﾝ 921 名前：デフォルトの名無しさん [2008/02/29(金) 19:59:29 ] テンプレート、ポインタ、動的確保はgotoと同じく排除しよう 現物使用は避けるべき STLを主軸に据える 922 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 19:59:49 ] あんまり本気で主張するつもりはないけど： Javaのバイトコードは本来ポータビリティのためのものであって、直接バイトコードをいじって なんでもできる万能の素材として用意されたものではないだろ DI 信者はそれが嬉しいんだろうけど、やりたい放題出来ちゃうという意味ではアセンブラと大して変わらん メタプログラミングをさせたいのなら、最初からそれ用の仕組みを作るべきなんじゃないのか という状況と対比するとC++の方がまだ健全に思える。 923 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 20:02:05 ] >>921 矛盾していないか？テンプレートとSTLとか。 924 名前：デフォルトの名無しさん [2008/02/29(金) 20:05:36 ] 現物 = テンプレート、ポインタ、動的確保 ラッパー　= STL 925 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 20:05:38 ] try-catch文の醜悪さに比べれば、丁寧に書かれたgoto文の例外処理の方がずっと読みやすいし美しいと思う ごめん関係なかった 926 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 20:06:49 ] >>919 Cのプリプロセッサでジェネリクス実現しちゃう人だっていたんだから、 C++でそれ用の構文を用意したのは一歩進化だろ。 C++0xでconstexprも用意されたし、さらに一歩前進してるじゃないか。 なんか技術与えられたら、想定外のことに使おうとするのはプログラマの悪い癖だと思うけど。 927 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 20:42:43 ] >>919 >メタプログラミングをさせたいのなら、最初からそれ用の仕組みを作るべきなんじゃないのか shiroさんも最近似たこと言ってたね。 ttp://reddit.com/info/62o9s/comments/ ＞Lispマクロを言語に入れない理由として、 ＞よく「文法が変わるから他人の書いたコードが読めなくなる」と言われますが、 ＞カンマ演算子をこんな使い方したらもう充分読めないでしょうってことです。 928 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 20:43:47 ] >>926 > なんか技術与えられたら、想定外のことに使おうとするのはプログラマの悪い癖だと思うけど。 限界を試すのは重要と思われ。 ジャンボジェットのお披露目でバレルロールだっけ？　やっちゃったテストパイロットみたいに。 それをプロダクトに積極的に使おうとかやりだすと、ちょwww だけど。 929 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 21:24:04 ] >>920 ちょっと論点のずらし方が卑怯すぎて気持ち悪いなぁ、君は。 DnEが証明するのは、「何も考えていないわけではないこと」であって、「すべてを考えていたこと」ではないよ。 そして、少しでも「考えていたこと」があれば、>>892が馬鹿なことを言っていたことになるのを、忘れちゃダメだよ。 930 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 22:32:22 ] C++でgotoなんて危険すぎて使えんわ。 そのための例外なのに。 931 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 22:39:45 ] お前は全国の後藤さんを敵に回した 932 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 22:40:48 ] gotoさんの髪茹でたい 933 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 22:59:39 ] ここってなんのスレだったっけ？ 934 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 23:07:04 ] 次スレ建てました pc11.2ch.net/test/read.cgi/tech/1191754720/ 935 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 23:11:43 ] >>933 美少女中学生が顔を赤らめながら指の隙間からチラチラと覗くスレ 936 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 23:34:59 ] 大体他人が自分自身と一緒にPCを見ていなければ、顔は赤らめても赤らめなくてもどうでも良いけど 恥ずかしがって指の隙間から顔を隠しつつ見なくてもいいだろ。 最近の子供は意識の根底に公私混同が見られて将来が危ぶまれるな。本当にしっかりしてほしい。 937 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 01:30:58 ] まあ、繰り返しになるが、DnE 読んでから出直せとしか言い様がない。 あれは C++ 信者でない人にとっても、どのような方針で言語を拡張していくと こういうトンでもないことになってしまうのかという様子が詳細に書いてある という点で非常に勉強になりますよ。C++ スレで煽るためにも、 すぐ反論されないように基礎知識を磨いておくことも重要です。 まずは敵を知ることからです。 というわけで DnE 読んでから出直してください 938 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 02:04:38 ] 了解です。 939 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 02:33:45 ] try節ローカルなオブジェクトをcatch節で見られるようにさえなれば何でもいいよ 940 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 02:35:39 ] それは同意 Hoge* p; try{ p= new Hoge(); }catch(){ } とかダサすぎる pそこに置く意味ねぇだろと 941 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 03:29:56 ] >>939-940 try{ Hoge* p = new Hoge(); }catch(){ } 仮に catch の中で p が見れたとして、 new Hoge() から例外が飛んだ場合は p の初期化が済んでないわけだが、そんなものを見られるようにして何に使うの？ 942 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 08:44:04 ] >>941はわざとか？天然か？ 943 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 08:54:03 ] これがポインタではなくデストラクタのあるクラスのインスタンスだと考えると スコープの差異による影響は? 944 名前：デフォルトの名無しさん [2008/03/01(土) 09:59:01 ] 確かに>>940は例が悪いな 945 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 10:10:34 ] 例が悪さが、他人の頭の悪さを引き出したケース。 946 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 10:32:56 ] 初心者スレ行けと 947 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 18:00:25 ] 上の例ならスマートポインタ使うよな。 948 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 18:36:38 ] ぬるぽ 949 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 19:54:46 ] 華麗にスルー 950 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 19:55:59 ] >>941 using { 　Hoge* p = NULL; } try { 　p = new Hoge(); } catch(...) { 　// p を使用 } こうすればいい。 951 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 19:56:52 ] 突っ込んじゃ負けとかいうゲームですか？ 952 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 20:00:30 ] コンストラクタの中で例外を投げるなんて変態すぎる。 953 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 20:01:36 ] RAII全否定ですか 954 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 20:04:00 ] >>952 m9（＾Д＾）ﾌﾟｷﾞｬｰ www.kijineko.co.jp/tech/superstitions/dont-throw-exception-from-constructor.html 955 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 20:04:10 ] RAII（）笑 956 名前：952 mailto:sage [2008/03/01(土) 20:05:55 ] (´；ω；`)おっおっううぇああぁああぅぅおぉぉおお 957 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 20:09:17 ] C++ ならデストラクタ使えよってことなんだろう。 958 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 20:10:34 ] >>956 お前はたぶんオレと同じスレをみている さぁガイドライン板に帰ろう 959 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 20:15:25 ] 泣いたらスカッとしました。 960 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 21:44:46 ] 関係なかった俺まで泣いた 961 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 00:30:37 ] >>954 切られている「比較的有名なサイト」ってこれだよね、たぶん。 C MAGAZINE - プログラミングの禁じ手Web版 C++編 ttp://www.cmagazine.jp/src/kinjite/cpp/ 適当にうろうろして見たところ、参考にしている人がそれなりにいる様子。 初心者が鵜呑みにするとまずいことを広められるのは困るなー。 962 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 00:41:02 ] C編はいいんだけどね 963 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 01:03:15 ] これ訂正してもらえないの？ いつまでもWeb上に残ってると勘違いするやつが後を絶たないと思うんだけど。 特にポインタのメンバが不定値になるとか、初期化子も知らないような書き方だし。 それともCマガの中の人は確信犯なんだろうか。 964 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 01:28:38 ] エキスパートなお前らの間ではコンストラクタで例外投げてもOKって判断なの？ 965 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 01:30:54 ] 自分では投げない場合も、投げられた場合への配慮は必要 966 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 01:32:30 ] >>963 糞ページ、糞本認定だけでいいじゃん。 それだって初心者スレでやるべき事だし。 >>963 初心者スレ行って教えて貰ってこい。 967 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 01:33:16 ] オブジェクトの構築に失敗したのに例外を投げないコンストラクタを持つクラスなんて、 初心者には使わせたくないな。 968 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 01:35:23 ] どっかの腐ったフレームワークの悪影響だろうね 969 名前：964 mailto:sage [2008/03/02(日) 01:41:54 ] 例外を投げないような初期化だけをコンストラクタでやって、 Initialize()とかのメソッドを作ってるんだけど。 なんだ、じゃぁ俺もバンバン例外なげるようにするよ 970 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 01:51:53 ] >>969 今までそう作ってきたなら、あえて変える必要は無いんじゃない。 問題なのは、「安全な処理のみでコンストラクタを実装していること」ではなく、 「安全でない処理に失敗したときに例外を投げないこと」なのだから。 971 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 01:53:18 ] 今気づいたけどスレ違いだな 972 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 08:25:21 ] うっすらと恥ずかしい毛が生えてきた美少女中学生のスリット違い 973 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 10:47:13 ] 古いんだよなアレ今となっては。著者が表に出る活動を凍結してるせいも あるんだろうが。 974 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 15:29:11 ] RAIIイディオムが一般的じゃなかった時代の知識だね 今となっては古臭い 975 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 22:02:27 ] 90年代から知られてるんだけどなw そのための初期化子リストだし。 976 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 22:16:51 ] 自分は何歳の若い美少女に手を付けたことがあるぞ〜って自慢する人がいるよね 俺は中学生が最高だと思いますが。おっぱい 977 名前：デフォルトの名無しさん mailto:sage [2008/03/04(火) 12:43:23 ] 手を付けたことはないが 手に付いたことはある 978 名前：デフォルトの名無しさん mailto:sage [2008/03/04(火) 13:11:08 ] 手を付けたことはないが、 懐かれたことはある。 979 名前：デフォルトの名無しさん mailto:sage [2008/03/04(火) 22:05:29 ] おまえらここは0x歳の美少女に手をつけるスレじゃないぞ 980 名前：デフォルトの名無しさん mailto:sage [2008/03/04(火) 22:33:52 ] 8歳未満はさすがにちょっと 981 名前：デフォルトの名無しさん mailto:sage [2008/03/05(水) 00:10:09 ] 何進なのかが問題だ 982 名前：デフォルトの名無しさん mailto:sage [2008/03/05(水) 00:14:59 ] 0頭でC系なら8進だろ、で1桁だから8歳未満 983 名前：デフォルトの名無しさん mailto:sage [2008/03/05(水) 00:15:30 ] x が数値として使われている以上、34進数以上だろう。 そして、34進数以上のどの進数だろうが、 0x は 33 になる。 X と x を使い分けるとなってくると話は変わってくるが・・・。 984 名前：デフォルトの名無しさん mailto:sage [2008/03/05(水) 00:28:38 ] 33で美少女はねーよｗってかそろそろスレチだからおわろー 985 名前：デフォルトの名無しさん mailto:sage [2008/03/05(水) 00:29:50 ] つか、スレ自体が終わりそうだし 986 名前：デフォルトの名無しさん mailto:sage [2008/03/05(水) 01:40:31 ] そういえば1000が近いな

---

---

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

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