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

C#, C♯, C＃相談室 P ..

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#で探します、ほんと助かりました。

前者後者で差が結構ありますね￥・・

次ページ