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

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

950:デフォルトの名無しさん
09/08/21 18:04:56
全体に意味が分からんが、まずそれはWPFか？

951:デフォルトの名無しさん
09/08/21 18:07:19
>>949
>ここで、クラスをそのまま ItemsSource へ突っ込むと、クラス名が表示されてしまいます。
ここで、クラスをそのまま ItemsSource へ突っ込むと、突っ込んだリスト中のクラスが保持するメンバクラスの名前、でした。

class hoge
{
public int m_hoge;
public foo m_foo;
}

class foo
{

で言う foo です。

m_hoge |　m_foo
------+------
　2　　　|　m_foo
　2　　　|　m_foo
　3　　　|　m_foo
　4　　　|　m_foo

952:デフォルトの名無しさん
09/08/21 18:10:29
>>950
WPF というか、 Silverlight でやってます。

>>951 では途中で送信してしまったので、続きです。

class foo
{
public int m_x;
public int m_y;
}

ここで、 foo というクラス名ではなく、数字の x を出力したい。

953:デフォルトの名無しさん
09/08/21 18:10:59
パブリックプロパティ用意すりゃいい

954:デフォルトの名無しさん
09/08/21 18:18:24
XAML側でどのプロパティを表示するかの指定があったはず－。
それにしてもpublicなフィールドでm_って気持ち悪い命名規則だね。

955:デフォルトの名無しさん
09/08/21 18:27:16
>>954
ありがとうございますっ！
そういうのを探していました。
とても助かりました。

956:デフォルトの名無しさん
09/08/21 18:51:19
アクセサを使いましょう

957:デフォルトの名無しさん
09/08/21 18:53:43
XAMLのバインディングってわかりづらいよね
もとより人間が書くものじゃないんだろうけど

958:デフォルトの名無しさん
09/08/21 19:01:24
>>956
アクセサって get とか set ですよね？
XAML と合わせて検索しても、どうにも分らないです。
すみません。

バインディングの記述に利用する識別子でしょうか？

>>957
未だにクラス名やそのメンバ名を直接 XAML ファイルに記述するのが気持ち悪くて仕方ありません。
慣れの問題でしょうか……。

959:デフォルトの名無しさん
09/08/21 19:20:53
BindingのPathは . 使ってプロパティのプロパティを指すこともできる
つかフィールドってバインディングできたっけ？　プロパティじゃないとダメな気が

> 未だにクラス名やそのメンバ名を直接 XAML ファイルに記述するのが気持ち悪くて仕方ありません。
XAMLに記述するのはViewModelのクラスのだから問題ない

960:デフォルトの名無しさん
09/08/21 19:23:48
>>942
>>927の考えは>>939やチミが勝手に心配しているような意味じゃないと思うぞw
別にクラスの中にしかメソッドが存在できないのがウザい、
というような意味のことは言ってないだろう。

っていうか、複雑な計算式をベタにコーディングしたら
>>927のように思うのはむしろ普通のこと。
実際見難くくてかなわんよ。

だから>>930のようにアドバイスするのが正しい。

しかし、今に始まったことじゃないけど本当シロートがシロートに講釈垂れる
図式が多すぎるなここ。

961:デフォルトの名無しさん
09/08/21 20:55:24
>> 未だにクラス名やそのメンバ名を直接 XAML ファイルに記述するのが気持ち悪くて仕方ありません。
>XAMLに記述するのはViewModelのクラスのだから問題ない
どうにもバインディングを勘違いしていました。
特に制約無く作ったデータでもバインディングは行えるものとして考えていました。
バインディングは特定のインタフェースを実装したクラスしか不可能なのですね。

962:デフォルトの名無しさん
09/08/21 21:01:05
>>961
>バインディングは特定のインタフェースを実装したクラスしか不可能なのですね。
違う。
設計の問題で、バインディング自体にそういう制限は無い。

963:デフォルトの名無しさん
09/08/22 00:13:55
>>960
このレベルの自分で頭使わないで文句言うタイプには「黙って書いとけ」が正しい。

964:デフォルトの名無しさん
09/08/22 00:39:36
""（空文字列）との比較は以下のどれがいいですか？
それぞれのメリット・デメリットを教えてください。

①str.Equals("")
②String.Equals(str, "")
③str == ""
④srt.Length == 0
⑤"".Equals(str)

965:デフォルトの名無しさん
09/08/22 00:45:34
個人的には３
他は４以外objectで比較できちゃう
１４はstrがnullのときを考慮しないといけない

でも大体はString.IsNullOrEmptyで片付けるかな

966:デフォルトの名無しさん
09/08/22 00:46:47
あくまで個人的な意見だけど。
俺は「str==""」が一番シンプルかつ直感的でいいと思うね。

1. 参照アドレスの比較と差別化するという意味合いはご尤もだが…。ここまでする必要あるかなぁ。
2. 冗長。
4. 使う場面による。文字列自体に着目した流れで来てるのか、
　文字列の長さに着目した流れで来てるのか、というのが判断基準。
5. これは逆。どういう意図でこう書くんだろう。

967:デフォルトの名無しさん
09/08/22 00:58:15
5の書き方はJavaかなんかでこうするのがイイ
みたいなのがどっかに載ってた気がする(そして当然叩かれてた)

C#だと3かIsNullOrEmptyだよね。

968:デフォルトの名無しさん
09/08/22 01:05:59
fxcopにIsNullOrEmpty使えっていわれたような

969:デフォルトの名無しさん
09/08/22 01:14:50
C#の世界でも割と「==使うなEquals()使え」っていう教条主義的意見は
見かけるね。

というか、俺の見解では、そもそも==がデフォで参照等価の検査なのが直感的じゃない。
少なくともこれに関してはVBの方がまともに感じる。
つまり、参照等価の検査用には別の演算子を導入することにして、==の方は
値等価用にオーバーロードしないと使えない方が分かりやすい。

まあそれを言うと、そもそもC由来の=と==からして逆なんじゃないのかとも思うが…

970:デフォルトの名無しさん
09/08/22 01:34:35
しかし値の同一性ってのはデフォで定義できない

971:デフォルトの名無しさん
09/08/22 01:40:47
⑥str == string.Empty

972:デフォルトの名無しさん
09/08/22 01:42:52
IsNullOrEmpty 派です。

973:デフォルトの名無しさん
09/08/22 02:14:56
>>966
>5. これは逆。どういう意図でこう書くんだろう。
これはリテラルのequals()呼び出しだから、コンパイラが最適化してくれる
可能性がある、という説明で自分は納得した。
実際のところ本当かは検証したわけじゃないけど、どう再定義してるかわか
んないstrのequals()を呼び出すよりは速い可能性があるというだけで充分
に意味はあると考えてる。

974:デフォルトの名無しさん
09/08/22 02:22:55
Javaでの話だけど、str.equals("")だとstrがnullのときにぬるぽの例外になるので、
"".equals(str)がいいんだって言っていた。
でも、まともな意見の人は"".equals(str)に否定的な人が多いという印象。

975:デフォルトの名無しさん
09/08/22 02:25:37
君の印象ではなく「まともな意見」でどう否定したかが重要。

976:デフォルトの名無しさん
09/08/22 02:29:39
つか str.Equals("") とほぼ等価でかつ str が null でも大丈夫だから
だろ。2 と 3 がほぼ同じ意味であることを除けば他は意味とか前提が
色々微妙に違う

977:デフォルトの名無しさん
09/08/22 02:57:02
class Tuple<T1,T2>{ T1 _t1,T2 _t2}(アクセッサとか省略)みたいな奴で
Tuple<Hoge,HogeHoge> tuple1,tuple2の比較したいときに、class でなくstructなら_t1,_t2が各々==でtrueの時tuple1==tuple2になるんだっけ？
classでEqualsとかoverrideするのめんどくさいよ(´д｀)ﾏﾏﾝ…
属性とかの指定一発でやってくれ･･･

978:デフォルトの名無しさん
09/08/22 03:46:49
>>964
俺も>>971と同じ書き方するな。
でも null と空文字列で特別に違う意味がなければ IsNullOrEmpty を使う。

979:デフォルトの名無しさん
09/08/22 05:58:42
str.Equals(string.Empty)か
String.Equals(str,stringEmpty)
だな。

javaと違って参照でも'=='が使えるのは知ってるんだけどね。

980:デフォルトの名無しさん
09/08/22 06:46:21
String以外にも話を展開してみる。

Equalsはタイプセーフではない。
Equalsをoverrideするなら==、!=もoverrideしなければならない。
a.Equals(b)はnullチェックが面倒なので、Object.Equals(a,b)が有効。

981:デフォルトの名無しさん
09/08/22 06:50:49
タイプセーフでないというのは事実だけど、型を意識しないで比較するのは個人的にはなしだ。
ライブラリ製作者と使用者で意見が食い違うところか。

982:デフォルトの名無しさん
09/08/22 07:22:05
10.0と10は違うのか？→時と場合と人による
"a"と'a'は違うのか？→〃
10と10は違うのか？→〃

しかし”参照”としての比較はドメインが”参照”に固定されているので混乱しない
値の比較はドメインが固定できないので混乱する
値の比較であーだこーだ言っていてもはじまらね

983:デフォルトの名無しさん
09/08/22 07:35:17
>>968はこれか
URLﾘﾝｸ(msdn.microsoft.com)

それはそうと次スレは？

984:デフォルトの名無しさん
09/08/22 08:59:39
>>980
＞タイプセーフではない。（
値型以外では使うことはまずないけど
IEquatable<T>.Equals(T　o)
＞Equalsをoverrideするなら==、!=もoverrideしなければならない。　
Stringのようにimutableでない限りは==や!=演算子のoverrideはするべきではない。

985:デフォルトの名無しさん
09/08/22 11:02:53
なんで

986:デフォルトの名無しさん
09/08/22 12:31:41
次ぎたててくる

987:デフォルトの名無しさん
09/08/22 12:34:22
C#, C♯, C＃相談室 Part54
ｽﾚﾘﾝｸ(tech板)

はい

988:デフォルトの名無しさん
09/08/22 12:44:02
>>987
^^

989:デフォルトの名無しさん
09/08/22 13:00:55
.NET 4では2.0の部分のパフォーマンスの向上とかあるのかな？

990:デフォルトの名無しさん
09/08/22 13:09:55
BCL部分はC#4.0などにあわせて確実に手が入るけど
WinFormsはどうせ放置だろ

991:デフォルトの名無しさん
09/08/22 13:36:55
>WinFormsはどうせ放置だろ
せっかく枯れてきたのに手を入れられてもねぇ…

992:デフォルトの名無しさん
09/08/22 13:40:42
2005以降に追加されたコントロールのバグはしっかり直してくれないと
困ると思うけど…

toolstrip関連はバグ多過ぎなんだよ本当。