ふらっとVisual C#,C♯,C#(初心者用) Part106at TECH
ふらっとVisual C#,C♯,C#(初心者用) Part106 - 暇つぶし2ch1:デフォルトの名無しさん
13/09/07 09:42:46.74
「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。

他のスレッドでは書き込めないような低レベルな質問。
質問者自身なんだか意味がよく分からない質問。
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。

内容に応じて、他スレ・他板へ行くことを勧められることがあります、ご了承下さい。

なお、テンプレが読めない回答者は邪魔なので後述のC#相談室に移動して下さい。

>>980を踏んだ人は新スレを建てて下さい。
>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。

■前スレ
ふらっとVisual C#,C♯,C#(初心者用) Part105
スレリンク(tech板)

■関連スレ
C#, C♯, C#相談室 Part80
スレリンク(tech板)

■コード貼るなら↓使ってください
URLリンク(ideone.com)

2:デフォルトの名無しさん
13/09/07 10:07:38.54
XNAが終了ということを知ったんですが
いまだとirrlichtが最強なのかなと思いました
このスレの先輩にもご意見をお伺いしたいのですがこのライブラリはどうでしょうか?

3:デフォルトの名無しさん
13/09/07 11:21:57.65
>>2
ゲームなら今やUnity一強
.NETじゃないけど言語はC#だよ

4:デフォルトの名無しさん
13/09/07 12:02:29.98
Unityっすか
実はUnity使ってみたかったんですが
ぼくのPCだと重すぎて
メモリ1GB オンボード Celeron1コア なんですが先輩方はどのくらいのスペックでUnityを快適に開発しているのでしょうか?

5:デフォルトの名無しさん
13/09/07 12:05:12.73
Unityが重いならVSの最新版もまともに動かんよ

6:デフォルトの名無しさん
13/09/07 12:15:11.02
>>4
さすがに買い換えろよ
それだとVS2003で精一杯なレベルだ
UnityもVS2012も今のでっかいソフトにしては決して重くない
最新のPCなら安いノートで十分快適に動くよ

7:デフォルトの名無しさん
13/09/07 12:57:43.50
3~4万も出せばPCを買える時代の終わりは近い

8:デフォルトの名無しさん
13/09/07 13:04:12.64
これからは1万円台か

9:デフォルトの名無しさん
13/09/07 14:58:48.38
TypeLoadException が出たのですが、どうやって直したらいいでしょうか?

アセンブリは、ちゃんとexeと同じ場所にあるので、アセンブリ(*.dll)は読み込めてると思います。
でも、たぶん型が読み込めてない(??)みたいなのですが……

教えてください





System.TypeLoadException はユーザー コードによってハンドルされませんでした。
HResult=-2146233054
Message=アセンブリ 'HogeHoge, Version=1.0.0.0, Culture=neutral, PublicKeyToken=ab81addb3b46712a' から型 'HogeHoge.ClassA' を読み込めませんでした。
Source=MameMame.ClassB
TypeName=HogeHoge.ClassA

10:デフォルトの名無しさん
13/09/07 15:12:40.58
try{>>9}
catch(Exception e){
int n= 0;   //ここにブレークポイント設定して e の中身見ろ。解決方法が載ってる
}

11:デフォルトの名無しさん
13/09/07 15:12:55.55
メッセージ通りとしか言いようがない

12:デフォルトの名無しさん
13/09/07 15:18:56.23
こういうのは全ソースとバイナリ貼ってくれないと解決しないパターン

13:デフォルトの名無しさん
13/09/07 15:21:48.13
必要も無いのにGACに登録してて、
コンパイルのとき指定したアセンブリと
GACのアセンブリで同期が取れてないとか

14:デフォルトの名無しさん
13/09/07 15:37:58.53
こうして欲しい

DLLプロジェクトを名前変えて作り直す
厳密名その他Hogehogeの設定に近づけつつ動かす
動かなくなる設定を突き止めたら調べて正しい設定にする
ダメならダメな理由を添えてここで質問

