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/ 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++の必然性が少ない。言語は他にいっぱいある。 276 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 12:57:35 ] ぷろぱてぃというかげったーとかせったいみたいなのは ０ｘではいるんですか？はいらないんですか？ どうなんです？heheheh 277 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 13:21:27 ] なんか変なのキタ 278 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 14:53:31 ] 下駄と雪駄？ もう入ってるだろうっつーか 下駄がcast operatorで 雪駄がassignment operatorで代用できそうな 279 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 17:00:46 ] それだとプロパティごとにクラス作らなきゃという気がする 280 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 17:19:19 ] >>279 プロパティは概念上、ダイレクトな生メンバとは違うものだから記述方法も違ってくるのかなと 下駄も雪駄もC++の原則 「テクニックでどうにもならない機能だけを言語仕様に頼む」 にはあたらないなあと 281 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 18:47:44 ] D言語マンセー 282 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 18:49:20 ] CよりDがEけど結局F# 283 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 20:20:20 ] Zもすでにあるみたいだし究極言語「ん」とか作ろうぜ 284 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 21:17:02 ] プログラム言語じゃなくて仕様記述言語だけどな。 285 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 21:20:42 ] ん、いいねぇ。 286 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 22:06:40 ] >>278 プロパティの代用はできねーよ。 そんなので代用したらクラスのサイズが無意味に増えるだろ。 287 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 23:06:29 ] >>286 getterとsetterが言語仕様に入るだろうか？という話をしているのに なぜクラスのサイズという実装上の問題の話に摩り替わってしまうのだろうな？ 288 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 23:23:14 ] >>287 はぁ？頭大丈夫か？ プロパティは >下駄がcast operatorで >雪駄がassignment operatorで代用できそうな とか言う奴に、それで代用なんかできてないという話をしてるのに、 何故getterとsetterが言語仕様に入るだろうか、という話に摩り替えようとするんだよ。 バカかこいつ。 289 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 23:25:26 ] >>288に一票 290 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 23:57:08 ] じゃあ俺は>>287に100億万票 291 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 23:57:24 ] >>288 正論だが物言いがよくない 292 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 00:09:54 ] >>288 (1)getter/setterのC++0x化 → (2)下駄雪駄 → (3)代用はできない → (4)クラスのサイズが増える で (1) || (2) の話をしている所に (2)->(3) と飛躍して (3) && (4) を適用していますが 話を逸らしている行為以外の何だと思っているのですか？ 「代」わりに「用」いる、ではなく「そのテクニックは既にある言語仕様で実現できる」という話ですよ (1) || (2) の時点で「あぁそうですね」で終わっていた話から (2)->(3) と展開する合理性が見えません 293 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 00:15:31 ] 別に君は見えないままでいいんじゃない？ 他の人は見えてるから問題無いし、君という一人の阿呆が困ったりムカついたりしても 誰も困らないし。 294 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 00:28:25 ] 個人攻撃をする間で関数の一つでも書こうぜ… 295 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 00:29:16 ] >>293 >誰も困らないし。 >>292が困る件について 296 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 00:38:40 ] >>292 それはお前の脳みその中だけで通用するパカ論理だということを忘れてはいけません。 297 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 00:55:41 ] クラスのサイズが増える、って具体的に何が増えるの？マジで。 コードサイズだというならインライン化の度合はsetter-getterと同じかそれより強いと思うし、 データサイズが増えるわけはないし。 感情が先走って論理展開がムチャクチャになってないか。 本当に中傷メソッドが追加されるなこりゃｗ 298 名前：デフォルトの名無しさん [2007/10/31(水) 01:00:34 ] レベルひっく〜 299 名前：デフォルトの名無しさん [2007/10/31(水) 01:07:11 ] 　　 ∧＿∧　　／￣￣￣￣￣ 　　（　´∀｀）＜　オマエモナー 　　（　　　　） 　＼＿＿＿＿＿ 　　｜ ｜　| 　　（＿_）＿） 300 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 01:32:05 ] たとえ内容がマトモでも罵倒口調だと読む気がしない 301 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 02:10:04 ] バカばーっか。 302 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 02:26:48 ] じゃ俺ははらたいらに3000点 303 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 03:38:05 ] もうお亡くなりになられました。 ってか、もういー加減にしろよｗ 304 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 08:50:15 ] >>297 パカ極まるなお前。 >下駄がcast operatorで >雪駄がassignment operatorで代用できそうな これで代用したプロパティを持つクラスを実際に作ってsizeofしてみろ場か 305 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 09:40:43 ] >>304 あなたの意見を私が証明しなければならない、というのは筋が通りませんが… sizeof にコード量が反映されるという処理系は知りませんよ？私は 306 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 09:41:41 ] >>304 sizeof は変わらないでしょう。 307 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 12:13:12 ] >>306 template< typename V > struct property { .... }; // プロパティクラス class foo { 　int value_; public: 　foo() : { value.setref(value_); } 　property<int> value; }; // プロパティ構文 C# class bar { 　int value_; public: 　int value { get{ return value_; } set(int val){ value_ = val; } }; }; sizeof(foo); sizeof(bar); どっちが大きい？ 308 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 12:21:10 ] 違う言語で比較してどうすんの？ 309 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 13:45:53 ] もともと（C#にあるような）プロパティが欲しいって話じゃなかったっけ 310 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 13:56:59 ] syntax sugar 以上の意味があるの？ 311 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 13:59:14 ] 参照の分メモリを節約できるといいたんじゃないの 312 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 14:32:05 ] プロパティ + Template で楽しいことが出来ると思うけどな。 従来の構造体と、変数を分け隔てなく扱えるようになるとかさ。 struct Interface { 　virtual int value { ... }　← 仮想プロパティ }; template< typename T > void init_val( T & val ) { 　val = 20; } int x = 0; init_val(x); // x = 20; Interface * p = ...; init_val(p->value); // p->value = 20 無理かな。 313 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 14:48:07 ] >>307 cast operator と assignment operator では代用できない、という話ではなかったのですか？ 314 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 15:35:48 ] 漏れもデータメンバが増えるようでは setter と getter の シンタックスシュガーの代用としては不適格だと思うが・・・ 単一の本物のデータメンバであることを活かせる場面もあるだろうから、 どっちが良いという話ではないけど。 315 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 15:42:33 ] getとsetが予約語になったら楽しい 316 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 15:56:07 ] D言語マンセー import std.stdio; class Foo{   private int value_;   int value(){return value_;}   int value(int val){return (value_=val);} } void main(){   auto f = new Foo;   f.value=10;   writefln(f.value); } 317 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 17:33:19 ] >>316 Dはそれでいいだろうが、C++で bind するとき大変そうだからヤダ 318 名前：デフォルトの名無しさん [2007/10/31(水) 18:38:23 ] Dとかイラネェ 319 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 19:03:55 ] template <typename _T> class property { 320 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 19:04:28 ] なかったことにしよう 321 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 19:16:58 ] template <typename _T> class property { private: T t; T* operator &(); public: operator T () { return t; } T& operator = ( const T& r ) { t = r; return *this; } }; class A { public: property<int> value; }; void test() { A a; int v = 1; a.value = 0; //ok (a.value == 0) v = a.value; //v = 1 a.value += 4; //error } 322 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 19:49:38 ] それ、publicメンバ変数に比べて何か嬉しいことあんの？ 323 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 20:47:09 ] なんもないｗ default constructibleじゃないとだめだし マジメなsetter/getter実装しようともったら結局なんらかの参照が必要になる 324 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 21:35:04 ] C++ : 不便に感じる糞仕様がそれなりに多い D : 妥協ライン C# : マイコーソフトの柵 C++0x : 期待と不安の境目 325 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 21:57:53 ] >>305 いつ誰がコード量が増えると言ったんだ？ 筋が通ってないのはお前だよ。 >>313 どうみても代用できてないだろ。お前の目はフシアナかいな。 326 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 23:05:08 ] 一応こんな提案あったみたいだけど、Not ready for C++0x, but open to resubmit in future になってる。 C++ Properties -- a Library Solution ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1615.pdf 327 名前：デフォルトの名無しさん mailto:sage [2007/11/01(木) 01:57:51 ] プロパティ話は Boostスレpart4 でもやってたやん もういいよ 328 名前：デフォルトの名無しさん mailto:sage [2007/11/01(木) 07:48:40 ] >>327 それ言ったらほとんどのスレッドが終わっていく… 329 名前：デフォルトの名無しさん mailto:sage [2007/11/01(木) 19:46:00 ] >>326 C++1x？が待ち遠しくなった。 330 名前：デフォルトの名無しさん mailto:sage [2007/11/01(木) 20:32:27 ] >>326 プロパティ1つ追加するごとに、ポインタ分だけオブジェクトのサイズが膨らむのか 331 名前：デフォルトの名無しさん mailto:sage [2007/11/02(金) 03:20:43 ] そもそもプロパティなんていらね 332 名前：デフォルトの名無しさん mailto:sage [2007/11/02(金) 10:42:00 ] たしかにいらね。 そのまま公開するんなら public メンバ変数にするさ。 333 名前：デフォルトの名無しさん mailto:sage [2007/11/02(金) 11:02:23 ] 下駄と雪駄にfuck…もといhookかけられるならそれなりに有用になるかも 334 名前：デフォルトの名無しさん mailto:sage [2007/11/02(金) 11:11:10 ] hook をかけないプロパティになんのいみがあるのかと問いたい 335 名前：デフォルトの名無しさん mailto:sage [2007/11/02(金) 11:23:07 ] なんとなくオブジェクト指向している気になれるというなかなかぬるぽな効果があります 336 名前：デフォルトの名無しさん mailto:sage [2007/11/02(金) 11:57:04 ] プロパティいらねぇから、組み込み変数とPODに対してだけでいいから 変数の値が更新されたときにフックかけれるようにして欲しい。 class MyWindow { 　void updateRect( RECT old_value ) { 　　SetWindowRect(&windowRect); 　} public: 　__declspec(onchange=updateRect) RECT windowRect; } みたいな。 337 名前：デフォルトの名無しさん mailto:sage [2007/11/02(金) 13:39:58 ] いつのまにやら日本語版にもC++0xの項目が ttp://ja.wikipedia.org/wiki/C%2B%2B0x M＄が21世紀終わるまでにちゃんと実装してくれるとは思えん。

---

---

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

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