C#, C♯, C＃相談室 Part52

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 03/27 07:18 / Filesize : 229 KB / Number-of Response : 925
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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くらい
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挙げるってのはないだろｗ

でも、.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 ]: ｃしらないと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年の記事眺めてて噴いたｗ　今だからこそ言える。ねーよｗｗｗ
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年越し、そろそろ半世紀前から使われてきた技術だ、さすがに熟成通り越して酢になってますよ。
今でも実用的に使われているというのはそれだけでも凄い事なんですけどね。
686 名前：デフォルトの名無しさん mailto:sage [2009/06/05(金) 12:04:10 ]: >>680
実際にバックグラウンドコンパイルを研究する価値はあるんじゃないか？ｗ
というか、きっと誰かしてる。
687 名前：デフォルトの名無しさん mailto:sage [2009/06/05(金) 13:55:37 ]: たしかにコーディング中の入力待ちアイドルタイムって長いもんな
688 名前：デフォルトの名無しさん mailto:sage [2009/06/05(金) 15:35:15 ]: これからのC++ではC#やVBがIntelliSenseを使うための情報収集をする時間でコンパイルか……
追い詰まっていると思われ
689 名前：デフォルトの名無しさん mailto:sage [2009/06/05(金) 19:08:53 ]: >>686
ていうか書いた奴が
インテリセンスで即反映、コードチェックも即掛かる
なんだからバックグラウンドってーか入力がある度にやってるんじゃないか
690 名前：デフォルトの名無しさん mailto:sage [2009/06/05(金) 20:20:30 ]: C++も使うが、Visual Studio 2010はびっくりするほどIntelliSenseが効くようになったのが凄い。
ブログでも今までのを捨てて新しくしたと言っていたし。
まあそれでもC#には敵わないが。
691 名前：デフォルトの名無しさん mailto:sage [2009/06/05(金) 21:33:22 ]: 個人的にはできる限り早い段階でC++よりC#へ移行させてほしいと願うばかり
さすがにもうC++ではやりきれない
692 名前：デフォルトの名無しさん mailto:sage [2009/06/07(日) 09:41:03 ]: C#で十分にできることを、C++でやってるんだとしたら、
それは悲しいことだな
693 名前：デフォルトの名無しさん mailto:sage [2009/06/07(日) 10:08:20 ]: 激しく計算するような分野じゃC#は使えないよ
694 名前：デフォルトの名無しさん mailto:sage [2009/06/07(日) 10:44:08 ]: GUIと通信部分をC#で書いて、計算はworkstationでやってるけど？
695 名前：デフォルトの名無しさん mailto:sage [2009/06/07(日) 10:47:45 ]: いいんじゃない
696 名前：デフォルトの名無しさん mailto:sage [2009/06/07(日) 11:18:04 ]: だから向き不向きあるゆーとろーが
向いてるところに生産性の悪いC++使うことないともゆーとろーが
697 名前：デフォルトの名無しさん mailto:sage [2009/06/07(日) 13:28:22 ]: 激しく計算するような分野だが、C#に変えちまったけどな
C++でスレッド管理めんどくさすぎ、やってられない
結局やりきれずにシングルスレッドで書いてC#より遅くて使い物にならん事多々あり
698 名前：デフォルトの名無しさん [2009/06/07(日) 13:29:49 ]: いまならC++を使う状況はメモリを直接参照して変更するような処理かな？
いまならC++/CLIつかってその部分だけ書くのが便利かもと思ってる。

C#でちょっとした画像処理をポインタを使用して書いた時は、
unsafeがいちいちめんどくさくてストレスがたまったよ。
699 名前：デフォルトの名無しさん mailto:sage [2009/06/07(日) 13:34:34 ]: C#のunsafeでだるいならC++でもだるいだろう。
ちょっとコード書き足すだけだし
700 名前：デフォルトの名無しさん mailto:sage [2009/06/07(日) 13:35:43 ]: C++スレで存分に語れよ
701 名前：デフォルトの名無しさん mailto:sage [2009/06/07(日) 13:36:11 ]: C++のほうもOpenMPはだいぶ楽だと思う。
C#にもあれくらい簡単に使えるのが欲しい。
というわけで、.NET 4.0の並列化関係のライブラリに期待している。
702 名前：デフォルトの名無しさん mailto:sage [2009/06/07(日) 13:37:34 ]: OpenMPは総合力に掛ける、使いどころが限定的すぎる。

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

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