- 1 名前:デフォルトの名無しさん mailto:sage [2009/04/01(水) 10:15:52 ]
- (#゚ー゚)つ < C#、.NETの話題はこちらでどうぞ。
前スレ C#, C♯, C#相談室 Part51 pc12.2ch.net/test/read.cgi/tech/1233757615/ Visual C# 2008 Express Edition 日本語版 www.microsoft.com/japan/msdn/vstudio/express/vcsharp/ その他テンプレ>>2-5くらい
- 585 名前:デフォルトの名無しさん mailto:sage [2009/05/31(日) 00:31:27 ]
- その前に
コンストラクタでこんなことしていいんか
- 586 名前:デフォルトの名無しさん mailto:sage [2009/05/31(日) 00:38:47 ]
- そもそもそんなこする方がやばいんだから
しないように修正するべきだろう。
- 587 名前:デフォルトの名無しさん mailto:sage [2009/05/31(日) 00:39:33 ]
- フォームをNewしたらいきなり表示されるとか、冗談ではないわ。
- 588 名前:デフォルトの名無しさん mailto:sage [2009/05/31(日) 00:46:51 ]
- しないように済む方法を指導しないテキストがクズだな。
- 589 名前:デフォルトの名無しさん mailto:sage [2009/05/31(日) 00:46:50 ]
- 引用した方がいいんだが、何せ立ち読みで読んだだけなんで、すまんね。
しかし、デリゲートの非同期実行でEndInvokeせずに、なんと例外が無視されてしまうのだ!! みたいなこといって、非同期実行するメソッド内で即座にコントロールにInvokeして、これで例外をとれる っておまえそれ非同期実行の意味全然ないだろうがよとか、こんなの見るとなんか書いてあることが信用できない。
- 590 名前:デフォルトの名無しさん mailto:sage [2009/05/31(日) 01:04:13 ]
- あー、エスパーすると、非同期実行すると例外取れないから同期しましょう、
と書いてあるのか?
- 591 名前:デフォルトの名無しさん mailto:sage [2009/05/31(日) 01:11:44 ]
- そういうこと
- 592 名前:デフォルトの名無しさん mailto:sage [2009/05/31(日) 01:17:58 ]
- その本でスレッド周りに何書いてあるのか、ちょっと気になってきたww
- 593 名前:デフォルトの名無しさん mailto:sage [2009/05/31(日) 01:39:23 ]
- 意外と好評な書評も。
mag.autumn.org/Content.modf?id=20090526140144
- 594 名前:デフォルトの名無しさん mailto:sage [2009/05/31(日) 02:11:24 ]
- んー今はどうかわからんけど、
Formは2回以上ShowDialogすると動作保証されない だった気がするけどな。 ナレッジに出てなかったっけな…
- 595 名前:デフォルトの名無しさん mailto:sage [2009/05/31(日) 07:20:32 ]
- C#で複数接続ができるサーバーを作成しているのですが、多くの接続を受け付けると、
「転送接続からデータを読み取れません: ブロック不可のソケット操作をすぐに完了できませんでした。」 というエラーが出て、例外が発生してしまいます。 誰かこのエラーの解決方法をご存じないでしょうか? よろしくお願いします。
- 596 名前:デフォルトの名無しさん mailto:sage [2009/05/31(日) 07:30:32 ]
- XPのコネクション制限に引っ掛かってるとか。
- 597 名前:デフォルトの名無しさん mailto:sage [2009/05/31(日) 07:48:28 ]
- >>596
XPのコネクション制限には引っかからない程度でも発生するんですよね… # 10本くらいConnectが発生すると5本目くらいからエラーが発生→例外→…という感じで
- 598 名前:デフォルトの名無しさん mailto:sage [2009/05/31(日) 09:22:23 ]
- サーバOSやTCP/IP Pacherとかで制限ない状態で試してみれば?
- 599 名前:デフォルトの名無しさん mailto:sage [2009/05/31(日) 09:51:46 ]
- その前にプログラムを
- 600 名前:デフォルトの名無しさん mailto:sage [2009/05/31(日) 13:22:18 ]
- 自分以外のコネクションが5〜6個あるんでしょ?
- 601 名前:デフォルトの名無しさん mailto:sage [2009/05/31(日) 14:13:55 ]
- VistaSP2と2008サーバでは撤廃されたっていうからXPでもパッチこないかな・・・
いやがらせとして残されたりして。
- 602 名前:デフォルトの名無しさん mailto:sage [2009/05/31(日) 14:15:20 ]
- >>593
これWM_CREATE代わりなんだ、確かにShowDialogするごとに呼び出されるね、名前が悪いよな。
- 603 名前:デフォルトの名無しさん mailto:sage [2009/06/01(月) 12:05:26 ]
- C#というか.netで使える
rubyでいうところの,Narray pythonでいうところのNumPy のような配列の形で演算してくれるクラスライブラリはありますか?
- 604 名前:デフォルトの名無しさん mailto:sage [2009/06/01(月) 12:21:34 ]
- >>603
コンセプトがまるで違うけれども、あえて言えばLINQがそのような処理を担当するライブラリと言えるかと思われます。 だけれども、そういう操作そのものを求めるとちょっと、というかまったく違うものかも やりかたとしては二つのシーケンスを一つのシーケンスにまとめる、そこに select なりで全体に演算を施す、といった具合。
- 605 名前:デフォルトの名無しさん mailto:sage [2009/06/01(月) 12:46:05 ]
- 数値演算ライブラリが欲しいと言ってるのに、linq挙げるってのはないだろw
でも、.NET向けってのは商業ものしか知らんわ。 BLAS系の.NETバインディングは探せばありそうだけど。
- 606 名前:デフォルトの名無しさん mailto:sage [2009/06/01(月) 12:53:14 ]
- >>603
詳細はまだ調べてないけど、.NET で線形代数を助けてくれるライブラリなら Math.NET があるみたい。 mathnet.opensourcedotnet.info/
- 607 名前:デフォルトの名無しさん mailto:sage [2009/06/01(月) 13:01:57 ]
- >>605
そうですか?むしろ汎用度の高いライブラリだと思うんですけどね。 自分は今は線形代数周りは全部LINQで構築してしまいましたけど
- 608 名前:デフォルトの名無しさん mailto:sage [2009/06/01(月) 13:04:41 ]
- そもそもLINQってのはテクノロジー()笑の名前であって、ライブラリの名前ではないと思うんだが。
- 609 名前:デフォルトの名無しさん mailto:sage [2009/06/01(月) 13:04:55 ]
- LINQのコンセプト、モナドと抽象線形空間の相性がいいというか……
実数上の線形空間はもちろん、複素数でも有限体でもいけるし、いっそ関数を基底とかも。 まぁなんかそんな感じてす
- 610 名前:デフォルトの名無しさん mailto:sage [2009/06/01(月) 13:15:52 ]
- LINQは集合演算
mapもあるしリスト演算(コンベア的な)もつかえるし そういういみじゃん
- 611 名前:デフォルトの名無しさん mailto:sage [2009/06/01(月) 13:26:56 ]
- LINQtoObjectによる各種演算処理からLINQtoSQL or LINQtoXMLと次々と同一コンセプトでつながっていくのも気持ちいいしね。
- 612 名前:デフォルトの名無しさん mailto:sage [2009/06/01(月) 18:04:30 ]
- 列挙型を含んだクラスをシリアライズしようとすると
例外が発生してしまいます。 ↓こんな列挙型です。 public enum ActionType { [XmlEnum(Name = "Single")] One, [XmlEnum(Name = "Double")] Two, [XmlEnum(Name = "Triple")] Three } なにか方法などありますでしょうか?
- 613 名前:デフォルトの名無しさん mailto:sage [2009/06/01(月) 18:10:14 ]
- 例外の詳細ぐらい書けよ
- 614 名前:デフォルトの名無しさん mailto:sage [2009/06/01(月) 18:15:12 ]
- IXmlSerializableを実装しろ
- 615 名前:デフォルトの名無しさん mailto:sage [2009/06/01(月) 22:20:33 ]
- アンマネージコードからコールバックされるマネージコードで例外をアンマネージ側に
漏らしたくない場合は以下のMyCallBackのような処理であってる? public delegate bool CallBack(); [DllImport("hoge.dll")] private static extern int Hoge(CallBack callback); static void MyCallBack() { // このメソッド内で発生した例外を hoge.dll に漏らしたくない RuntimeHelpers.PrepareConstrainedRegions(); try { // hoge } catch (Exception e) Console.WriteLine(e); } } static void Main() { Hoge(new CallBack(MyCallBack)); }
- 616 名前:デフォルトの名無しさん [2009/06/01(月) 22:25:23 ]
- それはいいけど渡し方がダメ
アンマネージコードに渡したデリゲートはstaticフィールドに入れとかないとGCされて死亡
- 617 名前:デフォルトの名無しさん mailto:sage [2009/06/01(月) 22:25:31 ]
- エラー時コールバック(イベント)でも登録できるようにするべきじゃないかな。
常にコンソール出力だけでOKなら別にいいかもだけど。
- 618 名前:デフォルトの名無しさん mailto:sage [2009/06/01(月) 22:29:47 ]
- >エラー時コールバック(イベント)でも登録できるようにするべきじゃないかな。
>常にコンソール出力だけでOKなら別にいいかもだけど。 おっと、CERじゃこんなのは無理か。 ってその前にコンソール出力も無理なんじゃないか?
- 619 名前:デフォルトの名無しさん mailto:sage [2009/06/01(月) 22:37:08 ]
- なんかイマイチやりたいことが伝わってこない
例外握りつぶしてしまっていいのか
- 620 名前:デフォルトの名無しさん mailto:sage [2009/06/01(月) 22:45:50 ]
- >public delegate bool CallBack();
>static void MyCallBack() >Hoge(new CallBack(MyCallBack)); 返り値違うぞ
- 621 名前:デフォルトの名無しさん mailto:sage [2009/06/01(月) 23:07:24 ]
- >>616
GCHandleいじるのが作法上正しいのでは
- 622 名前:デフォルトの名無しさん mailto:sage [2009/06/01(月) 23:22:17 ]
- >アンマネージコードに渡したデリゲートはstaticフィールドに入れとかないとGCされて死亡
このコードだと問題ないけどね。 もちろんこういう構造じゃない場合は問題あるので考慮は必要。
- 623 名前:デフォルトの名無しさん [2009/06/01(月) 23:29:05 ]
- 問題ないかどうかはHogeの中身による
非同期にコールバックされたり戻ったあとも向こうで関数ポインタ保持されたりしたら死ぬ
- 624 名前:デフォルトの名無しさん mailto:sage [2009/06/01(月) 23:59:45 ]
- 非同期にコールバックする頃にはプログラム終了してるんじゃないかな、この場合
- 625 名前:デフォルトの名無しさん mailto:sage [2009/06/02(火) 00:11:12 ]
- この場合ってhogeの中身が何も書いてないんだから
何も判断できない
- 626 名前:デフォルトの名無しさん mailto:sage [2009/06/02(火) 00:31:25 ]
- static void Main()
{ Hoge(new CallBack(MyCallBack)); } だから後でコールバックされるような使い方じゃないと「想定したら」、だよ。>このコードだと問題ない
- 627 名前:デフォルトの名無しさん mailto:sage [2009/06/02(火) 07:29:09 ]
- ホゲが何者かわからん状態で
てめー勝手に都合の良い想定をするのは愚の骨頂じゃないか
- 628 名前:デフォルトの名無しさん mailto:sage [2009/06/02(火) 09:57:11 ]
- 未来永劫大丈夫。
PCのメモリも640KBで十分だし。
- 629 名前:デフォルトの名無しさん mailto:sage [2009/06/02(火) 11:05:07 ]
- 別に普通の想定だろ。
まあ別に軽く突っ込んでみただけで、ホントにそれでいいとは思ってないよ。
- 630 名前:デフォルトの名無しさん mailto:sage [2009/06/02(火) 11:28:47 ]
- >>628
いつまでそんなネタひっぱってんだよ化石
- 631 名前:デフォルトの名無しさん [2009/06/02(火) 19:10:23 ]
- 登録しといて後で呼び出してもらう形の方が想定としては一般的だと思うんだが
P/Invokeでは特に
- 632 名前:デフォルトの名無しさん mailto:sage [2009/06/02(火) 19:10:47 ]
- 未来永劫ひっぱるぜ
- 633 名前:デフォルトの名無しさん mailto:sage [2009/06/02(火) 19:27:06 ]
- だから、このコードだと、なんだろ?
- 634 名前:デフォルトの名無しさん [2009/06/02(火) 19:33:36 ]
- Hogeが非同期ならこのコードでも死ぬよ
- 635 名前:デフォルトの名無しさん mailto:sage [2009/06/02(火) 19:44:12 ]
- CallBackが引数無い、返り値はbool、例外は関数の外に出したくない
工夫のしようがないよね hogeのインターフェイスを変更可なら色々出来るが
- 636 名前:デフォルトの名無しさん mailto:sage [2009/06/02(火) 22:18:06 ]
- >>634
いやまずあり得ないね。 まあ意味ないしどうでもいいけど。
- 637 名前:デフォルトの名無しさん [2009/06/03(水) 17:19:43 ]
- ちょっと相談させて下さい。
ネットワーク経由で送られてくるバイトストリームがあるとして、あるバイト位置まで読み進めないと どんなフォーマットのパケットが来てるか分からないという形態のプロトコルを処理する場合、C#的には どう書くとするとスマートなんでしょうか? 結果的には、パケットの種類に応じた構造体として後の処理で使えるようになればいいです。 C言語だと共用体を使うとスッキリ書けますが、C#でFieldOffsetを使うのは何となく邪道な気がします。
- 638 名前:デフォルトの名無しさん mailto:sage [2009/06/03(水) 17:46:28 ]
- 自分なら迷わずFieldOffsetを使うけど、なぜそれが邪道なのかはわからん。
- 639 名前:デフォルトの名無しさん mailto:sage [2009/06/03(水) 18:08:37 ]
- >>637
何で邪道なんだろ どうしても嫌ならビットシフトやらこねくり回せば?
- 640 名前:デフォルトの名無しさん mailto:sage [2009/06/03(水) 18:15:36 ]
- 指定位置までMemoryStreamに入れといて
データの種類が判明してから適宜変換して使うとか?
- 641 名前:デフォルトの名無しさん mailto:sage [2009/06/03(水) 19:44:55 ]
- >>637
バッファと実インスタンスを分けて書くしかないんじゃないかなぁ
- 642 名前:デフォルトの名無しさん mailto:sage [2009/06/03(水) 19:45:46 ]
- >>637
ある時点でpush backできるストリームを使うか作る
- 643 名前:デフォルトの名無しさん mailto:sage [2009/06/03(水) 20:48:33 ]
- 経験者に聞きたいのですが、C#はC++やCに比べて使いやすいでしょうか?
普及度とか今後を見たときに覚えておくと便利ですか?
- 644 名前:デフォルトの名無しさん mailto:sage [2009/06/03(水) 20:51:46 ]
- 段違いで使いやすい。
今後は、まあ、CやC++は上級者のための代物になりつつあるから 今からC,C++を一からやるよりは良いんじゃないかね。
- 645 名前:デフォルトの名無しさん mailto:sage [2009/06/03(水) 21:12:48 ]
- C/C++で書く経験自体はしておいた方がいいと思うけど、実用的にはC#のが楽。
まぁ、C#じゃなくてもJavaでもRubyでもErlangでも好きなものを使えばいいと思うが。
- 646 名前:デフォルトの名無しさん mailto:sage [2009/06/03(水) 21:17:40 ]
- レスありがとうございます。
C#は確かに使いやすくなっているようなイメージがあるのですが CやC++でしかできなくて、C#じゃできない事ってあるんですか?
- 647 名前:デフォルトの名無しさん mailto:sage [2009/06/03(水) 21:22:53 ]
- 大きく見ればデバイスドライバとかシステムフックとかぐらいか
- 648 名前:デフォルトの名無しさん mailto:sage [2009/06/03(水) 21:39:34 ]
- >>646
.NET言語だから移植性に難
- 649 名前:デフォルトの名無しさん mailto:sage [2009/06/03(水) 22:03:33 ]
- cしらないとdllimportかけないじゃん
- 650 名前:デフォルトの名無しさん mailto:sage [2009/06/03(水) 22:08:27 ]
- 全部やっといた方がいい
- 651 名前:デフォルトの名無しさん mailto:sage [2009/06/03(水) 23:02:14 ]
- >>646
OS関係の高度な操作とかは、C#では茨の道かも。 特定のCPUに特化したプログラムの作成とかも難しい感じ。
- 652 名前:デフォルトの名無しさん mailto:sage [2009/06/03(水) 23:42:57 ]
- そういう、プリミティブなことをするか、組み込みなどで選択肢が少ないこと、よほどの高速性(これもものによっては関数型のほうが速い場合もあるが)でなければ生産性などなど考えたらC++というのは選択肢にはあがらんなぁ・・・
昔C++で今はC#メインだが、コンパイル速度が激速な点が一番うれしい。
- 653 名前:デフォルトの名無しさん mailto:sage [2009/06/03(水) 23:53:16 ]
- Windows上で動く普通のアプリを作るだけなら
C#だけで充分だね。
- 654 名前:デフォルトの名無しさん mailto:sage [2009/06/04(木) 06:39:10 ]
- C#がここまで評価される言語になると誰が予想しただろう
- 655 名前:デフォルトの名無しさん mailto:sage [2009/06/04(木) 08:06:22 ]
- そりゃ、C# でググって出てくる上位サイトは
たいてい1.0とかそれのCTPの頃からC#の記事書いてるし、 その人らは予想してただろ。
- 656 名前:デフォルトの名無しさん mailto:sage [2009/06/04(木) 08:08:06 ]
- .NET 1.0の頃は見向きもせずC++使ってた。
.NET 2.0とVS2005が出た時に、熱心に布教してたMS見て試しに使ってみたら意外と良くて、そこから徐々に乗り換えた。 >>654 VistaがまだLonghornと呼ばれていた頃 Win32を置き換える!とか言って浮き足立ってたなぁ >Longhorn登場時期と予想されている2006年、PCは4〜6GHz/2コアのCPUを搭載し、メモリ2Gバイト超、HDD1Tバイト超 2003年の記事眺めてて噴いたw 今だからこそ言える。ねーよwww
- 657 名前:デフォルトの名無しさん mailto:sage [2009/06/04(木) 11:41:06 ]
- >>652
>昔C++で今はC#メインだが、コンパイル速度が激速な点が一番うれしい。 C#が速いというよりもC++が致命的に遅いというのが実態な気がする。 いずれにしても、ある程度の規模を超えたらC++のコンパイル時間・リンク時間は実用的でないです 特にリンクが遅いのが余りに致命的
- 658 名前:デフォルトの名無しさん mailto:sage [2009/06/04(木) 11:47:56 ]
- >>656
Core2辺りで一応達成といえるんじゃないかな、Pen4と同クロック比較で2倍程度(当時のCPUの想定はPen4クラスだと思われる) メモリは一応2Gにはなった、HDD1Tバイト超だけが実現されていないかと しかし、必要ない人には今の時点でもHDDは余っているだろうね
- 659 名前:デフォルトの名無しさん mailto:sage [2009/06/04(木) 14:18:04 ]
- >>657
ヘッダ書き換えた時のコストがあまりにもひどいと思うよ。
- 660 名前:デフォルトの名無しさん mailto:sage [2009/06/04(木) 14:20:34 ]
- >>659
それに関しては、分散コンパイルを使えば……、あんまり解決してないけど一応解決する けれどもリンクはもう完全にお手上げ
- 661 名前:デフォルトの名無しさん mailto:sage [2009/06/04(木) 14:27:54 ]
- 今や、マネージコードで書かれたFPSなんかが出てきても、驚くほどのことじゃないな。
- 662 名前:デフォルトの名無しさん mailto:sage [2009/06/04(木) 15:06:12 ]
- FPSって何?
- 663 名前:デフォルトの名無しさん mailto:sage [2009/06/04(木) 15:08:35 ]
- ファーストパーソンシューティング
ゲームの一ジャンル。欧米で今一番はやってる形態
- 664 名前:デフォルトの名無しさん mailto:sage [2009/06/04(木) 15:12:38 ]
- ファーストパーソンズシュータアァー!
- 665 名前:デフォルトの名無しさん mailto:sage [2009/06/04(木) 17:06:53 ]
- 空気よまずに、、、
フレーム・パー・セコンド
- 666 名前:デフォルトの名無しさん mailto:sage [2009/06/04(木) 17:52:15 ]
- そういや、Silverlight3で書かれたFPSのデモがあったな
普通に3Dの画面がサクサク動いてて驚いた
- 667 名前:デフォルトの名無しさん mailto:sage [2009/06/04(木) 18:33:59 ]
- >>666
これ? www.innoveware.com/quakelight.html
- 668 名前:デフォルトの名無しさん mailto:sage [2009/06/04(木) 18:55:11 ]
- >>659
そういうコストを減らすために ヘッダの依存を分散させる設計が必要 そのコストが高いってことは設計が悪いってことだ ヘッダのあるプログラミング言語的には
- 669 名前:デフォルトの名無しさん mailto:sage [2009/06/04(木) 19:14:07 ]
- template…
- 670 名前:デフォルトの名無しさん mailto:sage [2009/06/04(木) 21:22:45 ]
- >>668
それが最近の統計情報によると、ヘッダの重複コンパイルがコンパイル時間の8割がたを占めていて ぶっちゃけヘッダ別けファイル別けするよりも、全ヘッダ・ソースを一つに結合してコンパイルしたほうがマシって状況にあるらしい。 さらに、リンクファイルに無闇に外部参照ラベルが出現している上、それがCからの名残でツリー構造ではなく名前空間にヘッダやらフッタやら特殊規則の名前やらが無節操にぶちまけられてまともに検索もできない有様。 古すぎるんだ、技術的に…… 昔はこれでよかったんだよ、むしろこうする事により高速なコンパイルが期待できたんだ、だけどこの方法は数が増えるとコンパイル時間が爆発的に増えるんだ。 ちょっともうスレとは関係なさすぎますね、自粛します。
- 671 名前:デフォルトの名無しさん mailto:sage [2009/06/04(木) 21:55:00 ]
- 倍々ゲームでコンパイル時間が増えていたが、それでもコンピュータのパフォーマンスも倍々ゲームで増えていたので
しばらくは問題にならなかったんだな、しかしDiskIOその他は倍々ゲームパフォーマンスアップはしなかったので次第に問題が表面化してきたと。
- 672 名前:デフォルトの名無しさん mailto:sage [2009/06/04(木) 23:53:55 ]
- >>670
ヘッダに全部コードを書いて、ソースはそいつをインクルードしてるだけってソフトがあったんだが、 それが理由なのか。
- 673 名前:デフォルトの名無しさん mailto:sage [2009/06/05(金) 00:56:58 ]
- それはアレやないすかね、テンプレートの扱いがややこしいので
割り切って全部ヘッダにしただけやないですかね。 C++ は重複の多さもあるけど、コンパイル時に色々やりすぎって 話もあるんではなかろうか。
- 674 名前:デフォルトの名無しさん mailto:sage [2009/06/05(金) 01:45:06 ]
- ひとまとめにしたほうがコンパイラも最適化を聞かせやすい品。
SQLiteがやってる。
- 675 名前:デフォルトの名無しさん mailto:sage [2009/06/05(金) 02:10:54 ]
- .NetFrameworkのJITってSIMDを使わないんですか?
使う事があるのはmonoだけですか?
- 676 名前:デフォルトの名無しさん mailto:sage [2009/06/05(金) 02:48:54 ]
- せいぜいmovqくらいじゃね
- 677 名前:デフォルトの名無しさん mailto:sage [2009/06/05(金) 02:58:36 ]
- >>673
C++のコンパイル速度の遅さは文法の複雑さが主な原因。
- 678 名前:デフォルトの名無しさん mailto:sage [2009/06/05(金) 03:10:57 ]
- >>674
VC++はリンク時の最適化というのがあって、 それ使えば全部ひとまとめにしたのと同じような効果が得られる。 まあこれ使うとさらにリンク時間が長くなるんだが。
- 679 名前:デフォルトの名無しさん mailto:sage [2009/06/05(金) 03:47:29 ]
- >>675
SIMDが使える環境では使うようにJITコンパイルされる。 Mono.SIMDはSIMDによる"手動の最適化"を"マネージコードだけ"で行えるのが武器。 .NETでやるには部分的にC++/CLIを用いてネイティブで実装する必要がある。
- 680 名前:デフォルトの名無しさん mailto:sage [2009/06/05(金) 03:53:06 ]
- むしろC#のコンパイル速度が速すぎる。
入力中にバックグラウンドでコンパイルしてるんじゃないかと疑ってしまったぞ。
- 681 名前:デフォルトの名無しさん mailto:sage [2009/06/05(金) 07:14:37 ]
- >>680
VBにしてもJavaにしてもこんなもんじゃね? デルファイとかさらに早いし >>677 無意味なコンパイルだと思われる、一度コンパイルし結果が得られるはずであっても、直前のヘッダファイルが変更されると 全部コンパイルし直さない限り、そのままでいいか確定しないからな。 コンパイルの流れがちゃんとすれば、C++よりはるかに複雑な構造は取り扱えるし、C#だって今となってはC++と比較して遜色ないくらい複雑な内容をもっているし。
- 682 名前:デフォルトの名無しさん mailto:sage [2009/06/05(金) 07:21:48 ]
- >全部コンパイルし直さない限り、そのままでいいか確定しないからな
この原因を作り出しているのがプリプロセッサで、C系のプリプロセッサの仕組みは今となっては非常にマズイという事になっている。 それとincludeされるファイルがincludeし始めると、対象が指数関数的に増えるのも問題。 C#の場合はどんなに複雑でも、各ファイルが独立しているので、コンパイル時間は線形的にしか増えない。今の言語はほとんどこのスタイル。
- 683 名前:デフォルトの名無しさん [2009/06/05(金) 09:43:48 ]
- 構文解析やコード生成自体はそんなに大したコストじゃないよ
- 684 名前:デフォルトの名無しさん mailto:sage [2009/06/05(金) 11:11:08 ]
- >>683
十分デカイって、特に何か処理のする事がない、ただラベルの付け合わせだけのリンクでさえボロボロのC++においては
- 685 名前:デフォルトの名無しさん mailto:sage [2009/06/05(金) 11:25:48 ]
- C言語とオブジェクトファイルをリンクするldの方式は1960年代の技術だからな、C++も基本的にはこの考え方を踏襲しているわけで
かれこれ40年越し、そろそろ半世紀前から使われてきた技術だ、さすがに熟成通り越して酢になってますよ。 今でも実用的に使われているというのはそれだけでも凄い事なんですけどね。
|

|