15:デフォルトの名無しさん
13/09/07 15:48:46.42
全エレメントを列挙してscrollTopを取得したのに
0より大きい値がひとつも取れないってどうゆうこと?

16:デフォルトの名無しさん
13/09/07 16:05:19.41
俺んとこじゃBody.ScrollTopでちゃんととれてるから
ただの環境依存じゃない?

17:デフォルトの名無しさん
13/09/07 16:24:09.40
とれたよ。マジでありがとう。

18:デフォルトの名無しさん
13/09/07 17:04:21.13
現在マルチスレッド処理を行うプログラムを書こうとしています。
Form1とForm2が存在し、初めはForm1のみが表示されています。
Form1のボタンを押すとForm2が表示され、Form2では重い処理を行っています。
この際Form1ではそのまま処理を続行したいのでForm2のclassを作ることから表示するまでをThreadクラスを使って別で処理させて、そのままForm2の描画および処理を行っています。
ですがボタンのイベント内で行っているので、イベントを抜けた途端にForm2も消滅してしまいます。これを解決する方法はないのでしょうか?

19:デフォルトの名無しさん
13/09/07 17:10:36.69
Form2の表示はApplication.Runを使う必要があると思う

20:デフォルトの名無しさん
13/09/07 17:12:39.76
スレッドはSTAね

21:デフォルトの名無しさん
13/09/07 17:34:26.16
重い「処理」だけスレッドに追い出せばForm2自体はスレッド分ける必要ないだろ

22:デフォルトの名無しさん
13/09/07 17:37:57.41
別にフォームごとサブスレッドにしてもいいと思う

23:デフォルトの名無しさん
13/09/07 17:42:31.43
どう実装してるのか解らないけど、Form1のフィールドとしてForm2とスレッドの
変数を用意し、ボタンイベント内でそれぞれをインスタンス化すればいいんじゃ
ないの?
ボタンイベント内で変数を定義していないか?

24:デフォルトの名無しさん
13/09/07 17:45:01.53
何言ってるのかさっぱり意味不明な質問によく回答できるよね。
ア○な質問者よりそっちに関心するわ

25:デフォルトの名無しさん
13/09/07 17:46:08.07
>>21
そうだね
前にグレープシティのコントロールがマルチスレッドだと落ちるって情報を見かけたし、
UIは安易にマルチスレッドに頼らない方が良い

26:デフォルトの名無しさん
13/09/07 17:48:49.15
でもフォームごと別のスレッドにしないと元スレッドのUIの処理の
影響受けちゃうからなぁ。あれは嫌だなぁ。

27:デフォルトの名無しさん
13/09/07 17:52:23.40
>>24
暇なんだw
確かにForm2が全然イメージ出来ない
重い処理をForm2に押し付けたらすぐ応答なしになっちゃうし、何がしたいんだろうねw

28:デフォルトの名無しさん
13/09/07 18:00:17.37
>>26
影響受けちゃうと言うか受けないように作るべきだけど面倒だよね

29:デフォルトの名無しさん
13/09/07 18:01:58.30
C#で作ったアプリケーションを起動してみたら
アプリケーションを正しく起動できませんでした(0xc000007b)
ってエラーがでたんだけど解決方法わかります?

30:デフォルトの名無しさん
13/09/07 18:07:57.16
64bit環境で32bitアプリを起動したとか?

31:デフォルトの名無しさん
13/09/07 18:13:40.33
ワオキツネザルを無効にしてるんじゃなければ(そもそも無効にできるかどうか知らんけど)
それで問題が起こるとは思えませんが。

