1 名前:デフォルトの名無しさん [2006/06/05(月) 02:04:07 ] どんな感じになるの?
75 名前:デフォルトの名無しさん mailto:あげちゃう [2006/06/24(土) 01:13:05 ] TR1の本キタ━━━━━━(゚∀゚)━━━━━━ !!!!! www.amazon.com/gp/product/0321412990/ www.aw-bc.com/catalog/academic/product/0,1144,0321412990,00.html Pete Beckerハァハァ www.petebecker.com/
76 名前:デフォルトの名無しさん mailto:sage [2006/06/24(土) 01:37:47 ] >>75 本を出す意義がわからん。 ↓のドラフトや boost の実装、ドキュメントで十分だろ。 www.open-std.org/jtc1/sc22/wg21/
77 名前:デフォルトの名無しさん mailto:sage [2006/06/24(土) 02:37:21 ] EffectiveSTLのTR1に合わせた改訂予定はあるのかな
78 名前:デフォルトの名無しさん mailto:sage [2006/06/24(土) 05:35:16 ] ライブラリもいいけど、早いとこ concept や rvalue reference 決めねえと間に合わなくなると思うんだがな。こいつら入ったら ライブラリ大幅に書き直しじゃん?
79 名前:デフォルトの名無しさん mailto:sage [2006/06/24(土) 09:49:39 ] >>75 Peteが出すんだから、出す意味のある内容なんじゃないのかね。 >>78 0xは2009らしいから、ライブラリも頑張って全面的に書き直すんじゃないのかね。 C++って本当、永遠に仕様が確定しそうにないよな。
80 名前:デフォルトの名無しさん mailto:sage [2006/06/24(土) 13:02:27 ] C++は完璧ではないし、完璧になることはあり得ない。常に進化し続ける。 とは禿の言葉だっけか
81 名前:デフォルトの名無しさん mailto:sage [2006/06/24(土) 14:31:54 ] 常に進化し続けるのはいいが仕様が確定しないと処理系が出てこないわけで。
82 名前:export mailto:sage [2006/06/24(土) 14:55:05 ] すみません。 私を知っている人はいますか?
83 名前:・∀・)っ-○◎●新世紀ダンゴリオン ◆DanGorION6 [2006/06/24(土) 15:14:38 ] 仕様があるのにどの処理系でも未だサポートされないキーワードの典型ですな
84 名前:デフォルトの名無しさん mailto:sage [2006/06/24(土) 15:42:03 ] name lookup ruleも永遠に定まらないだろうな。
85 名前:・∀・)っ-○◎●新世紀ダンゴリオン ◆DanGorION6 [2006/06/24(土) 15:46:48 ] ガベコレでも標準ライブラリに入れて欲しいと思うの俺だけ?
86 名前:デフォルトの名無しさん mailto:sage [2006/06/24(土) 16:53:21 ] ガベコレが必要なのはCだろう... shared_ptrは再帰デストラクタ失敗するのが弱点だよな。
87 名前:デフォルトの名無しさん mailto:sage [2006/06/24(土) 17:23:13 ] >>86 > shared_ptrは再帰デストラクタ失敗するのが弱点だよな。 なんのこと?
88 名前:デフォルトの名無しさん mailto:sage [2006/06/24(土) 17:30:52 ] 循環参照のことでは?
89 名前:デフォルトの名無しさん mailto:sage [2006/06/24(土) 18:50:37 ] >>82 concept の導入によりテンプレートの定義と実装を分けることが 可能になれば、あるいは再デビューできるかも試練よ
90 名前:デフォルトの名無しさん mailto:sage [2006/06/24(土) 19:01:55 ] >>78 >0xは2009らしいから、ライブラリも頑張って全面的に書き直すんじゃないのかね。 現状の年2回のミーティングじゃ3年なんてあっと言う間だろう。 N2004より >The following proposed changes will cause the C++0x schedule >to slip if the committee does not commit to them by the end of >the October, 2006 meeting, ...
91 名前:デフォルトの名無しさん mailto:sage [2006/06/24(土) 20:46:20 ] 200C年くらいに出れば御の字だよね
92 名前:デフォルトの名無しさん mailto:sage [2006/06/24(土) 21:04:49 ] >>91 6198年後かよ
93 名前:デフォルトの名無しさん mailto:sage [2006/06/24(土) 23:26:48 ] >>83 でも予約だけはされてんのな。
94 名前:デフォルトの名無しさん mailto:sage [2006/06/25(日) 16:38:34 ] 予約じゃないですよ。 既に規格の一部です。
95 名前:デフォルトの名無しさん mailto:sage [2006/06/26(月) 08:09:14 ] 予約だし、規格の一部だよ。
96 名前:デフォルトの名無しさん [2006/06/29(木) 22:23:00 ] そういやどうして「予約語」っていうんだろう
97 名前:デフォルトの名無しさん mailto:sage [2006/06/29(木) 23:45:12 ] >>96 字句は識別子としての要件を満たしているから。 だけど文法上特別な意味を持たすために、 識別子として使えないようコンパイラがその字句を「予約」している。
98 名前:デフォルトの名無しさん mailto:sage [2006/06/30(金) 00:10:26 ] まあ「予約」語は誤訳みたいなもんで、(特に「予」め) 除外語がreserved workの訳には適当。
99 名前:デフォルトの名無しさん mailto:sage [2006/06/30(金) 01:10:08 ] うはw やべぇ concept_map 凶悪 concept_map InputIterator<int> { typedef int value_type; typedef int reference; typedef int* pointer; typedef int difference_type; int operator*(int x) { return x; } }; copy(1, 17, ostream_iterator<int>(cout, " ")); // prints: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
100 名前:デフォルトの名無しさん mailto:sage [2006/06/30(金) 09:43:52 ] >98 「除外」のほうが違和感がある
101 名前:デフォルトの名無しさん mailto:sage [2006/06/30(金) 12:53:14 ] 「お客様、そこは除外席ですので、他の席をお使い下さい」
102 名前:デフォルトの名無しさん mailto:sage [2006/06/30(金) 13:51:26 ] >>98 中学校からやり直せ。 いや、おまえは英語を読むな。
103 名前:デフォルトの名無しさん mailto:sage [2006/06/30(金) 18:43:40 ] >>99 ヘタにガリガリ書くコーディングが減っていいんじゃないか?
104 名前:デフォルトの名無しさん mailto:sage [2006/07/10(月) 12:59:49 ] int operator*(int x) { return x; } はやりすぎと思うが。 話題もないので張っときます。 www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2051.htm Strong candidates for TR2 include: * Filesystem (accepted) * Thread support * Date and time * Network file support * Consistent system/OS error reporting * Range-types, to complement iterators * String algorithms * Optional/Nullable values * Range-checked numeric-casts * 'Lexical' casts * typesafe 'any' class * interval arithmetic * Unlimitted precision integer type
105 名前:デフォルトの名無しさん mailto:sage [2006/07/10(月) 20:46:42 ] >>104 Thread単体でサポートしてもなぁ。 ACE見たく非同期関連のフレームワークと一緒でないとあんまり役に たたない様な気がするけど。 (boost.)lexical_castはspiritがあるのでちっとも使わん。
106 名前:デフォルトの名無しさん mailto:sage [2006/07/11(火) 03:12:35 ] >* typesafe 'any' class Boostにある、あれをそのまま盛り込むのだろうか。 >* Unlimitted precision integer type まあ、簡単につかえる標準ライブラリは欲しいかな。
107 名前:デフォルトの名無しさん mailto:sage [2006/07/11(火) 06:56:10 ] 基本的には同じ Any Library Proposal for TR2 www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1939.html かなり強力 Proposal for an Infinite Precision Integer for Library Technical Report 2, Revision 1 www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2020.pdf
108 名前:デフォルトの名無しさん mailto:sage [2006/07/12(水) 22:26:27 ] >>105 でもC++に標準でスレッドサポートされる、というのは大きいんじゃまいか。 もしかしたら将来のCでもサポートされるかもしれんし。
109 名前:デフォルトの名無しさん mailto:sage [2006/07/12(水) 22:42:35 ] tr2でXMLとかネットワークとかマジですか 実現したらかなり協力だなぁ
110 名前:デフォルトの名無しさん mailto:sage [2006/07/12(水) 23:06:20 ] この調子で行けばC++ 2xにはGUI関連が標準ライブラリに入るに違いない。
111 名前:デフォルトの名無しさん mailto:sage [2006/07/12(水) 23:28:26 ] Boostで便利なのが軒並み入ってるな。 それ以外の勢力は元気なくてさみしい。
112 名前:デフォルトの名無しさん mailto:sage [2006/07/14(金) 02:28:31 ] C++0xに対応したMSのコンパイラはいつ出るんだろ。 規格が決まってから、実装するまで何年ぐらいかかるのかな。
113 名前:デフォルトの名無しさん mailto:sage [2006/07/14(金) 03:00:55 ] 過去の例から考えると10年くらいか orz
114 名前:デフォルトの名無しさん mailto:sage [2006/07/14(金) 13:30:29 ] boost 1.34 には tr1が入るみたいだから、 boostからtr1が使っている部分だけ抜き出してそれをVC++用に使うようにすればいい といってみるテスト
115 名前:デフォルトの名無しさん mailto:sage [2006/07/14(金) 16:02:33 ] そういえば、いまさらで馬鹿にされる質問かもしれないけど、 新しいライブラリの名前空間はどうなるんだろう。 まさか tr1 などというかっこ悪い名前空間のままだったりはしないよね。 でも、stdに押し込むと、既存のライブラリと衝突したりしないのかな
116 名前:デフォルトの名無しさん mailto:sage [2006/07/14(金) 16:06:59 ] >>115 衝突しないようにstdに入れるんじゃまいか?
117 名前:デフォルトの名無しさん mailto:sage [2006/07/16(日) 01:56:20 ] 今はstd::tr1みたいだけど、最終的にはどうなるんだろね。
118 名前:デフォルトの名無しさん mailto:sage [2006/07/16(日) 09:12:22 ] stdにいれるに決まってるじゃん。 けどJavaみたいに階層構造になっているのもいいよな。 importってのは、#includeとusingをうまく組み合わせていると思う。
119 名前:デフォルトの名無しさん mailto:sage [2006/07/16(日) 10:13:57 ] 階層化する前に、名前空間の記述の簡易化をはやく標準化して欲しいよ
120 名前:デフォルトの名無しさん mailto:sage [2006/07/16(日) 10:46:32 ] namespace com { namespace example { namespace myproj { /* */ } } } ってめんどくさいから、例えば namespace com::example::myproj { /* */ } とかね。 ふと思ったんだけど、C++0xはライブラリ以外の部分はどう変わるんだろう。
121 名前:デフォルトの名無しさん mailto:sage [2006/07/16(日) 12:06:35 ] draft October 2005 www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf
122 名前:デフォルトの名無しさん mailto:sage [2006/07/16(日) 15:01:35 ] TR1のMathematical special functionsに球面調和関数が入ってるのね・・・ 昨今のPRT人気の影響なんだろうか
123 名前:デフォルトの名無しさん mailto:sage [2006/07/17(月) 09:20:31 ] >>121 追加削除あるところはだいたい文字色変えてあるのね。わかりやすくていい。 そこだけざっと見たところ、C99互換以外では、static_assert が増えてるのと、 コンテナやイテレータにちょこっとメンバが増えてるのくらいだな。
124 名前:デフォルトの名無しさん mailto:sage [2006/07/17(月) 11:47:30 ] >>121 ドラフトで800ページオーバーかよ・・・・orz
125 名前:デフォルトの名無しさん mailto:sage [2006/07/17(月) 12:52:37 ] Conceptおもしろいのう… Generic Programming in ConceptC++ www.generic-programming.org/languages/conceptcpp/
126 名前:デフォルトの名無しさん [2006/07/19(水) 18:16:54 ] 予約語 where がなにか違和感 この調子で5W1Hの予約語が追加されたらオモロ
127 名前:デフォルトの名無しさん mailto:sage [2006/07/19(水) 18:57:33 ] この調子では来世紀にはすべての英単語が予約語になってしまうのではないか...
128 名前:デフォルトの名無しさん mailto:sage [2006/07/19(水) 21:58:13 ] 今のところ私は来世紀までには死ぬ予定になっているからへっちゃらです
129 名前:デフォルトの名無しさん mailto:sage [2006/07/19(水) 22:00:17 ] 英単語はどんどん増えるから大丈夫です。 フランス語だとあぶないかもですが。
130 名前:デフォルトの名無しさん mailto:sage [2006/07/20(木) 11:12:13 ] 問題は既存の汎用英単語を新しく作る事だ。
131 名前:デフォルトの名無しさん mailto:sage [2006/07/20(木) 12:22:07 ] 文脈依存のキーワードになるから無問題
132 名前:デフォルトの名無しさん mailto:sage [2006/07/20(木) 12:29:00 ] 既存のものを新しく作るのはかなり難しいだろうな
133 名前:デフォルトの名無しさん mailto:sage [2006/07/20(木) 13:55:34 ] 132だけ読むと、所謂パクリにも技術が要るという風にも読み取れるな。 すみません、関係ないです。はい。
134 名前:デフォルトの名無しさん mailto:sage [2006/07/20(木) 18:37:25 ] 活用や接頭接尾語まで予約されたら悪夢 ってどんどん無関係な話題になってないか?
135 名前:デフォルトの名無しさん mailto:sage [2006/07/20(木) 21:33:30 ] じゃぁ、「もしこの英単語がC++の予約語になったら」でいってみようか。
136 名前:デフォルトの名無しさん mailto:sage [2006/07/20(木) 22:04:17 ] hage
137 名前:デフォルトの名無しさん mailto:sage [2006/07/20(木) 22:10:03 ] a, i, j, k, m, n, p, q, r, s, t, u, v, w, x, y
138 名前:C++/CLI mailto:sage [2006/07/21(金) 01:17:11 ] spaced keyword(藁
139 名前:デフォルトの名無しさん mailto:sage [2006/07/21(金) 02:08:14 ] fp, argc, argv
140 名前:デフォルトの名無しさん mailto:sage [2006/07/21(金) 02:26:37 ] C++0x 魚の骨かと
141 名前:デフォルトの名無しさん [2006/07/21(金) 05:39:13 ] Boostてどんな物なん?
142 名前:デフォルトの名無しさん mailto:sage [2006/07/21(金) 11:07:18 ] おまえにこのスレは早すぎる
143 名前:デフォルトの名無しさん mailto:sage [2006/07/22(土) 18:56:00 ] >>135 www.linkage-club.co.jp/ExamInfo&Data/BNC%20lemma%20Web.txt
144 名前:デフォルトの名無しさん mailto:sage [2006/08/12(土) 12:18:33 ] コンセプトとやらにテンポラリオブジェクトも含めて欲しい。 戻り値最適化が解決できるし。 STLコンテナやstringと相性いいと思うんだけどな。 T operator+(const T& lhs, const T& rhs) T& operator+(temporary T& lhs, const T& rhs) T& operator=(const T& t) T& operator=(temporary T& t)
145 名前:デフォルトの名無しさん mailto:sage [2006/08/12(土) 18:44:53 ] 右辺値参照と違うの?
146 名前:デフォルトの名無しさん mailto:sage [2006/08/12(土) 18:50:21 ] >>144 move semanticsがC++に導入されるのを期待しよう。
147 名前:デフォルトの名無しさん mailto:sage [2006/08/12(土) 23:04:01 ] うわー、まったくもってそのものな仕様だなこれ。恥ずかし。 でも例えばこう書ければなぁ、と思ってたんだけど move semanticsの仕様でも多分できるよね。 string&& operator+(string&& lhs, const string& rhs) { return lhs += rhs; } boost::arrayあたりはこう書けないと困るのだけど。
148 名前:デフォルトの名無しさん mailto:sage [2006/08/12(土) 23:42:19 ] と、思ったけどexpression templateとmove semanticsを組み合わせれば いらないか・・
149 名前:デフォルトの名無しさん mailto:sage [2006/08/13(日) 01:48:17 ] お前らそーいうネタはどこで勉強してるのですか。
150 名前:デフォルトの名無しさん mailto:sage [2006/08/13(日) 07:49:40 ] www.open-std.org/jtc1/sc22/wg21/docs/papers/
151 名前:デフォルトの名無しさん mailto:sage [2006/09/07(木) 04:19:13 ] tr1::regexって、もっとも多機能なsyntax_option_typeでも ECMAScript相当なんだな。 うーん、今時look-behindがないってのは見劣りするなあ。
152 名前:デフォルトの名無しさん [2006/09/07(木) 14:25:14 ] boostにTR1が実装されたみたいだけど、使ってみようかな
153 名前:デフォルトの名無しさん mailto:sage [2006/09/07(木) 15:22:21 ] >>3 を見るまでautoの存在を忘れていた
154 名前:デフォルトの名無しさん mailto:sage [2006/09/07(木) 16:44:13 ] C++0xの0xが16進プレフィクスではなく 2010年までには出すぞ、という願望の現われだと今日知った。 早く使いたいな。
155 名前:デフォルトの名無しさん mailto:sage [2006/09/07(木) 17:52:59 ] 対応コンパイラが出るのは5年後です
156 名前:デフォルトの名無しさん mailto:sage [2006/09/07(木) 21:27:24 ] C++0xが世に出るのは2109年だよ。 ドラえもんはそれで書かれてる。
157 名前:デフォルトの名無しさん mailto:sage [2006/09/07(木) 23:56:45 ] C++0xの実装は跳ばされる
158 名前:デフォルトの名無しさん mailto:sage [2006/09/08(金) 09:56:08 ] そんなことはないと言いたいところだけど、 exportの例があるからな…
159 名前:デフォルトの名無しさん mailto:sage [2006/09/08(金) 12:25:16 ] あれはどちらかというと、実装の手間を考えずに策定した側に 問題あるような。
160 名前:デフォルトの名無しさん mailto:sage [2006/09/09(土) 00:22:06 ] 実際問題、実装しろとか言われたら嫌な汗出てくるもんな。 C++全体に渡ってそんな感じではあるが。
161 名前:デフォルトの名無しさん mailto:sage [2006/09/09(土) 02:41:12 ] こんなこといいな、できたらいいなと何でもかんでも詰め込んだまではよかったが 不思議なポッケでかなえてくれるドラえもんはいないという点にまで気が回らなかったと
162 名前:デフォルトの名無しさん mailto:sage [2006/09/09(土) 03:24:51 ] exportは一応EDGが3人年かけてかなえてくれたけどな 誰も近寄らなくなったけどw
163 名前:デフォルトの名無しさん mailto:sage [2006/09/09(土) 04:32:41 ] C++は夢いっぱい
164 名前:デフォルトの名無しさん mailto:sage [2006/09/09(土) 09:46:54 ] VC2005で、リンク時のコード生成を行ってるけど、exportじゃ無いのかな?
165 名前:デフォルトの名無しさん mailto:sage [2006/09/09(土) 12:19:22 ] >>164 それは最適化。 たとえば、リンク時にインライン展開するとか。
166 名前:デフォルトの名無しさん mailto:sage [2006/09/09(土) 13:39:37 ] exportが駄目でした、なんてのはどうでもいいが コンパイルは出来るのにそれがC++言語として 正しいかどうか調べ回らないといけないのがつらい ガベージコレクタの*ない*Javaがモダンな言語とは全く思わないが write once, compile anywhereなのはうらやましい
167 名前:デフォルトの名無しさん mailto:sage [2006/09/09(土) 13:45:23 ] 実際、Javaはwrite once、compile once、run anywhereだもんな。 失うものも多いが、楽なのは確かだ。
168 名前:デフォルトの名無しさん mailto:sage [2006/09/09(土) 13:48:10 ] 拡張機能を切ってコンパイルすれば、そこそこ正しくはなる。 ただ、それでも他のコンパイラでコンパイルすると 不完全だと分かる事もよくある話。 難しいもんですな。
169 名前:デフォルトの名無しさん mailto:sage [2006/09/09(土) 14:54:45 ] >167 debug anywhere だけどな
170 名前:デフォルトの名無しさん mailto:sage [2006/09/09(土) 18:08:44 ] Write Once, Run Anywhere, Debug Everywhere!
171 名前:デフォルトの名無しさん mailto:sage [2006/09/09(土) 20:42:30 ] やっぱり、#ifdef は要るよ
172 名前:デフォルトの名無しさん mailto:sage [2006/09/09(土) 23:32:00 ] そんなあなたにBoost MPL。
173 名前:デフォルトの名無しさん mailto:sage [2006/09/11(月) 06:00:00 ] Debug Everyday!
174 名前:デフォルトの名無しさん mailto:sage [2006/09/11(月) 21:11:16 ] char を UTF-8、wchar_t を UTF-16 として認識する標準ライブラリおよび コンパイルオプションが欲しい。
175 名前:デフォルトの名無しさん mailto:sage [2006/09/11(月) 21:55:25 ] >>174 そういうlocale(特にcodecvt)を作ればいいという話ではないのか?
176 名前:デフォルトの名無しさん mailto:sage [2006/09/11(月) 22:11:50 ] STLのlocale周りは、はっきり言って無駄だから、 さっくり削除してほしいと思っているのは自分だけ?
177 名前:デフォルトの名無しさん mailto:sage [2006/09/11(月) 22:13:38 ] 実装の話?仕様の話?
178 名前:デフォルトの名無しさん mailto:sage [2006/09/11(月) 22:16:05 ] >>174 > char を UTF-8 どういうこと? charというか、mbsのこと?
179 名前:デフォルトの名無しさん mailto:sage [2006/09/11(月) 22:17:32 ] >>174 > wchar_t を UTF-16 として どういうこと? UTF-16じゃなくて、UCS-4でなく?
180 名前:デフォルトの名無しさん mailto:sage [2006/09/11(月) 22:18:43 ] >>176 君みたいな人は少ないと思う。
181 名前:デフォルトの名無しさん mailto:sage [2006/09/12(火) 01:02:06 ] サロゲート無しのUCS-2じゃ、やっぱりそのうちUCS-4に駆逐されるというか 邪魔にされる日が来るのかね。 1文字2Bytesは呑めても、4Bytesは呑み込み辛い…様な。
182 名前:デフォルトの名無しさん mailto:sage [2006/09/12(火) 01:24:19 ] しかし1文字2バイトを許容できるのは、日本人が元から2バイト文字に慣れ親しんでいたからであって、 欧米人は1文字2バイトも受け入れがたい存在なのではないかと考えたことがある。 実際のところどうなのかは知らないが。 ちなみに俺は仮名漢字がほとんどの場合、UTF-8でも受け入れ難い。
183 名前:デフォルトの名無しさん [2006/09/12(火) 02:34:51 ] www.open-std.org/jtc1/sc22/wg21/ > News 2006-09-11: The 2006-09 mailing is available (4700 kb tar.gz, .zip 4700 kb) individual papers > News 2006-09-11: The C++ Standard Library Issues List (Revision 44) is available (.tar.gz) > News 2006-09-11: C++ Standard Core Language Issues List (Revision 43) is available, also committee version
184 名前:デフォルトの名無しさん mailto:sage [2006/09/12(火) 13:22:39 ] >>183 (゚∀゚)ktkr 待ってたぜ。これで仕事中こっそり楽し(ry
185 名前:デフォルトの名無しさん mailto:sage [2006/09/13(水) 05:22:20 ] >>182 > 欧米人は1文字2バイトも受け入れがたい存在なのではないかと考えたことがある。 だからこそUTF-8でしょ > ちなみに俺は仮名漢字がほとんどの場合、UTF-8でも受け入れ難い。 日本人の都合なんか知ったこっちゃないし
186 名前:デフォルトの名無しさん mailto:sage [2006/09/13(水) 06:41:57 ] ゴチョゴチョうるさいから、だから言語の規格では文字コード未定義扱いなの。
187 名前:デフォルトの名無しさん mailto:sage [2006/09/13(水) 08:27:03 ] だからさ、char 型なんて廃止して、byte 型にしてほしいぜ 別個に string 型を用意して、string::char を定義して、あとは実装依存でいいと思うんだが
188 名前:デフォルトの名無しさん mailto:sage [2006/09/13(水) 09:48:52 ] charが実装依存ですが? basic_stringテンプレート知らない人ですか、ああそうですか
189 名前:デフォルトの名無しさん mailto:sage [2006/09/13(水) 12:24:08 ] 日本語も読めないのに皮肉を言おうとするとこうなる。
190 名前:デフォルトの名無しさん mailto:sage [2006/09/13(水) 12:54:37 ] uint8_tで何が不満なんだ? > byte_t
191 名前:デフォルトの名無しさん mailto:sage [2006/09/13(水) 18:51:23 ] 8bitとは限らないから…とか?
192 名前:デフォルトの名無しさん [2006/09/13(水) 21:24:18 ] uint8_t i = 32; std::cout << i; とやって、32じゃなくて、空白が出力されたるの嫌やん
193 名前:デフォルトの名無しさん mailto:sage [2006/09/13(水) 21:26:02 ] 1byteを表すchar 文字を表すchar 双方を別々に定義すべきだという主張かと
194 名前:デフォルトの名無しさん mailto:sage [2006/09/13(水) 21:38:12 ] C++ でせっかく char と signed char と unsigned char に分かれたのに、 なんで cout << で全部文字になっちまうんだ?
195 名前:デフォルトの名無しさん mailto:sage [2006/09/13(水) 21:54:36 ] 実際問題、符号ないほうが都合がいいから 文字としてuchar使ってるケースあるし、その辺との兼ね合いでね?
196 名前:デフォルトの名無しさん mailto:sage [2006/09/14(木) 08:34:29 ] >193 そう。バイト単位のデータを表す型と文字を表す型が同一であることが、本気で文字列を なんとかしようという意志の無さの表れではないかと 実体が wchar_t であろうと char であろうと、1文字を1文字として扱えるなら関心はないよね 文字列の仕様なんてたぶんこの先もふらふらするんだから、ある程度距離を取っておいた 方がいいと思うんだな string と encode をセットで別個にライブラリとして定義してもらった方が個人的には嬉しい
197 名前:デフォルトの名無しさん mailto:sage [2006/09/14(木) 08:52:47 ] >>196 文字列(というか文字)を何とかした結果が今の形 char だと思う。 >string と encode をセットで別個にライブラリとして定義してもらった方が個人的には嬉しい ができる柔軟性も、char, wchar_tのおかげと思えば・・
198 名前:デフォルトの名無しさん mailto:sage [2006/09/14(木) 22:37:48 ] char は C との互換性のために残しておく程度でいい std::string と std::wstring 間にろくな互換性無いだろ? これを柔軟性というのか?
199 名前:デフォルトの名無しさん [2006/09/14(木) 23:06:50 ] >>198 そういう意味だったのか。
200 名前:デフォルトの名無しさん mailto:sage [2006/09/15(金) 00:54:03 ] >>198 互換性って例えばどういうこと?
201 名前:デフォルトの名無しさん mailto:sage [2006/09/15(金) 01:44:55 ] >>200 もう血が止まってるんだから、変にいじったりしないの!
202 名前:デフォルトの名無しさん [2006/09/15(金) 09:11:21 ] おねがいします。 自分のファイル名(x.exe)を読み込んで xの部分がAすなわちA.exeだったらaを実行して xの部分がBすなわちB.exeだったらbを実行する っていうようなCのプログラムを教えてください。
203 名前:デフォルトの名無しさん mailto:sage [2006/09/15(金) 09:26:00 ] なんでまた C++0x スレに? もしかしてマルチ?
204 名前:デフォルトの名無しさん mailto:sage [2006/09/15(金) 09:34:41 ] マルチだね どこだか忘れたが別スレで見た >202 あっちのスレに答えが書いてあったぞ
205 名前:デフォルトの名無しさん mailto:sage [2006/09/17(日) 00:49:06 ] C++0xだと既存のC++とは比べ物にならないほどスマートにかけるとかそういう例題なんじゃね? たぶんそんなことはないだろうが
206 名前:デフォルトの名無しさん mailto:sage [2006/09/17(日) 11:10:37 ] おじいさんは、裏山に畑を耕しに行ったんじゃない? たぶんそんなことはないだろうが
207 名前:デフォルトの名無しさん mailto:sage [2006/09/17(日) 15:01:57 ] いいレス思いついた、と思ったら 書き込む前にまず他人に通じるかどうか考えようぜ。
208 名前:デフォルトの名無しさん mailto:sage [2006/09/17(日) 20:43:56 ] >>207 そりゃ無理だ。読む奴が基地外だったら、どんな書き方をしても通じない。 とにかく書きゃいいんだって。
209 名前:デフォルトの名無しさん mailto:sage [2006/09/17(日) 23:24:34 ] 書かれたものがキチガイだと 本当に誰にも通じないけどな。
210 名前:デフォルトの名無しさん mailto:age [2006/11/24(金) 14:31:34 ] N2133 06-0203 Editor's ReportPete Becker 2006-11-03 www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2133.html N2134 06-0204 Working Draft, Standard for Programming Language C++Pete Becker 2006-11-03N2009=06-0079 www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf 新規色分け版 N2135 06-0205 Programming Languages −C++ Pete Becker 2006-11-06 N2134=06-0204 www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2135.pdf 色分けなし版
211 名前:デフォルトの名無しさん mailto:sage [2006/11/24(金) 18:16:23 ] ちなみにADLのところ、3.4.2のルールが書き変わっています。 stringとchar_traitsのところも結構。 "文字"じゃなくてPODなら入れられる。
212 名前:デフォルトの名無しさん mailto:sage [2006/11/24(金) 18:56:53 ] 色の違いだったのね
213 名前:デフォルトの名無しさん mailto:sage [2006/11/24(金) 22:19:20 ] 論文リスト、ちらほら C++09 という記述が出始めたな
214 名前:デフォルトの名無しさん mailto:sage [2006/11/24(金) 22:21:19 ] 2009かあ。もうちょいペース上げてほしいなあ。 これじゃ本格的に使えるのは2010年代半ばになりそうだ。
215 名前:デフォルトの名無しさん mailto:sage [2006/11/28(火) 23:58:39 ] Rvalue referenceって本当に規格にはいるのかね? STLも仕様決め直しだし、それよりなにより、C++はマニア向けの言語になっちゃう… Move semantics、あれば便利なのは確かなんだけど。
216 名前:デフォルトの名無しさん mailto:sage [2006/11/29(水) 01:24:10 ] 一番ほしいのはTemplate aliasesかな
217 名前:デフォルトの名無しさん mailto:sage [2006/11/29(水) 01:31:43 ] >215 標準ライブラリに対する rvalue reference の導入は 下位互換を完全に意識した設計が提案されているので >STLも仕様決め直しだし、 という見方は少し違うような気がします. std::auto_ptr などは deprecated なだけで廃止されるわけでもないですし. というよりか,現在の標準ライブラリにおける rvalue reference 対応の提案は, (いつものことですが) 下位互換の維持のために非常に設計が汚い印象があります. move に対応していない場合 copy に fallback する設計は, たとえば例外送出時のときなどの仕様と動作が極めて煩雑になるのではないか, など個人的には不満も多いです. (この汚さは標準ライブラリにおける rvalue reference 対応がもたらす汚さで, 言語仕様として導入される rvalue reference の仕様とは独立です) 言語仕様としての rvalue reference は, move semantics の導入と同時に, the forwarding problem と呼ばれる非常に重要な問題を同時解決しますし, (この問題の解決も見た目に比してインパクトが極めて大きいと思います) 『便利』程度の恩恵ではなく『マニア向け』の機能でもないと思います. 今現在,そもそも rvalue reference / move semantics 自体が机上の空論ですから, これについて今何を語っても "almost as much of a hoax as Artificial Intelligence" でしかないですが,それを承知であえて, rvalue reference / move semantics は OOP・汎用プログラミング・関数プログラミング・効率・リソース管理・例外安全性 スレッド安全性など,ほぼあらゆるプログラミングパラダイム・概念の全域, あと特にこれらの概念が交錯する領域での貢献が極めて大きい, C++0x における (C++98 以来) 最大の進化だと主張したいです.
218 名前:デフォルトの名無しさん mailto:sage [2006/11/29(水) 01:42:23 ] とマニアが言っております
219 名前:デフォルトの名無しさん mailto:sage [2006/11/29(水) 01:48:06 ] いっそのこと名前空間std0xに新しいライブラリを作って、名前空間stdごと非推奨にしてしまえ。
220 名前:デフォルトの名無しさん mailto:sage [2006/11/29(水) 12:59:00 ] >>219 明暗!
221 名前:デフォルトの名無しさん mailto:sage [2006/11/29(水) 16:09:12 ] 言い得て妙な変換だなw
222 名前:デフォルトの名無しさん mailto:sage [2006/11/29(水) 17:42:23 ] namespace std0x { using namespace std; }
223 名前:デフォルトの名無しさん mailto:sage [2006/11/30(木) 08:53:29 ] namespace std0x = std;
224 名前:デフォルトの名無しさん mailto:sage [2006/11/30(木) 13:36:58 ] もうここはあれだ、Andrei Alexandrescu あたりに超変態的 template テストケース書いてもらってさ、これにパスしないと C++0x 準拠とは 名乗らせないってのはどうよ。 もうさ、これまでみたいなコンパイラ毎の ifdef 分岐の嵐はさすがにもう 勘弁して暮れって感じ
225 名前:デフォルトの名無しさん mailto:sage [2006/11/30(木) 13:50:21 ] >>224 テストケースには boost 使えばいいんじゃねーの。 mpl ができてから、それ使ってコーディングした部品も増えてるし。
226 名前:デフォルトの名無しさん mailto:sage [2006/11/30(木) 14:41:25 ] >>224 Discriminated Unions みたいに変態的すぎて すべてのコンパイラでコンパイルが通らないなんて ことになりそうだなw
227 名前:デフォルトの名無しさん mailto:sage [2006/11/30(木) 16:22:54 ] BOOST_FOREACHは実際そうなので それぞれのコンパイラのバグでエミュレートしている 恐ろしい
228 名前:デフォルトの名無しさん mailto:sage [2006/11/30(木) 16:52:46 ] "D&E"もC++0xに合わせて更新してくれ。 "Inside the C++ Object Model"でもいいけど、やつは既にC#の一味か…
229 名前:デフォルトの名無しさん mailto:sage [2006/11/30(木) 20:58:15 ] >>217 その熱い主張に興味がわいてきた。 rvalue ref.とmove semanticsがどういうものか、もう少し語ってはくれまいか。
230 名前:デフォルトの名無しさん mailto:sage [2006/11/30(木) 23:42:40 ] >>217 Cryoliteたん?
231 名前:デフォルトの名無しさん mailto:sage [2006/12/05(火) 21:36:18 ] >>215 です。 >>217 さんのおっしゃることには技術的に白黒の付く部分については同意です。 けど、やっぱりそうなるとC++はどんどんマイナー言語になっていくと思います。 じゃあ拡張しなければいいのかというとそういうわけでもないんですが… C++の前に萌えた言語(システム)がCLOSである私としては切ない気持ちです。> マイナー化
232 名前:デフォルトの名無しさん mailto:sage [2006/12/05(火) 22:07:30 ] rvalue referenceってなんなのさ?
233 名前:デフォルトの名無しさん mailto:sage [2006/12/05(火) 22:37:14 ] ここで。 A Brief Introduction to Rvalue References www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2027.html
234 名前:デフォルトの名無しさん mailto:sage [2006/12/05(火) 22:49:58 ] >>233 よく纏まっていてわかりやすいね。
235 名前:デフォルトの名無しさん mailto:sage [2006/12/06(水) 09:50:22 ] auto_ptr とかホントは廃止したくてたまらないんだろうなあ>委員会 とりあえず、Deleter 指定できる unique_ptr 使って std::move してね☆ とか言いつつ、Effective C++ で「shared_ptr 使え、以上」とか書かれそう
236 名前:デフォルトの名無しさん mailto:sage [2006/12/06(水) 12:13:53 ] >>235 一度、標準に採用されたらベンダーの独自拡張じゃないから安心して使ってねっていう 意味を暗に含むから非推奨にはなっても廃止はまずありえんだろうな。
237 名前:デフォルトの名無しさん mailto:sage [2006/12/07(木) 04:52:50 ] ていうか、その非推奨じたいをC++はもっとガンガンやるべき。 そこら辺のGURUな人々に無茶苦茶やらせるより先に 標準もっと仕事しやがれこんちくしょー、みたいな。 ストラスストラップのハゲの残り少ない髪の毛引き抜いて クローンハゲを量産して、規格の策定に充てるとかすればいいんじゃないのかと思った。
238 名前:デフォルトの名無しさん mailto:sage [2006/12/08(金) 18:26:39 ] その前にrvalue referenceが導入されるのか?って感じだが かなり大部分のライブラリに変更が必要になるし
239 名前:デフォルトの名無しさん mailto:sage [2006/12/09(土) 01:08:57 ] ここで>>217 に戻る。
240 名前:デフォルトの名無しさん mailto:sage [2006/12/09(土) 01:15:54 ] まあ導入されれば便利にはなるんだけどね。 便利なだけじゃなくパフォーマンスゲインも5倍以上になるし
241 名前:デフォルトの名無しさん mailto:sage [2006/12/09(土) 05:11:42 ] >パフォーマンスゲインも5倍 なにその機動戦士ガンダム
242 名前:デフォルトの名無しさん mailto:sage [2006/12/09(土) 09:13:34 ] こいつをお前のC++コンパイラに取り付けろ。 すごいぞぉ。 コンパイラの性能は5倍以上跳ね上がる。
243 名前:デフォルトの名無しさん mailto:sage [2006/12/09(土) 12:42:51 ] コンパイル時間も5倍に…
244 名前:デフォルトの名無しさん mailto:sage [2006/12/09(土) 12:56:47 ] >>243 そのコンパイラをコンパイルするときに5倍コンパイラを使えばへっちゃらですよ
245 名前:デフォルトの名無しさん mailto:sage [2006/12/09(土) 16:56:31 ] 父さん、言語拡張症にかかって…
246 名前:デフォルトの名無しさん mailto:sage [2006/12/09(土) 22:35:18 ] これからは言語のモジュール化ですよ。
247 名前:デフォルトの名無しさん mailto:sage [2006/12/10(日) 07:07:20 ] >>244 おまえマジで頭いいな じゃあそのコンパイラをそのコンパイラでコンパイル したらさらに5倍早くなるんじゃね?
248 名前:デフォルトの名無しさん mailto:sage [2006/12/10(日) 08:50:22 ] >>247 お前マジ天才じゃね?
249 名前:デフォルトの名無しさん mailto:sage [2006/12/10(日) 10:16:27 ] 最終的には今日コンパイルすると昨日完了するようになる
250 名前:デフォルトの名無しさん mailto:sage [2006/12/10(日) 10:20:32 ] そのコンパイラでコンパイラをコンパイルさせてください。
251 名前:デフォルトの名無しさん mailto:sage [2006/12/10(日) 10:53:35 ] おまいらホント暇だなw
252 名前:デフォルトの名無しさん [2006/12/10(日) 17:55:34 ] 最新のドラフトに static_assert っていうキーワードがあったんだけど、 キーワード増えるのってこれだけかな?
253 名前:デフォルトの名無しさん mailto:sage [2006/12/10(日) 19:57:26 ] ドラフトレベルならもっとがっつりあるぞ。 コンセプトだけでも concept,concept_map,where,axiom,late_check 他にも alignof とか decltype とか constexpr とか
254 名前:デフォルトの名無しさん mailto:sage [2006/12/10(日) 20:04:18 ] autoはC++09に確実に入るんじゃないのかな?
255 名前:デフォルトの名無しさん mailto:sage [2006/12/10(日) 20:17:08 ] 標準委員会、キーワード追加症にかかって…
256 名前:デフォルトの名無しさん mailto:sage [2006/12/10(日) 20:22:14 ] >>254 それはずっと前からキーワード。
257 名前:デフォルトの名無しさん mailto:sage [2006/12/10(日) 20:56:19 ] 意味が変更される予約語はautoだけかな
258 名前:デフォルトの名無しさん [2006/12/14(木) 13:27:42 ] しかしautoはどうかと思う… 型の弱い言語みたいだ
259 名前:デフォルトの名無しさん mailto:sage [2006/12/14(木) 13:32:51 ] 初期化される時点で型が決まってしまうのに、どこが弱いんだか。
260 名前:デフォルトの名無しさん mailto:sage [2006/12/14(木) 14:11:35 ] コンパイル時に型が決定するのだから、弱いわけがないわな。
261 名前:デフォルトの名無しさん mailto:sage [2006/12/14(木) 14:17:45 ] しかしtemplate引数の省略はどうかと思う・・・ 型の弱い言語みたいだ
262 名前:デフォルトの名無しさん mailto:sage [2006/12/14(木) 14:19:49 ] しかしboost.Anyが実装できるのはどうかと思う。 型の弱(ry
263 名前:デフォルトの名無しさん mailto:sage [2006/12/14(木) 19:08:59 ] キャス(ry
264 名前:デフォルトの名無しさん mailto:sage [2006/12/14(木) 20:18:58 ] vo(ry
265 名前:デフォルトの名無しさん mailto:sage [2006/12/14(木) 20:29:55 ] 悲しいかな、reinterpret_castやvoid*などの存在で、 C++が弱い型付けと分類されていることを見かける。
266 名前:デフォルトの名無しさん mailto:sage [2006/12/14(木) 20:44:04 ] まあ強い型付けされるとキーボードも痛みやすいからな…弱くていいんじゃないの
267 名前:デフォルトの名無しさん mailto:sage [2006/12/14(木) 21:48:36 ] その理屈だと、アセンブラは弱い肩か?
268 名前:デフォルトの名無しさん mailto:sage [2006/12/14(木) 23:04:19 ] アセンブラは弱すぎ。虚弱体質だな。
269 名前:デフォルトの名無しさん mailto:sage [2006/12/14(木) 23:12:43 ] 低級言語は型とかないだろ
270 名前:デフォルトの名無しさん mailto:sage [2006/12/14(木) 23:31:02 ] >>265 まさにカタ無しだね
271 名前:デフォルトの名無しさん mailto:sage [2006/12/15(金) 00:04:48 ] しかしこのスレの流れはどうかと思う。 頭の弱い……
272 名前:デフォルトの名無しさん mailto:sage [2006/12/21(木) 11:30:13 ] JIS X3014:2003って、 ISO/IEC 14882:2003の逐語訳じゃないんですね。 省略されているところがあってびっくりしました。 13.3.1.2.3のnon-memberのところ。
273 名前:デフォルトの名無しさん mailto:sage [2007/01/03(水) 19:15:16 ] >>272 JISチームのチョンボで抜けちゃったとかじゃなくて? そういえば、JIS X3014:2003 って買った時期によってPDFの"しおり"があったりなかったり するらしいね。なんか以前、cppll で金返せ的なことを愚痴ってたヤツがいた。
274 名前:デフォルトの名無しさん mailto:sage [2007/01/12(金) 19:40:21 ] シンボルの undef とこっから先 const の機能がほしい スレ違いか?
275 名前:デフォルトの名無しさん mailto:sage [2007/01/12(金) 20:41:03 ] シンボルの undef というか、スコープ付の define がほしい。 ここから先 const はいらんなあ。値を変えるところと変えないところで 関数が分かれてないのは設計ミスだと思う。
276 名前:デフォルトの名無しさん [2007/01/12(金) 22:21:49 ] 派生の禁止はできるようにならんの?
277 名前:デフォルトの名無しさん mailto:sage [2007/01/12(金) 22:29:27 ] ttp://article.gmane.org/gmane.comp.lib.boost.devel/101260
278 名前:デフォルトの名無しさん mailto:sage [2007/01/12(金) 23:23:42 ] あーなるほどね、宣言は出来るけどインスタンスは作れない、と。
279 名前:デフォルトの名無しさん [2007/01/12(金) 23:29:21 ] >>273 >JISチームのチョンボ まことしやかにささやかれてるけど真実味あるなw
280 名前:デフォルトの名無しさん mailto:sage [2007/01/13(土) 03:24:39 ] >>276 あと、派遣の禁止も欲しいよなぁ。
281 名前:デフォルトの名無しさん mailto:sage [2007/01/13(土) 23:29:46 ] >>277 古い。illegal noninheritableがどっかにあったな
282 名前:デフォルトの名無しさん [2007/01/13(土) 23:44:57 ] boostはなんでこのての接頭辞が non なんだろう。 not や um だとなにがまずいんだろう。
283 名前:デフォルトの名無しさん mailto:sage [2007/01/13(土) 23:47:38 ] -ableにnotは不味いだろ。
284 名前:デフォルトの名無しさん mailto:sage [2007/01/13(土) 23:50:06 ] >>283 ttp://msdn2.microsoft.com/ja-jp/library/h278d2d4(VS.80).aspx
285 名前:デフォルトの名無しさん mailto:sage [2007/01/13(土) 23:51:08 ] >>282 英語的にはunが正しい。 何故nonになっているのかは不明
286 名前:デフォルトの名無しさん mailto:sage [2007/01/13(土) 23:56:44 ] im と un を混同したのではないか
287 名前:デフォルトの名無しさん mailto:sage [2007/01/14(日) 08:33:30 ] Boostスレかどこかで非英語圏向けにあえてnon-にしていると聞いたことがある。
288 名前:デフォルトの名無しさん mailto:sage [2007/01/14(日) 17:09:42 ] それは俺の戯言なので真に受けないように
289 名前:デフォルトの名無しさん mailto:sage [2007/01/14(日) 22:53:43 ] Effectice C++ 3版でも突っ込まれてたような
290 名前:デフォルトの名無しさん [2007/01/26(金) 20:55:16 ] en.wikipedia.org/wiki/C%2B%2B0x 右辺値参照についてここでは一言も触れていないけど、C++0xに入るんだよね?
291 名前:デフォルトの名無しさん mailto:sage [2007/01/27(土) 09:21:41 ] 未定
292 名前:wankuma [2007/01/27(土) 19:20:53 ] わんくま加盟求む blogs.wankuma.com/
293 名前:デフォルトの名無しさん mailto:sage [2007/02/19(月) 19:49:16 ] ttp://herbsutter.spaces.live.com/Blog/cns!2D4327CC297151BB!159.entry >we finish the document in 2009, but because ISO takes most of >a year to approve and publish a standard, it would end up as >"C++10" (or, one could uncomfortably imagine, "C++0a").
294 名前:デフォルトの名無しさん mailto:sage [2007/02/19(月) 20:04:02 ] もうC++0fでいいよ。
295 名前:デフォルトの名無しさん mailto:sage [2007/02/20(火) 03:31:04 ] どうせVC7.1であと10年がんばるんですよ
296 名前:デフォルトの名無しさん mailto:sage [2007/02/20(火) 08:41:21 ] >>295 スレ違い。
297 名前:デフォルトの名無しさん mailto:sage [2007/02/20(火) 12:48:39 ] >>157
298 名前:デフォルトの名無しさん [2007/03/03(土) 09:39:19 ] vector<int> v; auto var = v.begin(); と型推論?ぽい事ができる様になるらしいですが、 この時のvarの型は vector<int>::iterator になるんでしょうか それとも vector<int>::const_iterator?
299 名前:デフォルトの名無しさん mailto:sage [2007/03/03(土) 10:30:49 ] 前者でないと困る。 前者なら、後者はauto const varという宣言で済むと思うが。
300 名前:デフォルトの名無しさん mailto:sage [2007/03/03(土) 10:34:50 ] そうすると、vector<int>::const_iteratorではなくて、 cont vector<int>::iteratorになりそうな
301 名前:デフォルトの名無しさん mailto:sage [2007/03/03(土) 11:14:10 ] const_付きのが欲しかったらboost::refと似たようなものを コンテナ側に被せればいいのかな。
302 名前:デフォルトの名無しさん mailto:sage [2007/03/03(土) 11:19:20 ] ああboost::cref使えば良さそうな気がする
303 名前:デフォルトの名無しさん mailto:sage [2007/03/03(土) 11:20:36 ] vector<int> v; auto var = const_cast<const vector<int>&>(v).begin(); これでいいでしょ?
304 名前:デフォルトの名無しさん mailto:sage [2007/03/03(土) 11:24:56 ] vをconstにしたいって話でcref?
305 名前:デフォルトの名無しさん mailto:sage [2007/03/03(土) 11:27:11 ] >>303 それやるならstatic_castだろ。 型名書くのがめんどくさい場合はcrefじゃね?
306 名前:デフォルトの名無しさん mailto:sage [2007/03/03(土) 11:28:58 ] C++0xを知らんけど そんなことしてまでauto使う意味わかんね。
307 名前:デフォルトの名無しさん mailto:sage [2007/03/03(土) 11:31:24 ] どっちかっていうと そんなことまでしてconst_iteratorにする意味わかんね。
308 名前:デフォルトの名無しさん mailto:sage [2007/03/03(土) 11:48:48 ] こういう手もある。まあかえって長ったらしくなっているけど。 boost::range_const_iterator<decltype(v)>::type var = v.begin();
309 名前:デフォルトの名無しさん mailto:sage [2007/03/03(土) 11:57:47 ] アホが来た
310 名前:デフォルトの名無しさん mailto:sage [2007/03/03(土) 12:03:54 ] >>301 cbegin(), cend(), crbegin(), crend() がイイんじゃね? www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1674.pdf 最新のドラフトには載ってるから、採用されたのかな?
311 名前:デフォルトの名無しさん mailto:sage [2007/03/03(土) 12:23:44 ] boost::cref (std::tr1::cref) では無理なのでは? template< class T > T const &as_const( T &x ) { return x; } とか作って使うのではダメなん?
312 名前:デフォルトの名無しさん mailto:sage [2007/03/03(土) 13:02:44 ] #include <iostream> #include <vector> #include <tr1/functional> using namespace std; int main(void) { vector<int> v(10); cout << typeid(v.begin()).name() << endl; cout << typeid(tr1::cref(v).get().begin()).name() << endl; return 0; }
313 名前:デフォルトの名無しさん mailto:sage [2007/03/03(土) 13:16:55 ] boostにconst_beginってなかったっけ?
314 名前:デフォルトの名無しさん mailto:sage [2007/03/03(土) 13:20:02 ] こんにちは、rvalueの型をconst_iteratorにすべく、華麗なるタイプ速度を披露する皆様。
315 名前:デフォルトの名無しさん mailto:sage [2007/03/03(土) 13:27:28 ] >>312 get() 使うなら当然できるけれど,それなら311で良いのでは?
316 名前:デフォルトの名無しさん mailto:sage [2007/03/03(土) 19:12:34 ] v.begin()じゃなくて、begin(v)を使う派なのだが (これだと、配列にもbegin(a)とか使えるし、crbegin(v)なんかもできる) こんな人にも、autoは役に立つのかしらん?
317 名前:デフォルトの名無しさん mailto:sage [2007/03/03(土) 20:28:01 ] auto v = v.begin() const; みたいな呼び出しができたらいいのにと思った
318 名前:デフォルトの名無しさん mailto:sage [2007/03/03(土) 20:38:02 ] const audo v = v.begin() の方がいいかも!?と思った
319 名前:デフォルトの名無しさん mailto:sage [2007/03/03(土) 22:25:17 ] >>318 >>300 流れよめんのか
320 名前:デフォルトの名無しさん mailto:sage [2007/03/05(月) 08:00:08 ] const_付きのが欲しかったらboost::refと似たようなものを コンテナ側に被せればいいのかな。
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 ] 整数演算だけでか?w
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が残ってるかどうかw
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用ということでおk?
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)みたいに一時インスタンス化すればおk?
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 ] ワイドな文字ってよく考えると意味不明だよね
458 名前:デフォルトの名無しさん mailto:sage [2007/06/17(日) 23:37:11 ] 仮にUnicode型があったとして、 UTF-16かUTF-32かはたまたUTF-8かなんてことが処理系定義になりそうだw
459 名前:デフォルトの名無しさん mailto:sage [2007/06/17(日) 23:39:23 ] もうUTF8って名前に決めちゃえばいいよ
460 名前:デフォルトの名無しさん mailto:sage [2007/06/18(月) 08:27:41 ] ちょっと上の話題ぐらい読もうや。
461 名前:デフォルトの名無しさん mailto:sage [2007/06/18(月) 08:36:17 ] >>458 UTF-8はmbs、つまりchar[]だろ。
462 名前:デフォルトの名無しさん mailto:sage [2007/06/18(月) 22:47:59 ] >>452 確かに、2Byte=WORDという意味でword char をwcharとするなら、別に構わないが、wchat_tと 書くと、いかにも規格外で後からつけました感が あって、気に入らんのだがねぇ。それより、 shortやlongといった元からあり、且つwordの様に 変数のサイズを2Byteとか具体的に意識させない型の方が、 自然な感じがするんだけどねぇ。
463 名前:デフォルトの名無しさん mailto:sage [2007/06/18(月) 22:50:57 ] 名前の衝突を避けるにはダサネーミングはある程度しかたない _Boolとかunorderd_mapとかダサすぎるし
464 名前:デフォルトの名無しさん mailto:sage [2007/06/18(月) 23:10:05 ] ライブラリならダサネーミングも仕方ないが、予約語としてはちょっと頂けないってことじゃね? 基本的には同感。(今さらしょうがないけど)
465 名前:デフォルトの名無しさん mailto:sage [2007/06/18(月) 23:10:16 ] virtual void hogehoge() = 0 なんて文法を導入しちゃう言語に対していまさらだな・・・
466 名前:デフォルトの名無しさん mailto:sage [2007/06/18(月) 23:25:01 ] >>462 wchar_tのwは、wideでは?
467 名前:デフォルトの名無しさん mailto:sage [2007/06/18(月) 23:47:46 ] >>450 のshort charとか、long charとかで思い出したけど、 昔、整数型のshort (int) - int - long (int)からの連想で、 浮動小数点数型も、short float - float - long floatにすれば良かったのにと考えたことがあった
468 名前:デフォルトの名無しさん mailto:sage [2007/06/19(火) 00:32:15 ] そうすると、long floatの省略が不可能になる罠。 まあ、long doubleは今でも省略不可だけどサ。
469 名前:デフォルトの名無しさん mailto:sage [2007/06/19(火) 01:35:30 ] >>464 C++では予約語だが、Cではそうではない。
470 名前:デフォルトの名無しさん mailto:sage [2007/06/19(火) 01:41:38 ] _Bool は仕方がないとは思うが失笑したな。
471 名前:デフォルトの名無しさん mailto:sage [2007/06/19(火) 02:37:05 ] wordが2バイト圏の人か 俺の国では2バイトはhalf wordなんだな
472 名前:デフォルトの名無しさん mailto:sage [2007/06/19(火) 02:40:36 ] MASM 使ってたら word = 2 バイトで使ってしまうな。 科学計算やってると word = 8 バイト(double)なことも多いんだがな。
473 名前:デフォルトの名無しさん mailto:sage [2007/06/19(火) 04:43:21 ] >>462 本当にモロ、 >それはお前が勉強不足で且つ経験不足なお子ちゃまってだけな話だ。 で、ワロスwww
474 名前:デフォルトの名無しさん mailto:sage [2007/06/19(火) 20:23:00 ] >>462 そうだね勉強するよ。 そういえば、1語長2語長なんて言葉もあったね。(敢えて言うが、 勿論1語長が1Byteなどと思っているわけではない。) MSのAPIの影響(DWORDとかQWORDとか)でWORDを2byteと仮定して書いてしまった。 あと、wchar_tはwide charなのにword charと書いたのは、素で間違えた。 それはそうと、C++0xが実現するとObjective-C++やC++/CLIはどうなるんだ ろうねぇ。三者三様の完全別言語路線に進むのか?0xに合わせてそれぞれ拡張 するのはは厳しい気がするが。実装的に。
475 名前:474 mailto:sage [2007/06/19(火) 20:25:01 ] 訂正 × >>464 ○ >>473 自分を指して何やってんだが…。
476 名前:474 mailto:sage [2007/06/19(火) 20:29:41 ] また間違えた...。欝だ。 × >>462 ○ >>473 病院でも行ってくる。
477 名前:デフォルトの名無しさん mailto:sage [2007/06/19(火) 20:30:02 ] もともとobj-cはC++とは全然別物だろうに
478 名前:デフォルトの名無しさん mailto:sage [2007/06/19(火) 22:43:01 ] >>474 なんかまだ少し勘違いしてそうだから、念のために書いておくと 必ずしも sizeof(wchar_t)==2 じゃないぞ。 sizeof(wchar_t)==4 な環境・処理系もある。 まぁ、あんまり気を落とすな。
479 名前:デフォルトの名無しさん mailto:sage [2007/06/19(火) 22:58:22 ] gccがsizeof(wchar_t)==4でいいんだったっけ
480 名前:デフォルトの名無しさん mailto:sage [2007/06/19(火) 23:51:09 ] -fshort_wchar フラグを指定したら 2 になるけどな。
481 名前:デフォルトの名無しさん mailto:sage [2007/06/20(水) 02:58:24 ] >>474 C++/CLIは、WG21の中のマイクロソフトの人がどうするかにかかっていると思う。 しかし純然たる研究者だったはずの二人が、 どうしてC++/CLIに必死なのか良くワカランネ。 契約になんか書かれているのかな。
482 名前:デフォルトの名無しさん mailto:sage [2007/06/20(水) 08:40:01 ] C++0x実現まであと9年もあるから大丈夫
483 名前:デフォルトの名無しさん mailto:sage [2007/06/21(木) 22:32:37 ] >479 cygwin 上だと gcc でも 2。
484 名前:デフォルトの名無しさん mailto:sage [2007/06/22(金) 01:24:22 ] 今は亡き、Windows版CodeWarriorでもsizeof(wchar_t)==4。 亡くなって当然w
485 名前:デフォルトの名無しさん mailto:sage [2007/06/22(金) 01:24:48 ] >477 Objective-C++ という Obj-C の C++ 拡張が存在する C++/CLI はどうせコンパイラの開発部分は共通だから強引に組み込むでしょ 直接ぶつかるところは少ないし、そもそも普及に至っては・・・
486 名前:デフォルトの名無しさん mailto:sage [2007/06/22(金) 01:44:27 ] 後半二行、何を言っているのかわからん。 「組み込む」対象は何なんだ?
487 名前:デフォルトの名無しさん mailto:sage [2007/06/22(金) 22:10:11 ] え、VC の cl にだけど
488 名前:デフォルトの名無しさん mailto:sage [2007/06/23(土) 10:46:35 ] マイクロソフトは規格への追従遅いじゃん。 メジャー番号が変わるまで延々放置って事がよくある。 スイッチで切り替えて、細心の規格に追従した動作になるってこともあまりない。
489 名前:デフォルトの名無しさん mailto:sage [2007/06/24(日) 21:02:05 ] C++1xに名前変えるか
490 名前:デフォルトの名無しさん mailto:sage [2007/06/25(月) 06:03:52 ] 何でこんなに時間掛かるんだろう?
491 名前:デフォルトの名無しさん mailto:sage [2007/06/25(月) 09:41:11 ] やっつけでやられても困る。
492 名前:デフォルトの名無しさん mailto:sage [2007/06/25(月) 13:37:16 ] >>490 天才のお前が傍観者だからだよ
493 名前:デフォルトの名無しさん mailto:age [2007/06/25(月) 17:37:29 ] Javaの初期のクラスライブラリみたいな不細工なのは困る。 iostreamだって今になってみれば、設計し直したいところ多数。
494 名前:デフォルトの名無しさん mailto:sage [2007/06/25(月) 19:56:26 ] >>474 ObjC++はコンパイラがC++のバージョン選べるようにしてくれるでしょ。
495 名前:デフォルトの名無しさん [2007/06/26(火) 03:02:50 ] News 2007-06-25: C++ Standard Core Language Issues List (Revision 48) is available News 2007-06-25: The C++ Standard Library Issues List (Revision 49) is available 今までC++相談室に貼ってた JTC1/SC22/WG21 の更新情報は 今回からこっちに貼ることにしました。
496 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 03:12:13 ] C++X の方が魚の骨っぽくて好き
497 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 13:38:12 ] もう規格なんてやめてBoost全部取り込んじゃえよ
498 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 17:06:10 ] それは行き過ぎだろうけど、ライブラリをほかとは別規格にするというのはありだと思う
499 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 17:57:38 ] 古い Fortran みたいにいくつかのレベルに分ければよかったのに、と 時々思うわけさね。
500 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 18:18:06 ] C++はPL/Iを超える化け物言語になりつつあるな。
501 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 22:21:29 ] Javaほどじゃないけどな
502 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 22:24:57 ] は?
503 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 22:31:00 ] またジャバグラマか。
504 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 23:26:45 ] そろそろミーティング回数増やさねえとヤヴァくね? 最近あんま進展ないし、また議論不足で vector<bool> とか auto_ptr みたいな 半端者が生まれちまうぜ
505 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 23:27:57 ] 禿が死ぬまでには出来てると思うから気長に待つよ
506 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 03:44:26 ] なぁに禿が死んだら誰かが代わりに永久脱毛すればいい話
507 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 09:25:40 ] >500 あのALGOL系とCOBOLを無理矢理繋げたような変態言語と比べられても… …いや、的確か
508 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 09:29:07 ] PL/Iを馬鹿にするなー 本当に何でもできる言語なんだぞー あ、でも糞言語だったけどね 消えたし
509 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 09:58:55 ] 他の言語は要らなくなるから、Programming Language/1。
510 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 10:33:28 ] その C++ と Objective-C を無理矢理繋げた変態言語の立場は。
511 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 22:21:53 ] お前ら頭良いんだからサッサと立派な規格でまとめてくれよ
512 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 22:24:43 ] よしきた
513 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 22:27:55 ] 標準ヘッダファイル2chを追加
514 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 22:30:20 ] boostをはじめとするライブラリが整備されている今でこそC++は「使える」言語だと思えるんだけど それらがあんまり無かった時代になんであんなに流行ったのかがいまいちよく分からない
515 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 22:33:48 ] 競争相手が無かったから
516 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 23:05:19 ] C++がもしなかったらと考えると興味深い。 JavaやLL言語のようなものはあっただろうか? LISPやSmalltalkの影響はもっと大きかっただろうか?
517 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 23:09:41 ] >JavaやLL言語のようなものはあっただろうか? 普通にあったんじゃない?
518 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 23:18:46 ] ねーよ。 C++の影響は計り知れない
519 名前:デフォルトの名無しさん mailto:sage [2007/06/28(木) 01:15:28 ] cfront最終版の頃には、 Modula-3, Oberon, CLU, Argus, Effiel, Ada 9X, Delhpi, Smalltalkあたりが軒並死亡宣告。 NEXTSTEP, Display PostscriptのおかげでObjective-Cが生き残っている程度だった。
520 名前:デフォルトの名無しさん mailto:sage [2007/06/28(木) 01:34:50 ] その言語大絶滅は何か原因はあるの? //まあマイナー言語の生成消滅は常に起きてるだろうけど。
521 名前:デフォルトの名無しさん mailto:sage [2007/06/28(木) 09:02:38 ] 勝手に言ってるだけだろ。もともとニッチなのもいくつかあるし 死んでないのもいくつかあるし。 要はC++が広まりすぎて、他の言語が相対的に影が薄くなったって ことだと思う。
522 名前:デフォルトの名無しさん mailto:sage [2007/06/28(木) 09:09:11 ] C++とJavaは、プログラミング言語の研究者をしゃぶりつくしているけどな。 こんなに人材が集まったことは今だかつてないんじゃないか? C++に関して言えば、マクロ(特殊化当たり前)由来のtemplateが決定打だったな。
523 名前:デフォルトの名無しさん mailto:sage [2007/06/28(木) 12:08:12 ] C++ってマクロなんでしょ?
524 名前:デフォルトの名無しさん mailto:sage [2007/06/28(木) 12:11:46 ] ???
525 名前:デフォルトの名無しさん mailto:sage [2007/06/28(木) 14:00:51 ] っ MFC
526 名前:デフォルトの名無しさん mailto:sage [2007/06/28(木) 14:14:36 ] MFCとVC6は大量のC++挫折者を生み出しました
527 名前:デフォルトの名無しさん mailto:sage [2007/06/28(木) 17:52:57 ] >>522 C++がひろがってたのはtemplate以前からだけどね。 TMPがはいって地獄がより強固になった。
528 名前:デフォルトの名無しさん mailto:sage [2007/06/28(木) 20:02:22 ] シェア90%のOSが推奨すれば広まって当然
529 名前:デフォルトの名無しさん mailto:sage [2007/06/28(木) 21:26:08 ] じゃあこれからはドトネト天国だね
530 名前:デフォルトの名無しさん mailto:sage [2007/06/28(木) 21:38:39 ] C#する気もしない気も〜VMの性能にかかっているんだよ〜
531 名前:デフォルトの名無しさん mailto:sage [2007/06/28(木) 22:21:08 ] C++は滅びぬ!何度でもよみがえるさ。 ネイティブコードの力こそ人類の夢だからだ
532 名前:デフォルトの名無しさん mailto:sage [2007/06/28(木) 22:22:00 ] D が完成しさえすれば・・・。
533 名前:デフォルトの名無しさん mailto:sage [2007/06/28(木) 22:50:37 ] ネイティブでGC無しというところが、 C++の強さにして弱み。
534 名前:デフォルトの名無しさん mailto:sage [2007/06/28(木) 22:52:36 ] し、C++/CLIとかどうですか・・
535 名前:デフォルトの名無しさん mailto:sage [2007/06/29(金) 00:03:58 ] Dもキメラ過ぎる
536 名前:デフォルトの名無しさん mailto:sage [2007/06/29(金) 23:28:16 ] Dがもっとリッチに色々揃えば良いけど。
537 名前:デフォルトの名無しさん mailto:sage [2007/06/29(金) 23:32:38 ] やっぱC++は最高だな
538 名前:デフォルトの名無しさん mailto:sage [2007/06/30(土) 19:25:36 ] C++0xになったらどんなステキな世界が待っているんだろう。 アスペクト志向取り入れないかな
539 名前:デフォルトの名無しさん mailto:sage [2007/06/30(土) 19:46:15 ] >533 でも委員会で GC の話してるみたいよ?
540 名前:デフォルトの名無しさん mailto:sage [2007/06/30(土) 20:31:26 ] 今のところHans Boehmの提案が最有力候補かな?
541 名前:デフォルトの名無しさん mailto:sage [2007/06/30(土) 20:32:07 ] GC ねえ。 GC なしで組めるモードもあるんだよね?
542 名前:デフォルトの名無しさん mailto:sage [2007/06/30(土) 21:19:39 ] C99に合わせたりはしないのかな。
543 名前:デフォルトの名無しさん mailto:sage [2007/06/30(土) 21:37:25 ] >>541 >GC なしで組めるモードもあるんだよね? C++(0x)的にほぼ採用のための必須条件とおもわれ
544 名前:デフォルトの名無しさん mailto:sage [2007/06/30(土) 22:30:57 ] >>542 だいたいのところは取り込まれてるみたい。
545 名前:デフォルトの名無しさん [2007/07/01(日) 11:32:07 ] www.open-std.org/jtc1/sc22/wg21/ News 2007-06-30: The 2007-06-pre-Toronto mailing is available
546 名前:デフォルトの名無しさん mailto:sage [2007/07/01(日) 11:33:18 ] >>543 えーーー! いくらなんでもそれは無くね?
547 名前:546 mailto:sage [2007/07/01(日) 11:34:11 ] 勘違いしてた 「GCなしでも組める」事が必須条件なのね ごめんなさい
548 名前:デフォルトの名無しさん mailto:sage [2007/07/01(日) 11:51:16 ] C++的には、使わなければ余分なコストはかからないというのは必須だろ。
549 名前:デフォルトの名無しさん mailto:sage [2007/07/01(日) 11:53:34 ] そこでGCCですよ
550 名前:デフォルトの名無しさん mailto:sage [2007/07/01(日) 11:57:17 ] GCを使うか使わないかを不具合無しで簡単に切り替えられるのがいい 例えばアロケータを差し替えるだけでとかそういうので
551 名前:デフォルトの名無しさん mailto:sage [2007/07/01(日) 12:00:52 ] GC自体はあってもいいが破棄のコードが無いと対称性が崩れてキモチワルイな
552 名前:デフォルトの名無しさん mailto:sage [2007/07/01(日) 12:02:25 ] >>551 現行の C++ でも delete はほとんど auto_ptr や shared_ptr 任せで コードには無いだろ。
553 名前:デフォルトの名無しさん mailto:sage [2007/07/01(日) 12:03:19 ] >>551 ではauto_ptrやshared_ptrについてどうお考えでしょうか?
554 名前:デフォルトの名無しさん mailto:sage [2007/07/01(日) 12:05:59 ] shared_ptrとかは削除子指定できるからな GCも同様に削除子が指定できれるならば生成子と対照が簡単に取れるから問題なし
555 名前:デフォルトの名無しさん mailto:sage [2007/07/01(日) 12:07:50 ] なんだよかたそういう対照性か。 まさかソースコード上の対照性を言っているのかと思って心配になった。
556 名前:デフォルトの名無しさん mailto:sage [2007/07/01(日) 12:11:55 ] >>554 メモリ管理専用にしないと GC によるメリットなんて得られないんじゃない? 削除子なんか入れたら実行タイミングに完全な規格を定義しないといけないでしょ。
557 名前:556 mailto:sage [2007/07/01(日) 12:16:45 ] うーんもうちょっと調べ物してから言えばよかったかな。 あんまりはっきりしたこともいえないんで、スルー推奨。
558 名前:デフォルトの名無しさん mailto:sage [2007/07/01(日) 12:17:46 ] 超基本的な質問なんだけど GCありの場合でも自動変数がスコープ抜けた時とかにデストラクタは呼ばれるの? その場合、そのクラスがフリーストアへのポインタを持っていた場合、 クラスのインスタンス自体は破棄されるけど、参照されていたメモリは GCの場合はすぐに回収されないってことになるの?
559 名前:デフォルトの名無しさん mailto:sage [2007/07/01(日) 12:21:51 ] GCってオンオフするもんなの? 当方C++/CLIのイメージが強いもんで、C++0xでどうなるのかわからないんだけどさ。 ^とgcnewみたいなものじゃまずいのかなぁ。
560 名前:デフォルトの名無しさん mailto:sage [2007/07/01(日) 12:38:43 ] すみません int a[] = new int[10]; int *b = new int[10]; みたいに確保したときって delete a; delete a[]; delete b; delete b[]; それぞれ解放の仕方で動作おかしくなりますか?
561 名前:デフォルトの名無しさん mailto:sage [2007/07/01(日) 12:45:19 ] >>560 スレ違い。こっち逝け→ pc11.2ch.net/test/read.cgi/tech/1182740506/
562 名前:デフォルトの名無しさん mailto:sage [2007/07/01(日) 15:35:28 ] >>560 とりあえず Effective C++ でも買ってこい
563 名前:デフォルトの名無しさん mailto:sage [2007/07/01(日) 23:47:23 ] >>545 今回はいつもよりちと早めだね 小技系だが、N2332 がはげしく欲しい
564 名前:デフォルトの名無しさん mailto:sage [2007/07/02(月) 07:35:17 ] やっぱSL73だろ gradeup.blog39.fc2.com/blog-entry-31.html
565 名前:デフォルトの名無しさん mailto:sage [2007/07/02(月) 09:24:38 ] みんな好き勝手いいやがって……だれが実装すると思ってるんだ
566 名前:デフォルトの名無しさん mailto:sage [2007/07/02(月) 12:50:56 ] >>563 make_*関数が要らなくなるのは確かに便利だな。
567 名前:デフォルトの名無しさん mailto:sage [2007/08/07(火) 08:31:37 ] 最近のSutterは完全にC++/CLI宣伝だな。 そういう契約なのかな…
568 名前:デフォルトの名無しさん mailto:sage [2007/08/09(木) 21:18:40 ] 最新のドラフトってこれでいいのかな? # ISO/IEC 14882: Programming Language C++ - draft www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2315.pdf
569 名前:デフォルトの名無しさん mailto:sage [2007/08/09(木) 21:27:04 ] 今日付けでn2369が出たみたい。
570 名前:デフォルトの名無しさん mailto:sage [2007/08/09(木) 22:45:56 ] 今日付けw 何とタイムリーな。 こいつかな? www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2369.pdf
571 名前:デフォルトの名無しさん mailto:sage [2007/08/09(木) 22:49:14 ] 今日じゃないや、6日だ… 今月分のもろもろ。 ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/#mailing2007-08
572 名前:デフォルトの名無しさん mailto:sage [2007/08/09(木) 23:50:33 ] decltype 追加か。細かい仕様はともかく、追加は確定なのかな。 あと alignas, alignof, constexpr も追加。 そして、char16_t, char32_t も追加? 色は変わってないけど。 constexpr は D のコンパイル時実行みたいなもんか。 メタプロの世界がまた1つ広がりそうだな。 alignas と alignof は構造体のアラインメント関連か。 alignas で指定して、alignof で取得する、といったところか。 char16_t と char32_t は UTF-16 と UTF-32 用の char だっけ? 何か前に話題に出てたよね。
573 名前:デフォルトの名無しさん mailto:sage [2007/08/10(金) 00:01:26 ] しかし、結構ドラスティックな変更が多いと思うけど、 こんなんがあと二年でまとまるんだろうか
574 名前:デフォルトの名無しさん mailto:sage [2007/08/10(金) 00:10:12 ] constexprは制限が強すぎて見た目ほど強力じゃなかったはず
575 名前:デフォルトの名無しさん [2007/08/10(金) 06:15:42 ] www.open-std.org/jtc1/sc22/wg21/ News 2007-08-09: The 2007-08-post-Toronto mailing is available News 2007-08-09: C++ Standard Core Language Issues List (Revision 49) is available News 2007-08-09: The C++ Standard Library Issues List (Revision 50) is available
576 名前:デフォルトの名無しさん mailto:sage [2007/08/10(金) 09:46:56 ] FORTRESSに、禿の"Generalizing Operator for C++2000"風の演算子拡張があって、 気になって仕方がない。
577 名前:デフォルトの名無しさん mailto:sage [2007/08/11(土) 06:43:14 ] = default と = delete がいまいち分かんないな。 = default はデフォルトで作られるメンバ関数を非 inline 化するためのもの・・・でいいのか? いまいち使い道が分からんが。 = delete は関数を使えなくする・・・でいいのか? こっちはまあ使い道あるだろうけど、 10.3p14 を見るに、基底クラスのメンバを殺すのには使えんのか?
578 名前:デフォルトの名無しさん mailto:sage [2007/08/11(土) 08:08:25 ] うわあああ もう予約語の使いまわしはやめてくれぇぇぇぇぇぇぇ =0ですらキモすぎるのに=deleteとか=defaultとか
579 名前:デフォルトの名無しさん mailto:sage [2007/08/11(土) 08:13:20 ] フフフ。そのキモさが C++ なのさ!
580 名前:デフォルトの名無しさん mailto:sage [2007/08/11(土) 08:41:36 ] 純粋仮想関数とかいいながら、構文が汚れてるよな
581 名前:デフォルトの名無しさん mailto:sage [2007/08/11(土) 08:47:17 ] 不純だわ
582 名前:デフォルトの名無しさん mailto:sage [2007/08/11(土) 08:51:54 ] 不接触の純粋さは当然のこと。 穢れに触れて、それでも尚純粋であることの方が素晴らしい。
583 名前:デフォルトの名無しさん mailto:sage [2007/08/11(土) 09:01:36 ] それもこれもstaticが全ての始まりでした…
584 名前:デフォルトの名無しさん mailto:sage [2007/08/11(土) 09:23:04 ] *じゃね?
585 名前:デフォルトの名無しさん mailto:sage [2007/08/11(土) 09:24:11 ] & もなかなか
586 名前:デフォルトの名無しさん mailto:sage [2007/08/11(土) 09:34:31 ] POD という表現がことごとく修正されてるのは、 やっぱ constexpr の影響?