08/10/07 07:23:11
>>665
いろいろと制約が厳しいな。
HttpWebRequest の AddHeader でだめってことは、標準ヘッダを
ごにょごにょしたい、ってことかな？
リフレクションで一部書き換えられたようには思うけど、変に細かい技を
使うより、Tcp でちくちくやるのがよさげだね。
667:デフォルトの名無しさん
08/10/07 08:34:17
>>661
ダメ。
メソッド呼びだした先で勝手に値が書き換えられるってのは嫌われる。
C++ でも、参照渡しがあるにもかかわらず、const 参照しか使わないって人多い。
出力パラメータとして参照渡ししたいときはポインタを使う。
668:デフォルトの名無しさん
08/10/07 08:41:53
>>656
俺は全部付ける。
MS のガイドラインだと、特に this. つけるとはなってなかった気が。
でも、MS のソースコードの品質チェックツール通すと this. 付いてないと警告出た気が。
669:デフォルトの名無しさん
08/10/07 08:49:17
あっ、ごめん、668 の最後の行は気のせいだった。
今やっとツールの名前と使い方思い出して試してみたけど、
付けても付けなくても文句言われない。
ちなみに、StyleCop ってやつ。
URLﾘﾝｸ(code.msdn.microsoft.com)
670:デフォルトの名無しさん
08/10/07 08:56:25
thisが必要なとこ以外にばらまかれてると
かえって見づらい気がするのでつけないな
671:デフォルトの名無しさん
08/10/07 08:57:47
.NET的にマウスホイールをカーソル直下のコントロールに送るのって、プロパティとかあるの？
MouseEnterでフォーカス移す以外であれば教えて(涙。
672:デフォルトの名無しさん
08/10/07 08:58:20
>>661
むしろ無いと怖いでしょ
>>664
>null
基本的に値型にnullは入れられません
Nullableを利用するとNullにできるけど…
>パフォーマンス
GCのスキャンコストが減ります
用途によってはボクシング/アンボクシングでかえって遅くなることもあります
と、これ以上はよくわからん
パス
673:デフォルトの名無しさん
08/10/07 11:04:56
>>661
そういう意味で参照渡しを前提とするパラメータには必ずrefかoutか付けないと
コンパイルが通らないようにすればいいと思ってるんだがC#はそうはなってない
んだよな。
値型の変数を参照渡しするときはoutなりrefなりつけないといけないが、参照型
の値を参照渡しするときは普通の変数のように渡せてしまう。
これじゃあとでコードを見たとき、この部分は参照渡しか値渡しなのか一目で
分からない。参照型の変数でも参照渡しするときはoutかrefを必須にすれば
よかったと思うんだがどうだろうか？
674:デフォルトの名無しさん
08/10/07 11:13:23
>>673
参照型もref/outが無ければ値渡し。参照渡しするならref/outが必要。
それに値型のなかの参照型メンバの値を変更とか考えると意味が無い。
675:デフォルトの名無しさん
08/10/07 11:28:12
C#の名称ってどうやって付けてる？どうにもVCとかVBの思考が抜けないんだが
自由なのは分かってるが一般的な付け方がしたいです
関数、プロパティ、名前空間、クラス名、定数は大文字から始める
MainForm、UpdateMenbers、LineMax
コントロールはプレフィックス(?)を付ける frmMain、btnCancel
ローカル変数は小文字から caption、changed
引数はローカル変数と同名を避けるためアンダーバーから _caption
大体こんな感じでいいのかな・・・
あと、引数付きプロパティが使えないが、Get～とかSet～ってやらないで、
インデクサ(?)付きクラスでも返した方がC#っぽい？
676:デフォルトの名無しさん
08/10/07 11:45:44
>>674
> 参照型もref/outが無ければ値渡し。
え( ´･ω･)？
677:デフォルトの名無しさん
08/10/07 11:50:08
>>675
URLﾘﾝｸ(msdn.microsoft.com)(VS.80).aspx
678:デフォルトの名無しさん
08/10/07 11:52:04
参照の値渡し、参照の参照渡しといいたいのだろう。
その辺はCでもいっしょっしょ。
ポインタの指してる中身を書き換えるだけならポインタをそのまま渡せばいいが、
ポインタそのものを書き換え戻したいなら、ポインタのポインタを渡さないといけない。
679:デフォルトの名無しさん
08/10/07 11:59:31
>>678
ああ、そういう意味か。
>>673で言いたかったことはメソッドに値を渡すとき、その値をコピーして
元の値は書き換えないのか、それとも書き換えるのかがメソッドの宣言を
見ただけでは識別しにくいってことなんだよね。
当然この型は値型だから渡しても書き換えされないはず、この型は参照型
だから渡せば書き換えられるはず、という知識を持っておけば分かるけど、
複雑なコードになるとそこらへんをうっかり間違えてしまいトラブルの元に
なるんじゃないかなと。
だから参照渡しをするときは値型だけでなく参照型の変数でもref/outを
必須にすればよかったのにと思ったわけ。
680:デフォルトの名無しさん
08/10/07 12:01:58
え？
681:デフォルトの名無しさん
08/10/07 12:04:03
参照型の値渡しにref付けるならば
参照の参照渡しだとrefrefキーワードが必要になるな
682:デフォルトの名無しさん
08/10/07 12:08:48
>>679
普通にref/outしたい時に困るんじゃない？
683:デフォルトの名無しさん
08/10/07 12:14:15
>>681
参照型の実体（格納してる変数は単なるメモリの番地）を知ってる人には
その通りだと思うんだが、そういうことを利用者に意識させないのがC#の
利点であることを考えると値型だろうと参照型だろうと参照渡しするときは
ref/outを必須にするように決めた方がいいと思うんだが。
そして参照型をref/out無しでメソッドに渡したら、その参照型のコピーが
メソッドに渡されるようにすればいい。つまりref/outなしで参照型の値を
メソッドに渡して書き換えられても、オリジナルの値にはなんら影響が
出ないようにすると。
これでユーザーがポインタを意識する必要は100%無くなる。
684:デフォルトの名無しさん
08/10/07 12:22:05
それどうみてもただの値型
685:デフォルトの名無しさん
08/10/07 12:24:26
むしろパフォーマンスを意識してポインタを知ることになるんじゃね？
refだらけになりそうだ
686:デフォルトの名無しさん
08/10/07 12:24:37
正直その主張はconstマンセーにしか読めない。
687:デフォルトの名無しさん
08/10/07 12:25:14
なんか初心者が好きなことを書き込むスレになってきてないか
688:デフォルトの名無しさん
08/10/07 12:33:32
> 値型だろうと参照型だろうと参照渡しするときはref/outを必須
C#は実際そう。参照渡しの語義を確認したほうがいい
URLﾘﾝｸ(ja.wikipedia.org)
他の言語のスレでもこういう展開になることが多いんだけど
元凶はどこにあるんだろうね・・・
689:デフォルトの名無しさん
08/10/07 12:34:56
元凶はC++だろ。早く無くなればいいのに・・・
690:デフォルトの名無しさん
08/10/07 12:45:11
>>686
できるよ。
以上。
↓次の方どうぞ
691:デフォルトの名無しさん
08/10/07 13:13:11
↑なんでそんなに馬鹿なんですか？
692:デフォルトの名無しさん
08/10/07 13:32:09
>>正直その主張はconstマンセーにしか読めない。
できるよ。
意味不…
693:デフォルトの名無しさん
08/10/07 13:33:36
やっと*から抜け出せたのに今度はrefかよ
それだったら、*のほうがマシだわ
694:デフォルトの名無しさん
08/10/07 13:35:21
>>688
数値もポインタもいずれも「値」がメソッドに渡される、という意味ではC#は「値渡し」
になるんだろうけど数値が渡されるのかポインタが渡されるのかは型によって
まちまちなわけで、その違いをもっとユーザーに意識させる仕組みが組み込まれて
然るべきじゃないかなと言ったわけよ。
695:デフォルトの名無しさん
08/10/07 13:36:31
どうやって参照型を自動でコピーするんだよ
フィールド全部再帰的になめるのか？
それでも駄目だけど
そしてrefだらけになると
あほかいな
696:デフォルトの名無しさん
08/10/07 13:38:48
あと文字列(string）は参照型にもかかわらずメソッドに渡すときは全く同じ
文字列がコピーされるからメソッド内でいくらいじくってもオリジナルの
文字列が変更されることはない。
でも文字列の配列(string[])をメソッドに渡すとメソッド内での操作が
オリジナルの文字列の配列にも反映される。
ここらへんのルールの違いをもっと明確にユーザーに伝わるような仕組みを
構築すべきじゃないかな？特にC#は後発の言語なんだから。
697:デフォルトの名無しさん
08/10/07 13:45:54
そうじゃないよ
698:デフォルトの名無しさん
08/10/07 13:46:05
>>696
stringは確かに不変オブジェクト扱いだけどこの場合何の関係も無いよ
単に自分自身を操作するメソッド/プロパティが無いだけなんだから
リフレクションで値書き換えればちゃんと呼び出し元でも変更される
699:デフォルトの名無しさん
08/10/07 13:49:15
言いたいことをまとめると、
この型はメソッドに渡すと変更を受けるけど
この型はメソッドでいじくり回しても一切の変更を受けない。
こういう型が区別も無く平然と並んでいるのがユーザーの混乱を招くってことよ。
どれが参照型でどれが値型かなんて言語ごとに違って当然なんだから
それを曖昧なままごちゃまぜにしていればいつか間違いが発生する。
言語の進化というのはそういううっかりミスをなくす方向で発展していく必要が
あると思うんだよ。
700:デフォルトの名無しさん
08/10/07 13:56:00
で、変更しないならconstつけることにした言語があったよね
701:デフォルトの名無しさん
08/10/07 14:00:00
型がimmutableかmutableかをその型の前提知識無しに
コードを見ただけで一発で判定可能にするってことか？
702:デフォルトの名無しさん
08/10/07 14:06:57
>>699
値型的な扱いはintとstringだけなんだから
これを覚えるのに大した労力も必要としないだろハゲ
703:デフォルトの名無しさん
08/10/07 14:15:01
どうも >>651以降、 アフォが湧いてるようじゃのう…
704:デフォルトの名無しさん
08/10/07 14:17:16
C#だけ扱うならな。
だが現実にはC++やJava、VisualBasicと多岐にわたる言語を同時に扱うのが普通だろ。
記憶だけに頼る方式は後々重大なエラーを招く。
「てっきりstring型は呼び出したメソッド先での変更が反映されるものだと思っていました」
そう言いながら打ち上げロケットを派手に爆発させるミスが発生するかもしれない。
705:デフォルトの名無しさん
08/10/07 14:31:50
どうにも手がつけられない
706:デフォルトの名無しさん
08/10/07 15:14:53
>>699
参照型を含む値型の扱いはどうする？
707:デフォルトの名無しさん
08/10/07 15:17:57
一日でレス進んでると思ったら(ry。
Stringでも他の参照型でも動作は共通してると思うが、>704の頭の中ではどうなってるんかが疑問だな・・。
Stringクラスの編集系メソッドはすべて新たなインスタンスを返してくるわけで、実体の操作は出来ないんだが。
つまり、参照型であっても、値渡しされたStringメソッドがその先で変更されることがありえないので誤解のしようがない。
ref指定した場合、「メソッド内での値の変更＝新しいインスタンスを参照」になるだけ。一貫してると思うが。
708:デフォルトの名無しさん
08/10/07 15:21:04
Stringメソッドがその先で→Stringがその先のメソッドで
709:デフォルトの名無しさん
08/10/07 15:34:56
ポインタ難しいスレにそっくりさんがいたのを思い出した
そういう人にはサンプルコード書かせると言い逃れできなくていいかもね
710:デフォルトの名無しさん
08/10/07 15:43:42
>>707
他の言語のString型も同じだと言い切れるかな？
そしてもし他の言語のString型とC#のString型が違ったらどうするんだ？
という疑問を投げかけられて、
「そりゃそれぞれ違いを覚えるしかない」
と答えたらその時点でヒューマンエラーが紛れ込む余地が誕生したと思うべき。
近代の言語が、とくにC#がこの手のヒューマンエラーを極力排除することを
念頭に新たに作り直されたことを考えるとこの点に置いてC#は不十分な言語と
言わざるを得ない。
見方を変えればいまだにC/C++時代のポインタを引きずっているとも言える。
711:デフォルトの名無しさん
08/10/07 15:47:37
何のためのCTS（共通型システム）だと思ってんだ
712:この話題にも飽きてきたが
08/10/07 16:23:06
正直その程度のリファレンスも見ない奴がマルチリンガル気取るのもどうかと思うけど（IntelliSenceで戻り値見るだけでも気付くはず）、
言語間の実装の違いや動作の相違は、そもそも無いほうがおかしい。
それより、言語内で一貫した基準があって、すべてのクラスがそれに則っていることが言語としては第一だろ。
C#の場合、引数は標準で値渡し、ref・outで参照渡し。それがすべて。そしてStringは参照型。
それを踏まえたうえで値渡しのStringが中で変更されると思うのは、参照のイメージが確立していないか、
Stringのメンバの使い方が分かってないかのどちらかじゃないか？
前者はマとして未熟。後者はウッカリというより、これから使うライブラリのリファレンスも見ない向こう見ずに思える。
皆、長文スマンな。
713:デフォルトの名無しさん
08/10/07 16:30:19
stringが参照型の値渡しなら
string[]はどうなるんだ？
714:デフォルトの名無しさん
08/10/07 16:32:48
stringは参照型の値渡し
string[]は参照型の値渡し
stringはmutable
string[]はimmutable
715:デフォルトの名無しさん
08/10/07 16:33:31
反対だ
stringはimmutable
string[]はmutable
716:デフォルトの名無しさん
08/10/07 17:10:42
class TaskMem
{
public IntPtr Ptr;
~TaskMem() { Marshal.FreeCoTaskMem(this.Ptr); }
}
[DllImport("hoge.dll")]
static extern int Foo(out IntPtr ptr); // int Foo(void** ptr);
TaskMem mem = new TaskMem();
Foo(out mem.Ptr);
とした場合、Fooから返って来てmem.Ptrに格納される間に例外が起きない事は保証されているのでしょうか?
それともCERで保護しないと駄目ですか?
717:デフォルトの名無しさん
08/10/07 17:17:25
>>714
string[]を値渡しするのとref付けて参照渡しするのとで、結果は違ってくる？
どちらもメソッドでの変更が反映されるだけで動作は全く同じになると思うんだが。
718:デフォルトの名無しさん
08/10/07 17:23:26
>>717
参照渡しと値渡しの違い分かってる？
719:デフォルトの名無しさん
08/10/07 17:26:11
わかってないだろうな。
>>717
void f1(string[] a){ a = new []{"a","b"}; }
void f2(ref string[] a){ a = new []{"a","b"}; }
f1、ｆ2が上のように定義されているとき、
string[] b = null;
f1(b); // bはnullのまま
f2(ref b); // bは{"a","b"}になる
720:デフォルトの名無しさん
08/10/07 17:27:13
>>717
public static void hoge(string[] s)
{
s = new[] { "c", "d" };
}
public static void hage(ref string[] s)
{
s = new[] { "e", "f" };
}
static void Main(string[] args)
{
string[] s = { "a", "b" };
Console.WriteLine("{0} {1}", s[0], s[1]);
hoge(s);
Console.WriteLine("{0} {1}", s[0], s[1]);
hage(ref s);
Console.WriteLine("{0} {1}", s[0], s[1]);
}
721:デフォルトの名無しさん
08/10/07 17:41:25
>>719
> void f1(string[] a){ a = new []{"a","b"}; }
> void f2(ref string[] a){ a = new []{"a","b"}; }
new演算子を使わずに
void f1(string[] a){ a = {"a","b"}; }
void f2(ref string[] a){ a = {"a","b"}; }
だったらどちらも結果は
bは{"a","b"}
にならない？
722:デフォルトの名無しさん
08/10/07 17:45:59
>>721
コンパイルエラー
723:デフォルトの名無しさん
08/10/07 17:51:00
>>722
いや、通ると思うんすけど・・・
724:デフォルトの名無しさん
08/10/07 17:57:10
はぁぁあ？
725:デフォルトの名無しさん
08/10/07 17:57:41
string[] a = { "a", "b" }; //おｋ
string[] b;
b = { "a", "b" }; //だめ
new[] を省略できるのは変数宣言の時だけだな
ちゃんとコンパイルして試してから言ってるのか？
726:デフォルトの名無しさん
08/10/07 17:58:54
どのバージョンで通った？
727:デフォルトの名無しさん
08/10/07 18:00:41
それにnew[]を省略できるのは構文糖みたいなもんで
入れたり入れなかったりで挙動が変わるなんてこたあないんじゃないかな
728:デフォルトの名無しさん
08/10/07 18:04:31
なんかねえ
初心者を装ったものすごく巧妙な釣り師というか荒らしが常駐してる気がする
729:デフォルトの名無しさん
08/10/07 18:08:58
該当人物は置いといて、どこまでが初心者として受け入れられるかって難しいぞ
質問するほうだって、これは知ってます、それも知ってますって一々言うわけに行かないし
730:デフォルトの名無しさん
08/10/07 18:10:25
virtualは遅い?
731:デフォルトの名無しさん
08/10/07 18:11:06
>>716
SafeHandle使えば悩む必要なかろ
outなら大丈夫だったとは思うが覚えてない
732:デフォルトの名無しさん
08/10/07 18:11:54
まあなんだ、初心者はstructやref/outには手を出さないことだね
733:デフォルトの名無しさん
08/10/07 18:42:37
しかし、平日の昼間からこんなところでレスしてる人ってどういう人なんだろ。
いや別に他意（<=なぜか変換できない）はないんだけど。
734:デフォルトの名無しさん
08/10/07 18:49:45
職場での息抜きに。
自由な職場っていいよね。
735:デフォルトの名無しさん
08/10/07 18:53:00
モノさえ仕上げりゃエロゲしようがアニソン垂れ流そうが自由よ。
736:デフォルトの名無しさん
08/10/07 19:07:42
>>732
鉄は熱いうちに打てじゃないが、structとemunは若いうちから慣れておいた方がいい。
なまじstructやemunを使わなくてもプログラムが書けてしまうだけに。
737:デフォルトの名無しさん
08/10/07 19:12:19
classは案外早い GCも含めて
わざわざstructを使う意義はほとんどない
738:デフォルトの名無しさん
08/10/07 19:15:11
ま、よほどタイトな処理内で使う場合じゃないと大して変わらんわな
739:デフォルトの名無しさん
08/10/07 19:16:56
無論状況によってはかなり変わるが、大抵は使い分けるデメリットのが大きい
740:デフォルトの名無しさん
08/10/07 19:27:40
>>737
ref/out使わずに結果を取り出したいならstructも少しは役に立つんでね？
741:デフォルトの名無しさん
08/10/07 19:33:34
>>739
言ってる意味が分からない。
いくらふらっとスレでもトンデモなことを言いすぎだろう。
使い分けないデメリット、なら話もわかるが使い分けるデメリットってどういう意味だよ。
あるいはどちらでも用が足りる用途なら迷わずクラスを選べ、
というのなら正しいし理解もできる。
だが構造体に存在意義がないかのような意見はおかしい。
742:デフォルトの名無しさん
08/10/07 19:55:10
俺は>>739じゃないが「それがstructかどうか」を意識しなきゃならなくなるのは苦痛だ
PointやRectangleをいちいちnewしなきゃならんのは実に面倒くさい
しかしform.Location.X = 100;みたいな記述を可能にするためには
Pointに親への参照が必要になってしまいかねないんだよな
なかなか難しい
743:デフォルトの名無しさん
08/10/07 19:57:51
enumイラネってWin32SDKみたいな定数の溢れたカオスワールドがイイって事？
744:デフォルトの名無しさん
08/10/07 20:06:08
つーかお前らほどのアニソンマスターなら放送される曲全て持ってるんだろ
公共ラジオで丸一日垂れ流しする意味ねーじゃん
745:デフォルトの名無しさん
08/10/07 20:06:58
>>742
まあPointにイベント(XChanged)を追加することでも可能だと思うけどね。
746:デフォルトの名無しさん
08/10/07 20:28:06
どとねとの構造体ってinteropでAPIとのやりとりのためにあえて残した
もんだと思ってた。win form のrect とかpointが構造体なのはwin32の
ラッパだからしかたねーんだなと 勝手に思っていた…。
747:デフォルトの名無しさん
08/10/07 20:31:52
書き方が悪かったが、使い分けなきゃならないデメリットというのか、
構造体特有の注意点とか意識しないといけないとか、
そういう点をデメリットって言ったんだよ。
748:デフォルトの名無しさん
08/10/07 20:37:29
巨大な構造体使う奴とか見たもんでな。
基本的に使うな、の方が無難なことが多い。
ちゃんと分かってる奴だけが使うならいいが。
749:デフォルトの名無しさん
08/10/07 20:40:18
メソッドいらない場合structだと思、
750:デフォルトの名無しさん
08/10/07 20:42:00
>>749
Cから来た人たちが引っかかる罠なんだよね。
ユーザー定義の値型にstructのキーワードを当てはめたのが失敗だったといわれている。
751:デフォルトの名無しさん
08/10/07 21:05:16
全然話の流れが分かってないけど、こういう使い方って問題無い？
こうしろよってのがあれば教えて下さい。
private List<Data> list = new List<Data>();
struct Data
{
public string Key;
public string Value;
}
752:デフォルトの名無しさん
08/10/07 21:07:46
>>750
そんな穴に落ちる奴はいないだろ。
入門者を斜め読みしただけで別物と普通は分かるよ。
「参照」って言葉の意味がC++と似てるけど別物だったりするのが落とし穴というのならわかるが、
構造体で引っかかる人間なんていないと思う。
753:デフォルトの名無しさん
08/10/07 21:10:10
struct Data
{
public readonly string Key;
public readonly string Value;
}
こうすべきじゃないかな
クラスまたは構造体の選択
URLﾘﾝｸ(msdn.microsoft.com)
754:デフォルトの名無しさん
08/10/07 21:15:23
リンク先の「変更できない。」という特性を守る場合
KeyやValueの値が可変なら、というか、readonlyだと駄目な状況では
構造体じゃなくクラスを使うべきなんですかね。
Listにクラスを放り込む場合どう書けば？？？
755:デフォルトの名無しさん
08/10/07 21:25:26
class Data
{
public string Key;
public string Value;
}
こんな感じのクラスを用意して
Data data = new Data();
で初期化して使う感じでしょうか？
756:デフォルトの名無しさん
08/10/07 21:31:58
ジェネリックなコレクションにstructを使う場合の注意としては、
IEquatable<T>.Equals(T o)と、大小比較する場合はIComparable<T>.CompareTo(T o)を実装すること。
そうしないと比較のたびにボクシングが頻発して悲惨なことになる。
もっとも基本配列であるListの場合はあまり問題ない。
実装しないなら非ジェネリックのコレクションの方が効率がいい。
登録時ボクシングは１回だけですむ。
757:デフォルトの名無しさん
08/10/07 21:51:59
>>745
そんなことしたら使い方によってはおっそろしく遅くなるよ
758:デフォルトの名無しさん
08/10/07 21:58:05
>>755
[TypeConverter(typeof(Design.DataConverter))]
struct Data : IEquatable<Data> {
public string Key { get; set; }
public string Value { get; set; }
public override int GetHashCode() {...}
public override bool Equals(object obj) {...}
public bool Equals(Data alt) { ... }
...
}
namespace Design {
class DataConverter : TypeConverter { ... }
}
759:デフォルトの名無しさん
08/10/07 22:00:44
>>758
構造体に自動プロパティを使うのは良くない
コンストラクタ書けなくなる
760:758
08/10/07 22:01:42
そいやそうだな、ごめん
761:デフォルトの名無しさん
08/10/07 22:06:00
>>757
さすがに意味がわからない突っ込みだ。
そもそもパフォーマンスが重要な場面に適合的なケースの話はしてないと思うんだけど。
762:758
08/10/07 22:07:04
ん、いや、>>759 は正確じゃないな
こうすれば書ける。自動プロパティやめとけは同意
struct Data {
public Data() : this() { ... }
}
763:758
08/10/07 22:08:37
ああもう、
struct Data {
public Data(string key, string value) : this() {...}
}
な
764:デフォルトの名無しさん
08/10/07 23:28:02
>>751って以下と変わらない気がするのですが、それでも
>>763みたいにするべきなのでしょうか。
private List<KeyValuePair<string, string>> MainList = new List<KeyValuePair<string, string>>();
そもそもがstring同士なので大小比較なども行わないし、私の頭では
どうするのが一番良いのかイマイチ理解できない…orz
765:デフォルトの名無しさん
08/10/07 23:46:17
>>764
・IL 上はだいぶ変わる(バイナリ互換の問題)
メソッドコールかフィールドアクセスになる
コード互換で言えば、ref で渡せるかどうか程度かな
・リフレクションもだいぶ変わる(バインディングで問題)
var props = TypeDescriptor.GetProperties(typeof(Data));
var prop = props["Key"];
・パフォーマンスかなと考えてもメンバ string だし
まとめると、少しでも変更に耐性のあるプロパティにしとけ
みたいな。というかフィールドにする意味ないなぁと
フィールドのほうが「あえて」立場なんだよ要するに
>>758 の例は struct 作るときに標準的にやっといたほうが
いい処理が含まれてる実装ですなただの
KeyValuePair 使うかどうかはそれ(表現したい対象)が
KeyValuePair の機能しか将来的にも持たないんなら
それでいいんじゃね
766:デフォルトの名無しさん
08/10/08 00:04:34
>>719
で引数がList<T>にしてみたんだけど
void hoge( ref List<int> a )
{
List<int> a = new List<int>();
}
767:デフォルトの名無しさん
08/10/08 00:05:54
失礼。
void hoge( ref List<int> a )
{
List<int> a = new List<int>();
}
としてコンパイルしてみたところ
ローカルの変数 'a' をこのスコープで宣言することはできません。
これは、'親またはカレント' スコープで別の意味を持つ 'a' の意味が
変更されるのを避けるためです。
というエラーが返されてしまった。
ref→out
に変更しても同じエラーが返される。
なにかまずいことでもしちゃったかな？
768:デフォルトの名無しさん
08/10/08 00:08:21
参照渡しが値渡しがどうのとか考えるレベルにすら達してないね
ローカル変数の宣言になっちゃってる
769:デフォルトの名無しさん
08/10/08 00:09:12
>>767
{
a = new List<int>();
}
770:デフォルトの名無しさん
08/10/08 00:10:34
>>769
おっ、サンクス(；^ω^)ﾉｼ
>>768
(´；ω；｀)ﾌﾞﾜｯ
771:デフォルトの名無しさん
08/10/08 00:12:46
>>768
ちょっと言い訳がましいことを言わせてもらうとList<T>があまりにも最新の技術なもんで
手持ちの参考書に一言も触れられてないのね。暗中模索状態だからつまらないところで
ミスしてしまう(；^ω^)
ちなみに
a = new List<int>();
↑
この()の部分ってコンストラクタの()の名残という認識でok？
772:デフォルトの名無しさん
08/10/08 00:14:35
名残っていうか引数なしのコンストラクタの呼び出しそのもの
773:デフォルトの名無しさん
08/10/08 00:18:42
List<int>もintもStringBuilderも全部型の名前
new StringBuilder()
new List<int>()
ほら同じ
774:デフォルトの名無しさん
08/10/08 00:22:10
List<T>ってC#の短い歴史から考えると全然最新じゃないんだけど
775:デフォルトの名無しさん
08/10/08 00:26:18
C#2.0が出たのって４年くらい前だっけ
776:デフォルトの名無しさん
08/10/08 00:27:03
>>771
ナカーマ
5-6年前に独習C#買って放置→最近また始めたら
ジェネリクスやらLINQやらとんでもないことになっててもうね
777:デフォルトの名無しさん
08/10/08 00:32:32
>>773
int a = new int();
string b = new string();
もokだっけ？
778:デフォルトの名無しさん
08/10/08 00:34:20
>>777
stringは引数なしコンストラクタが存在しないので無理だな
779:デフォルトの名無しさん
08/10/08 00:44:52
FileNotFoundExceptionをToString()で書き出すと
System.IO.FileNotFoundException: 指定されたファイルが見つかりません。
ファイル名 'image\hoge.png' です。
デバッガ上での実行だと、↑みたいにFileNameが出力されるのに
実行ファイルを直接開くと無視されるのね。そんなものなの？
780:デフォルトの名無しさん
08/10/08 00:45:44
>>771
言い訳が言い訳になってないのが滑稽。
781:デフォルトの名無しさん
08/10/08 00:52:39
>>790 自分でFileName出力すれば?
782:デフォルトの名無しさん
08/10/08 00:55:00
>>779
Windowsプロンプトから起動してみたけど
そんな感じのメッセージと一緒にスタックトレースが表示されるよ
783:764
08/10/08 07:50:28
>>765
>>764の書き方だと全然>>751みたいな使い方は出来ないですね。
KeyValuePairって初期化すれば値を割り当てられると思ってました。
>>764は結局>>753と同じだという事が分かりました。
クラスにすると上手く動かないし、>>763を参考にしてみます。
784:783
08/10/08 08:46:30
何度もすいません。
最終的に、クラスにしてKey、Valueのプロパティを持ち、その都度
インスタンスを生成する事で上手くいきました。
今の使い方ではあまりパフォーマンスにも影響は無さそうですが
今後の事を考えてクラスで運用します。
また、値型、参照型の違いが何となく分かった気がします。
有り難う御座いました。
785:デフォルトの名無しさん
08/10/08 10:53:02
C#ってJAVAと同じなの？
786:デフォルトの名無しさん
08/10/08 10:54:25
釣られないぞ
787:デフォルトの名無しさん
08/10/08 11:30:38
釣られてみる
あえて言おう！違うと！
まず名前が違う！これだけでじゅうぶんだ。
788:デフォルトの名無しさん
08/10/08 11:34:19
君と私は名前が違うけど同じ人間だよねえ。
789:デフォルトの名無しさん
08/10/08 11:34:30
JavaとJ++とJ#が同じかどうかとなると哲学なのだが
790:タイマーについて
08/10/08 11:35:13
質問です。タイマーについてですが、普通のWindows.Formsのタイマーを使って
います。
タイマにより一定時間間隔で処理を行うには？（Windowsタイマ編） － ＠IT
URLﾘﾝｸ(www.atmarkit.co.jp)
ここに書いてあるようなバグはFramework2.0以降は解決されているようでしたが、
ﾀｲﾑｱｯﾌﾟのイベントが立つたびに、I/Oのメモリー消費がちびっとずつ増えていく
ようなのですが、これはバグなのでしょうか。
791:デフォルトの名無しさん
08/10/08 11:35:37
一括りにすればC#もJAVAもプログラム
792:デフォルトの名無しさん
08/10/08 11:54:12
public PerformanceCounterCategory pcc = new PerformanceCounterCategory("LogicalDisk");
private void GetLogicalDiskRead()
{
this.listView1.Items.Clear();
foreach (string s in pcc.GetInstanceNames())
{
foreach (PerformanceCounter p in pcc.GetCounters(s))
{
if (p.CounterName == "Disk Read Bytes/sec" && p.InstanceName != "_Total")
{
this.listView1.Items.Add(new ListViewItem(new string[]{
p.CategoryName,
p.CounterName,
p.InstanceName,
p.NextValue().ToString()
}));
}
}
}
}
論理ディスクのReadを調べるためにこんなコードを書いたのですが、
エラーも何も無く実行できるものの値がずっと0になってしまいます。
これは何が問題なんでしょうか？
793:792
08/10/08 11:57:49
書き忘れです。タイマーで1秒毎の更新にしています。
private void timer1_Tick(object sender, EventArgs e)
{
GetLogicalDiskInfo();
}
794:デフォルトの名無しさん
08/10/08 12:53:59
>>790
失礼しました、これはタイマーのTickイベントの中で、フォルダの存在を
チェックしていて発生していたようです。メモリの消費量がイベントのたび
に０～５バイトぐらいずつ増えていくのでなんだろうと思いましたが、タイマー
とは無関係でした。すみません。
795:790
08/10/08 12:58:04
>>794
ただ、Directory.Exists(_strDirectory)これを行うたびにI/Oのメモリが
消費されるというのは正常なのでしょうか？
796:デフォルトの名無しさん
08/10/08 13:07:58
>>792
カウンタ毎回取得してたら駄目だろ
欲しいPerformanceCounterを保持しておく
797:デフォルトの名無しさん
08/10/08 13:13:48
C#とJAVAってできることはほぼ同じなの？
動く環境も。
798:デフォルトの名無しさん
08/10/08 13:13:50
>>795
「I/Oのメモリ」って何？
799:デフォルトの名無しさん
08/10/08 13:41:01
質問
VC++みたいな独自のイベントってどうやって実装するんですか？。
VC++ならWM_USER以下にならない様な番号ふってWM_HAGEとか定義して
afx_msgにつけ加え定義
MESSAGE_MAPにつけ加えて
て感じだったと思うんですが
C#ではどうやるのでしょうか
800:デフォルトの名無しさん
08/10/08 13:50:58
取りあえずヘルプでイベントの項目読め
801:デフォルトの名無しさん
08/10/08 15:06:27
WindowProc直接いじるならこれかな。
URLﾘﾝｸ(www.atmarkit.co.jp)
802:デフォルトの名無しさん
08/10/08 15:23:29
>>796
色々と書き直してみてとりあえず動くようにはなったんですが
我ながら何をやってるのかよくわかって無いですorz
変なことやってないですかね？
private List<PerformanceCounter> prfList = new List<PerformanceCounter>();
private void Form1_Load(object sender, EventArgs e){
SetReadInfo();
GetLogicalDiskRead2();
}
private void SetReadInfo(){
foreach(string s in pcc.GetInstanceNames())
{
if (s != "_Total"){
PerformanceCounter p = new PerformanceCounter("LogicalDisk", "Disk Read Bytes/sec", s);
prfList.Add(p);
}
}
}
private void GetLogicalDiskRead2(){
this.listView1.Items.Clear();
foreach (PerformanceCounter x in prfList){
this.listView1.Items.Add(new ListViewItem(new string[]{
x.CategoryName,
x.CounterName,
x.InstanceName,
((long)x.NextValue()).ToString()
}));
}
}
803:デフォルトの名無しさん
08/10/08 16:32:30
つぎのようなメソッドを定義し、（処理１）でエラーが発生したときただちに関数を抜け出すためには
どんな方法を採用するのが推奨されていますか？GOTO文で関数の終わりの方まで一気に
飛ばすのはあまり推奨された方法ではないと聞きました。
void Hoge()
{
・・・・
tyr{（処理１）}
catch{・・・}
tyr{（処理２）}
catch{・・・}
・・・
}
804:デフォルトの名無しさん
08/10/08 16:35:03
>>803
return;
805:デフォルトの名無しさん
08/10/08 16:37:46
>>802
何やってるか分からないてのが一番まずいな
>>803
Microsoft曰く「内部実装なんてどう書こうが知らね勝手にしろ」
806:デフォルトの名無しさん
08/10/08 16:39:41
>>804
こんな感じでいいでしょうか？
void Hoge()
{
・・・・
tyr{（処理１）}
catch{・・・; return;}
tyr{（処理２）}
catch{・・・; return;}
・・・
}
807:デフォルトの名無しさん
08/10/08 16:46:29
>>806
catch{ ... ; throw ...}という手もある
808:デフォルトの名無しさん
08/10/08 17:52:56
C#ってgoto文が実は生き残ってたのかよｗ
809:デフォルトの名無しさん
08/10/08 18:02:31
>>808
無知なのに上から目線ワロタw
810:デフォルトの名無しさん
08/10/08 18:22:24
下向き限定なら絶対ダメってほどでもないでそ
811:デフォルトの名無しさん
08/10/08 18:24:07
switchで使えるのはいけるかもと思った。まだ使ってないけど。
812:デフォルトの名無しさん
08/10/08 18:32:26
gotoをなくしても break ラベル とか別の文法が増えるだけ。
もう大人なんだからgotoの扱いは自分で責任をもてるだろってこと。
こういう考えでgotoを残してる言語はわりとある。
813:デフォルトの名無しさん
08/10/08 18:33:41
>>807
throw・・・例外を投げるメソッドでしたっけ？
これをそこで使うことにはどういう意味があるんですか？
814:デフォルトの名無しさん
08/10/08 18:40:48
例外投げればとにかく処理は呼び出し元に戻せる
場合によるけど何も考えずreturnよりは適切かも
815:デフォルトの名無しさん
08/10/08 18:45:33
>>814
> 例外投げればとにかく処理は呼び出し元に戻せる
void Hoge()を呼び出した元にもtry&catchの構文を書いて
そこのcatchに例外をthrowするということですか？
816:デフォルトの名無しさん
08/10/08 18:46:56
↑こんな感じでしょうか？
try{ void Hoge(); }
catch(Exception e){・・・・}
↑のcatch(Exception e){・・・・}に例外をスローすればvoid Hoge()を抜けられるという発想ですか？
817:デフォルトの名無しさん
08/10/08 20:18:34
JavaのTreeSetみたいなやつはない？
818:デフォルトの名無しさん
08/10/08 20:34:29
フォルダ名とファイル名のstringを合成してファイルへのフルパスを生成しようと思ってます。
string folder = @"c:\folder";
string file = "test.dat";
string fullPath = folder + @"\" + file;
ここでもし人によってフォルダ名を
string folder = @"c:\folder\";
のように末尾に\マークを入れてしまう人がいるかもしれません。
フルパスを合成する前にフォルダ名の末尾に\マークがあるかないか場合分けする必要が
あるわけですが、C#のクラスにこのあたりの処理を自動化してくれるものはありませんか？
無ければフォルダ名の末尾に\マークがあるかないかで場合分けして対処する必要があります。
819:デフォルトの名無しさん
08/10/08 20:37:16
Path.Combineあたり
できるかは知らないけどその辺に無かったら無い
820:デフォルトの名無しさん
08/10/08 20:47:14
>>819
どうもです。調べてみますﾉｼ
821:デフォルトの名無しさん
08/10/08 20:47:37
ユーザに見せる必要がなければ、\が幾つ並んでも問題ない。
それでも受け付けてくれる。
822:デフォルトの名無しさん
08/10/08 20:50:54
配列のラストが\\なら消す。
823:デフォルトの名無しさん
08/10/08 21:45:13
>>816
そういうこと
抜けるだけならreturnを使うけど、例外の時はthrowを使うという手段もある。
特に、その関数無いでは対処仕切れない場合とか、例外の再throwをすることがある。
string GetMessage()
{ try {...} catch (ry) { return " tell a lie :p";} }
より
{ try {...} catch (ry) { throw (new Exception("ごごご、ごめんなさい");} }
のほうが良い
824:デフォルトの名無しさん
08/10/08 21:47:15
>>823
それやるなら、前の例外も付けてやったほうがいいんじゃない？
catch(Exception e) {
throw (new Exception("ごごご、ごめんなさい", e);
}
825:デフォルトの名無しさん
08/10/08 21:53:09
普通のrethrowでいいよ
826:デフォルトの名無しさん
08/10/08 21:56:20
>>825
それもそうだな。ネタを考えてて変なことやっちゃったよ
827:デフォルトの名無しさん
08/10/08 22:21:57
>>797
C#とJavaって言語だけ見るとダメで、
バックについてるのが Microsoft か SUN かという違いを見ないとダメ。
SUN がクソ。
828:デフォルトの名無しさん
08/10/08 22:35:02
Linux等でも普通に動くところがJavaと違うんだよな。
だから、おれんとこでは、クライアントアプリがC#、VBどとねと
でASPXより、Tomcat－JBOSS-Apatchがまだまだ主流だ。。。
業務サーバーとなれば、どうしてもDB+Unix系がまだまだ主流で
顧客に高級感という付加価値があびせれる。
制御系は、以外とWindowsOnlyでいけること多いんでCのDLL
をC#で呼び出す系統のものを提案できるな。
829:デフォルトの名無しさん
08/10/08 22:57:47
>>828
制御の世界でも確かに.netで組む例多くなってきてるな。
ただ、制御もSWもわかる技術者をあつめるのが難しいから
IT側とコントローラ側を分離してるだけで決してwindows オンリーでいける
というわけではない。コントローラ側はむしろ組み込みの世界に近いと思う