32:デフォルトの名無しさん
13/09/07 18:19:52.68
自分でも何を質問してるのかわからない状態に陥っていますが…
再度整理すると、
現状ではボタンのクリックイベント内に別のFormクラスを宣言させて、Show()メソッドでForm2を表示しています。
Form2で行いたいことは、Form2内のボタンを押すとファイルを読み取りファイルを編集し、終わった後にForm2を自動的に閉じる、というものです。
ですがファイルサイズが大きいので動作が重くなってしまい、呼び出したForm1が止まってしまいます。

Application.Run()を使ったら
単一スレッド上で 2 回目のメッセージ ループを開始することは有効な操作ではありません。Form.ShowDialog を使用してください。
というエラーが表示されてしまいました。

33:デフォルトの名無しさん
13/09/07 18:20:15.32
うんそうだね

34:デフォルトの名無しさん
13/09/07 18:22:53.91
>>32
>>33>>31
Application.Runはバックグラウンド実行させるメソッドの中だよ

35:デフォルトの名無しさん
13/09/07 18:29:43.10
>>32
>Form2内のボタンを押すとファイルを読み取り
この「ファイルを読み取る」のが遅いんだから、その部分だけを別スレッドにすればいい

36:デフォルトの名無しさん
13/09/07 18:33:45.51
>>32
>>35の言うとおり、そうしないとForm2がフリーズする事になる。

37:デフォルトの名無しさん
13/09/07 18:35:48.31
非同期も選択肢がだんだん増えて便利になった分、ゼロから覚える人は大変だよな。
まあデキる人ならどの道3日ぐらいでものにしちゃうのかもしれんが。

38:デフォルトの名無しさん
13/09/07 18:41:32.66
ファイル読み取りを別スレッドにわけて、その処理の最後にfinishフラグのboolをtureにし、Timerで1秒間隔で読ませて、条件を満たしていたらFormを閉じるという無理やりな処理ですが、一応目標は達成できました…
もっといい処理はないものでしょうか…?

39:デフォルトの名無しさん
13/09/07 18:45:58.76
invokeする

40:デフォルトの名無しさん
13/09/07 18:50:58.93
>>38
これ最適化で無限ループ化するやつだよね

41:デフォルトの名無しさん
13/09/07 19:14:26.20
>>38
スレッドにフォーム渡しておいて、読み込み終わったらform.Close()
↑こういうやり方すると誰かが文句いうが気にしない

42:デフォルトの名無しさん
13/09/07 19:27:14.79
処理が終わったら閉じるとか、form2って単に処理中とか
プログレスバーを表示するだけのものなのか?
だったらそれ自体不要なんじゃないのかな

43:デフォルトの名無しさん
13/09/07 19:48:35.69
その重い処理から定期的にメッセージループを回せよ。
どうせプログレスバーも更新する必要もあるんだし。

44:デフォルトの名無しさん
13/09/07 19:50:42.87
>>41
invokeでだよね

>>42
ボタンを押したらって書いてあるからファイル選択するんじゃないか?

45:デフォルトの名無しさん
13/09/07 20:19:23.96
NET4.5以降ならAsync/Awaitの出番
TaskやBackgroundWorkerでもよい

46:デフォルトの名無しさん
13/09/07 20:21:08.49
ファイル読み込みなんだからボトルネックはHDD。
いちいちスレッド使うなよw 同期とかで余計に複雑になるわw

47:デフォルトの名無しさん
13/09/07 20:24:22.80
Form2にはファイル選択とどの動作を行うかの選択のボタンやチェックボックスがついているため、Form2は必要になっています。
Invokeの使い方をまだよくわかっていなかったため使用を見送っていました。
メッセージループということは、Application.DoEvents()で良かったでしょうか。
Frameworkは4を想定していたので、それは使えませんね…

48:デフォルトの名無しさん
13/09/07 20:27:23.21
>>46
じゃどうすんだよ?w

49:デフォルトの名無しさん
13/09/07 20:32:33.19
>>48
ファイル読込ループにDoEvents()でも入れとけ。

50:デフォルトの名無しさん
13/09/07 20:33:24.62
Windows7って標準で.Net4.0がインストールされていますか?

