C++0x 5

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/ 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に置換するだけで済む ちょっと頭使った置換じゃないと確かにうまくいかんかもなー。 253 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 22:09:31 ] Yが基底クラス持たなければ常に適格だな それがどうした 254 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 22:12:32 ] Tがvoidのとき適格じゃないけど。 255 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 22:14:39 ] これの話だろ？ d.hatena.ne.jp/Cryolite/20060108 問題は保存してるポインタの型じゃなくて呼ばれるデストラクタがいつ決まるか N2800には何も書いてない 256 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 22:15:43 ] 書いてるって 257 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 22:21:05 ] 素朴な疑問 1) どうしてここまでして C++ 使いたいんだ? 2) 型に厳格な関数型言語で十分じゃね? 258 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 22:22:43 ] とにかく最強を目指す ただし何が最強かは重要ではない 259 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 22:23:40 ] >>257 スレ違いどころか板違いです。 260 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 22:27:53 ] >>256 だからどこに？ コンストラクタではdelete pがwell definedでもデストラクタでdelete pが未定義になりうるってのが pimplでの問題なんだけど 261 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 22:34:32 ] >>260 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. 262 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 22:40:12 ] >>261 だからそれはコンストラクタでしょ shared_ptrのコンストラクタではimplクラスの完全な定義が見えてなきゃならないから、 その位置ではdelete p;はwell definedになるけど、 外側のデストラクタが自動生成だった場合にimplクラスの定義が見えてなくて shared_ptrのデストラクタが呼ぶdelete p;が未定義になりうるんだが、 それを禁じる要件はshared_ptrのデストラクタの説明には書いてない わかる？ 263 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 22:41:22 ] そういう仕様のアラを突き上げるのが去年の集まりだったんだよなあ。 今年もやるらしいから、そんとき誰かが言えば、委員会の人まで話が届くぞ。 264 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 22:47:21 ] >>262 デストラクタにdeleterを持つときは、d(p)となると書いてある。 ここでは明確に書かれていないが template<class Y> explicit shared_ptr(Y* p); は、Y*として解体するdeleterを設定しなければ仕様を満たせない。 template<class Y> explicit shared_ptr(Y* p); の仕様に The expression delete (T*)p shall be well formed, shall have well defined behavior, and shall not throw exceptions. という一文が無い限りは。 265 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 22:50:16 ] >>264 やっぱりわかってなかったのな pimplの時の問題だと言ってるだろう Y==Tの場合だ shared_ptr<impl>をimpl*で作った時に呼ばれるimplのデストラクタの話をしてるんだぞ 266 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 22:53:30 ] >>265 いや、それでも同じ話ですけど。 適切なdeleterがなされなければ、仕様を満たさないでしょ 267 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 22:56:43 ] なくても満たしちゃうだろ、と言ってるんだけど もう一度言うけどY==Tでの話だぞ 268 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 23:01:07 ] N2800で言う所のdeleterってのは template<class Y, class D> shared_ptr(Y* p, D d);の形のコンストラクタで渡されるdのことであって template<class Y> explicit shared_ptr(Y* p);は「deleterを所有」しない 269 名前：デフォルトの名無しさん mailto:sage [2009/02/18(水) 00:05:26 ] 結局pimplにshared_ptr使っていいの？ 270 名前：デフォルトの名無しさん mailto:sage [2009/02/18(水) 01:31:05 ] >>238 > template<class Y> explicit shared_ptr(Y* p); > Effects: Constructs a shared_ptr object that owns the pointer p. > ~shared_ptr(); > Effects: （略） > ? Otherwise, *this owns a pointer p, and delete p is called. ここでイタリックになってる "owns" を厳密な用語として読めばつながる。 つまり 　int* p = new int; 　shared_ptr<void> x(p); によって x は p を「所持」する。 (void*)p を「所持」するのではない。 このまま x のデストラクタが実行されるとき、 x は deleter を持たず p を「所持」しているので、 delete p が実行される。何も問題ない。 271 名前：デフォルトの名無しさん mailto:sage [2009/02/18(水) 02:17:33 ] そっちの話は終わってるだろ 問題はデストラクタテンプレートの実体化時点でpが不完全型ポインタになってる時に 「delete p」が未定義動作にならないような仕掛けが規格で強制されてるかどうか 272 名前：デフォルトの名無しさん mailto:sage [2009/02/18(水) 03:08:39 ] >>233 できるよ。現にD言語ではそうなってるし。 単に実装面倒だからコンパイラベンダが反対してるだけでしょ。 Dだと、こんなふうにかける： 　typeof(T+U) add(T, U)(T t, U u) { return t + u; } もっと簡単に 　auto add(T, U)(T t, U u) { return t + u; } ともかけるけど。 273 名前：デフォルトの名無しさん mailto:sage [2009/02/18(水) 03:12:24 ] >>271 そういうことか。 なるほど。今の記述だとはっきりしないね。 Effects の記述は boost のドキュメントと同じだけど、 boost のほうには template<class Y> explicit shared_ptr(Y * p) について注釈が添えられている。 > The destructor will call delete with the same pointer, complete with its original type, even when T does not have a virtual destructor, or is void. 規格にもこれが必要（できればもっとはっきり強制する書き方で）ってことだね。 早めに DR 挙げてくれ。 274 名前：デフォルトの名無しさん mailto:sage [2009/02/18(水) 08:02:53 ] >>272 実装が面倒っての、ここまですでに複雑な言語だと、結構な問題では。 あと、C# 使いとして言わせてもらうと、 T Add<T>(T x, T y) の最初の T でインテリセンスが利かないのはかなりのストレス。 275 名前：デフォルトの名無しさん mailto:sage [2009/02/18(水) 08:27:04 ] ×C#使い ○VisualStudio使い ◎MS迎合派 276 名前：デフォルトの名無しさん mailto:sage [2009/02/18(水) 09:17:10 ] こんなデブで非実用的な言語なんか使えねー 277 名前：デフォルトの名無しさん mailto:sage [2009/02/18(水) 09:30:04 ] まあC++使ってない携帯電話探す方が難しいけどな。 278 名前：デフォルトの名無しさん mailto:sage [2009/02/18(水) 16:16:50 ] Embedded C++（笑） 279 名前：デフォルトの名無しさん mailto:sage [2009/02/18(水) 17:59:58 ] Embedded C++0xを予想するスレ とりあえずラムダは真っ先に消される コンセプトはテンプレートがないんだから入るわけがないな 右辺値参照はどうかな、組み込みでこそ必要だと思うけど消しそうだなｗ 280 名前：デフォルトの名無しさん mailto:sage [2009/02/18(水) 18:24:51 ] それ以前にEmbedded C++はフリースタンディング環境で ライブラリがないから特殊用途以外は既に死んでる。 DarwinのI/O Kitですらnamespaceはありになってるし。 281 名前：デフォルトの名無しさん mailto:sage [2009/02/18(水) 19:18:32 ] C++にはフリースタンディングの規格は元々あるけど、 Embeddedって日本独自の規格だっけ？ 製品化されてる実装なんてあるの？ 282 名前：デフォルトの名無しさん mailto:sage [2009/02/18(水) 19:35:47 ] >>281 >Embeddedって日本独自の規格だっけ？ 事実上日本独自規格 C++のまともな処理系が作れないから、作りやすい縮小規格を作ったってだけ >製品化されてる実装なんてあるの？ GHS C++なんかはサポートしてるみたい 283 名前：デフォルトの名無しさん mailto:sage [2009/02/18(水) 19:41:57 ] >>281 www.dinkumware.com/ > ・a full implementation of EC++, the widely used embedded subset of Standard C++ 彼は"Embedded Systems Programming"にコラム書いていて、 よくコンサルもやってた。www.plauger.com/esp.html メイヤーさんも組み込み屋相手によくレクチャーしてる。EC++はやってるかどうかしらんが。 284 名前：デフォルトの名無しさん mailto:sage [2009/02/18(水) 20:08:08 ] 使い物になるやつを頼む。 C#より早いやつを頼むよ。 285 名前：デフォルトの名無しさん mailto:sage [2009/02/18(水) 21:44:24 ] コンパイル速度の速さなら一生かなわない自信がある。 286 名前：デフォルトの名無しさん mailto:sage [2009/02/19(木) 00:55:27 ] EC++のほうがC++より幾分ましだよ。 言語オタクにはわからんだろうが。 287 名前：デフォルトの名無しさん mailto:sage [2009/02/19(木) 01:03:03 ] とにかく必要なモノは実用品だ。 288 名前：デフォルトの名無しさん mailto:sage [2009/02/19(木) 01:56:22 ] EC++のページ見に行ったけど、2002年で更新止まってるしURL削ったら会社潰れたとか書いてるし もう死んでるようにしか見えないんだけどどうなの どっかで亡霊みたいに生き延びてるの？ 289 名前：デフォルトの名無しさん mailto:sage [2009/02/19(木) 02:01:24 ] 生き延びてたとしたら俺が殺しにいくかもしれない。 290 名前：デフォルトの名無しさん mailto:sage [2009/02/19(木) 02:15:51 ] なんで日本のこういうジャンルはクソなもんばかりなんだろうな？ うまいこと行ったのはRubyぐらいか？ てか著名なソフトの作者は大体医者だったりする所が泣ける。 291 名前：デフォルトの名無しさん mailto:sage [2009/02/19(木) 02:43:25 ] rubyも最近は面白くなさそうだけどな。 292 名前：デフォルトの名無しさん mailto:sage [2009/02/19(木) 07:41:03 ] >>289 これが止め刺したから必要ない。 C++ - TR 18015 Technical Report on C++ Performance www.open-std.org/jtc1/sc22/wg21/docs/18015.html 要約すると「フルセットのC++でもパフォーマンスに問題なんかねえよ、屑」 293 名前：デフォルトの名無しさん mailto:sage [2009/02/19(木) 09:21:51 ] >>269 問題としては >>271,273 が残ってるだけなので、生成時に deleter として std::default_delete<Y>() を渡しとけば現状のドラフトの記述でも動作保証はできる。 しかし激しくダルイな。 現実としては記述に不備があるだけで、未定義動作の可能性は本来の意図では 無いし実装としても boost のやつを持ってくれば問題ないはずだから、あんまり 心配しなくていいと思う。 294 名前：デフォルトの名無しさん mailto:sage [2009/02/19(木) 18:47:09 ] >>292 わざわざそんなドキュメントを出されなくても フツーに考えたら、C++がパフォーマンスで 劣るハズがないのに。 世間はバカなの？死ぬの？ ECは、パフォーマンス優先なのでrestrict ポインタを実装必須にするとかなら、 一理あると思うし、覚悟もわかるんだけど。 295 名前：デフォルトの名無しさん mailto:sage [2009/02/19(木) 19:13:46 ] >>292 てかEC++はパフォーマンスなんて謳ってたの？ 速度なら、例外とnew deleteぐらい、容量なら templateとinline関数とランタイム。実際には、 それぞれ自前で調整できるからまったく問題ないのは バカでも解ると思うが。 296 名前：デフォルトの名無しさん mailto:sage [2009/02/19(木) 20:31:53 ] 利点しかない新形式キャストを全部消してるあたり（多分RTTIとdynamic_cast消す時に巻き添え食らったんだろう） C++を理解してない奴らが作ってたのは明白 297 名前：デフォルトの名無しさん mailto:sage [2009/02/19(木) 20:37:24 ] >>294 かわいそうな人。 バカじゃね？ 現時点でもパフォーマンスにもんだいあんのによ。 298 名前：デフォルトの名無しさん mailto:sage [2009/02/19(木) 20:37:38 ] >>293 でもちゃんと規定しておいてくれないとvectorの連続性保証みたいなことになるからな はっきり書いてない要件はやっぱり信用できない たとえ事実上全部の実装がそうなってたとしても 299 名前：デフォルトの名無しさん mailto:sage [2009/02/19(木) 23:16:37 ] バカ専用にしょぼい言語つくろうって話なんだからｗ 300 名前：デフォルトの名無しさん mailto:sage [2009/02/19(木) 23:47:39 ] 同じ事ができるならシンプルな方が正しい。 301 名前：デフォルトの名無しさん mailto:sage [2009/02/19(木) 23:54:10 ] 百歩譲ってシンプルな事は認めても、同じ事(表現)はできないだろ 302 名前：デフォルトの名無しさん mailto:sage [2009/02/20(金) 00:13:28 ] EC++は名前空間さえ残してれば単なるC++サブセットでほぼ済んだのに なんでわざわざ互換性捨てちゃったんだろうな 303 名前：デフォルトの名無しさん mailto:sage [2009/02/20(金) 00:44:53 ] いらないから。 やたら短い関数名つけて検索性下げるバカとか普通に多いから。 304 名前：デフォルトの名無しさん mailto:sage [2009/02/20(金) 00:45:36 ] EC++のメリットがパフォーマンスとか言っちゃうやつらに何いってもね。 305 名前：デフォルトの名無しさん mailto:sage [2009/02/20(金) 00:52:47 ] 日本の企業が中心になって決めたから。 306 名前：デフォルトの名無しさん mailto:sage [2009/02/20(金) 09:15:46 ] >>300 それは大きなカンチガイ。 このバカ。 307 名前：デフォルトの名無しさん mailto:sage [2009/02/20(金) 10:53:55 ] シンプルだと言うにも視点はそれぞれだからね 短かく書ければシンプルであるというわけでもない 308 名前：デフォルトの名無しさん mailto:sage [2009/02/20(金) 11:00:10 ] ああ、三項演算子がバグの元とかいうアレですね 309 名前：デフォルトの名無しさん mailto:sage [2009/02/20(金) 12:22:46 ] いいかげんgccのコナピルまんどくせ 310 名前：デフォルトの名無しさん mailto:sage [2009/02/20(金) 15:31:51 ] 昔gccにあったSignatureいつか次期C++で復活しないかなぁ。 interfaceなんかより遥に便利そうなんだけど何で廃止されかなぁ。 311 名前：デフォルトの名無しさん mailto:sage [2009/02/20(金) 15:32:54 ] >>303 逆にループ変数にわざわざcounterとかつけてたり、引数に関数名が入ってたりするアホも見たことがある 312 名前：デフォルトの名無しさん mailto:sage [2009/02/20(金) 15:50:13 ] >ループ変数にわざわざcounter いや、それは別にいいんでねーの。 最近はディスプレイの解像度も上がったし、MSのインテリセンスに代表されるように、 エディタには補完機能があって便利だし。 変数一覧でiとかcntなんて表示されるよりよほど分かりやすそうだ。 引数に関数名ってのがよくわからんが。 こういうのか？ void hoge( int hoges_first_argument, int hoges_second_argument ) ; 313 名前：デフォルトの名無しさん mailto:sage [2009/02/20(金) 16:14:24 ] そんなん ループ変数の方はアホはいい過ぎだったな 314 名前：デフォルトの名無しさん mailto:sage [2009/02/20(金) 16:31:42 ] >>306 それはシンプルという言葉から、アインシュタイン言うところの 「単純化せよ。ただし単純化しすぎてもいけない」 の後者のケースばかり思い出すから出てくる反応で、 前者を完全スルーするお前の姿勢がカンチガイってオチじゃないの？ 315 名前：デフォルトの名無しさん mailto:sage [2009/02/20(金) 19:56:49 ] >>314 アインシュタインはプログラマーか？ つーか、シンプルとか言えたのはアインシュタインが最後だって知ってたか？ このバカ！ 316 名前：デフォルトの名無しさん mailto:sage [2009/02/20(金) 20:34:28 ] simplicityとかいった形で数値化できればいいのにな でさらにある法則に沿って変形していったらsimplicityがmonotonically decreasingになっていってそれを使って機械的にコードを変形して云々 317 名前：デフォルトの名無しさん mailto:sage [2009/02/20(金) 20:34:51 ] アインシュタインのその言葉を引用するには致命的なほど具体性にかけているな。 318 名前：デフォルトの名無しさん [2009/02/20(金) 21:23:40 ] w 319 名前：デフォルトの名無しさん mailto:sage [2009/02/20(金) 21:43:09 ] wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww 320 名前：デフォルトの名無しさん mailto:sage [2009/02/20(金) 23:17:46 ] >>310 concept来たやん 321 名前：デフォルトの名無しさん mailto:sage [2009/02/21(土) 00:14:40 ] クラス作る時にコンセプト使って InputIterator my_iterator{/*...*/}; とかやって要件満たしてなかったらエラー出してくれるみたいな使い方ができればよかったのに 322 名前：デフォルトの名無しさん mailto:sage [2009/02/21(土) 00:16:33 ] 表記が違うだけで出来るやん 323 名前：デフォルトの名無しさん mailto:sage [2009/02/21(土) 00:27:12 ] いや、そりゃやろうと思えばできるけどさ こんな風になるのかな class my_iterator{/*...*/}; template<InputIterator T> class InputIteratorChecker{}; static_assert(sizeof(InputIteratorChecker<my_iterator>)); めんどくさくね？ 324 名前：デフォルトの名無しさん mailto:sage [2009/02/21(土) 00:29:53 ] >>315 主旨だけシンプルに書きましょう。 わめいて逃げてるようにしか見えませんｗ 325 名前：デフォルトの名無しさん mailto:sage [2009/02/21(土) 00:49:16 ] >>323 Only required, > requires InputIterator 326 名前：デフォルトの名無しさん mailto:sage [2009/02/21(土) 01:02:42 ] >>325 それでどうやって簡単に書くんだ？ requiresってテンプレートとコンセプトの中でしか使えないだろ 327 名前：デフォルトの名無しさん mailto:sage [2009/02/21(土) 01:13:26 ] my_iteratorは、template<〜> iteratorとは無縁のクラス、 まったく別のsignatureってわけですか? だったらconcept_map書くしかないですね。 328 名前：デフォルトの名無しさん mailto:sage [2009/02/21(土) 01:18:10 ] めんどくさい誤解招いてるみたいだからInputIteratorやめる auto concept HasFoo<class T>{ void foo(); }; があるときに HasFoo Hoge{void foo(){}}; //OK HasFoo Fuga{}; //NG とかできたらいいなー、というのが>>321の趣旨 329 名前：デフォルトの名無しさん mailto:sage [2009/02/21(土) 02:01:42 ] fooにT型の関与なしかあ。 auto concept HasFoo<>{ void foo(); }; template<> class Hoge { void foo(); }; template<> concept_map HasFoo<Hoge> { void foo() {} }; 〜 Hoge<> 〜 でいいのかなあ。 330 名前：デフォルトの名無しさん mailto:sage [2009/02/21(土) 02:14:42 ] めんどくさいなぁ やりたいことはただ自作クラスがHasFooコンセプト満たしてるかどうかチェックしたいだけだってのに チェックするためだけにテンプレート化すんの？ 馬鹿げてる 331 名前：デフォルトの名無しさん mailto:sage [2009/02/21(土) 02:23:59 ] これでいいじゃん template<> class Hoge { void foo(); requires HasFoo<Hoge>; }; 332 名前：デフォルトの名無しさん mailto:sage [2009/02/21(土) 02:23:59 ] auto concept HasFoo<typename T>{ void foo(T); }; だと、 template<typename T> class Hoge { requires HasFoo<T> void foo(T) {} } って書けるけど。 template<> class Hoge { requires HasFoo<> void foo() {} } はいけるかどうかわからん。もう一回ドラフト読まんと。 333 名前：332 mailto:sage [2009/02/21(土) 02:26:50 ] 間違えた。 class Hoge { requires HasFoo<> void foo() {} } これは駄目だった。 >>331 ああそだね。 334 名前：デフォルトの名無しさん mailto:sage [2009/02/21(土) 02:28:05 ] >>332 それ以前の問題として HasFooは簡単なコンセプトだからいいけど これがもし10個の型名と20個の関数を要求するコンセプトだったら Hogeの型名と関数全部にそのrequires付けて回る気か？ >>323の方が楽だわ 335 名前：デフォルトの名無しさん mailto:sage [2009/02/21(土) 02:31:08 ] 直接こう書ければなんの問題もないのにな class Hoge { void foo(); requires HasFoo<Hoge>; }; 336 名前：デフォルトの名無しさん mailto:sage [2009/02/21(土) 02:44:18 ] C++ってほんとに糞言語ですね☆ 337 名前：デフォルトの名無しさん mailto:sage [2009/02/21(土) 02:45:25 ] C++がwadlerとかにボロ糞に貶されるところを見てみたい

---

---

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

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