C++0x 2

1 名前：デフォルトの名無しさん mailto:sage [2007/10/08(月) 20:29:11 ] The C++ Standards Committee ttp://www.open-std.org/jtc1/sc22/wg21/ 前スレ pc11.2ch.net/test/read.cgi/tech/1149440647/ 175 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 21:25:50 ] >>165 １．隠蔽不可 ２．隠蔽可能＆明示不要 ３．隠蔽可能＆明示必要 どれがいいと思ってるの？１？２？ 自分は３だけど 176 名前：165 mailto:sage [2007/10/23(火) 21:34:33 ] 熟考はせずにいうけど 継承時には 1 そのほかでは 2 が良さそうい思う でも、ルールは少ないほうが良いので結局 2 つまり現状のC++ 内側の名前が外側の名前を隠すのは直感的だと思うし 177 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 21:53:21 ] そうは思わない人がC#を作りましたと 178 名前：デフォルトの名無しさん mailto:sage [2007/10/24(水) 00:54:02 ] >>173 巨大なクラスがどうこう、って話だったっけ？ 導出クラスが作られた後で基底クラスが変更されて、 同じシグネチャのメソッドが追加されるととっても危険、 というJavaでの問題が報告されたから、 明示的な隠蔽みたいなのが出てきたんだと思ってたけど。 179 名前：デフォルトの名無しさん mailto:sage [2007/10/24(水) 03:16:53 ] >>175 俺は２ 理由はC系の言語ってそういうもんだと思っているから。 けど隠蔽を警告しない糞コンパイラは使う気しない。 180 名前：デフォルトの名無しさん mailto:sage [2007/10/24(水) 11:20:58 ] 過去のコードを捨て去るなら別の言語を作ってそっちでやってください、というのが現状の委員会でしょ 181 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 00:16:13 ] C++ って久々に使うと結構楽しいね。 182 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 03:55:26 ] >>172 Visual C++ 2005 で同等の強さの警告出させたいものだ。 >>181 まいにち使うと結構つらいよ。 183 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 07:57:24 ] boostのvaultのやつまで使用おkなら楽しいよ 184 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 08:01:26 ] C++0xが来ればもっと楽しくなるだろうな。 185 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 09:10:11 ] ConceptGCC楽し はやくこいこいC++0x 186 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 10:06:50 ] 楽しいと言うかコーディングが楽になりそうでいいね。 187 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 11:06:48 ] 特に auto が。 188 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 13:29:38 ] auto ってなんでも推論できるんかね？ なんか馬鹿の一つ覚えみたいに auto が氾濫しそう。 そんあこたーない？ 189 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 13:41:15 ] >>188 タイピング量を減らしたいからって理由で使ってたら可読性がﾜｯｼﾜｯｼ下がったのが俺 今じゃまったく使ってない 今までの言語仕様にautoだけプラスした、って環境ではかえって負担になる感じ きちんとしたC++0xが出てくればまた違うと思うんだけれど 190 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 13:57:34 ] でも適切な使用法もあるはずだよ そうでなければBoostからとっくにrejectされてるはず 191 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 22:08:42 ] イテレータを使うときにちょっと楽じゃね ってところから使えば肩もこらないんじゃないかと 192 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 22:17:37 ] ML系の関数型言語では推論をするのに十分な型しか明示しなくても問題ないよ 可読性の低下は感じない ML系は暗黙の変換がないけどね そこさえ避ければ大丈夫そう 193 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 22:28:36 ] オーバーロードされてる関数のポインタを取得しようとして void func(int); void func(void*); auto ptr = func; エラーだなこりゃ。 194 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 22:32:59 ] >>193 そうそう。どこまで「自動」なのか知りたいね。 そして、C++0x的におｋな限界まで auto を乱用されると、きっと萎えるよな。 195 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 22:36:32 ] typedef std::vector<auto> vt; void func(vt &v){...} std::vector<int> v_a; std::vector<short> v_b; func(v_a); func(v_b); こんな事もできるようになるのかね？ template要らずだな 196 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 22:36:44 ] そのときはまたboostが以下略 197 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 22:48:06 ] >>195 それは型のパラメタ化であって推論ではない やっぱりtemplateの出番 198 名前：デフォルトの名無しさん mailto:sage [2007/10/26(金) 00:09:59 ] >>193 オーバーロードされた関数は名前だけで型を決められないので auto だけじゃなく bind でも使いにくいしなあ。 それに、C++ のライブラリでは f(a) と f(a, b) が 2 つの関数として 定義されているのか、f(a, b = B()) みたいなデフォルト引数つきの 関数なのかは規定されてないらしく、bind1st/2nd をライブラリ関数に 使うことは(移植姓の観点から)よろしくないらしいし。 というわけで lambda 切望。むしろ bind イラネ。 199 名前：デフォルトの名無しさん mailto:sage [2007/10/26(金) 00:51:25 ] >>198 標準関数の引数並びは規定されてるだろ。 それ、どっから出てきた話？ 200 名前：デフォルトの名無しさん mailto:sage [2007/10/26(金) 01:05:36 ] >>199はどっかを読み違えているのだろう でも、どう読み違えて、そう解釈したのかが解らないから うまくアドバイスしてやることも出来ない 201 名前：198 mailto:sage [2007/10/26(金) 01:35:31 ] >>199 引数並びではなくシグネチャの話。 正確には関数じゃなくて「メンバ関数」限定だった。ごめん。 「std::mem_fun は標準ライブラリのメンバー関数に使うなゴルァ」 by はーぶさったー (Exceptional C++ Style) だってさ 202 名前：199 mailto:sage [2007/10/26(金) 01:44:20 ] >>201 シグネチャの意味で「引数並び」って言った。でもやっぱり決まってるでしょ。 メンバ関数に限定するってことは何か具体的な例があると思うんだけど、挙げてもらえる？ 203 名前：198 mailto:sage [2007/10/26(金) 03:26:09 ] >>202 Exceptional C++ Style P.29 >・デフォルトパラメータを持つメンバー関数のシグニチャは、 > 「等価な振る舞いを持つ2つ以上のメンバー関数のシグニチャ」に > 置き換えても良い。 >・メンバー関数のシグニチャには、追加のデフォルトパラメータが > 含まれていても良い。 P.30 >つまり、コードの移植姓を保ちながら標準ライブラリのメンバー関数 >へのポインタを生成することは不可能なのだ。 これ以上は立ち読みでもしてくれ 204 名前：199 mailto:sage [2007/10/26(金) 12:13:51 ] >>203 なんだかそういうルールがどこかに書かれてそうだな。 ってことで規格を signature あたりで検索したら、あった。 17.4.4.4p2 > An implementation can declare additional non-virtual member function signatures within a class: > ? by adding arguments with default values to a member function signature;172) The same latitude does not > extend to the implementation of virtual or global or non-member functions, however. > ? by replacing a member function signature with default values by two or more member function signatures > with equivalent behavior; んで脚注 172 に > 172) Hence, taking the address of a member function has an unspecified type. うーん。 bind に push_back とかコンテナのメンバ関数を使ったことがあったような 気がするんだけど、実装依存なコードだったのか。 あ virtual なメンバ関数には static_cast でシグネチャ明示すればなんとかいけるね。 コンテナとか普段使うやつはほとんど非 virtual だから救われないけど。 205 名前：デフォルトの名無しさん mailto:sage [2007/10/26(金) 15:28:41 ] >>203の言ってる意味がよくわからん 誰かコードに落としてくれ 206 名前：デフォルトの名無しさん mailto:sage [2007/10/26(金) 16:23:30 ] >>205 Exceptional C++ Styleにそのまま例が載ってるじゃん std::mem_fun</*...*/>(&std::vector<int>::clear)が正しいかどうか 自分で検証してみればわかるはず。 207 名前：デフォルトの名無しさん mailto:sage [2007/10/26(金) 21:48:45 ] 極端は話、 push_back(T val,bool hoge=true,int hage = 5,float foo = 0.05f) なんて実装でもいいわけか 208 名前：デフォルトの名無しさん [2007/10/26(金) 22:42:06 ] push_back(T val,bool uramode=true) 209 名前：デフォルトの名無しさん mailto:sage [2007/10/26(金) 22:45:16 ] デフォルトパラメータを利用して独自拡張ができるってことか 210 名前：デフォルトの名無しさん mailto:sage [2007/10/27(土) 00:35:22 ] このあたりの標準の改定案は出てないんかな？ 実装に自由裁量権を認めたはいいけど、自由度あり過ぎて std::mem_fun の位置付けが中途半端になってしまったのは 仕様の不備という気もするし 211 名前：デフォルトの名無しさん mailto:sage [2007/10/27(土) 00:47:04 ] >>210 コーディング標準として、 >>204に相当するようなコードは書かないようにするしかないかと。 212 名前：デフォルトの名無しさん mailto:sage [2007/10/27(土) 01:07:04 ] >>211 現状の話じゃなくて、C++0x にも同じ制限を持ち越すのか？ ってことが知りたいわけで Exceptional C++0x Style でまた書かれるぞ 213 名前：デフォルトの名無しさん mailto:sage [2007/10/27(土) 01:09:12 ] >Exceptional C++0x Style でまた書かれるぞ また落とし穴が増えるのかよ 　　　　　　　　 　∧＿∧ 　　　　　　　　　（ ´Д⊂ヽ 214 名前：デフォルトの名無しさん mailto:sage [2007/10/27(土) 01:12:22 ] >>212 とりあえず>>180は前提ですよ。馬鹿じゃない限り。 215 名前：デフォルトの名無しさん [2007/10/27(土) 01:26:38 ] boost::function<void (std::vector<int>*)> vector_clear = &std::vector<int>::clear; 216 名前：デフォルトの名無しさん mailto:sage [2007/10/27(土) 04:01:16 ] >>214 この件については >204 にあるような実装への自由度を制限することで ライブラリユーザー向けに課せられていた暗黙の制限が解消されることになるだけで、 過去のコードは依然としてコンパイルできるし動作に変化は生じない。 2003 の規格に準拠した実装は変更された規格に適合しなくなるかもしれないけど、 古い実装が新しい規格に適合していないことになるのは何も問題ない。 C++09 にはもう手遅れだけど、提案してみれば将来につながる可能性はあると思う。 217 名前：デフォルトの名無しさん mailto:sage [2007/10/27(土) 10:07:03 ] >>216 > 実装への自由度を制限することで > 依然としてコンパイルできるし どういうこと? 禁止したらコンパイルできないでしょ。 218 名前：デフォルトの名無しさん mailto:sage [2007/10/27(土) 10:39:08 ] STL実装に依存した関数ポインタを使ってないかぎり大丈夫だろ 219 名前：デフォルトの名無しさん mailto:sage [2007/10/27(土) 13:46:39 ] 「オーバーロードセットが存在するメンバ関数だけにういて適用される」 みたいな制限だけでもだいぶ違うね。 そうなれば vector push_back, clear は問題なくなる。 220 名前：デフォルトの名無しさん mailto:sage [2007/10/27(土) 13:50:12 ] >>219 そんな中途半端な仕様いやだよ。 push_back() はいけるのに insert() はだめとか。 仕様かえるなら半端にする必要ないでしょ。 221 名前：デフォルトの名無しさん mailto:sage [2007/10/27(土) 13:58:08 ] C++1xスレでも立てるか？ 222 名前：デフォルトの名無しさん mailto:sage [2007/10/27(土) 14:20:42 ] >>220 じゃあどういう修正なら納得するかｋｗｓｋ どのみちオーバーロードされたメンバ関数はシグネチャ明示しなければならんけど、 それ以外は一意に決まるってだけでも今よりだいぶマシじゃん。 根本的にはlambda式が導入されない限り解決にはならんと思うけど。 223 名前：デフォルトの名無しさん mailto:sage [2007/10/27(土) 16:13:50 ] >>222 >219 のやつだと、オーバーロードされてるやつは static_cast でシグネチャを 明示しても移植性を確保できない。 どうせやるなら >204 にある記述を全部削除して、 public なメンバ関数の シグネチャを規格でしばることにしたほうがいいと思う。そうすれば オーバーロードされてるやつでも static_cast での明示さえ我慢すれば 移植性を保ちつつメンバ関数へのポインタが使えるはず。 224 名前：デフォルトの名無しさん mailto:sage [2007/10/27(土) 16:57:44 ] >>223 そりゃ204全削除できれば一番いいけどね。 std::string とかメンバ関数100以上あるし、デフォルト引数使えないとなると 例えばfind_first_ofだけでも4つから7つに増えるわけで、実装側は大変だ。 少なくとも Defect Reports のレベルじゃ受け入れられなそうな印象。 225 名前：デフォルトの名無しさん mailto:sage [2007/10/27(土) 18:14:05 ] >>224 なんで「デフォルト引数使えない」なんて話になるの？ 226 名前：デフォルトの名無しさん mailto:sage [2007/10/27(土) 19:38:09 ] 流れぶった切りですまんけど >116 で紹介した Quantum::Superpositions の(簡易) C++ 版を作ってみた。 ttp://yak.myhome.cx/junks/index.html#cpp.superposition superposition と非 superposition 間の関係演算子だけ実装。 スレ違いかもしれないけど、発端はここだし Variadic templates 版実装も作ったってことでここは一つ。 >213 とりあえず Variadic template と通常の template は混ぜるな、に一票。 227 名前：デフォルトの名無しさん mailto:sage [2007/10/27(土) 21:57:34 ] >>226 読んで感想を書こうと思ったけど自宅モードでは boost/preprocessorが使われているコードを読む集中力が沸かない サンプルから察するに非決定的計算っぽく比較できるもの? 計算量はネストすると指数オーダーかな 228 名前：デフォルトの名無しさん mailto:sage [2007/10/28(日) 00:21:59 ] >>225 すまん早とちりした デフォルト引数の部分も含めて仕様にすればたしかに問題ないね デフォルト引数の存在を意識せずにシグネチャ指定を可能にする、 みたいなものを夢想してしまったようだ x.f(a) -> R (X::*)(A) x.f(a. b) -> R (X::*)(A, B) 229 名前：デフォルトの名無しさん mailto:sage [2007/10/28(日) 00:47:28 ] >227 > 非決定計算っぽく そこまで大それたことを考えてたわけではなくて基本要求は >114 ね。 any(a, b, c) == d → any(a == d, b == d, c == d) → any(bool0, bool1, bool2) → bool0 || bool1 || bool2 のように評価される(bool* はそれぞれの評価結果)。all の場合は最後の || が && になる。 で、↑から大体想像つくかもしれないけど、重要なこと書き忘れてた。 この実装だとショートカット評価しない。全ての項目に対して対応する演算子が呼ばれて bool の tuple に変換されてから最後 || とか && してる。 ショートカット評価するなら Expression Template 使うのかな。その上で Boost Lambda とか使えばほんとに非決定計算っぽくできるかもしれない。 230 名前：デフォルトの名無しさん mailto:sage [2007/10/28(日) 01:47:11 ] Expression Templateを使おうが、Boost Lambda使おうが、ショートカット評価は不可能だよ。 231 名前：デフォルトの名無しさん mailto:sage [2007/10/28(日) 02:22:58 ] >230 評価のタイミングもコントロールできるのが Expression Template の強みの一つだと思う。 operator&& それ自体をショートカット評価にすることはできないけど、Expression Template 使って木を生成した後で、 評価するときにこっちで勝手にショートカット評価してやればいい。 232 名前：デフォルトの名無しさん mailto:sage [2007/10/28(日) 02:40:30 ] なんか落ち着かないと思ったら、普通はショート「サーキット」評価だ。 で、ちょっと考え直してみたけど、a, b, c, d の評価自体が発生してしまうから、正しいショートサーキット評価にはならないってことでいい？ operator==() の呼び出しについてしか考えてなかった。 233 名前：デフォルトの名無しさん mailto:sage [2007/10/28(日) 07:13:39 ] 最近普通にshortcut evaluationって言うぞ。 Short circuitは古いだろ。マイキットじゃねーんだから。 234 名前：デフォルトの名無しさん mailto:sage [2007/10/28(日) 08:12:40 ] 0xにはDのlazyみたいなものないの？ 235 名前：デフォルトの名無しさん mailto:sage [2007/10/28(日) 09:42:07 ] >>233 短絡評価（short-circuit evaluation）や最小評価（minimal evaluation）に次いで 新たな用語が出てきたのかと思って調べてみたけど、どこで使われてる用語なの？ ここで話題にするってことは言語はC++なんだよね？ 簡略評価ならVB書籍で見たことあるけど･･･。（正直誤訳だと思ってた） 236 名前：デフォルトの名無しさん mailto:sage [2007/10/28(日) 12:06:23 ] >>231 ムリだって。 >>232 >で、ちょっと考え直してみたけど、a, b, c, d の評価自体が発生してしまうから、正しいショートサーキット評価にはならないってことでいい？ >operator==() の呼び出しについてしか考えてなかった。 operator==だけが短絡評価されて、なんの意味があるのか、普通そこまで考えるだろ。 お前の思考回路が短絡評価されてるよ。 void 思考回路(){ 　if ( (operator==呼び出しを遅延できる) || (a,b,cの評価を遅延できる) ){ 　　レス( 　　　　"評価のタイミングもコントロールできるのが Expression Template の強みの一つだと思う。" 　　　　"operator&& それ自体をショートカット評価にすることはできないけど、Expression Template 使って木を生成した後で、" 　　　　"評価するときにこっちで勝手にショートカット評価してやればいい。" 　 ); 　} } 237 名前：デフォルトの名無しさん mailto:sage [2007/10/28(日) 13:16:45 ] 次の言語仕様に中傷メソッドでも入れる勢いだなおい 238 名前：デフォルトの名無しさん mailto:sage [2007/10/28(日) 14:26:16 ] >236 すまんね。a, b, c, d の評価はこっちではどうしようもないところだから思考の外にあった。 なのでむしろこんな感じだな。 void 思考回路() {   if ( (operator==呼び出しを遅延できる) ){     レス(/*略*/);   } } bool out_of_scope = (a,b,cの評価を遅延できる); 239 名前：デフォルトの名無しさん mailto:sage [2007/10/28(日) 14:27:02 ] ちょっと言い過ぎた。 240 名前：デフォルトの名無しさん mailto:sage [2007/10/28(日) 21:06:43 ] ぬこぬこ 241 名前：デフォルトの名無しさん [2007/10/28(日) 23:35:22 ] coutって、printfより使えないと思うのは俺だけ？ 242 名前：デフォルトの名無しさん mailto:sage [2007/10/28(日) 23:45:22 ] 使えないとは言わないけども、 今思えば opeartor overload の乱用は失敗だったし、 フォーマット出力は欲しいってのはみんな思ってる。 243 名前：デフォルトの名無しさん mailto:sage [2007/10/28(日) 23:53:31 ] こんなこともできるよ的なものじゃないの？ 244 名前：デフォルトの名無しさん mailto:sage [2007/10/29(月) 00:33:23 ] basic_ostreamはそもそもコンソール出力のために作ったものではないだろう 役割が違う 使いたければstd::printfを使えばいいだけの話ではないのかな そういう言語だよね 245 名前：デフォルトの名無しさん mailto:sage [2007/10/29(月) 00:35:59 ] しかし型安全性は欲しいところ 246 名前：デフォルトの名無しさん mailto:sage [2007/10/29(月) 00:37:33 ] コンソール出力のためでないならば、具体的にどういう場合 printf よりグーなのだろうか 247 名前：デフォルトの名無しさん mailto:sage [2007/10/29(月) 00:42:32 ] ていうか型安全を考えれば printf のほうがありえねーって感じ？ typedef されてる整数型を正しく出力するために対応するフォーマット文字列を マクロで用意とか、やってられないでしょ。 248 名前：デフォルトの名無しさん [2007/10/29(月) 00:48:29 ] でもboost::formatはどうコンパイルされてるやらさっぱりわからんから恐くて使えない。 0xでこのあたり、なにか改善はありますか？ 249 名前：デフォルトの名無しさん mailto:sage [2007/10/29(月) 00:50:16 ] 怖くないよー怖くないよー 250 名前：デフォルトの名無しさん [2007/10/29(月) 01:14:46 ] printf問題は書式文字列リテラルっていう文字列と別のリテラルを作って コンパイラが型チェックするようにするのが結局いいんじゃないかなー 251 名前：デフォルトの名無しさん mailto:sage [2007/10/29(月) 01:19:58 ] 実際、多くのコンパイラがそれに近い扱いで型チェックしてるわけだな 252 名前：デフォルトの名無しさん mailto:sage [2007/10/29(月) 05:15:01 ] stringstream でええやん。 253 名前：デフォルトの名無しさん mailto:sage [2007/10/29(月) 20:02:05 ] >>248 boost::formatは別にコンパイル時にややこしいことをしてないと思うけど。 そんなことをする意味がない。 254 名前：デフォルトの名無しさん [2007/10/29(月) 21:34:04 ] >>253 仕組み説明してYO 255 名前：デフォルトの名無しさん [2007/10/29(月) 22:56:21 ] C++0x 2なんてつぶれろ 禿を含めたC++基地外共がややこしことばかり考えてるのに これ以上つき合えるか！ どんなに論理的に強力な根拠があると言ってもややこしい論理は 結局受け入れられないんだよ。 お前らだけで勝手に遊んでろや！馬鹿 256 名前：デフォルトの名無しさん mailto:sage [2007/10/29(月) 23:10:53 ] むしろわかりやすくなる方向に行ってると思うけどね まぁ他の言語でも楽しんできてください 257 名前：デフォルトの名無しさん mailto:sage [2007/10/29(月) 23:17:18 ] 確かにややこしすぎる感じはする よく使われる主要な言語が難しいのは歓迎だけど、わかる人間の価値が高まるし でもこの勢いだと主要でなくなりそう 258 名前：デフォルトの名無しさん mailto:sage [2007/10/29(月) 23:21:14 ] 右辺値参照を理解できない人が多そう 259 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 00:06:35 ] >>255 よしきた 俺たちだけで勝手に遊ぶよ 260 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 00:06:49 ] >>256 >むしろわかりやすくなる方向に行ってると思うけどね 基本的には同意だが、どちらかというと 今までのややこしさを軽減させようとしているだけとも感じる。 つまり、今までのややこしさでC++に匙を投げた人間は、 C++0xを好意的に受け止めるとは思い難い。また、なんか追加されるのかよ的な感じで。 でも、そのおかげでオレのような本来はたいして有能でもない人間が、 チーム、部署内でのある程度の地位をキープできてる。 オレのまわりはC++敬遠ぎみの人が多いから。 まさにオレは禿のジョークを体現している。 そういうわけでC++0xには期待している。ほどよくややこしくしてほしい。 261 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 00:10:58 ] ややこしいのが嫌いな人には、今は代わりになる言語があるからね 262 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 00:15:56 ] それよりいつになったらC++はまともなオブジェクト指向言語になるのかと 263 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 00:17:38 ] いまのSTLすら理解できない人には functionやbindは無視されるだろうね 264 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 00:21:24 ] >>263 bint1st, bind2nd, mem_fun, ptr_funなんかよりbindのほうが全然わかりやすい件について。 いまのMPLすら理解できない人には C++0xの大部分はスルーされるだろうね だったら同意。 265 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 00:26:09 ] >>264 bind1stとかについては同意 でもC++の文法からbindの存在を想像するのが難しいので 理解できないんじゃないかと思ったけど インターフェースが簡単だから大丈夫なのかな 266 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 00:29:13 ] 関数ポインタよりfunctionの方が全然分かりやすい件について 267 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 00:34:18 ] >>265 うん。大丈夫。以前経験した現場だと、C++初心者レベルのみんながboost::bindを使いまくって プロジェクトが崩壊しかけたたよーん。 兄さん、そのbindしたthis、とっくに死んでます・・・みたいな。 268 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 01:56:25 ] bindでポインタ持ち運んだらえらいことになりそうだ 269 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 02:03:57 ] C++初心者はC++なんて使っちゃ駄目なのだ つまりC++を学ぶときは、いきなりC++の達人にならなければいけない 270 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 02:06:12 ] んなこたぁ〜ない 271 名前：デフォルトの名無しさん [2007/10/30(火) 02:17:34 ] www.open-std.org/jtc1/sc22/wg21/ News 2007-10-28: The 2007-10-post-Kona mailing is available News 2007-10-28: The C++ Standard Library Issues List (Revision 52) is available 272 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 05:11:26 ] 便利な機能があるからって使わなきゃいけないということはない。 bindやconceptなんてライブラリビルダが使ってればよろしい。 273 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 08:21:15 ] まさにC++は男坂 274 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 09:18:28 ] いやbindは便利だよ 沢山引数を指定する関数のある引数だけを変えながら実行する場合、さらに具体的にいえば 初期化ルーチンで動作モードを調べながら実行するときとかよく使うし 275 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 12:33:27 ] >>272 そのレベルで使うならC++の必然性が少ない。言語は他にいっぱいある。

---

---

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

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