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/ 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とかにボロ糞に貶されるところを見てみたい 338 名前：デフォルトの名無しさん mailto:sage [2009/02/21(土) 03:30:09 ] class Hoge : public HasFoo<Hoge> { void foo(); }; こう書かせろよ。めんどくさいな 339 名前：デフォルトの名無しさん mailto:sage [2009/02/21(土) 03:53:18 ] >>320 配列で使えんやん 340 名前：デフォルトの名無しさん mailto:sage [2009/02/21(土) 08:56:53 ] >>338 class Hoge requires HasFoo { void foo(); }; ならあり得るかも。 341 名前：デフォルトの名無しさん mailto:sage [2009/02/21(土) 12:08:31 ] >>339 concept_map ? 342 名前：デフォルトの名無しさん mailto:sage [2009/02/21(土) 18:07:11 ] >>341 concept_mapってsignatureのようなことできる様になるの？ 便利やね。 struct A { 　//・・・ 　void Method(); }; struct B { 　//・・・ 　void Method(): }; signature Sig { 　void Method(); }; Sig array[]={new A(),new B()};//継承関係の無いオブジェクトを代入 array[0].Method();//それぞれ正しいメンバーが呼び出される 343 名前：デフォルトの名無しさん [2009/02/21(土) 20:13:06 ] ↓がg++4なら通るけどVC9などintがint&に変えられなくて駄目といって通らない。 これって自分何か勘違いしてますか？VC9のバグってことはありませんか？ struct MyClass { int value; void set_value(int v) { value = v; } int get_value(void) const { return value; } }; vector<shared_ptr<MyClass> > v; ...vに適当に要素を入れる... for_each(v.begin(), v.end(), bind(&MyClass::set_value, _1, bind(&MyClass::get_value, _1))); // 駄目子ちゃん 344 名前：343 mailto:sage [2009/02/21(土) 20:14:24 ] あ、bindは<functional>のstd::tr1::bind、_1はstd::tr1::placeholders::_1です。 345 名前：343 mailto:sage [2009/02/21(土) 20:21:13 ] スレ違いな気がしてきた。C++スレへ行きます。すみません。 346 名前：デフォルトの名無しさん mailto:sage [2009/02/22(日) 15:49:24 ] さあもう一度アインシュタインでなにか例え話してみれば？ 347 名前：デフォルトの名無しさん mailto:sage [2009/02/22(日) 17:01:38 ] 誰もアインシュタインで例えたことなんて無いと思うが。 348 名前：デフォルトの名無しさん mailto:sage [2009/02/22(日) 17:47:07 ] 誰かアインシュタインclass作れよ 349 名前：デフォルトの名無しさん mailto:sage [2009/02/22(日) 18:35:28 ] __declspec(dllimport) class Einstein * __stdcall BangEinstein(void); class Einstein *Albert=BangEinstein(); 350 名前：デフォルトの名無しさん mailto:sage [2009/02/22(日) 18:55:22 ] assert(E==mc2) 351 名前：デフォルトの名無しさん mailto:sage [2009/02/22(日) 19:19:11 ] アインシュタインタンジェント 352 名前：デフォルトの名無しさん mailto:sage [2009/02/23(月) 10:05:15 ] もう拡張メソッドも組み込んじゃえよ 353 名前：デフォルトの名無しさん mailto:sage [2009/02/23(月) 19:54:44 ] C++に拡張メソッドは色々と面倒で厄介な問題があるから無理 354 名前：デフォルトの名無しさん mailto:sage [2009/02/23(月) 23:39:28 ] もうちょっと説明ｸﾚ 抽象的な言い方では判らないよ 355 名前：デフォルトの名無しさん mailto:sage [2009/02/24(火) 00:23:27 ] ヒント：拡張メソッドはメンバ関数もどきを提供するんだから 当然ポインタから->を通して呼ぶこともできるべきだよな、C++的に考えて ここから思いつく面倒ごとに思いを馳せれば現実的じゃないという結論には簡単にたどり着く 356 名前：デフォルトの名無しさん mailto:sage [2009/02/24(火) 05:30:40 ] >>355 テンプレートメンバ関数の特殊化と同じような方法で実装すればいいんじゃね？ あれも新しいメンバ関数をクラスの定義の外で作ってるわけだし。 357 名前：デフォルトの名無しさん mailto:sage [2009/02/24(火) 10:13:33 ] なんか演算子余ってないの？ p->>func() を func(p) の糖衣構文として扱うとかそんなんでいいんだが 358 名前：デフォルトの名無しさん mailto:sage [2009/02/24(火) 10:17:34 ] >>356 特殊化はシグネチャを変えているわけじゃない。 359 名前：デフォルトの名無しさん mailto:sage [2009/02/24(火) 15:44:17 ] >>357 ->* とか? でも (p->*func)() みたいに括弧が必須なのが面倒。 360 名前：デフォルトの名無しさん mailto:sage [2009/02/24(火) 18:49:01 ] >>359 肛門を指してるように見えた俺は逝ったほうがいいんだろうな orz 361 名前：デフォルトの名無しさん mailto:sage [2009/02/24(火) 19:02:12 ] 　)*( 362 名前：デフォルトの名無しさん mailto:sage [2009/02/24(火) 22:53:49 ] >>352 拡張メソッドのメリットって何？

---

---

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

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