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

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

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
ちなみに何回くらい呼ばれるの？
また毎回同じ回数なのか場合によって変わるのかどんな感じ？

717:デフォルトの名無しさん
09/08/07 22:33:34
>>716
以下が問題を再現する最短のコード。
コンストラクタは省略してある。

public partial class Form1 : Form
{
　　Form2 _form2;

　　protected override void OnLoad(EventArgs e)
　　{
　　　　base.OnLoad(e);
　　　　_form2 = new Form2();
　　　　_form2.FormClosed += new FormClosedEventHandler(_form2_FormClosed);
　　　　_form2.Show(this);
　　}

　　void _form2_FormClosed(object sender, FormClosedEventArgs e)
　　{
　　　　Close();
　　}
}

public partial class Form2 : Form
{
　　int _count = 0;
　　protected override void OnFormClosed(FormClosedEventArgs e)
　　{
　　　　base.OnFormClosed(e);
　　　　Console.WriteLine("Form2.OnFormClosed Called ! // count = {0}", _count++);
　　}
}

718:デフォルトの名無しさん
09/08/07 22:53:53
>>717
とりあえずDisposedイベントでForm1.Closeやるように変更したら
現象回避出来たぞ

719:デフォルトの名無しさん
09/08/07 23:00:06
>>718
うん、それはわかるけど、
俺が知りたいのはこういうコードを書くと「何故」そんなことになってしまうか、なんだ。

普通に考えれば、OnFormClosedが何度も呼ばれるのは理解に苦しむと思うんだが。

720:デフォルトの名無しさん
09/08/07 23:00:45
Form2ClosedでForm1Closeして新しいClosedが発生するのがおかしいと言ってるの？
何がおかしいのかよくわからない

721:デフォルトの名無しさん
09/08/07 23:02:44
>>719

まあ所持関係にあるForm同士として呼び出してるんだから
＞　　　　_form2.Show(this);

Form1閉じる→Form2閉じる
っていうのは標準動作として組み込まれてる

逆方向の動きを追加したい場合(Form2閉じる→Form1閉じる)は
標準の動作と競合しないようにしなきゃ不具合が起きて当たり前

FormClosed()の時点ではForm同士の所持関係を破棄していないようなので
無限ループが起きる
Disposed()の時点でForm同士の所持関係を破棄しきったので
やりたい動作が実現できる

722:デフォルトの名無しさん
09/08/07 23:07:42
FormClosedイベントなんだから、「完全にフォームが閉じた後」に発生しないとおかしい
と言いたい訳か。
んで_form2が完全に閉じた後だから、_form2_FormClosedが呼ばれても子フォームのCloseが呼ばれるのはおかしい、と

723:デフォルトの名無しさん
09/08/07 23:15:06
Close()をこうやって呼べばいけるっちゃいける。
this.BeginInvoke((MethodInvoker)　(()　=>　Close()));

親フォームが子フォームを閉じるための参照のコレクションを持ってて、
親フォームから登録を抹消するタイミングがFormClosedの後なんだろうな。

724:デフォルトの名無しさん
09/08/07 23:16:44
>>722
＞_form2が完全に閉じた後だから、_form2_FormClosedが呼ばれても子フォームのCloseが呼ばれるのはおかしい、と
いや、そこは必ずしもそうは思わないけど、>>717のコードの動作が「おかしい」と思う点は、
何度も言うけどOnFormClosedの呼ばれ方が、MSDNに書かれたFormClosedイベントの仕様に
反するように思える点。

725:デフォルトの名無しさん
09/08/07 23:17:10
>>723
なんかそれタイミング次第で
うまく行ったり例外おきたり
危険な動作しそうな気がする

726:デフォルトの名無しさん
09/08/07 23:18:43
例えば、Form.Show()は何度でも呼べるけど、
その都度Shownイベントが発生したりはしないよね。

727:デフォルトの名無しさん
09/08/07 23:19:47
>>724
Formのオーナーシップの関係で
Formクラスから子FormのCloseが呼び出されるってことでしょ
何も反してないよ

728:デフォルトの名無しさん
09/08/07 23:23:40
>>727
だから、FormClosedイベントの意味、つまり仕様は、「Closeメソッドが呼ばれました」
ではないよね。少なくともMSDNライブラリを詠む限り、そうは読み取れない。

729:デフォルトの名無しさん
09/08/08 00:26:58
お前が明示的に呼んだときしかCloseメソッドが呼ばれないと思ってるということか

730:デフォルトの名無しさん
09/08/08 00:37:46
>>729
こんなこと言いたくないが、馬鹿はすっこんでてくれよ。
二重の意味で日本語も読めないのかまったく……

731:デフォルトの名無しさん
09/08/08 00:40:59
>>730
どう見てもお前の方が馬鹿だが

732:デフォルトの名無しさん
09/08/08 00:41:33
むしろMSDライブラリを読み取れないレベルの馬鹿がやめた方がいい
お話になりません

733:デフォルトの名無しさん
09/08/08 00:59:09
横やりだが>>728とかの言ってることは別にそんなおかしくないぞ。
Closeを何度呼ぼうが、実際に閉じたタイミングで一度だけ発生する
と期待するのは普通の感覚。
MSDNの説明も普通に読めばそうだと期待する。

一度しか呼ばれない、とは明記されてないし結局仕様なんだろうとは思うけど。

734:デフォルトの名無しさん
09/08/08 01:05:38
1度テストしてみて理解できないようなら方法は無い

735:デフォルトの名無しさん
09/08/08 01:14:25
MSDNのクラスのドキュメントって
クラス単体の動作を説明してるのが基本であって
フレームワークの中でそのクラスがどう扱われてるかは
オマケ程度にしか説明されていない

