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/ 152 名前：デフォルトの名無しさん mailto:sage [2007/10/22(月) 01:19:30 ] Wikipediaをwikiって言うの以上に無理がある気が… 153 名前：デフォルトの名無しさん mailto:sage [2007/10/22(月) 01:49:31 ] 清岡以前の世代はC++0xに興味を持っていないようだよ・・・寂しいね・・・ 154 名前：デフォルトの名無しさん mailto:rvalue reference [2007/10/22(月) 01:50:40 ] >>153 誰だよ？w 155 名前：デフォルトの名無しさん mailto:sage [2007/10/22(月) 23:35:35 ] 俺俺、俺だって 156 名前：デフォルトの名無しさん mailto:sage [2007/10/22(月) 23:53:16 ] おまえかあ 157 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 00:11:43 ] >>154 平清盛の大叔父の平清岡だよ。 ちなみに弟は平盛岡。 158 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 10:36:59 ] >C++ では、継承によってメソッドが暗黙的に "隠ぺい" されます。 >C# では、new 修飾子を使用して、継承メンバを明示的に隠ぺい >する必要があります。 こういう安全機構（といっても構文上の）が C++ にも必要じゃね？ 159 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 10:38:33 ] 賛成 160 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 11:54:33 ] 俺なんかメンバ変数と同じ名前のローカル変数を メソッドの中で使ってしまって●一日悩んだ． こういうのも言語仕様上明示的に隠ぺいしなきゃ ならないとしてくれるとありがたい． 161 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 12:59:28 ] >>160 今時のコンパイラなら適切に警告が出るはずだが。 162 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 14:29:32 ] >>161 まじっすか〜？ Visual C++ 2005 で警告をレベル4にしても出なかった希ガス 163 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 14:57:09 ] ゴメン。今見たら、手元のコンパイラはディフォルトでは全滅だった。 見た記憶はあるからgccのオプションであると思うんだけどなぁ。 164 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 15:34:17 ] >>163 -Wshadow かな? 165 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 15:39:11 ] そういう明示的な隠蔽とか まずい設計の尻拭いの機能は言語仕様にはないほうがいいと思う コンパイラのオプションにあるのは別にいいけど 166 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 15:58:32 ] なぜ？ 167 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 16:15:38 ] $ cat test.c class C { int x, y; int m(void) { int x; x = y * y; return x; } }; $ g++ -c -Wshadow test.c test.c: In member function 'int C::m()': test.c:5: 警告: declaration of 'x' shadows a member of 'this' 168 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 16:16:12 ] >まずい設計の尻拭いの機能は言語仕様にはないほうがいいと思う これにかかる「なぜ？」への答えは 以下のことが起こる可能性があるから 1 不必要なことを強制される 2 予約語が増える 3 言語仕様が大きくなる 4 まずい設計を支援する > コンパイラのオプションにあるのは別にいいけど これにかかる「なぜ？」への答えは、自分への悪影響はないから 169 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 16:53:40 ] １と３は矛盾 ４は丸っきり逆 170 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 16:55:24 ] なぜ？ 171 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 19:08:56 ] >>165 まずい設計のしりぬぐいってわけでもないと思うんだよ。 １）変数名の規則は設計というよりはコーディング規約 ２）しりぬぐいじゃなくて、まずいコーディングが 　　やりにくいようにしておくのが幸せ >>169 の指摘は正しいと思う。まずいコーディングを 支援するんじゃなくて「やりにくく」するのだから。 172 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 19:14:01 ] www.blender.org/documentation/intranet/conventions/codingstyleguide.html によると、gcc でのお勧め警告フラグは、 * -Wall, -W * -Wshadow * -Wpointer-arith * -Wbad-function-cast * -Wcast-qual * -Wcast-align * -Waggregate-return * -Wstrict-prototypes * -Wmissing-prototypes * -Wmissing-declarations * -Wredundant-decls * -Wnested-externs 173 名前：165 mailto:sage [2007/10/23(火) 20:11:50 ] 自分が言ってるのは 明示的に隠蔽を宣言しなければ、うっかり意図せず名前を隠蔽しちゃうような 巨大なベースクラスは設計がまずい ということ 継承の階層が深すぎたり、メンバが多すぎたりしなければ 明示的な隠蔽の宣言が必要なんて、押し付けがましく感じるってこと で、明示的な隠蔽の宣言はそういうまずい設計を助けてしまう 174 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 20:27:42 ] いや、わかるけど 逆に継承させた人が隠蔽してることを明示したいって事もあるんじゃない 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 でええやん。

---

---

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

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