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/
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 ] バカ専用にしょぼい言語つくろうって話なんだからw
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 主旨だけシンプルに書きましょう。 わめいて逃げてるようにしか見えませんw
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 拡張メソッドのメリットって何?
363 名前:デフォルトの名無しさん mailto:sage [2009/02/25(水) 01:13:23 ] >>361 むしろ梅干し食べてる感じ
364 名前:デフォルトの名無しさん mailto:sage [2009/02/25(水) 03:35:03 ] >>356 難しく考えすぎ 普通に第一引数がthisでそれ以外が普通の関数の定義と同じようになるようにすれば良い。 たとえば class foo {}; // 定義 class foo { int bar(int baz) { return baz; } }; // 拡張メソッド(C#風) って書いたら int foo_extended_method_bar(foo* this, int baz) { return baz;} って書くのと同じようになるようにすればいい。 でも継承したらどうなるかとかは知らん >>362 使ったこと無いからわかんないなぁ rubyのサンプルコードで良く見るけど
365 名前:デフォルトの名無しさん mailto:sage [2009/02/25(水) 09:00:55 ] >>364 なにその生産性の低い記述は。
366 名前:デフォルトの名無しさん mailto:sage [2009/02/25(水) 09:13:32 ] あくまで後から擬似的にメンバメソッドを追加できるようにするシンタックスシュガーでしょ。 あんまりいい例じゃないけど、なんでこの行列クラス、固有値求められないんだよ…ってときに: #include "matrix" // class Matrix; #include "eigenvalues" // vector<double> eigenvalues(const Matrix& this); Matrix m; auto es = m.eigenvalues(); // eigenvalues(m); と同等 Matrix* pm; pm->eigenvalues(); // eigenvalues(*pm);
367 名前:デフォルトの名無しさん mailto:sage [2009/02/25(水) 11:11:44 ] 比較的簡単な処理の流れはメソッドチェイン出来ると楽ってだけかと ただC++だと例外を軽く使えないからエラー処理をどうしようってことでMaybeモナドが欲しくなる
368 名前:デフォルトの名無しさん mailto:sage [2009/02/25(水) 12:10:37 ] >>366 例が悪すぎます
369 名前:デフォルトの名無しさん mailto:sage [2009/02/25(水) 12:45:38 ] >>366 Matrixをテンプレートの型パラメータで渡したときなんか拡張メソッドの定義includeの読み込み順で拡張メソッドが適用されたりされなかったりするのかな
370 名前:デフォルトの名無しさん mailto:sage [2009/02/25(水) 15:11:17 ] oven(egg)のpipableは拡張メソッドっぽい
371 名前:デフォルトの名無しさん mailto:sage [2009/02/25(水) 19:56:06 ] ソースが短くなるだけで、生産性の低い、動きがトロい、そんなバイナリーができそうだな。 現状のSTLも遅いし。
372 名前:デフォルトの名無しさん mailto:sage [2009/02/25(水) 20:06:19 ] 拡張メソッドの解決は動的ポリモルしなければコンパイル時に行うことができるんでそうとも言いきれない
373 名前:デフォルトの名無しさん mailto:sage [2009/02/25(水) 22:40:52 ] 第一引数を前に出す、単なる糖衣構文だから、バイナリが遅くなるなんてことはないわ
374 名前:デフォルトの名無しさん mailto:sage [2009/02/25(水) 23:12:40 ] C++だとただの糖衣じゃ済まないから注意しないとオーバーヘッドはかかるな
375 名前:デフォルトの名無しさん mailto:sage [2009/02/25(水) 23:15:33 ] operator.ぐらいの糖衣
376 名前:デフォルトの名無しさん mailto:sage [2009/02/25(水) 23:47:58 ] generic functionがあるのに必要ですかね。
377 名前:デフォルトの名無しさん mailto:sage [2009/02/26(木) 01:09:52 ] >>372 それが問題なんでねぇかい テンプレートメンバ関数はその辺上手く逃げたよなぁ
378 名前:デフォルトの名無しさん mailto:sage [2009/02/26(木) 05:05:59 ] 普通のオーバーロード解決でなんか問題あるんか。
379 名前:デフォルトの名無しさん mailto:sage [2009/02/26(木) 11:52:07 ] >>378 kwsk
380 名前:デフォルトの名無しさん mailto:sage [2009/02/26(木) 13:18:24 ] objがfuncメソッドを持ってなくて、スコープにfunc拡張関数がある場合、 obj.func(args) を func(obj, args) と字面上同義みなすってことでは?
381 名前:デフォルトの名無しさん mailto:sage [2009/02/26(木) 13:20:17 ] generic functionがあるのに必要ですかね。