っていうことをわかって無いから的外れなこと言い出すんだよね

736:デフォルトの名無しさん
09/08/08 01:28:44
>>735
ほほう、「的外れ」とは？
具体的に何がどう「的外れ」だ、と？

いや、無理しなくていいよ。
そんな自分の頭で理解していることを表現しているとは思えない、
悪いけど意味不明な文章を書いているようじゃたぶん正面からの回答は無理だと思うから。

しかし、別に初心者が悪いと思わんけど（誰だって最初はそうだし）
知りもしないことに口出しして挙句に相手をいきなり罵倒する奴っていうのは
迷惑以外の何者でもないな本当。

初心者どころか自分でイベントを生成するコードすら書いたことすらないのが、
言っちゃ悪いがミエミエなのに。
まあそれ以前に日本語もまともに読めていないようだけどw

2chでこんなこと言ってみても仕方ないのは分かっているが、あまりに腹が立ったのでね。

737:デフォルトの名無しさん
09/08/08 03:20:05
ここでクダ巻いててもしょーもねーだろｗ

738:デフォルトの名無しさん
09/08/08 04:57:36
長文書いたら負けですよ

739:デフォルトの名無しさん
09/08/08 06:37:29
閉じられる理由位見ろ
_form2_FormClosed() の処理が
if (e.CloseReason == CloseReason.UserClosing)
　　Close();
じゃないの点が問題なんだよ

何度も Form2 に FormClosed が送られてくるのも
あくまでも Form2.FormClosed イベントが終了していない段階で
Form1 を改めて閉じようとしているからループしてるに決まってるだろ

ユーザ操作以外ではどうせ親から Close が送られてくるから無視でいい

740:デフォルトの名無しさん
09/08/08 16:24:06
Form 1 の中で生成した Form2 を破棄しようとして起きるんじゃないの

741:デフォルトの名無しさん
09/08/08 18:41:56
テキストボックスやパネルの境界線の色をグレーや薄いブルーなどにするにはどうすればいいですか？
また、
ラベルの上に小さめのテキストボックスを重ね、一つのコントロールにすることはできますか？

調べましたが分かりませんでした。
どなたか教えてください
(T_T;)。

742:デフォルトの名無しさん
09/08/08 19:08:28
WPFをつかっとけ

743:デフォルトの名無しさん
09/08/08 19:45:28
>>742
WindowsフォームアプリケーションでWPFのコントロールを使えるんだっけ…。

744:デフォルトの名無しさん
09/08/08 19:50:05
>>740
ユーザ要求により Form2 に WM_CLOSE が送られ
その処理中に Form2 から Form1 に WM_CLOSE が送られ
Form1 が閉じる際に子ウィンドウに対して WM_CLOSE が送られ
その処理中に Form2 から Form1 に WM_CLOSE が送られ……

WM_CLOSE から発生する一連の処理が終了してない間に
改めて WM_CLOSE を流したらループするだろ

745:デフォルトの名無しさん
09/08/08 19:51:38
>>743
Windows Forms の編集時にツールボックス見たら
WPF 相互運用機能グループに ElementHost あるでしょ

746:デフォルトの名無しさん
09/08/08 19:56:57
>>717の場合は、別にWin32のウィンドウメッセージの水準で連鎖が起こってるわけじゃなく、
あくまで.NET Frameworkの、いわゆる「イベントの連鎖」が起こってるだけ
（しかも仕様というよりバグが原因ぽい）だから、ちょっとその説明は違うと思うけど。

747:デフォルトの名無しさん
09/08/08 19:57:05
なんでElementHost なんてわけわからん名前にしたんだ？

748:デフォルトの名無しさん
09/08/08 20:09:08
至って普通の名前だと思うが･･･

749:デフォルトの名無しさん
09/08/08 20:11:01
わけわからんって。
Element(UIElement) を Host するから ElementHost。

750:デフォルトの名無しさん
09/08/08 20:14:18
WinFormだけでやるなら、
TextBoxやらはボーダーなしにして、
その親としてPanelを用意して、
そのPanelのPaintで枠を描画

751:デフォルトの名無しさん
09/08/08 20:15:37
このスレはMS信者に乗っ取られているようだ
嘆かわしい

752:デフォルトの名無しさん
09/08/08 20:31:56
まぁC#使ってる奴の99.9%がMS使いだと思うよ(´・ω・｀)
だれかC#でiPhone開発してる人来ないかな･･･

753:デフォルトの名無しさん
09/08/08 20:34:52
というかどこから >>751 が出てきたんだ？

754:デフォルトの名無しさん
09/08/08 20:44:26
何かのキーワードに反応するボットじゃない？

755:デフォルトの名無しさん
09/08/08 21:12:16
>>750
PanelにPaintができるの？
枠線入りの画像をパネルの背景にするってこと？

756:デフォルトの名無しさん
09/08/08 21:17:07
普通にPaintできるだろ
もしWPFを使うなら，テキストボックス一つ一つをElementHostでホストするようなことはお勧めしない
ある程度の大きい範囲で丸ごとWPFにしてElementHostに乗せる

757:デフォルトの名無しさん
09/08/08 21:28:28
>>755
具体的にどうやるの？
panel1_iventが出てきたけど…。

758:デフォルトの名無しさん
09/08/08 21:45:35
paintイベントって、formをloadしたときに自動で発生するの？

759:デフォルトの名無しさん
09/08/08 21:51:23
描画が必要なとき
もちろん初めにフォームを表示するときも呼ばれるな

760:デフォルトの名無しさん
09/08/08 21:51:35
くれくれしすぎは

次ページ