1 名前:デフォルトの名無しさん mailto:sage [2009/01/20(火) 23:10:49 ] The C++ Standards Committee www.open-std.org/jtc1/sc22/wg21/ wikipedia ja.wikipedia.org/wiki/C%2B%2B0x C++0x pc11.2ch.net/test/read.cgi/tech/1149440647/ C++0x 2 pc11.2ch.net/test/read.cgi/tech/1191842951/ C++0x 3 pc11.2ch.net/test/read.cgi/tech/1204808027/ C++0x 4 pc11.2ch.net/test/read.cgi/tech/1214407525/
152 名前:デフォルトの名無しさん mailto:sage [2009/02/04(水) 23:54:43 ] varとかtypeとかfunctionとかのキーワードがないのに合わせて、 typedefが止めを刺した感じ。 classやtemplateやcoceptはキーワード付けてくれて本当に良かったよ。
153 名前:デフォルトの名無しさん mailto:sage [2009/02/05(木) 11:08:28 ] >>152 何かで見たけど、キーワードはできるだけ 追加しないってのがポリシーなんだよね。
154 名前:デフォルトの名無しさん mailto:sage [2009/02/05(木) 11:14:40 ] >>138 わかってないな。 省略できるから、つけようがつけまいが自由なんだぞ。 単にあのかっこも、一時期のバグ回避だし。
155 名前:デフォルトの名無しさん mailto:sage [2009/02/05(木) 11:45:46 ] どうでもいいことで盛り上がるなこのスレ
156 名前:デフォルトの名無しさん mailto:sage [2009/02/05(木) 11:54:32 ] 馬鹿が必死になるから挑発しないでくれ
157 名前:デフォルトの名無しさん mailto:sage [2009/02/05(木) 12:00:29 ] というか、どうでもいいことだから盛り上がる
158 名前:デフォルトの名無しさん mailto:sage [2009/02/05(木) 12:12:45 ] ごめんなさい…
159 名前:デフォルトの名無しさん mailto:sage [2009/02/08(日) 20:28:10 ] >>154 へー、そんな理由がねぇ。 おいらてっきり、void return(x);的な関数に見せかけたいが為に やってんだと思ってた。あんま関係ないけど int(main)(int(argc),char**(argv))なんて所にも括弧付けれるね。 まぁ、当方returnですらカッコ付けたことは無いから付ける輩の気持ちは解らんけど。
160 名前:デフォルトの名無しさん mailto:sage [2009/02/08(日) 20:33:08 ] return って、20年以上前の大昔には実際に関数だったとかじゃなかったっけ? ANSI 以前の。 大昔の良書(今となっては歴史的資料)がANSI以前の文法で書かれてたりするせいで、 それが正しい書式だと思ってる人が絶えなかった。
161 名前:デフォルトの名無しさん mailto:sage [2009/02/08(日) 20:35:06 ] 未だにflex/bisonみたいな古いツールの解説では旧形式の関数定義があったりするな。
162 名前:デフォルトの名無しさん mailto:sage [2009/02/08(日) 22:26:28 ] >>160 >return って、20年以上前の大昔には実際に関数だったとかじゃなかったっけ? それはない。exit()の実装と勘違いしていないか?
163 名前:デフォルトの名無しさん mailto:sage [2009/02/08(日) 22:51:35 ] >>160 このレスは全て間違い。以下無視するように。
164 名前:デフォルトの名無しさん mailto:sage [2009/02/08(日) 22:56:56 ] C FAQを当たってみたけど、 ttp://www.kouno.jp/home/c_faq/c20.html#0 > 20.19: > returnの後ろに来る式をくくるカッコは本当に省略可能か。 > A: > 省略可能だ。 > 大昔、Cの初期には、必要であった。そのころにCを学んだ人がたくさんいるし、 > そのころ書かれたコードが今でも世の中に出まわっている。 それでカッコが > 今でも必要であるという考えが広まっている。 ということで、昔は必要だった(が関数ではない)ってのが正しいようだ。
165 名前:デフォルトの名無しさん mailto:sage [2009/02/09(月) 00:52:05 ] ifとかwhileが関数ではないけど括弧が要るってのと同じことだったんだと思う。
166 名前:デフォルトの名無しさん mailto:sage [2009/02/09(月) 06:58:32 ] 統一性を考えたらカッコが必要なままでもよかった気がする。 つか、不要にするならするで if や while もカッコ不要にして統一しろよ。
167 名前:デフォルトの名無しさん mailto:sage [2009/02/09(月) 07:24:14 ] >>166 ifやwhileは括弧があっても、タイプミスをするとコンパイル時に検出できるが、 returnに括弧があるとそうはいかない。
168 名前:デフォルトの名無しさん mailto:sage [2009/02/09(月) 08:53:03 ] >>166 retrun() でハマるというネタが
169 名前:デフォルトの名無しさん mailto:sage [2009/02/09(月) 10:42:17 ] >>166 つーか 統一するという言葉自体に惹かれても意味ないし 第一、統一する理由がない
170 名前:デフォルトの名無しさん mailto:sage [2009/02/09(月) 11:42:57 ] 括弧無しでも文法としては作れるよね? そうしろっていってるんじゃなくて、ふとした疑問で
171 名前:デフォルトの名無しさん mailto:sage [2009/02/09(月) 12:30:29 ] return-statement := return EXP と定義すれば既に統一されてるじゃん 空白や(は識別子に含めないからそこで打ち切られてreturnが認識され、 以降の式が続けて認識される
172 名前:デフォルトの名無しさん mailto:sage [2009/02/09(月) 16:13:55 ] >>166 break continue sizeof系統だからある意味統一されてるだろ。
173 名前:デフォルトの名無しさん mailto:sage [2009/02/09(月) 16:26:05 ] >>172 sizeofちと違う
174 名前:デフォルトの名無しさん mailto:sage [2009/02/09(月) 17:58:38 ] >>170 ついでにifなどにぶら下がる文を複文限定にして、中括弧必須にしてくれればいいのにと思う。
175 名前:デフォルトの名無しさん mailto:sage [2009/02/09(月) 18:14:32 ] P e r l 化 決 定
176 名前:デフォルトの名無しさん mailto:sage [2009/02/09(月) 19:22:59 ] #define begin { #define end }
177 名前:デフォルトの名無しさん mailto:sage [2009/02/09(月) 20:02:27 ] >>176 嘘のような、本当の話。
178 名前:デフォルトの名無しさん mailto:sage [2009/02/09(月) 21:21:51 ] 昔々のはなしじゃねーか。 つーか、ゴテゴテ強化してJAVAより遅くなってたら笑える。
179 名前:デフォルトの名無しさん mailto:sage [2009/02/09(月) 21:23:53 ] >>176 STL コンテナと一緒に使えますか?
180 名前:デフォルトの名無しさん mailto:sage [2009/02/09(月) 21:42:50 ] #defineはコンパイル以前に発現するのでSTLと一緒には使えません。
181 名前:デフォルトの名無しさん mailto:sage [2009/02/10(火) 09:15:30 ] えー
182 名前:デフォルトの名無しさん mailto:sage [2009/02/10(火) 11:57:45 ] #define private public
183 名前:デフォルトの名無しさん mailto:sage [2009/02/10(火) 19:11:50 ] #define privata public
184 名前:デフォルトの名無しさん mailto:sage [2009/02/10(火) 20:59:45 ] #define mein main #define retrun return #define cahr char
185 名前:デフォルトの名無しさん mailto:sage [2009/02/10(火) 21:06:58 ] #define itn int #define sohrt short #define unsgied unsigned #define long lgon #define vodi void #define defien define #define incldue include #define thrwo throw
186 名前:デフォルトの名無しさん mailto:sage [2009/02/10(火) 21:18:27 ] #define unsinged unsigned がないのはおかしい
187 名前:デフォルトの名無しさん mailto:sage [2009/02/10(火) 22:49:20 ] ^t
188 名前:デフォルトの名無しさん mailto:sage [2009/02/10(火) 23:04:18 ] 結局、単なるデブ言語か。 テンプレートでarray使うと、C#より遅くなるんだからたまらん。
189 名前:デフォルトの名無しさん [2009/02/11(水) 00:08:35 ] >>188 え〜。コンパイル時に最適化掛けてないとかそんな話じゃないよね?
190 名前:デフォルトの名無しさん mailto:sage [2009/02/11(水) 00:36:58 ] 「テンプレートで」とか、馬鹿に決まってるから相手にするな。
191 名前:デフォルトの名無しさん [2009/02/11(水) 01:09:58 ] すいませんでした。いや、数年前に、 知り合いで大学院で C++ でシミュレーションをしていた奴が、 遅くて困るんだよね... といってたから最適化オプションはどうしてる?と聞いたら 何もしらなくて、調べてみるとなんとデバッグオプションつきで inline 展開も無しだったという恐ろしい話があったのでね...
192 名前:デフォルトの名無しさん mailto:sage [2009/02/11(水) 01:20:19 ] 188はコンパイルが遅いって話かと思った
193 名前:デフォルトの名無しさん mailto:sage [2009/02/11(水) 01:36:50 ] 遅いなら速くすればいいじゃない
194 名前:デフォルトの名無しさん mailto:sage [2009/02/11(水) 03:34:24 ] コンパイルが遅いならDをt(ry
195 名前:デフォルトの名無しさん mailto:sage [2009/02/11(水) 23:05:34 ] ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
196 名前:デフォルトの名無しさん mailto:sage [2009/02/12(木) 22:07:49 ] いやいや、三次元配列だとすで使っても遅いぞ。
197 名前:デフォルトの名無しさん mailto:sage [2009/02/13(金) 18:09:29 ] mailing2009来てるじゃん スレッドのバグが山のように報告されてて吹いた
198 名前:デフォルトの名無しさん mailto:sage [2009/02/13(金) 20:58:23 ] constexpr の再帰が復帰してるっぽ。
199 名前:デフォルトの名無しさん mailto:sage [2009/02/13(金) 21:15:07 ] 停止判定できないのはテンプレートも同じだからな
200 名前:デフォルトの名無しさん mailto:sage [2009/02/13(金) 22:36:24 ] 結局コンパイラ側で制限かけるんじゃね?
201 名前:デフォルトの名無しさん mailto:sage [2009/02/14(土) 00:28:13 ] そういう問題じゃない。
202 名前:デフォルトの名無しさん mailto:sage [2009/02/15(日) 02:07:01 ] final class に相当するものは導入されてんの? const class とかでキーワード導入しなくても大丈夫そうな気がするんだけど。
203 名前:デフォルトの名無しさん mailto:sage [2009/02/15(日) 02:14:04 ] されてない
204 名前:デフォルトの名無しさん mailto:sage [2009/02/15(日) 02:33:02 ] 意見すら出なかったのだろうか
205 名前:デフォルトの名無しさん [2009/02/15(日) 03:36:12 ] 0x はそういう小手先の便利さとかとは掛け離れた大きいものを狙っている気がする。
206 名前:デフォルトの名無しさん mailto:sage [2009/02/15(日) 05:12:01 ] 小手先の便利さはライブラリやコーディングテクで補うのが禿と愉快な仲間たちの趣味です。
207 名前:デフォルトの名無しさん mailto:sage [2009/02/15(日) 08:03:04 ] あるあるw
208 名前:デフォルトの名無しさん mailto:sage [2009/02/15(日) 13:43:24 ] >>202 [[final]]っていうオーバーライド禁止属性が入る
209 名前:デフォルトの名無しさん mailto:sage [2009/02/15(日) 14:56:54 ] class hoge [[final]] ってのは入る事になったの? virtual member function にたいしてだけ?
210 名前:デフォルトの名無しさん mailto:sage [2009/02/15(日) 16:24:18 ] N2800では入ってる 効果はクラスの全仮想関数に[[final]]を付けるのと同じ
211 名前:デフォルトの名無しさん mailto:sage [2009/02/15(日) 16:46:12 ] >>210 継承禁止ならともかく仮想関数オーバーラード禁止してどうするの? virtual付けなきゃ良いだけじゃない。
212 名前:デフォルトの名無しさん mailto:sage [2009/02/15(日) 17:10:07 ] 豚脂の摂り過ぎは禁止じゃないけど控えた方がいいだろうな。
213 名前:デフォルトの名無しさん mailto:sage [2009/02/15(日) 17:14:36 ] >>211 > virtual付けなきゃ良いだけじゃない。 ( ゚д゚)ポカーン
214 名前:デフォルトの名無しさん mailto:sage [2009/02/15(日) 17:45:54 ] >>211 俺に言われても困るが、virtual付き関数のオーバーライドさえ封じておけば 基底クラスの機能を派生側で変更できなくなるんだから十分だろう virtualにしないという手は、基底クラスから受け継いだ仮想関数がある場合には使えない クラス付き[[final]]はそういうのにも効いてくれるから意味がある
215 名前:デフォルトの名無しさん mailto:sage [2009/02/15(日) 19:25:02 ] >>214 やっぱりそういう事なんだ。成るほどね。 >>202 に「final classに相当するもの」って書いてあったから、 Javaと同系統の機能なのかと混乱したよ。
216 名前:デフォルトの名無しさん mailto:sage [2009/02/16(月) 01:57:18 ] Java の final メソッドと同じだな
217 名前:デフォルトの名無しさん mailto:sage [2009/02/16(月) 21:39:37 ] どうせクラスと関数でセマンティクスが変わるのが嫌だったんだろうけど やっぱりキッパリと「派生クラス作ったらアウト」にして欲しかったな 仮想デストラクタ作らないと派生禁止にできないのは本末転倒な気がする
218 名前:デフォルトの名無しさん mailto:sage [2009/02/16(月) 22:39:33 ] デフォルトがアーリーバインディングのC++で final が必要なケースのほとんどは悪い設計の尻拭いでしょ そんなことより早く仕様Fixして欲しいよ
219 名前:デフォルトの名無しさん mailto:sage [2009/02/16(月) 22:40:34 ] 安全性より速度側に倒すC++だからこそ finalが必要なんだろう。
220 名前:デフォルトの名無しさん mailto:sage [2009/02/16(月) 22:45:07 ] 統一関数構文周りがここへ来てまた愉快なことになってるからな 今年中には無理だな
221 名前:デフォルトの名無しさん mailto:sage [2009/02/16(月) 23:41:14 ] 統一関数構文とかって、英語話者なら前から読んでわかりやすいかもしらんが 日本語だとあんまり C のとかわらなくね? function of int i and int j which returns array of pointers to function of int i とかそのままになる?んだろうけど日本語の語順とは全然ちがうよね。
222 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 00:09:52 ] まあ戻り値を引数列の後ろに置きたいための変更で 読みやすさのためじゃないからな しっかし既存の宣言に無理矢理押し込むためにこれ→[]を型扱いしようとしたり この期に及んで関数とラムダを完全統合しようと派手に文法いじくり回したり 迷走がひどい
223 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 00:22:59 ] てかC++使いに自然言語的可読性気にする奴いるのかね? 最早ここまで崩れたら英語圏だろうどこの人間でも 気にする気にもならんと思うんだが。
224 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 00:23:56 ] 統一関数構文は別言語でやってくれって感じだ。 C++にいれるには無理がある。
225 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 01:06:20 ] 最初に思い切ってfuncdefでも予約語にすると決定すれば良かったんだ
226 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 01:07:08 ] いや、あれは必要だ。 とくにdecltypeがあるC++0xにとっては。
227 名前:デフォルトの名無しさん [2009/02/17(火) 01:24:49 ] shared_ptrが付いたのはいいけど、やっぱり演算子にならないといまいち使えないよなー。構文長くなりすぎだし。 [*]とか何か導入できなかったのかな。バカだなー。
228 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 01:41:12 ] 最大の問題はstd::shared_ptrがboost::shared_ptrと同じように使えるとは限らないこと dynamic deleterが要件に入ってないとか何なの?死ぬの?
229 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 02:08:28 ] そんなあほな
230 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 02:29:42 ] >>224 入れないほうが無理があるよw 俺はあのスタイルは好きじゃないけれど、 なんか入れないと>>226 の言う通りで破綻する。
231 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 02:44:02 ] C++って何がしたいの?
232 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 03:52:37 ] >>228 どこ読んでそう思ったの? n2800 見たけど、 get_deleter() とかあるし、 template 引数には静的な deleter 型は無いよ。 これなら deleter については boost::shared_ptr と同じでしょ。
233 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 07:22:12 ] >>226 関数の戻り値の型は前置しても 以降の部分を考慮できるようにはできないんだろうか。
234 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 14:53:02 ] デブが集うスレ。
235 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 16:33:44 ] 時間が経ってみるとこの構文も悪くない気がして来た [] func(int arg) -> void {}
236 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 16:35:51 ] いい具合に洗脳されてきてますね
237 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 18:30:44 ] 何を今更。C++0x最高!
238 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 20:53:21 ] >>232 コンストラクタで明示的に指定するdeleterの話じゃないぞ boost::shared_ptr<Base> p(new Derived); が(~Base()が仮想じゃなくても)デストラクタで~Derived()を呼んでくれるのがdynamic deleterだけど N2800のtemplate<class Y> explicit shared_ptr(Y* p);の説明をよく読んでくれ 4 Requires: p shall be convertible to T*. Y shall be a complete type. The expression delete p shall be well formed, shall have well defined behavior, and shall not throw exceptions. 5 Effects: Constructs a shared_ptr object that owns the pointer p. 6 Postconditions: use_count() == 1 && get() == p. ポインタpを所有したshared_ptrを作るとは書いてあるが、Y*として所有するとは書いてない pはT*に変換できなければならないし、事後条件で出てくるget()の戻り値型はT*だし T*として所有する実装は十分にありうる そして~shared_ptr()の説明には(deleterを指定していなければ)所有するポインタpに対して delete p;を呼ぶとしか書いてない つまり、Y*を持ってるshared_ptrならdelete (Y*)p;を呼んで欲しい(そしてboostはそうなってる)のに、 stdの方はdelete (T*)p;を呼びやがる可能性がある(そして破滅が待ってる) というわけで、shared_ptr<Base> p(new Derived);の解体に~Base()を呼び shared_ptr<void>は使い物にならずpimplに使うと鼻から悪魔を呼ぶ「標準準拠」のshared_ptrがありうるわけだ 恐ろしい話だと思わないか
239 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 21:18:19 ] Y* として delete pとなるようにすべきである、 というように書いてあるような気がするんだけど。 仮にそこが保障されなかったとしてもdeleterを指定できるんだから、 ファクトリ関数ひとつ書くだけですべてうまくいくような気がするんだけど。
240 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 21:23:54 ] >>231 とにかく最強を目指す ただし何が最強かは重要ではない
241 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 21:31:15 ] >Constructs a shared_ptr object that owns the pointer p. 「このポインタpを所有するshared_ptrオブジェクト」とあるから T*では 条件を満たさないんじゃね?
242 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 21:33:54 ] >>239 どこに書いてる? コンストラクタの説明ではdelete pがwell formed/well defined behaviorじゃなきゃダメだとは書いてるけど デストラクタの説明には「そのdelete p」を呼ぶとは書いてない(pの真の型については何も触れてない) それにget()の説明を見ると「stored pointer」はT*であるというようにも見える Y*で持ってY*で解体しろと強制してる箇所は見あたらないと思うんだけどなぁ deleter指定すればどうにかなるってのは関係ない話 boost::shared_ptrはそんなものなくても上手くいってるんだから
243 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 21:39:11 ] >>241 そこがハッキリしないんだよなぁ 「ポインタ」がアドレス値の情報だけなら別の型のポインタで持ったっていい訳だし 型も含めて全部保存しろとなると、今度はboostの方アウトになるような気がする 確か内部的にはvoid*で持ってるから
244 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 21:41:33 ] [] func(int arg) -> void {} と auto func(int arg) -> void {} どちらが正式になりそう?
245 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 21:45:50 ] unified function syntaxが入るなら前者で、入らないなら後者なわけだが。 俺としては、後々のことも考えて、統一して欲しいところなんだが、(今回は規格に入らないlocal functionとかnamed lambdaなどを入れる際に簡単) でもなー、実際に書かれたコードを読むと、後者のほうがぱっと見に分かりやすいんだよね。
246 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 21:45:52 ] あと一年時間があれば間違いなく[]が正式になっただろうけど、今の状況だと微妙だな autoが意味持ちすぎだから[]の方がいいと思うけどね
247 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 21:47:57 ] いや、こんな調子じゃ、あと一年ぐらいじゃ規格制定までは無理だろ。 まだ数年かかるんじゃない? x == 9にはならんだろう。
248 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 21:51:16 ] >>242 >Y*で持ってY*で解体しろと強制してる箇所 だから Requires: p shall be convertible to T*. Y shall be a complete type. The expression delete p shall be well formed, shall have well defined behavior, and shall not throw exceptions. これでしょ? デストラクタのところに書いてあるわけないじゃん。 >deleter指定すればどうにかなるってのは関係ない話 deleter指定したら確実にうまくいくんだから、関係無くはないだろ。 お前もギャーギャー騒ぐ必要がなくなる。
249 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 21:58:18 ] >>248 pがT*に変換できて、Yが完全型で、「delete p」の形式が適格で定義済みの振る舞いをして例外を投げない としか書いてないように見えるんだけど、どこで「Y*で持ってY*で解体しろと強制してる」の? それにdeleter指定するだけでいいとは言うけど、 boost::shared_ptrを使ってる所を全部探して適切なdeleter作って書き直すのと ただboost::shared_ptrをstd::shared_ptrに置換するだけで済むのでは全然違うと思うんだがね
250 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 22:05:13 ] pimplで使うことを考えるとY==Tだとしても問題だしな
251 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 22:06:31 ] Yのデストラクタがvirtualでなければならないとはどこかに書いてあるのかな? 書いてなければ、delete p がwell formedになるためには、一体どうすればいいんだろうな。
252 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 22:09:11 ] >pがT*に変換できて、Yが完全型で、「delete p」の形式が適格で定義済みの振る舞いをして例外を投げない delete p;の形式についてだけ適格で定義済みの振る舞いを要求していて、 delete (T*)p; の形式については適格で定義済みの振る舞いを要求していない以上、 実装がY*として解体するのはもう強制でしょ。 >deleter作って書き直す いちいち個別にdeleter作る必要は無いけどね。 >ただboost::shared_ptrをstd::shared_ptrに置換するだけで済む ちょっと頭使った置換じゃないと確かにうまくいかんかもなー。