51:デフォルトの名無しさん
13/09/07 20:35:45.44
>>47
invokeならこう
this.Invoke((MethodInvoker)delegate
{
this.Close();
});

DoEventsだとForm1の反応も悪くなる

52:デフォルトの名無しさん
13/09/07 20:40:37.43
>>49
ファイル読み込みなんだからボトルネックはHDD。
だからスレッドなんて使わずDoEventsにしろ。

全く意味が分かりませんねぇ┐(´~`)┌ ヤレヤレ

53:デフォルトの名無しさん
13/09/07 20:45:59.60
>>52
コード書かない奴には理解できないよ。

54:デフォルトの名無しさん
13/09/07 20:53:57.93
コード書いてるけど分からんわ

55:デフォルトの名無しさん
13/09/07 20:55:57.20
ややこしそうだからスルーで

56:デフォルトの名無しさん
13/09/07 20:56:57.88
同期考えないでスレッド生成しまくってるタイプか。
不定期にデッドロックしてもマイクロソフトだからですとか言いそう。

そういうプログラマを何人も見てきた。

57:デフォルトの名無しさん
13/09/07 20:59:43.16
DoEventを素人にすすめる低能は死んでくれる?

58:デフォルトの名無しさん
13/09/07 21:01:07.44
素人にマルチスレッド薦めるなw >>52 みたいなアホが大量生産されるw

59:デフォルトの名無しさん
13/09/07 21:08:14.51
doeventsよりスレッドのほうがわかりやすいけど

60:デフォルトの名無しさん
13/09/07 21:10:44.86
同期考えないからだろwww
過去にハイパースレッドとか出始めたときどんだけフリーズするアプリがあったんだよw

61:デフォルトの名無しさん
13/09/07 21:11:39.37
どんだけあったの?w

62:デフォルトの名無しさん
13/09/07 21:16:14.72
さすがに初心者にマルチスレッドはないな。
単独スレ立つぐらいなのに。CPUの知識は必須。

マルチスレッドプログラミング相談室 その9
スレリンク(tech板)

63:デフォルトの名無しさん
13/09/07 21:19:14.81
CPUの知識てw

64:デフォルトの名無しさん
13/09/07 21:19:16.44
>>50
されてません
URLリンク(www.atmarkit.co.jp)

65:デフォルトの名無しさん
13/09/07 21:19:34.58
CPUの知識ワロタ。どうせおまえもCPUの知識なんてカスほどしかねーだろ

66:デフォルトの名無しさん
13/09/07 21:22:16.45
原理から理解する必要があるって言ってた奴とかぶるものがあるなw

67:デフォルトの名無しさん
13/09/07 21:25:45.64
原理主義者だな
テログラマーか?

68:デフォルトの名無しさん
13/09/07 21:26:09.72
いくつ抽象化レイヤーをぶち抜いたらCPUの話になるんだよ

69:デフォルトの名無しさん
13/09/07 21:27:07.83
>>63
落ち着け。初心者だと言ってるようなものだぞ。
さて、この勘違いした初心者をスルーすべきか相手にすべきかだな。


おれはパス。

70:デフォルトの名無しさん
13/09/07 21:35:59.33
>>68
ほう。なぜこれが同期できてないかCPUレベルの話なしで初心者に説明してくれ。
これは典型的な初心者が書く馬鹿コードだから。既に稼動してるシステムで何度も見てきた。

Form1とかで
bool lock = false
int data = 0;

別スレッドで
if(!lock){
lock = true;
data処理
lock = false;
}

71:デフォルトの名無しさん
13/09/07 21:36:16.73
確かにスレッド案はまだ停止用フラグの実装とかやる事あるけど、
今回は独立性高いし勉強用としては良いと思う。

72:デフォルトの名無しさん
13/09/07 21:40:44.40
>>70
そもそも待機するコードになってないから

73:デフォルトの名無しさん
13/09/07 21:41:26.13
釣りでなければ、どこにCPUレベルの話があるのかわからんが
もしかして、スレッドの話=CPUの話だとでも思ってるのか

74:デフォルトの名無しさん
13/09/07 21:44:41.35
>>72
正しいコードプリーズ。

75:デフォルトの名無しさん
13/09/07 21:46:23.41
volatileが必要とでも言いたいの?
そもそも説明を要求された理由が分からない

76:デフォルトの名無しさん
13/09/07 21:49:17.98
このスレのあまりのレベルの低さに同情する。 >>70

77:デフォルトの名無しさん
13/09/07 21:50:50.87
CPUの知識がどのレベルなのか分からないけど
レジスター、スタック、ヒープの構造と
各スレッドのコンテキストに割り当てられるリソースの
関係については知ってる必要があるし、それはCPUの
知識と言えるかもしれない

78:デフォルトの名無しさん
13/09/07 21:51:46.24
ロックしたいなら>>70なソースは書くわけないし。どう見ても>>70=>>76だし。自演までレベル低くて同情するよ

79:デフォルトの名無しさん
13/09/07 21:52:06.95
ロックってmonitor使うんじゃないの?騙された?

80:デフォルトの名無しさん
13/09/07 21:52:25.85
>>78
正しいコードプリーズ。

81:デフォルトの名無しさん
13/09/07 21:53:11.43
アセンブラのプログラマーの方ですか?
ここはC#スレですよ

82:デフォルトの名無しさん
13/09/07 21:55:25.45
初心者ならそれこそBackgroundWorkerだろ
同期やロックはBackgroundWorkerイベントで
隠蔽されて安全に使える。

83:デフォルトの名無しさん
13/09/07 21:56:42.28
精々lockやReaderWriterLockSlimで終わる話
なぜにCPUまで持ち出さないといけないのか

84:デフォルトの名無しさん
13/09/07 21:58:27.67
初心者にはマルチスレッドは無理。

知ったかに説明しても逆ギレするだけ。

85:デフォルトの名無しさん
13/09/07 22:01:57.62
>>80
ほらよ
URLリンク(codezine.jp) の待機ハンドル

if(!lock)なんてやっても一瞬で素通り。while(1)かましたらずっと判定処理になるだろ
そんな糞コード書くなよ

86:デフォルトの名無しさん
13/09/07 22:04:47.30
>>85
while(1)にしても同期できないよ、素人。

87:デフォルトの名無しさん
13/09/07 22:07:32.39
while(true){
if(!lock){
lock = true;
data処理
lock = false;
}
}

これなら同期できると思ってる馬鹿がいる件について

88:デフォルトの名無しさん
13/09/07 22:09:01.24
>>86
だからそんなの使わないって書いてるだろ。日本語ぐらい読めるようになれ

89:デフォルトの名無しさん
13/09/07 22:09:51.13
>>70は会社員なのかなんなのかしらんが
既に稼動してるシステムでこのレベルのコードでマルチスレッド扱うプログラマがいるの?
ちょっといくらなんでも信じられん

90:デフォルトの名無しさん
13/09/07 22:12:23.64
>>89
このスレで誰も答えを言えないのが答えさ。

91:デフォルトの名無しさん
13/09/07 22:19:01.08
>>79,81,82,85に答えがあるのにそれを全部無視する>>70

92:デフォルトの名無しさん
13/09/07 22:19:19.66
>>85は知ってるが>>70のコード断片から導くのは困難だわ
CPUのキャッシュとメモリの同期の話とかかと思いきや何だよ考えて損したw

93:デフォルトの名無しさん
13/09/07 22:20:29.15
>>91
その中で一つでも同期できない理由を説明したものがあるのか。

ないじゃんwww

94:デフォルトの名無しさん
13/09/07 22:23:16.30
素直にマルチスレッドなんにも分からないから教えてください、って言えよ

95:デフォルトの名無しさん
13/09/07 22:23:18.54
>>93
>>72

96:デフォルトの名無しさん
13/09/07 22:24:51.14
>>95
while(true){
if(!lock){
lock = true;
data処理
lock = false;
break;
}
}

これで同期できる?

97:デフォルトの名無しさん
13/09/07 22:25:32.79
はい解散~
解散解散~

98:デフォルトの名無しさん
13/09/07 22:26:16.59
>>96
それで同期出来るなんて誰も言ってないしw
もう引き下がってくれよw
めんどくせーよー

99:デフォルトの名無しさん
13/09/07 22:27:25.68
>>96
できない>>85にあるだろ。こんなイメージ
while(true)
{
  manualEvent.WaitOne();
 //処理
}

100:デフォルトの名無しさん
13/09/07 22:27:30.81
>>96
もちろんできない。
それ以前にその同期って言葉の使い方はちょとおかしい気が

101:デフォルトの名無しさん
13/09/07 22:28:55.09
>>96
無理。動いたり動かなかったりデバッグ困難な糞コード。

102:デフォルトの名無しさん
13/09/07 22:30:23.84
>>96 じゃ同期できない理由を説明しろ、糞ども。

103:デフォルトの名無しさん
13/09/07 22:33:37.85
してもいいけどそれがどうCPUと関係するのかも説明してくれよ

104:デフォルトの名無しさん
13/09/07 22:34:36.01
頼む。説明してくれ。論理的な間違いが見つけられないw

105:デフォルトの名無しさん
13/09/07 22:37:30.81
>>104
ガチで言ってるの?
仮にlockが不揮発だとしても、「data処理」実行中の値は?

106:デフォルトの名無しさん
13/09/07 22:39:14.39
>>105
処理中にlockが変更されても問題ない(処理なら問題ない)

107:デフォルトの名無しさん
13/09/07 22:39:22.97
いやif(!lock){とlock = true;がアトミックじゃねえって話だろ

108:デフォルトの名無しさん
13/09/07 22:40:43.42
こう言った方がいいか。
シングルコアを前提としても、3行目が実行される直前に別のスレッドに
実行権が移ったらどうなる?

109:デフォルトの名無しさん
13/09/07 22:40:44.60
>>102
詳しそうだからスルーしといたんだけど、
lockが予約語だって知らないでしょw

110:デフォルトの名無しさん
13/09/07 22:41:14.81
if(!lock)

lock = true
の間に、他のスレッドがlockの値を書き換える可能性がある
こんなチェックはなんのあてにもならない

111:デフォルトの名無しさん
13/09/07 22:43:25.96
でCPUの知識はいつ生きるの?

112:デフォルトの名無しさん
13/09/07 22:45:08.84
>>110
breakで飛ばす処理だから値書き換えられても問題ない

113:デフォルトの名無しさん
13/09/07 22:45:28.43
すくなくともC#でのプログラムに、概念的な知識以上のCPUの知識なんていらん

114:デフォルトの名無しさん
13/09/07 22:45:40.20
C#の1行とマシン語の1行が違うってこと?

115:デフォルトの名無しさん
13/09/07 22:50:23.25
機械語1命令と実際のCPUの動作も違うな
OoO μOPとかややこしいのがあれこれ

C#でスレッドやるなら出来る限り高いレベルの同期命令を使うのが吉

116:デフォルトの名無しさん
13/09/07 22:50:45.02
>>113
どんなコードを書こうとOSが提供する同期オブジェクトを使わないかぎり
同期できない理由を説明するにはCPUの話をするしかないんだけどね。
スレッド切り替えの粒度は機械語レベルだから。

117:デフォルトの名無しさん
13/09/07 22:53:22.06
CLRのスレッドをOSが管理しているわけがないだろ
midoriでも使ってんのか

118:デフォルトの名無しさん
13/09/07 22:54:25.98
結局はmonitor使っておけばいいんだよね?

119:デフォルトの名無しさん
13/09/07 22:55:05.60
だからマルチスレッドは初心者には無理だと言ったんだ。

120:デフォルトの名無しさん
13/09/07 22:55:36.45
C#に(というか.NETに)スレッド同期のための仕組みが用意されているんだが?
スレッドについても、実際のコンテキストがどうであろうが、それは.NETによって隠蔽されているわけで
OSよりさらに上位のレベルで抽象化されているわけだが

121:デフォルトの名無しさん
13/09/07 22:56:41.80
よし。これからはファイル読み込みにmonitorとかいうの使うぞw
マルチスレッドなんて簡単、簡単w

122:デフォルトの名無しさん
13/09/07 22:57:45.27
>>119
だな。>>70には無理

123:デフォルトの名無しさん
13/09/07 22:58:10.50
>>118
そのレベルだとMonitorも危険
BackgroundWorkerだけでいいよ

124:デフォルトの名無しさん
13/09/07 22:58:54.31
CPUの知識(笑)という言葉で想定されている知識の範囲もよく分からんけど、
どっちにしろそんなもの知らなきゃ非同期のコードが書けないわけでもないし、
知ってたからってより最適化されたコードが書けるってわけでも恐らくないよね。

それともパイプラインとかキャッシュとかHTとかマルチコアとか、CPUアーキテクチャーについて
深いレベルの知識があるのとないのとで何か違ってくることがあるのか?

125:デフォルトの名無しさん
13/09/07 23:01:21.20
>>123
俺は一番軽い同期オブジェクトを使いたい

126:デフォルトの名無しさん
13/09/07 23:01:57.24
マルチスレッドの話題は高度なので専用スレで、どうぞ。

127:デフォルトの名無しさん
13/09/07 23:03:39.37
質問されてから同期オブジェクトの話が出てくるまで50レス近く消費するおまえらってw

初心者スレらしいなw

128:デフォルトの名無しさん
13/09/07 23:03:46.27
C#がどういうCLRになって、それがどういうアセンブラになるかまで理解できて
その上で、動かしてるOSのプログラム管理に関して精通していて
実行しているCPUにたいしてパイプラインやキャッシュについての知識があれば
より最適化されたコードが書ける かもしれないな

129:デフォルトの名無しさん
13/09/07 23:04:16.91
>>125
これで結果が 0, 0 になるケースがあるのを理解できたら使っていいよ
URLリンク(ideone.com)

130:デフォルトの名無しさん
13/09/07 23:06:25.90
NANDやNORのTTLレベルの回路とか、ALUとかマイクロプログラミングとか、CPUのムダ知識は大学で習ったな

131:デフォルトの名無しさん
13/09/07 23:06:48.56
>>129
もう使いまくってるから今頃使ってもいいよとか言われても困ります

132:デフォルトの名無しさん
13/09/07 23:07:01.83
>>70
簡単じゃん。同期オブジェクト使ってないから。

133:デフォルトの名無しさん
13/09/07 23:07:23.27
>>126
いくらでも気づきにくい落とし穴が作れるという意味では高度だけど、
非同期の処理って言ったって大半は単純なもので、そこまで複雑でも高度でも
ないと思うんだけどね。

基本的なアイデアはそう難しいものではないし、WPFみたいに覚えることが膨大に
あるわけでもないし。

134:デフォルトの名無しさん
13/09/07 23:12:05.38
>>133
それはアプリによる。
どんどんForm開く仕様で共通データを処理しまくるとかは頭使う。
ロックするデータの範囲でパフォーマンスが全然変わってくるから。
下手すると簡単にデッドロック。しかも場所がどこだかログ追うだけでも地獄。

135:デフォルトの名無しさん
13/09/07 23:21:58.53
スレッドの使い方は2種類あって、
1.重たい処理をバックグラウンドで処理してユーザーインターフェイスを硬直させない
2.処理をCPUコアに分散して処理効率を上げる
というのがあって、1は普通に使っていいと思うよ
これは構造的にもそんなにややこしくならないし、
ややこしくなるようなら設計がおかしい

136:デフォルトの名無しさん
13/09/07 23:25:59.86
>>133
どう考えても「どんどんForm開く」というViewの仕様が
非同期処理の難易度を上げる(デッドロックを起こさないようコーディングすることを
困難にする)ことに貢献するとは思えないけどw

137:デフォルトの名無しさん
13/09/07 23:27:20.81
>1.重たい処理をバックグラウンドで処理してユーザーインターフェイスを硬直させない

ややこしいだろ。UIが操作できるんだぞ。処理中にあれこれ動かされたらたまらん。
結果、コントロール全部、Enabled(false)

138:デフォルトの名無しさん
13/09/07 23:28:18.26
>>137
再入の問題ならdoeventsでも同じだろ?

139:デフォルトの名無しさん
13/09/07 23:30:11.62
WCF使って、重い処理を別プロセスに追いやるのが最強だろ
最後は別のコンピューターまで使えるし

140:デフォルトの名無しさん
13/09/07 23:30:37.91
もういいから

141:デフォルトの名無しさん
13/09/07 23:31:51.84
>>137
それはビューの状態管理の問題であって非同期処理に限った問題じゃないでしょ

142:デフォルトの名無しさん
13/09/07 23:33:48.07
実例でいうと年金DBはデータがぐちゃぐちゃ。

143:デフォルトの名無しさん
13/09/07 23:42:58.98
>>133
オラクルのバグに関していいたいが、契約に違反するので我慢することにしよう。

144:デフォルトの名無しさん
13/09/08 02:59:40.47
必ずOSの同期を使わないいけないのは
スレッドスイッチングがC#コードやILレベルではなく、機械語レベルだからだな。
ロックは高級言語だけでは実装はできない。アセンブラ言語必須。

145:デフォルトの名無しさん
13/09/08 03:19:21.61
「すべて」は機械語レベルで動いてるから機械語レベルじゃないとできない
だけどその機械語レベルの処理をC#なんかから呼び出すことができるからC#レベルからスイッチできるよ
もうなんか書いてて頭いたくなって来た

146:デフォルトの名無しさん
13/09/08 03:34:12.11
C#は言語レベルでメモリモデルが規定されてる。
x86限定のメモリモデルでコーディングしてしてしまうと
移植性が無くなる。

147:デフォルトの名無しさん
13/09/08 03:48:16.81
C#で実装できないという話と、C#で機能を提供しているとでは意味違う。
C言語でもロックの実装は書けない。

148:デフォルトの名無しさん
13/09/08 03:55:47.44
>>147
違うようで同じだろ

149:デフォルトの名無しさん
13/09/08 03:59:41.03
>>147
おまえは「CでもC#でもそれはそのままじゃ動かない。機械語での実装が必要」って言ってるようなもんなんだよ
何が言いたいのかまったく意味不明

150:デフォルトの名無しさん
13/09/08 04:00:45.16
fenceもcasもILレベルであったような気がするな

C言語のような古い言語の場合はいまさら統一した
メモリモデルを導入するのは難しいけど
新しい言語ははじめからマルチスレッド前提だから、
メモリモデルはしっかり規定されているよ

151:デフォルトの名無しさん
13/09/08 05:48:25.41
>>149
あんた実装の意味を勘違いしてるよ。

152:デフォルトの名無しさん
13/09/08 10:05:07.86
なにこのグダグダ感は

153:デフォルトの名無しさん
13/09/08 12:26:47.88
2chでクダ撒いてるような素人Lv2が何したり顔してんだって言う


最新レス表示
レスジャンプ
類似スレ一覧
スレッドの検索
話題のニュース
おまかせリスト
オプション
しおりを挟む
スレッドに書込
スレッドの一覧
暇つぶし2ch