09/07/13 11:49:28
試したけど3秒くらいだったよ。
イベントハンドラがあったりする？
あと描画関係なら、BeginUpdate - EndUpdateで挟むとか
263:デフォルトの名無しさん
09/07/13 11:59:23
>>262
実地に調べてまでして下さり、大変ありがとうございます！
いろいろすみませんです。
＞BeginUpdate - EndUpdateで挟む
これたった今やってみました。結果として時間の変化はありませんでした。
＞イベントハンドラがあったりする？
わかりました、すぐ調べてみます。どうもです！
264:261
09/07/13 12:15:11
>>262
＞イベントハンドラ
この件、仰るとおりでした。Selectされた時点で、何かのメッセージの
Hookが行われているようでした！これは別のコントロールのものでしたが
対策を考えてみます。ご指導、大変どうもでした！助かりました！
265:デフォルトの名無しさん
09/07/13 19:26:25
インデックスで回してない？
foreachにすれば大丈夫だと思うけど。
266:デフォルトの名無しさん
09/07/13 23:23:23
VirtualModeにしてみたら？
267:デフォルトの名無しさん
09/07/14 09:41:49
良く使うジェネリックコレクションは何？
とりあえずList<T>とDictionary<T>覚えておけばいい？
268:デフォルトの名無しさん
09/07/14 09:42:31
Dictionary<K,V>だった。
269:デフォルトの名無しさん
09/07/14 09:52:07
K,VじゃなくてTKey,TValueな
型パラメータの命名ガイドラインは接頭辞Tプラスその型引数の意味
（ただし用途が明らかな場合List<T>とかはT一字でOK）
2.0ならあとはLinkedList<T>, KeyedCollection<TKey, TItem>辺り？
あ、Queue<T>とStack<T>があった
3.0（WPF）ならObservableCollection<T>
3.5はHashSet<T>とか？ コレクションじゃないけどやはり最重要はIEnumerable<T>だな
270:デフォルトの名無しさん
09/07/14 10:24:18
>>269
ふむふむ。
IEnumerable<T>はLINQで出て来るなあ。
ObservableCollection<T>はWPF本で出てきたけど
まだいいや。
List<T>
LinkedList<T>
KeyedCollection<TKey, TItem>
Dictionary<TKey, TValue>
IEnumerable<T>
とりあえずこのあたりからマスターする。
271:デフォルトの名無しさん
09/07/14 10:29:51
あ、KeyedCollectionは後で良いよ
つか全体にマスターするほどでもないような
IEnumerable<T>以外は
272:デフォルトの名無しさん
09/07/14 13:37:18
T[] も忘れないで上げてください、影薄いですけど
273:デフォルトの名無しさん
09/07/14 21:15:32
>>269
.NETの型引数の命名規則は合理的で優れてるよな
java式のK,Vとかイミフ
274:デフォルトの名無しさん
09/07/14 21:33:54
Tとかそういう意味だったのかw
ほかの引数にSとかUとかつけてたわｗ
275:デフォルトの名無しさん
09/07/14 21:43:12
c++テンプレートのTypenameだよね
276:デフォルトの名無しさん
09/07/14 21:44:53
>>274
SとかUってどういう意味よ？ｗ
277:デフォルトの名無しさん
09/07/14 21:45:31
SとかUつける人いるんだｗ
278:デフォルトの名無しさん
09/07/14 21:46:57
ｱﾙﾃｨﾒｯﾄﾌｧｲﾅﾙｸｿﾜﾛﾁｗ
ま、俺はVをつけてたけど。
279:デフォルトの名無しさん
09/07/14 21:56:52
>276,277
いや、Tの前とか次の文字とかｗ
HogeHoge<S,T,U>ってかんじ。
280:デフォルトの名無しさん
09/07/14 22:08:04
型引数を真面目に変数っぽく名前考えてるのって
C#くらいだよね
javaもc++もそんな習慣無い
281:デフォルトの名無しさん
09/07/14 22:23:47
C++には型引数に普通の名前付ける文化もある(STLなど)
わかりやすいけど普通の型名と見分けがつかないので、
.NETの(プリフィクス)+(意味)はその落としどころ
282:デフォルトの名無しさん
09/07/14 22:30:04
>>281
今VC9見たら真面目に命名してるな
VC6とか_Aとか_Cとかだったんだが
283:デフォルトの名無しさん
09/07/14 23:45:07
>>280
.NET も初めからそうだったわけではなく、型引数のこの命名は
ベータかどっかでやっぱりこうしようみたいに一気に変えたんだよ
確か。Connect とかの Suggestion も絡んでた気がする
出来上がりとか見てみんな思うところがあったんじゃないかな
284:デフォルトの名無しさん
09/07/14 23:52:12
>>283
.NET 2.0ベータ中は一文字だった、ように記憶してる
リリースされた正式版のドキュメント見て初めは違和感あった
285:デフォルトの名無しさん
09/07/14 23:57:32
制約がわかりやすいのはいいよね
TEventArgs : EventArgs なんか神
286:デフォルトの名無しさん
09/07/15 00:09:02
>>284
ああごめん。
>出来上がりとか見て
はベータのです。
なんか変わると発表したときにフィードバックの存在を
書いていた記憶があるから。
287:デフォルトの名無しさん
09/07/15 00:17:22
おまいらC#でオープンソースとか使ってる?
Log4netはつかってるがほかゴリゴリ書いてるので時間かかるお(´・ω・｀)
URLﾘﾝｸ(csharp-source.net)
288:デフォルトの名無しさん
09/07/15 03:22:30
SerialPortクラスについて質問
DataReceivedイベント使えばVC++の時みたいに自分でスレッド組まなくて済みそうで楽出来そうなんだけど
実際に受けてみると欠ける時がある
STXhoge123ETX
↑見たいなデータが改行無しで垂れ流しで延々と来るんだけど
たまに
STXhoge123ETX
STXhoge124ETX
STXhoge125ETX
STXhoge126ETX
STXhoge127ETX
STXhoge128ETX
STXhoge129 ←ETXが受けれて無かったり
STXhoge134ETX←間の130-133までが無かったり・・・
private void serialPort1_DataReceived(object sender, System.IO.Ports.SerialDataReceivedEventArgs e)
{
string recvData = serialPort1.ReadExisting();
Console.WriteLine(recvData);
}
こんな感じで直接出力しても途切れる・・・
何故なんでしょうか？誰か詳しい人教えて
289:デフォルトの名無しさん
09/07/15 03:22:38
すいません。質問ですが、
new RelayCommand(param => this.OnRequestClose());
この=>はどういう意味があるのでしょうか？
290:デフォルトの名無しさん
09/07/15 03:34:36
ラムダ式
URLﾘﾝｸ(ufcpp.net)
291:デフォルトの名無しさん
09/07/15 05:26:44
>>288
フロー制御はうまく言ってる？
292:デフォルトの名無しさん
09/07/15 06:30:27
>>290
おお、ラムダ式。
どうもありがとうございました。
293:デフォルトの名無しさん
09/07/15 14:06:19
ジェネリクスのクラスの型パラメータを配列に制限したい
のですが、以下だと上手く行かないようです。
class Widget<T> where T : IEnumerable
{
public void Iterate(T arr)
{
foreach (object item in arr)
{
Console.WriteLine(item);
}
}
}
・型パラメータTは、競合する制約IEnumerableおよびobjectを継承します
・foreachステートメントは、TがGetEnumeratorのパブリック定義を含んで
いないため、型Tの変数に対して使用できません。
というエラーが出ます。どうかご教示願います。
294:デフォルトの名無しさん
09/07/15 14:13:11
間違ってない
それだけならコンパイル通るし動く
他のところに問題がある
295:デフォルトの名無しさん
09/07/15 14:13:14
ジェネリックでdelegateを指定するにはどうすれば
いいでしょうか？
やりたいことは
public delegate_T func<delegate_T>( string str )
こんな感じなんですが。
296:デフォルトの名無しさん
09/07/15 14:25:37
コンパイル時にチェックするのは無理
Expression<TDelegate>みたいに、名前だけそれっぽくして実行時にチェックする
297:デフォルトの名無しさん
09/07/15 14:31:40
typedefがないので無名になるが
Func<string, int> func;
funcがstringを受け取ってintを返す関数になる
戻り値がdelegateって言うなら
Func<string, Action> func;
とかです
298:デフォルトの名無しさん
09/07/15 14:44:14
>>294
レスありがとうございます。
using System.Collections;
を宣言していませんでした。
299:デフォルトの名無しさん
09/07/15 15:04:49
>>296>>297
上で書いたような書式じゃ無理ということとですね。
Funcとか知らなかったので試してみます
ありがとう
300:デフォルトの名無しさん
09/07/15 16:12:22
C#入門としてオススメな本があれば教えて下さい
301:デフォルトの名無しさん
09/07/15 16:20:19
>>291
レスありがとう
フロー制御に問題がある様には思えません
送信側と合わせてるので
疑似で
STXhoge0ETX～STXhoge5000ETX
までのデータを作ってtxtファイルにして
ハイパーターミナルからテキストファイルの送信で流してみたんですが
5000までデータはあるのにコンソール上には200行から300行くらいまでしか出てこない・・・
フロー制御もいろいろ設定変えて試したんですが変わらずです・・・
302:デフォルトの名無しさん
09/07/15 16:53:02
症状はどう見てもバッファあふれだろう。
＞フロー制御に問題がある様には思えません
経験的にいえば強く思い込んでるところが間違ってる可能性が高いな。
コントロールパネルで設定したとか言うなよ。
あとＰＣ－ＰＣでの接続だったらリバースケーブルになるけど、
結線に種類があってハード制御用のラインが自分のほうに戻ってきてるのもあるから要注意。
303:デフォルトの名無しさん
09/07/15 17:36:23
threshold設定してるだけ？
アレってあんまり信用ならなかったとおもう
304:デフォルトの名無しさん
09/07/15 17:37:26
概算じゃなくてデータのサイズきっちり計算してバッファと比べたりしようぜ
305:デフォルトの名無しさん
09/07/15 19:30:24
すいません。質問です。
C#や.NETの資格で、MS社以外のものはありますか？
また、MCPですが、
70-505 TS: Microsoft .NET Framework 3.5, Windows Forms Application Development
などの「開発経験が 1 年以上」は、大学の研究室での開発や趣味プログラミングでも大丈夫でしょうか？
306:デフォルトの名無しさん
09/07/15 21:48:39
Console.WriteLine(new Uri("URLﾘﾝｸ(example.com)"));
この出力が "URLﾘﾝｸ(example.com)" になるんですが、これってバグですか？
307:デフォルトの名無しさん
09/07/15 21:52:30
いいえ
308:デフォルトの名無しさん
09/07/15 22:03:26
sample/../foobar.txt
/ を足して味噌
309:デフォルトの名無しさん
09/07/15 22:07:41
>>308
いや、それはわかるけど、俺が聞きたいのはそれじゃない。
".." が消えているのはなぜかと、どうすれば回避できるのか、だ (´･ω･`)
310:デフォルトの名無しさん
09/07/15 22:22:46
OriginalStringプロパティ
311:デフォルトの名無しさん
09/07/15 22:27:16
URIの仕様としては>>306の動作は正しいのかい？
312:デフォルトの名無しさん
09/07/15 22:42:31
RFC2396
Similarly, parsers must avoid treating "." and ".." as special when
they are not complete components of a relative path.
これ？
313:デフォルトの名無しさん
09/07/15 22:45:45
sample.. の .. を特別扱いしちゃいけないから
>>306の動作は仕様を満たしてないってことかな
314:デフォルトの名無しさん
09/07/15 22:49:36
>>310
Console.WriteLine(new Uri(new Uri("URLﾘﾝｸ(example.com)"), "sample../foobar.txt").OriginalString);
ごめん。こういうのを書いて、ちょっと (´･ω･`) とした。
RFC か何かで規定されているなら、まあ無視しちゃって良いかなって気にはなるんだけど、
まだ読みきってないス (´･ω･)
315:デフォルトの名無しさん
09/07/15 23:25:59
全然関係ない。
趣味でも十分な奴もいれば仕事でも無理な奴もいる。
316:デフォルトの名無しさん
09/07/15 23:27:39
ふらっとの誤爆か？
317:デフォルトの名無しさん
09/07/16 19:30:14
Path.DirectorySeparatorCharとPath.AltDirectorySeparatorCharを
くっつけたものを出来ればconstで定数にしたいんですが
どう書けばよいでしょうか？
もしくはC++の関数内で
static string str = "123";
みたいなことは出来ないでしょうか？
別な方法はありますが、これが出来るとすっきりしそうなのです。
318:デフォルトの名無しさん
09/07/16 19:40:42
readonlyじゃ駄目なの？
319:デフォルトの名無しさん
09/07/16 19:57:42
>>318
なるほど。うまくいきました。
readonly static string str = string.Format( "{0}{1}", Path.DirectorySeparatorChar, Path.AltDirectorySeparatorChar );
ちなみに
>もしくはC++の関数内で
>static string str = "123";
>みたいなことは出来ないでしょうか？
これって出来ますか？
320:デフォルトの名無しさん
09/07/16 20:01:25
できない
321:デフォルトの名無しさん
09/07/16 20:04:56
そうですか・・。
了解しました。
322:デフォルトの名無しさん
09/07/16 21:15:10
>>319
C++で関数内のstatic string str = "123";は可能では？
まあスレ違いになるからC++スレで聞け。
323:デフォルトの名無しさん
09/07/18 00:36:11
internal修飾子の使いどころがイマイチわからん
324:デフォルトの名無しさん
09/07/18 00:40:57
ライブラリ作成をしてみると分かるんじゃないか
325:デフォルトの名無しさん
09/07/18 00:41:24
プログラムをDLLで分割しまくって
アクセス制限考え出すとわかる
326:デフォルトの名無しさん
09/07/18 02:26:16
TabIndexに-1を指定できるようにしてほしい
327:デフォルトの名無しさん
09/07/18 03:00:27
何故？
328:デフォルトの名無しさん
09/07/18 03:09:19
使用していないことを明確に表すため
329:デフォルトの名無しさん
09/07/18 03:16:08
継承して、使用していないことを明確に表すため のプロパティを用意すればいいじゃん
330:デフォルトの名無しさん
09/07/18 03:31:49
いえ、相談ではなく提案です
TabIndexプロパティの仕様の話で、-1が使えた方がスマートだということ
331:デフォルトの名無しさん
09/07/18 03:35:20
でもそれだとデザイナで設定できなくなるし、
そもそもTabStopがあるからいらないと思う
332:デフォルトの名無しさん
09/07/18 03:38:55
どうでもいいオブジェクトのTabIndexの値がふらふらしてて気持ち悪い
収まりが悪い
333:デフォルトの名無しさん
09/07/18 07:04:28
そう良かったね。
334:デフォルトの名無しさん
09/07/18 08:19:21
使ってないやつは-1とか
発想が前時代的
335:デフォルトの名無しさん
09/07/18 14:04:06
そうだな。
TabIndexはタブの移動順序を決めるためのプロパティだから、タブの有効/無効とは無関係だよな。
TabEnableてきなプロパティを作るべき。
336:デフォルトの名無しさん
09/07/18 14:27:34
ヌルあぶればいいじゃない
337:デフォルトの名無しさん
09/07/19 04:05:27
おまえらセンス無い
338:デフォルトの名無しさん
09/07/19 04:05:56
ごめん
339:デフォルトの名無しさん
09/07/20 10:11:32
2つの256色ビットマップを読み込んで（パレットは2つとも同じ）、
1つの大きな256ビットマップに描画して、保存したいと思っています。
System.Drawing.Bitmapオブジェクトは作成できたのですが、
ピクセルフォーマットがFormat8bppIndexedになっているので、Graphicsオブジェクトが作成できません。
256色ビットマップに描画するには、どのようにすればよいでしょうか？
340:デフォルトの名無しさん
09/07/20 10:42:12
1枚をRead→Writeはできてるの？
341:デフォルトの名無しさん
09/07/20 10:44:29
>>339
Bitmap コンストラクタ (Int32, Int32, PixelFormat) でコピー先ビットマップ作って
GetPixcel/SetPixelで書き写すしかないんじゃね？
342:デフォルトの名無しさん
09/07/20 11:45:19
最近、ビットマップ合成がらみを色々見てて、
2.0以前のSystem.Drawing.Bitmapよりも、
3.0以降のSystem.Windows.Media.Imaging.BitmapSource と
WriteableBitmap の方が使いやすかった。
343:デフォルトの名無しさん
09/07/20 12:19:39
そんなことSetPixelでやったら死ぬよ
LockBitsだな
WPFが使えるならもちろんそっちの方が遥かに便利で強力
344:デフォルトの名無しさん
09/07/20 12:27:12
結局、32bitBitmap上に描画し、LockBitsして32bit->8bit変換を行いました。
回答してくださった方、どうもありがとうございました。
345:デフォルトの名無しさん
09/07/20 12:28:08
>>344は>>339です。
346:デフォルトの名無しさん
09/07/22 02:08:09
会社で社内の業務改善ツールを任されることになりました
上からＪａｖａかＣ＃を選ぶようにいわれましたが
どちらが扱いやすくて今後の将来性がありますか？
347:デフォルトの名無しさん
09/07/22 02:12:17
C#スレで訊いたらC#と答えるに決まっているだろう
348:デフォルトの名無しさん
09/07/22 02:23:27
>>346
Javaスレで聞いたら？
Javaって返ってくるだろうけど。
まぁ、アレですよ。
自分で使いたいと思うほうを使えばいいと思います。
どっちも将来性なんて分からないので。
349:デフォルトの名無しさん
09/07/22 02:29:17
>>346
製作されたソフトウェアのどちらが長期使用に耐えられるかと言ったら
C#だろうな
350:デフォルトの名無しさん
09/07/22 04:16:08
URLﾘﾝｸ(www10.ocn.ne.jp)
RPGClientでログインして、少し動かした後で切断。再度ログインすると、KeyNotFoundExpectionが発生してしまう。
しらべてみると、MapChangReq（）のunits.setUnit()でunitlistに登録したキーの値がfindUnit(）でキーを元に検索しようとする前の段階で入れ替わってるのが原因だとわかった。
でも、治し方がわからない。
詳しい人がいたら教えてほしい。
351:デフォルトの名無しさん
09/07/22 07:48:58
Windows環境限定でいいんだったらC#でいいんじゃね？
352:デフォルトの名無しさん
09/07/22 07:59:31
互換性考えるとC89だよな
353:デフォルトの名無しさん
09/07/22 08:37:00
コンシューマ用ならC#が俄然有利な気がするが
後方互換保ってくれるかわからないんだよなぁ
なんだかんだで１０年来動き続けてるVB6という手も怖い
354:デフォルトの名無しさん
09/07/22 09:17:18
>>352
互換性(笑)
>>353
少なくとも IL は互換性保たれるんじゃないかな。
355:デフォルトの名無しさん
09/07/22 09:48:41
>>350
プロジェクト開けねーじゃねーか・・・XNA入れないとならんのか？ﾒﾝﾄﾞｸｻ
356:デフォルトの名無しさん
09/07/22 10:01:33
>>350
解凍できね
357:デフォルトの名無しさん
09/07/22 10:25:04
>>356
7zipで解凍できたよ。
>>350
ぱっと見なんだけどRPGServerをリブートしていたというオチではないか？
UnitManagerのunitlistをセーブしたりしている箇所はどこだ？
しかし、なんかUnitの管理とかが微妙な感じがする。
精査したわけじゃないが、unitsが座標ごとに持ってる部分とか。
358:デフォルトの名無しさん
09/07/22 12:04:26
>>357
RPGServerをリブートしているという落ちは残念ながありませんｗ
unitlistをセーブしている部分はsetunit、removeall、removeUnitの三つです。
359:デフォルトの名無しさん
09/07/22 13:40:05
>>358
右クリックして、送る→圧縮(zip 形式)フォルダ
で圧縮したものでうｐしなおしてくれ。
360:358
09/07/22 13:54:39
>>359
すまん。今使ってるウィンドウズにはその機能はない。
361:デフォルトの名無しさん
09/07/22 14:44:12
>>360
機能がないんじゃなくてテメーが無効にしたんだろ。
362:デフォルトの名無しさん
09/07/22 15:05:03
使っているWindowsかビルド環境が古いというオチか。
363:デフォルトの名無しさん
09/07/22 16:11:02
Vistaの標準のエクスプローラで解凍できたけどな
364:デフォルトの名無しさん
09/07/22 16:33:30
>>358
んじゃ、recive_packetでMapChangReqコマンドを投げる前にHandleInput受け取って
SetPosコマンド投げた。とか？
は無いか、initedチェックしてるから。
わかんね。ギブ。
ただ、ひとつ気になったのはunitlist.Add(id, u);。
Dictionary#Addは「ただし、指定したキーが Dictionary<(Of <(TKey, TValue>)>) 内に
既に存在する場合、Item プロパティを設定すると既存の値が上書きされます。
一方、Add メソッドは、指定したキーを持つ値が既に存在する場合、例外をスローします。」
365:デフォルトの名無しさん
09/07/22 22:30:01
何が何だかよくわからない。
切断した後IPとか変わってても大丈夫なの？
366:デフォルトの名無しさん
09/07/22 22:54:46
駄目だけど、そこんとこはまた別の問題。
ツッコミどころはまだまだ多いけど、それは一つずつ解決していくしかなかろう。
とりあえず、結構頑張ってると思う。
367:デフォルトの名無しさん
09/07/26 18:08:18
C++/CLI のスレから誘導されてきた。よろしくお願いしたい。
----------
おしえて。
フォームアプリのテキストボックスとかにデータバインディングで、
DataTable の要素を関連づけて入力値を管理したい。
ここで、テーブル中のレコードが１つの場合はいいんだが、複数あって
かつ、バインドするレコードを動的に変更したい場合ってのはどうすれば
いいのだろうか？
よくわからなかったので、
・バインド用に同じ構造のテーブルを用意して
・そこにレコードをひとつだけ作り
・そのレコードに元テーブルの任意のレコードの値をコピーする
・フォーム終了後にもとのテーブルのレコードに値をコピーし直す
方法で使おうとも思ったのだけど、もっと直接的な方法がありそうな気がする。
いかがだろうか。教示いただけると嬉しい。
368:デフォルトの名無しさん
09/07/26 19:14:08
何を言いたいのかがハッキリわからないけど
DataTableに複数レコードつっこんで
あるときは1レコード目、あるときは2レコード目をバインドすればいいんじゃないの
369:デフォルトの名無しさん
09/07/26 19:37:11
返信をありがとう。
>あるときは1レコード目、あるときは2レコード目をバインドすればいいんじゃないの
その２レコード目をバインドする方法がわからなかったんだ。。。
370:デフォルトの名無しさん
09/07/26 19:38:54
何言ってるんだろ？ 次のレコードに進めるだけだろ。
371:デフォルトの名無しさん
09/07/26 23:37:42
ああ。そう言う方法があるんだね。
ごめん。まだこれの経験が浅くてそれ自体がわかってないんだ。
その方向で調べ直すよ。ありがとう。
372:デフォルトの名無しさん
09/07/27 00:35:25
BindingManagerBase::Position のことか。
気がつかなかったよ。お騒がせしました。
373:デフォルトの名無しさん
09/07/27 14:13:58
非ジェネリックのIDictionaryをジェネリックのIDictionary<TKey, TValue>に
変換するスマートな方法があったら教えてください。
foreachで別のDictionayに１つずつ追加するのはやれてます。
374:デフォルトの名無しさん
09/07/27 14:30:54
それが一番だと思うけど。
dic.Cast<DictionaryEntry>().ToDictionary(entry => (TKey)entry.Key, entry => (TValue)entry.Value);
がスマートとは思えない。
375:デフォルトの名無しさん
09/07/27 14:34:42
C# 2.0
で質問です
System.Threading.ManualResetEvent
のインスタンスを使用して1ミリ秒のウェイト処理をループ中にかけようとしているのですが
・Vista環境だと上手く1mSec 程度停止するのに
・XP環境だと15mSec程度まで跳ね上がる時があります。
OSの分解能ということで1mSecは諦めるしかないのでしょうか？
用途は最高速で常時まわしたい処理を以下のソースのWhileの中に組み込んでHOGEの処理をしているのですが
可能であれば10mSec以下で1ループを終わらせたいのです。（中の処理は2～3mSec程度）
ただしこのままでは別スレッドで実行しているにもかかわらずCPU負荷率が高すぎるために
最低レベルでのスレッド停止処理を行いたいのです。
ちなみにSystem.Threding.Thred.Sleep(1); を行うとVista環境でも1mSecより大きく停止してしまいます。
System.Threading.ManualResetEvent mre = new System.Threading.ManualResetEvent(false);
While(True)
{
HOGE();//処理
//ストップウォッチ計測開始
mre.WaitOne(1);
//ストップウォッチ計測終了
if(exitFlag == true) break;
}
何とか最速でまわしつつ負荷を上げずにWhile文を回し続ける方法はないでしょうか？
376:デフォルトの名無しさん
09/07/27 17:19:40
1msの分解能が欲しかったらCPU負荷率は諦めるしかないと思うけどな
スレッド切り替えるのに1ms以上かかりそうだし
377:デフォルトの名無しさん
09/07/27 17:55:33
>>376
そうですか・・・
まぁヂュアルCPUなんで負荷率は50％なので構わないと言えば構わないのですが・・・
できるだけ使用率を低くして寿命を延ばしてやりたかったのです
378:デフォルトの名無しさん
09/07/27 17:59:39
>>375
Sleepすることが目的ではなく、CPUを使いすぎることを抑えたいだけのように感じる。
もしそうなら、Priorityプロパティでスレッドの優先度を下げるだけというのはどう？
もちろん、優先度を下げるということはCPU使用率を下げることとは違うから、、
ほかにやることがなければCPUを使い尽くすということに変わりはないけど。
379:デフォルトの名無しさん
09/07/27 18:02:17
>>377
何をやりたいのか知らないけど専用マシンを用意すれば？
380:デフォルトの名無しさん
09/07/27 18:32:57
10mSecでTimer回した方が良いように思えてならない。
再入をブロックする必要はあるけど。
381:デフォルトの名無しさん
09/07/27 20:17:27
>>375
よくわかんないけどこういうこと？
Stopwatch sw = new Stopwatch();
long nextTiming = sw.ElapsedMilliseconds + 10;
sw.Start();
while (true)
{
while (sw.ElapsedMilliseconds < nextTiming) { Thread.Sleep(0); }
nextTiming += 10;
Console.WriteLine("Now is {0} ms", sw.ElapsedMilliseconds);
}
Thread.Sleep(1)にしてやればCPU使用率は無駄に上がらない。
その場合、処理のインターバルの精度は落ちるけど、時間あたりの処理回数の精度は
保てるといってよいんじゃないか。
382:デフォルトの名無しさん
09/07/27 23:32:44
マルチメディア系の機能でミリ秒レベルの精度でsleepする方法ってあったりするんだっけ？
普通のSleepって、TimeBeginPeriodで指定した分解能でスレッドの状態変わるんだっけ？
もしSleepの精度にTimeBeginPeriodが効くなら、それやってスレッドの優先度をあげればいいかも。
ただし処理をきちっと終えてちゃんと確実に速やかにSleepしないと死ぬことになるが。
383:デフォルトの名無しさん
09/07/27 23:35:31
各回のインターバルの精度が必要でないなら、10回分繰り返して10回分Sleepとかそういう手もあるが。
384:デフォルトの名無しさん
09/07/27 23:42:24
>>382
timeBeginPeriodは消費電力を増やすと言われているのだから、
寿命を気にする>>377には似つかわしくないと思う。
385:デフォルトの名無しさん
09/07/27 23:54:07
HDDはともかく、CPUはヒートシンクが動作中に外れるとか
余程のことでもなければ「寿命」を縮めるなんてことはないと思うけど。
真空管じゃないんだから
386:デフォルトの名無しさん
09/07/28 00:07:36
まあCPU自体にはあんま関係ないけど、
使用率が高いところを維持するのは全体で見ればあまり望ましいことじゃなかろう。
あと確かに大麻精度あげると電力使用はアップしてしまうのかも知れんが、
CPU使用率が高いままになるよりはましじゃないかと思うがどうだろう。
もちろんそうせずに済むならそれにこしたことはない。
387:デフォルトの名無しさん
09/07/28 00:19:55
結局のところ、何であんな事をやりたいのかハッキリしないと何とも言えん
388:デフォルトの名無しさん
09/07/28 10:43:04
C#では、グラフィック関連のメソッドで、小数の引数はfloat型になってますよね。
floatよりdoubleの方が一般に速いと思うのですが、なぜfloatなんですか？
389:デフォルトの名無しさん
09/07/28 10:49:39
GPUはほぼ単精度までしか扱えなかったぜ
まあGDI+はGPU使わんけどな！
390:デフォルトの名無しさん
09/07/28 10:57:27
計算速度じゃなくて帯域幅の問題。
あとdoubleが速いってのは今のCPUでの話にすぎない。
391:デフォルトの名無しさん
09/07/28 10:58:17
あGPU関係なかったか…
392:デフォルトの名無しさん
09/07/28 11:00:36
>>389
なるほど…。
今まで、座標を保存するための変数x, yをdouble型で宣言して、
描画時にintに変換して使っていたのですが、
これはfloatにしてキャストなしで使った方がいいんでしょうか？
「float同士の演算(座標計算時)」と「double同士の演算(座標計算時)＋intへのキャスト(描画時)」
では、どっちが速いんでしょうか。
393:デフォルトの名無しさん
09/07/28 11:05:11
>>390
> 今のCPUでの話にすぎない。
昔のCPUのことを想定してどうすんだよｗ
394:デフォルトの名無しさん
09/07/28 11:19:55
>>392
自分でベンチ書いて試しなよ
その方が納得できるだろ
395:デフォルトの名無しさん
09/07/28 11:53:38
昔のCPUの話じゃなくて今のGPUの話だよ。
関係なかったけど。
396:デフォルトの名無しさん
09/07/28 12:20:35
レスが遅くなりました。
>>378
おっしゃる通り現在の処理速度を犠牲にせずにCPUの負荷を下げてあげたいということです。
スレッドの優先度は、この処理部分以外にあまり同時に激しい処理をしているわけではないので微妙な感じです
>>379
まぁ専用マシンを用意してもCPU負荷がずっと大きな値に張り付くのは・・・微妙なきがします。
FA系なので安定して長く動作させたいのです。
>>380
やってみた感じスレッドのタイマで１ｍSecで動かしてもどうも間隔はOSに引っ張られるようですorz
例えばですが・・・再入ブロックはこんな感じの処理のことでしたっけ？
タイマコントロール
void tick
{
タイマ停止
処理
タイマ開始
}
スレッドタイマ （間隔で動かすというか1回だけ動かすのを繰り返す）
void Tick()
{
処理
次回Tickを動かす時に１ｍSec間隔をあけて実行
}
397:デフォルトの名無しさん
09/07/28 12:37:37
>>381->>383, >>387
本当はWhileの中は最速でまわしてあげたいのです。
しかし、CPU負荷率が高くなりすぎるのでそれを防ぐためだけに仕方なく1mSecのスレッド停止を挟んでいるのですが
そのスレッド停止がXPではきっちり１ｍSec止まってくれない
（別に２ｍSecとかでもいいのですが１５ｍSecとか止まってしまうのです。）
結局やりたいことを説明すると
FAの工場内のでラインの制御をおこなうのに１スキャンあたり（１ループ）25mSec以内で処理しなければ処理ヌケが発生する。
→処理ヌケが発生しないようにする処理は現在のループ処理の中では余裕
→だけどCPUがずっと高い使用率に張り付いたまま
→基本的に長期安定動作させたいので使用率は大きいよりは小さいほうがいい
→SleepやManualResetEvent.WaitOneではXP上で停止時間が不安定 （これで運用すると少しでもOSの動きに引っ張られると処理時間が延びて処理ヌケしてしまう）
→VISTAはなぜか停止時間が結構安定する
→上に VISTAにしてくれというと「FAでVISTAとかまじありえね XPでやれ」 と言われ取り合ってももらえず
→打つ手が思い付かずに ここへ知恵を借りに
↑いまここ
そして同じPC内にはコスト削減とかでラインの画像判定を撮って判定するソフトが・・・
（これ自身はCPU負荷はそこまで使いません。 一瞬５～１０％まで上がる程度が５０ｍSec程度の間隔）
こんな状況ですorz
そもそも、Pgを別のPCに分けてもメインのループ部分がCPU使いっぱなしになるので問題の解決はしないという・・・
>>385-386
CPU自体は迷信なのかもれません。
まぁ、ただずっと高しようりつで張り付くと結局温度が上がってしまうので
色々と起きてきそうなのです。
398:デフォルトの名無しさん
09/07/28 12:49:09
CPUのタイムスライスってレジストリでいじれなかったっけ？
そこまでシビアなFAの制御なら専用のCPUボードにやらせて、
OSはサマリーだけ受け取るような仕掛けにしないといかんだろう。
399:デフォルトの名無しさん
09/07/28 12:53:35
>>398
本当はそうなんですよね
せめてPLC使って処理させるとか
でも・・・今回は期限ないうえにコストも落とせという色々無茶な状態が重なってしまいまして…
400: [―{}@{}@{}-] デフォルトの名無しさん
09/07/28 13:11:31
>>399
RTOSが必要なんじゃね？
この辺にも色々書いてあるけど
URLﾘﾝｸ(www.microsoft.com)
401:デフォルトの名無しさん
09/07/28 13:13:02
他のプロセス（サービス含む）が動いたらあっという間に25ミリ秒とか過ぎ去るな
402:デフォルトの名無しさん
09/07/28 13:17:34
>>400
エンベデッド（これで読みはいいのか？）ですよね
そう、せめてそれがあれば最低限のコンポーネント入れていけるとおもうんです
しかし普通のPCに普通のXP PRO
サービスとかはできる限りとめて動かしていますがなんというか・・・がっくりです
>>401
そうなんです！
というか、やる気起きないのでダラダラと
403:デフォルトの名無しさん
09/07/28 13:22:06
連投ばっかですみません
なんとなくですが
>>382
のTimeBeginPeriodでいけそうな気がします。
また詳しいことは微妙ですが
これ使って簡単に1日程度動かして様子を一回見てみようかと
404:デフォルトの名無しさん
09/07/28 17:53:02
>>392
描画メソッドの呼び出し頻度なんか知れてる
呼び出してからの実際の描画処理の方が遥かに時間がかかるからそんな細かい差は全く意味がない
405:デフォルトの名無しさん
09/07/28 19:47:21
>>403
なんか>>397を読んでもやっぱりよく分からないんだけど、
要するにDIOか何かをポーリングしてるのかな？
それでそのDIOのイベントに応答するときのレイテンシの最大許容時間が25ms、
みたいなこと？
406:デフォルトの名無しさん
09/07/28 20:18:16
浮動小数から整数への丸め制御方法によっては、intにキャストする回数が多いと遅くなるかもね
407:デフォルトの名無しさん
09/07/28 20:24:57
そんな差が目に見えるほど描画メソッド呼び出したらそれこそ死亡
408:デフォルトの名無しさん
09/07/28 21:33:20
>>397 >>403
タイマーが15ms間隔でしか発動しないのはWindowsの仕様。
パラメータでは1ms単位の数値が設定できるけど、実際の動作は約15.5ms間隔に切り上げられる。
TimeBeginPeriodを使えば間隔を詰めることはできるけど、実際に試してみると、
最短の間隔がせいぜい2ms程度で、それより長くなることもある。
それにTimeBeginPeriodには副作用があって、他のアプリがたまたまTimeBeginPeriodを再設定してしまうと、
そのマシンで動いているすべてのアプリが影響を受けてしまう。
>>375でVistaは1msてのは、たまたま何かのアプリがTimeBeginPeriodをいじってただけの可能性が高い。
そもそもSleep関数の動作は「少なくとも」指定した時間経過、だから、どれだけオーバーするかは運次第。
ただしこれはVistaまでの話で、Windows7ではタイマー関係がようやく強化される予定なので、
どうしても2ms以下の間隔を死守したいならWindows7を使えばすんなり解決するかもしれない。
409:デフォルトの名無しさん
09/07/28 21:47:44
タイマっていうかタイムスライスの問題だからちょっと話がズレてると思うけど。。
410:デフォルトの名無しさん
09/07/28 21:53:02
>>408
XPしかだめっつうてんだろｗ
XPにPLCと同じことさせようとしても無理。
制御じゃなく監視だよね？
FA屋で制御までさせようとしてるなら職変えたほうが良いよ。
411:デフォルトの名無しさん
09/07/28 22:08:01
Chrome起動中だと高速化するよ（笑い）
412:デフォルトの名無しさん
09/07/28 22:16:54
25msなら、スレッドの優先度上げてやればSleepでも大丈夫かもしれん（実質15msくらいで）。
まあTimeBeginPeriod使った方がいいと思うけど。
優先度を上げない場合、Sleepでの停止自体は短時間でも、実行順が回ってくるまでに
タイムオーバーする危険がある（他のスレッドがある場合）。
優先度を上げると実行可能になった時優先的に処理が回ってくるので、遅れる危険が小さくなる。
ただし、処理を終えたら確実にSleepしないと、下手すればマシンハングアップ状態になるので注意。
ただ、いずれにしてもWindowsではそういうのを本当に確実に処理することはできない。
413:デフォルトの名無しさん
09/07/28 22:21:58
XPのタイムスライスってどんくらいだっけ？15msくらいだっけ？20msくらいだっけかな？
もしフォアグラウンドで何かを動かしたらそいつは3倍になるから処理にもよるけど簡単に死ねる。
414:デフォルトの名無しさん
09/07/28 22:23:41
スレッドの優先順位？
スレッド？
415:デフォルトの名無しさん
09/07/28 22:29:46
>>413
1/64 s
416:デフォルトの名無しさん
09/07/28 22:37:57
あー大きく上げるにはプロセス側で上げとかないと駄目だったか、
言いたかったのは単に最終的なスレッドの優先度を上げるということ。
417:デフォルトの名無しさん
09/07/28 23:23:52
>397の人件費考えたらVISTAなんて安いものだろうに・・・
418:デフォルトの名無しさん
09/07/29 00:05:42
ていうか・・・なんでWindowsでそんなリアルタイムOS的な制御をやろうと企画した
んだろ、発注元。
419:デフォルトの名無しさん
09/07/29 00:17:34
>>397の言葉遣いも怪しいところがあるから、
必ずしも本来の要求仕様を満たすために必要のない手法を>>397自身が
考えているだけかもしれない。
なんかその可能性が高いように思う。
420:デフォルトの名無しさん
09/07/29 00:36:59
リアルタイムにセンシングするとして、データをキューに入れといて別スレッド
で処理したら駄目なのかな・・・いや、そういう話じゃないな。
382の言うとおりマルチメディアタイマ使えばいいんじゃね？
421:デフォルトの名無しさん
09/07/29 00:47:18
>>410
いや、Vistaはカンベンしてくれって話だろ？
422:デフォルトの名無しさん
09/07/29 00:48:14
マルチメディアタイマーも15ms縛りがあったような…
423:デフォルトの名無しさん
09/07/29 00:49:07
要求が「VistaとXP」なんだからそんなところの議論は無駄無駄
424:デフォルトの名無しさん
09/07/29 01:16:39
てか1ms周期で動かしたら大抵CPU時間使いまくるってオチ
425:397
09/07/29 02:13:03
多くのレスありがとうございます。
そもそもなぜXPなのか？
というのはその上役の人間が安定志向でXPで今まで出来てたんだから という考えのもとに言っているような感じです。
しかし、その実績はせいぜい50～1000mSec程度なのでどのOSでも簡単に実装できるものでした。
新しい機械を開発するにあたり
そこそこ高速で移動するライン状の物の位置をエンコーダで追い、DIOの信号を利用して移動させる という処理が必要になり
上役の人間が打ち合わせをした際にその程度の処理なら出来る という憶測で仕事を受け入れてしまいました。
その尻拭い的な感じをいまやっているわけなのです。
多くの皆様意見をいただき本当にありがとうございます。
さすがに限界を感じる感じなので、CPUをフルに使う状態での運用か、それとも設計や方針自体を変更するべきなのかを上の人間にかけあってみます。
ちなみに単純な処理です
→ 物の流れる方向
｜----------------目的地
センサ ↓
センサをＯＮしたタイミングでエンコーダ値を取得・保持し、目的地の位置までパルスが移動したらＤＩＯ信号をＯＮし、流れているものを矢印の方向へ稼働させる機械を動かす。
たったこれだけです。
ＰＬＣでやればどれだけ単純で簡単なレベル という話 orz
多くの意見、今後のＰＧに生かしていこうと思います。
はぁ・・・月曜日が鬱だｗ
426:デフォルトの名無しさん
09/07/29 03:16:37
しかもC#でとな('A`
427:デフォルトの名無しさん
09/07/29 06:05:48
>>425
それ本当に1msの精度求められてるの？
仕分けでそこまでの速度を要求されるとは思えんのだが。
428:デフォルトの名無しさん
09/07/29 06:47:49
>>393
intよりdoubleが早い環境なんて少数派だぞ
429:デフォルトの名無しさん
09/07/29 06:58:29
PCでそんな制御やるのがそもそも間違えてる
カーネルから優先度の高い命令が割り込んだら何ぼでも処理落ちするぞ
430:デフォルトの名無しさん
09/07/29 08:05:16
動かないと思ったらWindowsUpdateでリブートしてるんですね。わかります。
431:デフォルトの名無しさん
09/07/29 12:06:08
>>427
初めに書いたとおり1mSecまでは求められてはいませんが
自分がWindowsで制御するなかでは初めての精度になります。
まぁごくまれに処理抜けする程度ならリターンしてもう一度処理をすればいいのでそれはそれで何とかなるわけですが
その為、処理負荷をできるだけ下げつつ処理時間間隔を短くするために可能な範囲で試行錯誤してみています。
>>426
>>429
そうなんですよね
何というか・・・GUIがほしいのはわかるんですが・・・
ちなみに現在実機でタイマ精度変更後に一日動作させた感じ1処理は停止含めて15mSecを超えていない（StopWatch調べ）感じです。
CPU負荷も常時高い位置にあったものが時々大きく上がる程度まで抑えることができている感じです。
でもぶっちゃけ実運用になったら・・・ちょっと怖いかも
432:デフォルトの名無しさん
09/07/29 12:17:58
実際のとこ、全力でぶん回してもリスクは変わらないから。
433:デフォルトの名無しさん
09/07/29 12:31:00
全くもってそのとおり
”ずーっと確実に最長1msの周期で観測する”という要件しか聞いていないから，PCの電源が落とされた時点でアウト，
PCの電源落とさないってんなら，たった一日の観測(>>431)くらいで何か分かるわけでもないし．
おとなしくデバイス作ってUSBかシリアルで接続したほうが安心．
GUIはC#でいいだろうが
434: [―{}@{}@{}-] デフォルトの名無しさん
09/07/29 12:39:49
>>433
なんかPC障害でラインが暴走しそうな悪寒もする。
ちょっとした機能追加で制御不能になったりとか
担当者さんのデスマーチが目に浮かぶ
435:デフォルトの名無しさん
09/07/29 12:44:55
今思った
GC時間考慮してねー
436:デフォルトの名無しさん
09/07/29 13:02:29
まあ書かれてた処理内容なら大丈夫だろ。
もち注意して作る必要はあるけど。
437:デフォルトの名無しさん
09/07/29 19:25:38
>>425
その説明だと、そもそも「目的地」のところにセンサをつけ、
その出力を「流れているものを矢印の方向へ稼働させる機械」に直結すれば
PCなんか要らないように思えるけど。
それにどうしてエンコーダが必要になるのか意味がわからない。
わざわざ目的地じゃなくてその手前なんかにセンサを付けるから、
目的地を検出するためだけにエンコーダが必要になるんじゃ？
438:デフォルトの名無しさん
09/07/29 20:39:38
>>425
目的地にセンサつけたらだめだろｗ
目的地はｎ通りあるから事前に振り分ける処理が要る。
FAの機械ってのは大抵が独自のプロトコルで通信する。
だからPCなりPLCなどの中継が必要になる。
ここまでは皆理解していて、その先の精度や耐久性について語ってるのだよ。
439:デフォルトの名無しさん
09/07/29 22:02:36
>>438
よくわかんない発想をする人だなあ。
仮に目的がN通りだとする。
それって何を基準に振り分けるの？
その仮説と>>425の説明をあわせれば、恐らく物体の高さか何かによって
ONするセンサが変わるから、それを基準に振り分けることになる。
だとすると、それってN個の目的地の直前で、対応するセンサと
「矢印の方向へ稼働させる機械」を直結することと等価でしょ。
440:デフォルトの名無しさん
09/07/29 22:37:57
まあ、質問主が詳細を明らかにしてないのに細かいこといってもしょうがないか。
なんとなくセンサの設置法さえ工夫すればビジーループでポーリング、
なんてことしなくてもPCでもこなせそうな仕事にも思えるけど。
DIOの付属のライブラリって、たいてい入力のイベントでコールバックする
機能がついてると思うから、そのあたりとあわせればできるんじゃないのかな。
441:デフォルトの名無しさん
09/07/30 06:33:12
>>439
バーコード、QR、RFIDなんかは普通に使うぞ？素人か？
442:デフォルトの名無しさん
09/07/30 19:46:27
もうどうでもいいよ。
さっさと上司と拳闘しろ。
443:デフォルトの名無しさん
09/07/30 20:16:21
>>441
そういう問題か。
そんなことは>>425の文章からは読み取れない。
余程の馬鹿じゃなければ、そんな重要なことは最初に明確に書くだろう。
444:デフォルトの名無しさん
09/07/30 20:42:16
＞そんな重要なことは最初に明確に書くだろう。
うーん
そんなこと無いケースが多々あるが・・・
445:デフォルトの名無しさん
09/07/30 20:48:45
そういうスレでやれ
446:デフォルトの名無しさん
09/07/31 12:41:04
EventHandler eh += delegate { };
EventHandler eh += (sender, e) => { };
sender, eを使わない場合ラムダ式にしない方がいいの？
447:デフォルトの名無しさん
09/07/31 12:49:58
使いもしないのに書くのは気持ち悪い
448:デフォルトの名無しさん
09/07/31 20:20:09
関数でシステム作る様な言語でもないんだし
LINQの目的に使わないのなら俺は使ってないなー
449:デフォルトの名無しさん
09/08/01 01:35:08
>>446
ラムダ式使うなあ。
別に引数を使わないのはLinqでもあることだし。
450:デフォルトの名無しさん
09/08/01 08:27:42
使ってると関数式が分散しちゃって管理しづらくない？
451:デフォルトの名無しさん
09/08/01 12:16:38
複数箇所で使うならメソッドにしとけ。その場限りならラムダにしとけ。
作ったメソッドをシグネチャ合わせるためにラムダ使うとかも良くあること。
452:デフォルトの名無しさん
09/08/01 13:20:59
はい匿名関数使います。
453:デフォルトの名無しさん
09/08/01 13:29:18
delegate { }の形の匿名メソッドはそのうち「今後は使用しないでください」ってお達しが出るかもね
454:デフォルトの名無しさん
09/08/02 01:07:34
C#って内部クラスをどういうときに使うの？
関連の強いクラスでも、内部クラスにするメリットがわからない。
Javaならすごいはっきりしてるけど・・・
455:デフォルトの名無しさん
09/08/02 01:08:10
>>1の本文は「飲み過ぎた・・・」と予想したが見事にはずれた
456:デフォルトの名無しさん
09/08/02 01:13:55
>>454
javaだろうがc#だろうがインナークラスの使い道なんて一緒だと思うけど…。
よくわからん疑問だな。
457:デフォルトの名無しさん
09/08/02 01:32:22
>>454
おまえはおれかｗ
今日ふと気になってそれ調べてたよ。
外部クラスのprivateフィールド、関数にアクセスできるのが一番のメリットだろうね。
458:デフォルトの名無しさん
09/08/02 01:32:42
>>454
わざわざ外に書くほどでもないとき
スコープ的にそのクラスの外に見れないようにしたりしたいし
459:デフォルトの名無しさん
09/08/02 01:49:07
>457,458
こんな遅い時間にサンクスコ！
>外部クラスのprivateフィールド、関数にアクセスできるのが一番のメリットだろうね。
ああ、なんか勘違いしてました。外部クラスのインスタンスは渡してやらなきゃいけないけど
privateにアクセス可能なんですね。馬鹿な漏れですみません。
C#ってJavaに似せてはいるけど、かなり別モンですね。
スコープっていうかアクセス権については、
Javaのパッケージプライベートに相当するものが欲しい・・・
でもプロパティは素晴らしいです！(JavaのBeansは最悪。)
460:デフォルトの名無しさん
09/08/02 02:26:21
プロパティはすばらしいとおれも思う。直観的だし、見やすい。
461:デフォルトの名無しさん
09/08/02 02:59:27
そして書きやすいしね。VB.NETのプロパティはﾏﾝﾄﾞｸｻだけど。
462:デフォルトの名無しさん
09/08/02 03:00:55
プロパティとデリゲートは自慢できる機構だな。
いつJavaが逆輸入してくれるかと期待してるんだが、無理なのか。
463:デフォルトの名無しさん
09/08/02 04:01:16
プロパティはいいとしても、
delegateはVJ++時代の歴史的ないさかいがあるからあれだなぁ。
464:デフォルトの名無しさん
09/08/02 04:02:34
プロパティはJavaの新機能の候補にまで入ったんだけど・・・駄目だった
デリゲートはありえなさそうだ
465:デフォルトの名無しさん
09/08/02 07:55:22
C++の将来はどうなりますか？
466:デフォルトの名無しさん
09/08/02 09:19:43
C++の将来はC++0x、2015年までに何とかしてくれるらしい。
そろそろスレ違いだな。
467:デフォルトの名無しさん
09/08/02 10:36:21
>>459
パッケージスコープはinternalがある。
「名前空間」っていうのはそもそもクラスライブラリを使う側のためにあるものだから
作る側の実装の都合によるパッケージスコープとは明確に区別されてる。
どっちがいいかは別にして，考え方の問題。
468:デフォルトの名無しさん
09/08/02 10:48:31
.NETでCollectionを返してくるやつがあるけど何でジェネリック使ってないの？
469:デフォルトの名無しさん
09/08/02 11:03:03
.NET1.xのころはジェネリックが使えなかったから。
3.0～のWPFで非ジェネリックコレクションが一部使われてる理由は，
WPFはけっこう型にルーズで，突っ込まれたいろんな型のオブジェクトを
適当に自動的に変換したりするから
470:デフォルトの名無しさん
09/08/02 11:46:54
>>467
考え方がどうとかはしらんが、
internalはexeやdllレベルのアクセス制限だから、Javaのpackage privateとは別モンだろ。
適度なアクセス制限かけたい時に、いちいちdllに分けるとかありえんwww
471:デフォルトの名無しさん
09/08/02 12:59:45
?:でelse側要らない時あるから、何もしないで辞めるという予約語cancelを追加してほしい
x = x > y ? 10 : cancel;
Open(Exist(path) ? path : cancel);
引数にcancelが入るとそのメソッドは実行されない
472:デフォルトの名無しさん
09/08/02 13:05:42
素直にif使えよ
473:デフォルトの名無しさん
09/08/02 13:14:30
Exec(a(), Open(b(), Exist(path) ? path : cancel, c()), d())
じゃあこれでExist(path)がfalseになったときはExecも実行されないの?
aやbやcやdは?
無駄に複雑になりすぎる
474:デフォルトの名無しさん
09/08/02 13:33:32
x = x > y ? 10 : x;
475:デフォルトの名無しさん
09/08/02 13:38:21
x = x > y ? 10;
こう書けりゃいいのにな
476:デフォルトの名無しさん
09/08/02 13:57:46
>>473
あー、なんか無理っぽいね
全部実行されないで欲しい感じはするものの
477:デフォルトの名無しさん
09/08/02 13:59:24
無理して三項演算子使わなくてもいいのに。
478:デフォルトの名無しさん
09/08/02 14:38:47
>>475
代入式なのに代入されない場合があるって、すんごいキモイと思うんだけど
どうだろうか
479:デフォルトの名無しさん
09/08/02 14:41:25
タイプ数そんなに変わらん
if(x > y) x = 10;
cancel導入だとむしろ多くなるじゃないか
480:デフォルトの名無しさん
09/08/02 14:53:24
>>479
これでいいじゃん
三項演算子にこだわる必要どこにもないし
481:デフォルトの名無しさん
09/08/02 14:53:48
全メソッドが毎回cancelチェックするらしいぜ！
482:デフォルトの名無しさん
09/08/02 14:57:36
なんで阿保の思いつきを開陳しようとする気になったの。
483:デフォルトの名無しさん
09/08/02 15:22:10
おまえというド阿呆をおびき寄せるため
484:デフォルトの名無しさん
09/08/02 16:35:49
本筋ではないけど、>>471のOpenの例はテストせずにモードOpenでtryして、
FileNotFoundExceptionなどをcatchでしょ。
ファイルは存在さえすれば開けるというものじゃないから、
どのみちtryする必要あり。それならばExistで存在確認するのは無駄。
485:デフォルトの名無しさん
09/08/02 16:38:23
例外は重たいから事前にチェックできるのならばチェックすべし
486:デフォルトの名無しさん
09/08/02 16:40:16
チェックから開くまでに、ファイルが消される可能性があるから無意味。
487:デフォルトの名無しさん
09/08/02 16:40:50
チェックした方がいいのは確かだが
ファイルを開こうとして失敗するなんて秒間何千回起こるようなものでもないんだから
重たいとか別に関係ない
488:デフォルトの名無しさん
09/08/02 16:42:34
例外は重いからチェックするってのは正か否か
これもよく揉める議題だよね。
頻度を考慮したらそんなに避けるべき問題でもないという結論に。
489:デフォルトの名無しさん
09/08/02 17:03:41
平均的には、チェックする方が遅くなるだろうな
どっちみち頻度考えたら問題にはならないけど
490:デフォルトの名無しさん
09/08/02 23:04:04
例外が思いからファイルを開くときにチェックしない
→ファイルを開くアクションを起こすと時々アプリケーションが終了
→作業内容が喪失
→作業意欲低下
→業務が滞る
→会社の収益が低下
→GDPが減少
→犯罪発生率の上昇
→本国崩壊
→朝鮮半島がなにかを主張し始める ←ここまで１年半
つまり例外処理反対派は反日親韓ということ？
491:デフォルトの名無しさん
09/08/02 23:10:37
>>490
それを言うなら、
例外が思い（ママ）からファイルを開くときにチェック＜する＞
だろ。
いつも思うんだが、ネタっていうのは分かってる奴がやるから面白いんであって、
何もわかってない奴が無理してやるネタなんて面白くもないともないんだよお馬鹿さん。
492:デフォルトの名無しさん
09/08/02 23:14:21
プログラムがファイルが存在しない状況について想定していることが伝わるからチェックはすべきでしょ
493:デフォルトの名無しさん
09/08/02 23:14:51
>>491
？？
494:デフォルトの名無しさん
09/08/02 23:17:53
必要な処理を必要なだけやるわけであって
重いから処理しないのはゆとり
495:デフォルトの名無しさん
09/08/02 23:18:03
ファイルが存在しない状況について想定していることが伝わればいいのなら
FileNotFoundExceptionを別にcatchするだけで十分じゃねーの
496:デフォルトの名無しさん
09/08/02 23:19:40
はげどう
497:デフォルトの名無しさん
09/08/02 23:25:50
まあFile.Existなんて気休めだよな。
498:デフォルトの名無しさん
09/08/02 23:56:25
ところで
Try(() => Open(path)).Catch<FileNotFoundException>(ex => Console.Write(ex));
とか書けたらいいなと思ってるのは俺だけじゃないはず
というか多分書けるな
今から作ってこよう
499:デフォルトの名無しさん
09/08/03 00:05:20
醜い醜い醜い醜い醜い醜い醜い醜い醜い醜い醜い醜い
醜い醜い醜い醜い醜い醜い醜い醜い醜い醜い醜い醜い
醜い醜い醜い醜い醜い醜い醜い醜い醜い醜い醜い醜い
醜い醜い醜い醜い醜い醜い醜い醜い醜い醜い醜い醜い
醜い醜い醜い醜い醜い醜い醜い醜い醜い醜い醜い醜い
醜い醜い醜い醜い醜い醜い醜い醜い醜い醜い醜い醜い
500:デフォルトの名無しさん
09/08/03 00:10:24
try～catchじゃない意味あるの？
こんなオナニーコード見せられたら卒倒しちゃうよ。
501:デフォルトの名無しさん
09/08/03 00:14:51
吐き気がするｗ
502:デフォルトの名無しさん
09/08/03 01:43:51
>>498
賛同者はごくまれだろうな・・・・・
503:デフォルトの名無しさん
09/08/03 02:18:06
if(auto ex = collectException(new File(path))) writeln(ex);
504:デフォルトの名無しさん
09/08/03 03:17:30
RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup
みたいのはあるけどな。
もちろん理由があって。
505:デフォルトの名無しさん
09/08/03 05:05:40
Util.TryCatch(()=>hogehoge...,e=>hoge....);
というのは作った。
506:デフォルトの名無しさん
09/08/03 05:10:59
何の役にもたたなそうだな
507:デフォルトの名無しさん
09/08/03 07:06:19
きもい流れになってるな・・・
508:デフォルトの名無しさん
09/08/03 12:01:36
C#を見にくいコードにする友の会か？
509:デフォルトの名無しさん
09/08/03 12:47:28
使う気にはなれないが、総称型をcatchに使えることは分かった。
public static T Try<TEx,T>(Func<T> func) where TEx : System.Exception {
try { return func(); } catch (TEx ex) { Console.WriteLine(ex); return default(T); }
}
510:デフォルトの名無しさん
09/08/03 13:08:02
これがラムダ厨の威力だというのか。
511:デフォルトの名無しさん
09/08/03 13:12:37
もうクラス使わずに全部クロージャだけで書こうぜ
512:デフォルトの名無しさん
09/08/03 13:20:44
一部のラムダ基地外をどうにかしてくれ。
513:デフォルトの名無しさん
09/08/03 13:27:07
短かく書きたい病ってのは誰でも一度は発症するもんだよ
514:デフォルトの名無しさん
09/08/03 15:10:12
ありすぎて困る
515:デフォルトの名無しさん
09/08/03 15:19:57
短く書きたい自体は分かるが、
短くなってない、見にくくなってるだけが多いのはなんでだ。
516:デフォルトの名無しさん
09/08/03 15:20:14
短く書きすぎて可読性落ちたらいみねぇｗｗｗ
に気付くのにPGはじめて数年かかった
517:デフォルトの名無しさん
09/08/03 15:21:54
try-catch-finallyをラムダで書くのに何のメリットがある。
518:デフォルトの名無しさん
09/08/03 15:48:42
テストコードやアサーションとかなら使い道があるかも
思いつかないけど
519:デフォルトの名無しさん
09/08/03 18:00:32
>>515
同感、未だ短く書きたい病発症してますけど、つか冗長コード書くやつ死ね派ですが
Tryは間違ってるだろと思うわ
520:デフォルトの名無しさん
09/08/03 18:05:09
俺は冗長コードは可読性とパフォーマンスはかりにかけて許容範囲ならOKな派
521:デフォルトの名無しさん
09/08/03 18:34:03
C#は文法自体が冗長だから短く書いてもたかがしれてるんだよな。
とりあえずPerlとかRubyは糞。
522:デフォルトの名無しさん
09/08/03 18:36:49
冗長にも種類があって、この修正いったい何か所なおしゃいいんだよボケっって冗長タイプは大嫌い
523:デフォルトの名無しさん
09/08/03 18:52:04
特定の人間しか読めないようだとそれはそれで冗長といえる気がする
524:デフォルトの名無しさん
09/08/03 19:00:18
>>498みたいなのはともかく，さすがにラムダが全く分からないのは問題外
525:デフォルトの名無しさん
09/08/03 19:30:49
いつも思うけどこのスレって程度の低い盛り上がり方するよね
ラムダ式なんて書けて当然読めて当然
ラムダ厨も叩いている奴も意識しすぎできもいよ
526:デフォルトの名無しさん
09/08/03 19:37:50
と、>>498が言っております
527:デフォルトの名無しさん
09/08/03 20:08:43
2chブラウザみたいに動的に分割するウインドウって作れるでしょうか？
528:デフォルトの名無しさん
09/08/03 20:17:19
2chブラウザっていろいろない？
529:デフォルトの名無しさん
09/08/03 20:18:54
それよりも
TryってVBじゃねえの
530:デフォルトの名無しさん
09/08/03 20:20:22
どう考えてもjavaだろう
531:デフォルトの名無しさん
09/08/03 20:23:11
いや そこはNullでしょ
532:デフォルトの名無しさん
09/08/03 20:27:53
書けて当然読めて当然濫用も当然
533:デフォルトの名無しさん
09/08/03 20:33:24
俺の書くコードが一番！
お前らの書くコードは二番！
534:デフォルトの名無しさん
09/08/03 20:37:40
1人で書いてる限りは好きなように書いていいよ
535:デフォルトの名無しさん
09/08/03 20:59:43
さんじのおやつはぶんめいどー
536:デフォルトの名無しさん
09/08/03 21:00:33
534 おまえねーじゃますんなよw
537:デフォルトの名無しさん
09/08/03 21:09:53
俺の言った設計通りに動いてくれるならどんな書き方したっていいよ
保守するのはお前らだし
538:デフォルトの名無しさん
09/08/03 21:46:04
>保守するのはお前らだし
そう思ってたころもありました・・・
539:デフォルトの名無しさん
09/08/03 22:39:59
Enum.ToStringはメタデータ検索するから遅くなるって言ってるけど
じゃあEnum.GetNamesとかはどうなの？遅くならんの？
540:デフォルトの名無しさん
09/08/03 22:48:22
ウダウダここに書いてる間に試せると思うんですが…
541:デフォルトの名無しさん
09/08/03 22:49:04
俺とお前じゃ時間単価が違うんだよ
542:デフォルトの名無しさん
09/08/03 22:49:59
GetNamesやGetValuesは中でキャッシュされてるからそんなに遅くない
といっても配列の作成とコピーは毎回行われるので注意
543:デフォルトの名無しさん
09/08/03 22:51:32
ToStringよりはずっと速い。
544:デフォルトの名無しさん
09/08/03 23:14:44
全然関係ないけど、プロパティをリフレクションで取得したりするコードで、
リフレクションは遅いからプロパティ情報をキャッシュするのだ！って言って
DictionaryとかにPropertyInfoやMethodInfoをキャッシュしてるサンプル見るんだけど、
どうせキャッシュするならデリゲートにしとけっつの。
圧倒的に速いしリフレクション特有の問題も起きない。
545:デフォルトの名無しさん
09/08/03 23:29:47
GetMethodとかは中でキャッシュされるからPropertyInfoやMethodInfoを
キャッシュするのはあまり意味がないとかいうのをMSDN Magagineあたりで読んだ覚えがある。
パフォーマンスのためなら>>544の言うようにデリゲートをキャッシュする。
546:545
09/08/03 23:34:54
URLﾘﾝｸ(www.microsoft.com)
あった
547:デフォルトの名無しさん
09/08/03 23:47:28
メンバの検索には結構時間がかかったりもする（条件によってことなる）ので無意味ではないけど
デリゲートをキャッシュする効果に比べたら全く無意味と言っていいレベルだな。
548:デフォルトの名無しさん
09/08/03 23:55:42
>>541
だったらなおさら時間を大事にしろよ。
頭悪いのかね。
549:デフォルトの名無しさん
09/08/04 00:46:07
うん
550:デフォルトの名無しさん
09/08/04 01:20:09
くだらねー
551:デフォルトの名無しさん
09/08/04 01:53:58
うん
552:デフォルトの名無しさん
09/08/04 18:11:07
質問です。
領域を確保したbyte型の配列を以下の関数Funcに渡したいのですが、
どうすればいいのでしょうか？
byte[] bytes = new data[640*480];
Func(????)
void Func(ref byte data){
}
553:デフォルトの名無しさん
09/08/04 18:14:22
int n = 0; //好きな数字を入れてね！
Func(ref bytes[n]);
554:デフォルトの名無しさん
09/08/04 18:14:40
void Func(byte data[]){
}
何でこうなるのか考えてから次に進めよ
555:デフォルトの名無しさん
09/08/04 18:18:01
cじゃねえんだから
void Func(byte[] data)
556:デフォルトの名無しさん
09/08/04 18:26:09
>>553,554,555さん
レス有難う御座います。
この場合、関数の型を以下で定義するべきなのは重々承知しております。
void Func( byte [] data)
ただ、この関数は他社提供のクラスライブラリの為、替えることができません。
これってやっぱり、関数の定義ミスでしょうか？
ちなみに、この関数は某大手電卓メーカの提供しているクラスライブラになります。
557:デフォルトの名無しさん
09/08/04 18:27:03
>>556
それなら使い方をサポートに問い合わせるのが一番だろ
558:デフォルトの名無しさん
09/08/04 18:31:21
>>557さん
恥ずかしながら、保守契約が切れていてけないのです
・・・ちょっと見落としていたけど、553の案で行けそうな気がしてきた
559:デフォルトの名無しさん
09/08/04 18:33:58
553の方法でアクセスできました！！！！！
すいません。 有難うございます。
3時間ぐらいハマってた・・・
皆様有難う御座いました。
560:デフォルトの名無しさん
09/08/04 18:34:14
なんじゃそりゃあ。
561:デフォルトの名無しさん
09/08/04 18:35:35
なんつうライブラリだ・・・・
要は配列の中の1バイトを書き換えるプログラムってことか…？
562:デフォルトの名無しさん
09/08/04 18:37:30
まさかのネタがマジレス
563:デフォルトの名無しさん
09/08/04 18:48:06
ネタじゃないです。
ネイティブコードのラッパライブラリみたいです。
サンプルさえあれば、こんなにハマることは無かったのですが、
本当に助かりました。感謝！！！！
564:デフォルトの名無しさん
09/08/04 18:52:54
中でえげつないことしてそうだなあ
565:デフォルトの名無しさん
09/08/04 18:57:52
なんというか・・・・
これはひどそうな匂いがぷんぷんしてくるな
566:デフォルトの名無しさん
09/08/04 19:26:21
ライブラリの機能や仕様が不明なんだから何とも言えん。
ぱっと見た感じで怪しいのは確かだが。
567:デフォルトの名無しさん
09/08/04 19:36:16
C++ の
void Func(byte* data)
を、C# に持ってくるときに
void Func(byte[] data)
にするべきはずのところを
void Func(ref byte data)
にしただけだと思う
まあわかりやすい間違いだな
568:デフォルトの名無しさん
09/08/04 19:57:55
こんばんわ
文系のプログラムわからないぼくですが
仕事の兼ね合い覚えないといけないことになりました。
やはり先に本をかって進めていったほうがよろしいですか？
569:デフォルトの名無しさん
09/08/04 20:01:21
あたりまえ
いくらPCに詳しくても，プログラミングでは「なんとなく触ってたら使える」というのはありえません
570:デフォルトの名無しさん
09/08/04 20:03:09
>>568
それってC#でなきゃいけないの？
571:デフォルトの名無しさん
09/08/04 20:08:39
>>570
はい、C#で開発なんで
それでないといけないと思います。
本で初心者用って書いてあればなんでも平気ですかね。
572:デフォルトの名無しさん
09/08/04 20:10:16
C# とだけ書いてある本ではなく，Visual C# と書いてある本を選びましょう。
いきなり前者に挑むと挫折します。
573:デフォルトの名無しさん
09/08/04 20:12:58
しかし門外漢を使おうなんて余程手が足りないのね
ここからが本当の地獄だ
574:デフォルトの名無しさん
09/08/04 20:17:23
>>572
助かります。
2種類あったのか・・・
visualstudio2005を使うんですが、C#って書いてあったようなきがしたけど
visualC#ってことでいいのでしょうか？
575:デフォルトの名無しさん
09/08/04 20:22:36
VisualStudio2005は複数のプログラミング言語が使える。
その中でC#を使うならVisualC#2005を使うことになる。
二種類あるっていうのは，例えるなら>>572の前者は英文法の本，後者は英会話の本だ。
576:デフォルトの名無しさん
09/08/04 20:23:44
>>575
なんと・・・・
VisualC#で探します、ほんと助かりました。
前者後者で差が結構ありますね￥・・
577:デフォルトの名無しさん
09/08/04 20:30:01
>>574
プログラミング未経験者がいきなり本で独学でC#とか俺は無謀だと思う。
特別地頭がいいなら別だけど。
こういうスレの連中は変な見栄と気取りがあるから認めないと思うけどねw
いきなりC#でも人に直接教えて貰えばなんとかなるかもしれんけど、
そういう訳にいかんのかな。
578:デフォルトの名無しさん
09/08/04 20:30:59
だから地獄の始まりだと言ってるだろ
579:デフォルトの名無しさん
09/08/04 20:32:57
>>577
うちの会社教えてくれる人いないんですよ・・・
これやってねって言った人も始めてだし。
今まで仕事・・・まぁ新入社員だけど
プログラミング教えてもらったことなど一度もないんです。
本渡されてどうぞ？しかないです。
580:デフォルトの名無しさん
09/08/04 20:37:02
まあとりあえず触ってみりゃいいんじゃない
「VisualC#入門」みたいな本買ってきて一通り打ち込んで動かしてみてそれからだな
プログラミング自体に興味が持てれば次は文法の本に行けばいいし無理ならキャリアスクールへどうぞ
581:デフォルトの名無しさん
09/08/04 20:45:10
そのレベルの初心者なら、最初は研修に行かせてもらったほうが早いんだけどな。
最初は入門書は定番の有名なのより、
手取り足取りタイプの超入門書を２～３冊読み漁るのがいい。
物足りなくなったら定番に移行。
582:デフォルトの名無しさん
09/08/04 20:55:54
>>577
C#が無謀なら何ならいいの？
583:デフォルトの名無しさん
09/08/04 20:56:17
研修とかスクールって行った事ないけど意味あるの？
実際に仕事したことのない講師が教えてそうで怖いわ。
584:デフォルトの名無しさん
09/08/04 21:10:35
研修とかプログラム受けると
お金になるとききました
（経理的な意味で）
585:デフォルトの名無しさん
09/08/04 21:34:40
URLﾘﾝｸ(msdn.microsoft.com)
＞複数の単語で構成されるパブリック メンバ、型、および名前空間の名前には、常に Pascal 形式を使用してください。
ってあるけどプライベートなメンバの命名規則はどこにあるの？
586:デフォルトの名無しさん
09/08/04 21:35:54
公式には原則自由
それ「クラスライブラリ開発者向け」のガイドラインだからアセンブリの外から見えないメンバについては
どうでもいいの
587:デフォルトの名無しさん
09/08/04 21:37:02
すばやい返答ありがとう
588:デフォルトの名無しさん
09/08/04 21:49:37
ちなみに非推奨のアンダーバー始まりを使ってます。
589:デフォルトの名無しさん
09/08/04 21:52:15
Cじゃないんだから取り立てて禁止というわけじゃないよ。
590:デフォルトの名無しさん
09/08/04 21:55:53
むしろMSが公開してるC#で書かれたコードでは _camelCase が多数派
591:デフォルトの名無しさん
09/08/04 22:29:41
C#って結構とっつきやすい方だと思うんだけどなぁ。
592:デフォルトの名無しさん
09/08/04 22:32:20
他の言語の経験がある人にはね
もともとそういうコンセプト
593:デフォルトの名無しさん
09/08/04 22:38:09
他の言語使ったことないと結構きつい気がするよ
594:デフォルトの名無しさん
09/08/04 22:40:13
他のってCとjavaだけだろ。
595:デフォルトの名無しさん
09/08/04 23:07:54
delphiから移行したけど結構簡単だった
596:デフォルトの名無しさん
09/08/04 23:09:54
delphi とは腹違いの兄弟みたいなものだからなぁ
597:デフォルトの名無しさん
09/08/04 23:12:02
>>590
そうなんだけど非推奨なんだよｗ
598:デフォルトの名無しさん
09/08/04 23:16:02
ああ・・・種は一緒だからな
確かに腹違いだ
599:デフォルトの名無しさん
09/08/04 23:18:45
お下品。
600:デフォルトの名無しさん
09/08/04 23:32:40
他の言語の経験なんているか？
どの辺が？
601:デフォルトの名無しさん
09/08/04 23:42:45
>>600
誰に向かって反論してるわけ？
「どの辺」にそんなこと書いてあるの？
どうでもいいけど、こんなちっちゃいことで自分を大きく見せたい奴は
大概その意図に反して無能な奴だわな。
602:デフォルトの名無しさん
09/08/04 23:46:25
C/C++やってた俺には最初ヘッダが無いのが気持ち悪くて仕方なかった
603:デフォルトの名無しさん
09/08/04 23:47:37
>>597
非推奨と書いてある箇所は何処でしたっけ？MSDNみてるけど出てこない。
604:デフォルトの名無しさん
09/08/04 23:48:08
#defineが無くて幸せ
605:デフォルトの名無しさん
09/08/04 23:49:24
マクロには使えないが一応あったような。#define
606:デフォルトの名無しさん
09/08/04 23:49:36
あ、#defineマクロのことな
607:デフォルトの名無しさん
09/08/04 23:59:12
条件付きコンパイルはもうちょっと言語を壊さない形で実現できなかったのかな
conditional (DEBUG) { }とか
608:デフォルトの名無しさん
09/08/04 23:59:40
プリプロセスを無くすのはいいが、ファイルのインクルードまで無くしたせいで
条件付コンパイルがやり難くてしょうがないと思うんだけど。
とくに条件が複数のプロジェクトを横断的に規定するようなものだった場合。
609:デフォルトの名無しさん
09/08/05 00:02:52
>>601
うわっ、キモっ
610:デフォルトの名無しさん
09/08/05 00:03:40
>>579
悪いことは言わん。明日の退社後にでも、夜でもやってるパソコン教室へ、せめて1日(2時間)だけでも行ってこい。
最低限のとっかかりがないと、参考書のコードをそのまま入力するのも大変だろうし、ぐぐることもできんはず。
つーか、俺を雇ってくれよ…
611:デフォルトの名無しさん
09/08/05 00:09:54
なんか変な妄想ふくらませてるのがいるなｗ
習得に相当時間がかかったのだろうか。
612:デフォルトの名無しさん
09/08/05 00:12:26
>>610
悪いことは言わん。明日の朝にでも職安へ行ってこい。
613:デフォルトの名無しさん
09/08/05 01:17:30
>>568
明日の朝、退職願出して、ハローワークに行って、事務か介護か土方の仕事探しな。
お前みたいな奴が居ると迷惑だ。
614:デフォルトの名無しさん
09/08/05 06:32:24
>>603
URLﾘﾝｸ(msdn.microsoft.com)
アンダースコア (_) やハイフン (-) など、英数字以外の文字は使用しないでください。
ハンガリー表記法は使用しないでください。
読み直したらこれはプロパティのことだけに言ってるのか一般的なことに言ってるのかがわからんようになった。
615:デフォルトの名無しさん
09/08/05 07:25:28
>>614
>>586の見解で正しいと思う。
自メンバーのアクセスには全部this.つけろより、
前か後ろにアンダーバーのほうが好みだ。
616:デフォルトの名無しさん
09/08/05 08:43:36
日本語使ってるコード見たことあるな
617:デフォルトの名無しさん
09/08/05 09:27:46
○○○○○○ToolStripMenuItem_Click(object sender, EventArgs e)
これの前に日本語つくよねｗ
618:デフォルトの名無しさん
09/08/05 09:42:06
インテリセンスの都合で、後ろに _ の方が好き。
アンダーバーってキーボードの位置的に押しづらくて、先頭に持ってきたくない。
619:デフォルトの名無しさん
09/08/05 09:46:47
private readonly stringのメンバー変数名って大文字から始まるの？
620:デフォルトの名無しさん
09/08/05 09:58:36
privateは好きにしろと何度も出てるだろ
621:デフォルトの名無しさん
09/08/05 10:18:09
今はC#だからメソッド名とか大文字にしてるけどF#始めるから小文字になる予感。
そのあとC#使うときはどっちになるんだか･･･
622:デフォルトの名無しさん
09/08/05 10:24:36
正直どうでもいいな。
623:デフォルトの名無しさん
09/08/05 10:25:16
F#ってC#と比べてどんなメリットあるの？
624:デフォルトの名無しさん
09/08/05 10:54:16
>>617
エンティティフレームワークなんて、Hogesってテーブルがあったらデフォルトで
エンティティ=Hoges
エンティティセット=Hoges設定
だぜ。
625:デフォルトの名無しさん
09/08/05 11:12:59
ﾜﾛﾀ
626:デフォルトの名無しさん
09/08/05 12:05:34
プログラミングで初めての言語が C# だとクラスとか
よくわからないままになるかもしれないかな。
C++ から入るとあまり問題にならないような気がする。
627:デフォルトの名無しさん
09/08/05 12:08:04
C++こそクラスから逃げられないと思うんだが…
628:デフォルトの名無しさん
09/08/05 12:18:26
C# をはじめてのプログラミング言語にすると Main メソッドをもつクラスの意味がわかりづらい。
いきなりおまじないから始まるのはちょっと考えもの。
629:デフォルトの名無しさん
09/08/05 12:30:56
>>627
逃げられないからこそよくわからないままでいられないってことでしょ？
630:デフォルトの名無しさん
09/08/05 12:51:18
クラス設計が難しい
631:デフォルトの名無しさん
09/08/05 14:33:24
>>608
プリプロセスのうちヤバイとされる物の一つだからそりゃなくなるだろ。
また、define の方は、Conditional アトリビュートを使えとのいうがC#流。
これによって、マクロ機能等をライブラリ化する時に捨てず、きっちりdllまで維持して再コンパイル等を防止している。
632:デフォルトの名無しさん
09/08/05 15:14:12
ファイル横断的にやりたいなら、
csc /define:HOGE ... やMSBUILDのスクリプトで指定するのが原則。
633:デフォルトの名無しさん
09/08/05 17:17:09
C#でのスレッドセーフなプログラミングに関する簡単な質問なんですが
あるクラスインスタンスの値を取得する部分
work = myClass;
と、クラスインスタンスの参照をセットする部分
myClass = new MyClass();
これってそれぞれクリティカルセクション化しないとまずいですか？
内部で何をやっているのか分からず不安なんですが、何でもかんでもlockするのは嫌なので…
また、intなどの値型でも同じことが言えるんでしょうか。お願いします。
634:デフォルトの名無しさん
09/08/05 17:57:08
前提が抜けすぎてて答えようがない。もう少しシナリオをしっかり書こうよ。
635:デフォルトの名無しさん
09/08/05 18:42:23
そこだけをロックしなけりゃならないことはあまりない
636:デフォルトの名無しさん
09/08/05 18:50:18
念のため、なんでもかんでもロックしたところでそれでもスレッドセーフになるわけじゃないぜ
637:デフォルトの名無しさん
09/08/05 18:59:04
普通は想定される複数スレッドからの使われ方というのがあって、
その時にどのように動作させるという設計があって、
その上で内部のデータや動作が不正にならないための条件を導いて、
それを壊さないようにロックなどで保護するんだよ。
だから何の前提もなくただスレッドセーフなんてのはない。
638:デフォルトの名無しさん
09/08/05 21:49:32
// どちらが実行されるでしょうか？
bool a = true, b = false, c = true;
if ((a = b == c) == (a == b == c))
d();
else
e();
639:デフォルトの名無しさん
09/08/05 21:53:46
ｄ
640:デフォルトの名無しさん
09/08/05 21:53:47
宿題か？
641:デフォルトの名無しさん
09/08/05 21:55:20
貼りつければ分かるから宿題じゃないです
クイズです
642:デフォルトの名無しさん
09/08/05 21:58:15
不適切な問題じゃね
演算子の優先順を問う感じだろうけど=と==をどっち優先にしてもdになる気がする
643:デフォルトの名無しさん
09/08/05 22:01:08
d?
644:デフォルトの名無しさん
09/08/05 22:03:05
>>642
(a = t == f) == (f == t == f)
(a = f) == (f == t)
(f) == (f)
t
(a = t == f) == (f == t == f)
(t == f) == (f == t)
(f) == (f)
t
ホントだｗ
645:デフォルトの名無しさん
09/08/05 22:17:53
あほやのう
646:デフォルトの名無しさん
09/08/05 22:26:34
>>644
(f == t == f) が (f == t) ？
なんで？
647:デフォルトの名無しさん
09/08/05 22:33:06
安産してeだと思った15年目の俺･･･orz
基本的に優先順位とか気にしたくないのでかっこでくくってますが( ﾟДﾟ)ﾅﾆｶ?
648:デフォルトの名無しさん
09/08/05 22:34:56
なんだろうねぇ
649:デフォルトの名無しさん
09/08/05 22:39:14
なにいってんの？
eだろ
650:デフォルトの名無しさん
09/08/05 22:53:01
>>644
(f == t == f) の出所は？
651:デフォルトの名無しさん
09/08/05 23:18:16
(a = b == c) == (a == b == c)
=> (a = (F == T)) == (a == b == c)
=> (a = F) == (a == b == c)
=> F == (F == (F == T))
=> F == (F == F)
=> F == T
=> F
なので e が正解
652:デフォルトの名無しさん
09/08/05 23:21:37
==演算子って左結合じゃなかった？
653:デフォルトの名無しさん
09/08/05 23:28:05
>>651
まて結合の優先順位と、実行される順序は別だ。
(a = b == c) == (a == b == c)
=> (a = (F == T)) == (a == b == c)
=> (a = F) == (a == b == c)
1)
=> F == (F == (F == T))
=> F == (F == F)
=> F == T
=> F
2)
=> (a = F) == (T == (F == T))
=> (a = F) == (T == F)
=> F == F
=> T
654:デフォルトの名無しさん
09/08/05 23:32:29
大漁ですな(；´Д｀)
655:デフォルトの名無しさん
09/08/05 23:34:36
式は右辺からと思っていると、
(a = b == c) == (a == b == c)
-> X == Y
の右辺Yからやることになり、地獄行きになるんです
656:デフォルトの名無しさん
09/08/06 00:13:44
(==)((a = b == c), (a == b == c))
657:651
09/08/06 03:03:09
>>652
すまん4行目は F == ((F == F) == T) だな。
結果は一緒。
URLﾘﾝｸ(msdn.microsoft.com)(VS.71).aspx
658:633
09/08/06 09:04:57
>>634-637
遅くなってすみません。
たとえば、スレッドAとスレッドBで変数myClassを共有している
スレッドAでは、myClassに新規インスタンスをセットする
while( 1 )
{
myClass = new MyClass();
}
スレッドBでは、myClassを作業用変数に確保し、さまざまな処理を実行する
while( 1 )
{
MyClass work = myClass;
workに対しての様々な処理
}
代入演算子はオーバーロードしていません
ちょっと何をやりたいかわかりにくいかもしれませんが、これだけを見た場合に問題はありそうですか？
内部的に参照カウント関係の処理が走っていたりして、危険だったりしますか？お願いします。
659:デフォルトの名無しさん
09/08/06 09:10:07
ダメダメ絶対ダメ
スレッドBのループが一回回る間にスレッドAのループが何回回るか全く分からないんだよ?
それにいくらメモリを意識しなくていいといったってさすがにノーウェイトでnewしまくったらGCの負担になる
660:デフォルトの名無しさん
09/08/06 09:21:04
スレッドAとスレッドBの周回数は同期がとれていなくていいです
GCの負荷は考慮しないとして、スレッドセーフかっていう質問なんですが・・・
要するに
myClass = new MyClass();
と
MyClass work = myClass;
のところをロックしないとメモリを壊したりしますか？ってことが聞きたいんです
C言語なら問題無いはずですがC#だとどうなのかな？って
>>635 の言うようにこれ自体はロックしなくても問題ないんですかね＾＾；
661:デフォルトの名無しさん
09/08/06 09:28:22
ｍｙClassが共有されてると言うことでおけー？
ロックされる云々の前に多分それ意図してるように動かないよ。エスパーしてみるとｗ
662:デフォルトの名無しさん
09/08/06 09:29:44
必ずしも間違った扱いではないけど問題あるかどうかは別だな
AでMyClassのコンストラクタが呼ばれた後に，Bで古いインスタンスが使われる可能性はある
663:デフォルトの名無しさん
09/08/06 09:32:02
ロックするならスレッドBの書かれてない処理のところじゃね？
664:デフォルトの名無しさん
09/08/06 09:36:37
参照やintへのアクセスはアトミックと規定されている。
つまり、myClassが32bitだとすると16bitだけ新しい値に書き換わってるという状態は存在しない。
一方doubleやlongはそういう状態が発生しえる。
ただしマルチCPUの場合はもう少しややこしくて、
スレッドAが書き換えたmyClassの内容がスレッドBに反映するまでにタイムラグが発生する場合がある。
これが問題になるならlockを使用するかmyClassをvolatileで宣言する。
Cのvolatileとの違いに注意。
665:デフォルトの名無しさん
09/08/06 09:44:52
あと、C#のGCは参照カウントじゃないよ。
666:デフォルトの名無しさん
09/08/06 09:58:55
ま、確実性という意味なら、volatileつけとけば確実。
ただしなくてもメモリが壊れるとかのレベルの問題はない。
実質的にはCLR2.0以降のメモリモデルと86系CPUのメモリモデルから、
事実上はvolatileなくても問題ないはず。
667:デフォルトの名無しさん
09/08/06 10:02:26
あ、確実というのは、可能な限り最新のインスタンスを使うという意味でね。
668:デフォルトの名無しさん
09/08/06 10:13:30
Interlocked.Exchangeでも使えば
669:デフォルトの名無しさん
09/08/06 10:40:47
volatileを使わない場合はもうひとつ問題があって、
MyClassの初期化が終わる前にスレッドBに参照が渡ってしまう可能性がある。
ただし、これが起きるのはMSだとItatiumの場合だけ。
原理的には有名なダブルチェックロッキング問題と同じ。
myClassをvolatileにしない場合のスレッドA
while( true ){
MyClass tmp = new MyClass();
Thread.MemoryBarrier();
myClass = tmp;
}
670:デフォルトの名無しさん
09/08/06 11:15:28
おまいら詳しいのな
671:デフォルトの名無しさん
09/08/06 11:20:35
それもCLR2.0以降では大丈夫でそ。
ついでにその問題を出すなら、Aのメモリバリアだけじゃだめ。
なぜなら、Bスレッドのワーク変数が目的通りに動かないから。
ワーク変数への各アクセスで、新しい参照を読んでしまう危険がある。
かなり直感に反する動作だと思うけど。
結局この場合もvolatileつけるのが最も簡単確実。
672:デフォルトの名無しさん
09/08/06 11:58:19
>>671
いや大丈夫でないから.NET2.0で.MemoryBarrier()が追加になってるわけで。
myClassからworkの参照コピーは１回限りのようだから問題ない。
work変数はローカルなんだし、
MyClassはスレッドAでセットしたあとは放置状態なのだから、
途中で新しい参照を読み込むことはありえない。
workは一貫したクラスを参照できてれば、MyClassのバージョンは問わないという前提だよ。
673:デフォルトの名無しさん
09/08/06 12:00:37
Ｃ＃ 2.0で質問です。
List<int> _list = new List<int>();
//(本当はintではなくクラスなんですが説明しやすいようにintで・・・)
_list.Add(1);
_list.Add(2);
_list.Add(3);
_list.Add(4);
_list.Add(5);
foreach(int data in _list)
{
Console.WriteLine(data);
}
このような感じで記述した時に
List<int>はインデックス0からデータを順番に必ず返すのでしょうか？
やってみた感じ必ず返っては来ているようなんですが、保障されているというような感じの文章がヘルプから探せなかったので質問させていただきました。
よろしくお願いいたします。
コレクションやソーテッドリストなんかはその並び順は勝手に変わるようですがListオブジェクトはどうもみあたらない・・・orz
674:デフォルトの名無しさん
09/08/06 12:11:22
foreach が配列の要素を走査する順序は、次のように定義されます。
1 次元配列の場合、要素はインデックス 0 から始まってインデックス Length ? 1 で終わるインデックスの昇順に走査されます。
多次元配列の場合、要素は、最初に右端の次元のインデックスが増加し、次にその左側の次元のインデックスが増加し、さらにその左側の次元のインデックスが増加する、というように走査されます。
675:デフォルトの名無しさん
09/08/06 12:37:54
>>674
int のコレクションとして考えれば0～インデックスの最後までの順序で処理される
それでもってListコレクションの中身も同じように処理されるということでしょうか？
ということであればすっきり処理を続けることができます。
ありがとうございました！
676:デフォルトの名無しさん
09/08/06 13:09:05
>>672
違うよ。
メモリバリアはCLIの標準仕様では必要。
CLR2.0以降の実装では不要だとしても、互換性の為には必要になる。
だからある。
あとソースコード上はワーク変数に1回だけ取得してても、
実際にはワーク変数を削除して毎回実体にアクセスするという、
直感的でない最適化が行われる可能性があるんだよ。
共有してる変数をvolatileにすればそれを防げる。
677:デフォルトの名無しさん
09/08/06 13:11:03
この辺はいつだったかのMSDNマガジンに詳しく書かれてる。
678:デフォルトの名無しさん
09/08/06 14:05:33
>>676
ありがと、勉強になった。MSDNマガジンで確かに見た気がするがスルーしてた。
679:デフォルトの名無しさん
09/08/06 14:46:29
ごめんもう一つ補足。
CLR2.0以降では書き込みアクセスでのvolatileは事実上不要だけど、
読み取りでは必要な可能性もあったと思う。
書き込み順序と回数はデフォルトでvolatileのように保証されるが、
読み込みは場合によっては省略されることがある。
ただ、その他諸々の事情により、実際に問題が出るパターンはあまりなかったと思う。
680:デフォルトの名無しさん
09/08/06 17:20:59
C#からUnmanaged-DLLを利用する場合についての質問です。
DLL側でThread Local Strage(__declspec(thread)を付けた静的変数)を使用し
ている場合、(DLL内の関数がC#から呼び出され)DLL内でこれにアクセスしよう
とした時にSystem.AccessViolationExceptionになるようです。(エラー画面.PNG)
DLL側を修正せずに、C#側の修正もしくは他の手段でこれを回避する方法はあ
りませんでしょうか？
URLﾘﾝｸ(www1.axfc.net)
は問題を再現する簡単なコード例です。
Test\MyDll\MyDll.cpp の18行目が__declspec(thread)を付けた静的変数で、
これを、N:\Test\MyCSApp\Program.cs の29行目から呼び出されたMyFunc(5)の
処理でszMyLastErrorにエラー情報をセットするところで例外が発生します。
Test\MyC++App は同じ処理をC++で記述した場合で、これは問題なく動作しま
す。
以上、よろしくお願いいたします。
681:デフォルトの名無しさん
09/08/06 17:43:07
>>680
URLﾘﾝｸ(msdn.microsoft.com)(VS.80).aspx
の一番下
682:デフォルトの名無しさん
09/08/06 17:57:52
C++/CLIあたりでlibを使ってラッパ作れば何とかなるかもね
683:デフォルトの名無しさん
09/08/06 21:44:03
レスありがとうございます。
>>681
症状からして、そのページに書かれていることが起きている(C#はDLLを動的にローディングしている)
のだろうな、とは思っていたのですが、それを回避する方法がなにかあるのではないかと質問させてい
ただきました。
>>682
MangedなラッパDLLを作成し、これにMyDll.libをリンクしてみましたが、ラッパDLLがC#アプリからは
動的にローディングためか結局ダメでした。
何か、裏技がありませんかねえ？？
684:デフォルトの名無しさん
09/08/06 21:52:25
別 Exe にしてプロセス間通信するしかないだろ。
685:デフォルトの名無しさん
09/08/06 21:57:02
C++/CLIから起動してC#側を動的ロードするとか
686:デフォルトの名無しさん
09/08/06 22:23:54
DLLのほうを触っていいならTlsAllocを使えばいいはずだけど。
687:デフォルトの名無しさん
09/08/06 23:40:08
COMのアウトプロセスサーバーでラップすると何とかなりそうだが、
激しくめんどい。
インプロセスサーバーだと駄目だった。
688:デフォルトの名無しさん
09/08/07 02:56:45
一番現実的なのは>>685だろうな
マネージ側は参照だけでいいんで動的ロードとか言わんけど
689:デフォルトの名無しさん
09/08/07 08:47:30
.NETのWindowsアプリケーションで作成したプログラムにおいて、
ネットワークPCのドライブにあるフォルダをアクセスしようとした時、
たまたまそのPCが立ち上がっていなくてネットワーク上に見つからない
場合に長く待たされていました。このタイムアウト時間はたぶんＯＳ
の設定で変えられるものとは思うのですが、タイムアウトにならない
うちにプログラムでアクセスを中断してしまうことは可能でしょうか？
690:デフォルトの名無しさん
09/08/07 10:09:55
C#でパケットキャプチャしたいのですが、サンプルありますか？
691:デフォルトの名無しさん
09/08/07 10:18:07
URLﾘﾝｸ(www.stackasterisk.jp)
URLﾘﾝｸ(sourceforge.net)
692:デフォルトの名無しさん
09/08/07 11:42:39
>>691
ども、でもなんかよくわからないです
エラー 2 型または名前空間名 'NetDefineSet' は名前空間 'StackAsterisk' に存在しません。アセンブリ参照が不足しています。
とか
693:デフォルトの名無しさん
09/08/07 12:04:49
お前にはまだ早いということだね
694:デフォルトの名無しさん
09/08/07 12:16:19
>>689
別スレッドでチェックしに行って適当にタイムアウトとかできるんじゃ？
695:デフォルトの名無しさん
09/08/07 13:22:57
>>692
そういやなんかサンプルそのままじゃビルドできなかった記憶があるな
>The Code Projectによいサンプルがあったので拝借させていただき、それを元に書いてみました。
>元となったのは 「RawSocket Class-Create Network Monitoring (Packet Sniffing) Apps」 というものです。
って書いてあるしそっちも参考にするといい
696:デフォルトの名無しさん
09/08/07 14:39:34
スレッド分けるのに一票
697:デフォルトの名無しさん
09/08/07 14:49:45
Process.Start()で存在しないフォルダを起動したら、FileNotFoundExceptionじゃなくてSystem.ComponentModel.Win32Exceptionというのが来る
Frameworkが吸収するところじゃないのか
698:デフォルトの名無しさん
09/08/07 15:34:45
あなたはそれがいいと思うかもしれないが、
大多数の他人はそう思わない
699:デフォルトの名無しさん
09/08/07 16:48:15
いやそうでもない
700:デフォルトの名無しさん
09/08/07 16:59:52
Frameworkが吸収すべき所のような気がするけど
実害は無いからとやかく言わない
701:デフォルトの名無しさん
09/08/07 17:06:23
>>697
つうかふつうに固まるだろ・・・・
問題はみに行く時に固まるつうのが問題なわけで
なにかボタン押したときにチェック
↓
チェック中ですのダイアログ的なものと共に強制キャンセルボタン
↓
チェック開始（バックグラウンドワーカーでもなんでも）
↓
バックグラウンド終了前にキャンセルされたら
ナックグラウンドワーカー停止
こんなんでいいんじゃね？
成功のときはバックグラウンドの完了イベントかなんかで処理するとか
色々あると思うけど
702:デフォルトの名無しさん
09/08/07 17:25:47
Microsoftの決めたことなんだから正しいお
703:デフォルトの名無しさん
09/08/07 18:37:58
>>697
吸収してどうしろって？
別プロセスからの例外をプロセス間通信で受け取るの？
それをフレームワークでやれって？
704:デフォルトの名無しさん
09/08/07 19:01:23
なん…だと…
705:デフォルトの名無しさん
09/08/07 20:19:40
Windowsフォームで質問。
Form2 _form2 = new Form2(_form1);
としたとき、_form2.FormClosedのイベントハンドラで_form1.Close()するコードを書くと、
Form2.OnFormClosed()が何度も呼ばれる（つまりFormClosedイベントが何度も発生する）
ようなんだけど、これは仕様？バグ？
仕様だとしたらどう理解したらいいんだろう？
706:デフォルトの名無しさん
09/08/07 20:25:45
OwnerはCloseするときOwnedFormsを全部Closeする
って言えば分かる？
707:デフォルトの名無しさん
09/08/07 20:34:10
>>706
そのレベルの話はOK
708:デフォルトの名無しさん
09/08/07 20:53:58
普通に再帰呼び出しになってるだけっしょ
止まるのはハンドルが消えるから
709:デフォルトの名無しさん
09/08/07 20:59:15
>>708
現象の説明としてはそれでいいと思うんだけど、
俺が聞きたいのはそういうことじゃなくて、それが仕様なのか、
仕様だとしてそれに何らかの意味があるのかってこと。
FormClosedイベントの意味は、「Close()が呼ばれました」ではないはずだよね。
710:デフォルトの名無しさん
09/08/07 21:06:03
> FormClosed イベントは、ユーザー、Close メソッド、または Application クラスの Exit メソッドによって
> フォームが閉じられた後に発生します。
「Form.Closeが呼ばれました」でも大体いいんじゃないかな
ま、おいらはMSの人じゃないので意味とか答えられないけど
711:デフォルトの名無しさん
09/08/07 21:09:46
>>710
それはさすがに読解力マズいんじゃないかと思うけど。。
712:デフォルトの名無しさん
09/08/07 21:50:30
何度も呼ばれるって何度？
713:デフォルトの名無しさん
09/08/07 21:52:55
バグだよ、>>705のプログラムのね
714:デフォルトの名無しさん
09/08/07 21:55:57
Closed≠Disposedと理解すれば良い
715:デフォルトの名無しさん
09/08/07 22:07:36
>>710-711
MSDNの説明から読み取れるのは
・ユーザ操作、Close()、Application.Exit()で発生しうる
・FormClosedが発生した時点ではフォームは閉じられている
の2点だけじゃね？
てか、説明が怪しいと感じたら英語版を読むといい
それでも怪しいときも多いけどな
716:デフォルトの名無しさん
09/08/07 22:20:48
ちなみに何回くらい呼ばれるの？
また毎回同じ回数なのか場合によって変わるのかどんな感じ？