[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 08/16 23:53 / Filesize : 244 KB / Number-of Response : 980
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

C#, C♯, C#相談室 Part46



1 名前:デフォルトの名無しさん [2008/04/22(火) 00:31:59 ]
(#゚ー゚)つ < C#、.NETの話題はこちらでどうぞ。
c++厨の嵐はスルー汁。

前スレ
C#, C♯, C#相談室 Part45
pc11.2ch.net/test/read.cgi/tech/1200911737/

その他テンプレ>>2-5くらい

159 名前:148 mailto:sage [2008/05/11(日) 17:40:01 ]
>>149
C側のイメージだと、
struct T_INFO_DATA
{
DWORD Id;
DWORD Fixed;
BYTE Array[48];
}

という認識です。
ポインタを送るほうがいいのでしょうか?

160 名前:デフォルトの名無しさん mailto:sage [2008/05/11(日) 19:23:15 ]
>>159
構造体メンバの固定長配列は、
unsafe 限定で fixed って構文がある。

ufcpp.net/study/csharp/sp_unsafe.html#fixed

161 名前:デフォルトの名無しさん mailto:sage [2008/05/12(月) 13:42:03 ]
属性使っていろいろする必要がある。
[StructLayout(LayoutKind.Sequential)]
public struct T_INFO_DATA { 
 public uint Id;
 public uint Fixed;
 [MarshalAs(UnmanagedType.ByValArray, SizeConst=48)]
 public byte[] Array;
};
なお、コンパイルは通してないからこのままでOKかどうかの保証はない。
あとは調べてくれ。


162 名前:148 mailto:sage [2008/05/13(火) 07:16:56 ]
>>161
ありがとうございます。
構造体をその記述にするだけでうまくいきました。

163 名前:デフォルトの名無しさん [2008/05/13(火) 15:55:00 ]
相談内容
RS232C通信のプログラムを作っているのですが、
デバックの効率化のために実際の通信内容を別Windownにてモニタリング
できないか検討してます。

本当はStreamにフックするだけで使えるものが他のデバックにも使えて
望ましいのですが、そんな便利なクラスってないれすか?


164 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 16:02:31 ]
.Net には、フックの類はないよ
自分がやるとしたら、Streamクラスから派生したクラスにフックコードを挿入したアダプタクラスを作って
RS232C通信をアプリ側でフックする
引き続いてWCFを使ってプロセス間通信ができるように、サービスを作って
別ウインドウで作ったデバッグウインドウは、そのサービスに接続して、状況を読み取るといった形式にすると思う。
ついでに、通信情報以外の各種情報もモニターできるようにするかな。

165 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 16:09:14 ]
昔、まさにそういうツールがフリーであって重宝したなあ。
NTで動いてたから、今でも使えるとは思うが何って言ったっけな。

166 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 16:12:25 ]
便利とは思うが、盗聴まがいのAPIはよろしくないから無くした方がいいと思う。
キーボードフックを筆頭に。

167 名前:163 mailto:sage [2008/05/13(火) 16:38:31 ]
>>164さん,165さん
レス有難う御座います。
アダプタクラスですか・・
腑抜けの私には、むりっぽそうですw。

申し訳ない、追加で質問なんですが、
フックがだめなら、
またStreamの中身を盗見することって難しいのでしょうか?

普通に考えると
ReadStreamは一度読み取ると消えちゃうし、
WriteStreamはそもそも読めないですよね。

これができれば、何とか簡易もどきが作れそうな気がするのですが




168 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 16:47:43 ]
>>167
中身みるよりアダプタの法がよっぽど楽だ、Streamクラスの抽象関数オーバーロードして、呼び出しをそのままReadStreamなりWriteStreamなりに渡せば以上終了だぞ。

169 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 16:53:10 ]
>>167
いい機会だからデザインパターンを勉強しような

170 名前:163 mailto:sage [2008/05/13(火) 16:57:26 ]
>>168
そうですか。了解です。

普段は組み込み関連の仕事が多いもので、
不慣れな環境なんで、他に良い手がないか、
無駄に時間をつぶして調べ回っていました。

アダプタ法で頑張ってみます。
勉強になります。有難う御座います!!

171 名前:163 mailto:sage [2008/05/13(火) 17:20:28 ]
ぐは、早くも生きづまった・・
SerialPortクラスのBaseStreamメンバはReadOnly・・・
Streamの継承クラスを渡せない・・
早くもだめぽw

そうすると専用のStreamReadrとWriterを自作するのが王道でしょうか?
それとも、SerialPortクラスを継承してメソッドを書き換えるか・・

>>169さん
アドバイス有難う御座います
今度本を買ってきます。
デザインパターンの根本的なところを理解していないのに、
何か作ろうとするから、いつもメタメタになる・・

172 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 17:39:58 ]
本買って読むのもいいが、この種の本は場数が足りんとどうせ読めんよ。
自分で頭をひねって考えるのが重要。
class MyStream : Stream
{
Stream rs232 = ここで、BaseStream を突っ込む
override 関数各種() { rs232.同名の関数() ; }
}
基本は、こうやって作る。とにかくオブジェクト図を描くこと。
オブジェクト間のメッセージ(関数の呼び出し)の接続が最少になるのはどういう時かよく考えること。
さっさとオブジェクト指向アプローチをおぼえて、古いやり方は捨てること。

173 名前:163 mailto:sage [2008/05/13(火) 17:55:08 ]
>>172さん
有難う御座います。
コードまで書いて頂き、お時間を取らせてしまって、
すいません。

なるほど!!、こうすればBaseStreamそのものがReadOnlyでも制御できる。
こうすれば、デフォルトのStreamReaderが使いまわせる。
つくづく自分の頭の固さが嫌になります。

>とにかくオブジェクト図を描くこと。
>オブジェクト間のメッセージ(関数の呼び出し)の接続が最少になるのはどういう時かよく考えること。
>さっさとオブジェクト指向アプローチをおぼえて、古いやり方は捨てること。
こういった、アドバイス非常にありがたいです。!!
自分でもあがいてはいるのですが、
周りにこういった話が出来る人がいないんです。

オブジェクト図ですね。書きまくって見ます!!

174 名前:163 mailto:sage [2008/05/13(火) 18:04:07 ]
>>172さん
まだいらっしゃるかな・・
>オブジェクト間のメッセージ(関数の呼び出し)の接続が最少になるのはどういう時かよく考えること。
もしよろしければ、この部分についてもう少し解説していただけないですか?
これは、どんなときに考えるのでしょうか。
クラスの責務の振り分け/分割時?
またメッセージの接続が最小になると、どんな良いことがあるのでしょうか?

質問ばかりですいません。


175 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 18:11:30 ]
オブジェクト指向のもっとも重要なポイントは、クラスではなくインスタンス。
インスタンスが主役であって、クラスはオマケ。継承がウンタラとかいう連中もいるが間違っているから相手にするな。
今四つのインスタンスがあるとする、それぞれ A , B , C , D
粒度が細かすぎて取り扱いにくいので、二つにまとめてみようと考えてみる。
インスタンスAがBを呼び出すなら
A --関数名--> B
と書いてみる。
まとめる方法は[A,B,C] [D]がよいか[A,B] [C,D]がよいか。
呼び出しが最少になるような図を考えてみよという事。
適当に矢印書きまくって、最小になるように分離してみるといい。
あとは応用。

176 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 18:56:57 ]
インスタンスが主役でクラスがおまけ、って俺には理解できない発想だマジで。
っていうか、それに類するような主張をこれまでに聞いたことがないよ。

177 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 19:06:45 ]
なにいってるかよくわからんが、継承か包含かちゅー話じゃないのか



178 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 19:12:02 ]
プロトタイプ指向のことなんじゃね

179 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 19:16:53 ]
インスタンスが主役w

180 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 19:21:47 ]
C#は型指向

181 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 20:35:08 ]
>>176
オブジェクト指向を扱っているサイトにいってみたら?
そうすれば無知も治るよ

182 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 20:39:21 ]
オブジェクト指向ではインスタンス(実体)は脇役だろう。

183 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 20:40:36 ]
>>182
今から15年前くらいは、確かにそういう事になっていたが、そのまま固まったか?

184 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 20:43:19 ]
Javaが登場して以降、体系的に研究されたオブジェクト指向もちょっとは勉強するといいよ。
でないと、デザインパターン意味や使い方など理解に及ぶことはできないし、上の例だって発想することすら難しいだろう。

185 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 20:46:44 ]
Javaと関係なく研究は進んでいたと思うんだけど。

186 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 20:50:18 ]
何言ってんの。
オブジェクト指向イコールJavaと言ってもいい程だよ。

187 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 20:52:15 ]
その進んだ研究を勉強していないのは駄目だという事だよ
今のライブラリは当たり前にその設計思想が入っているからな、知らないと使い方分らんだろ。



188 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 20:53:17 ]
>>186
ゴールじゃねぇよ、LINQとか見てみろ

189 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 20:54:35 ]
別にオブジェクト指向がどうとかこうとかどうでも良いよ

190 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 20:55:05 ]
インスタンスは実体。
お前はパソコンに文字を表示させるとき、直にVGAのメモリを書き換えるのか?違うだろう。
ドライバやらOSやらGDI+やらライブラリ郡など抽象化されたものを通してアクセスし表示させるだろう。

オブジェクト指向はインスタンス(実体)を直接操作せず、抽象化して利用しやすくする手法。
インスタンスがメインなわけがない。

191 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 20:55:55 ]
>>188
ゴールなんて関係ないこと持ち出して自ら否定して
結局何が言いたかったのかね。


192 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 20:56:37 ]
>>190
ヒント:言葉遊び


193 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 20:56:38 ]
>>190
そうだな、もう永久にそう思っていろよw

194 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 20:59:04 ]
>>190
そんな考えでも君のプログラムがちゃんと動くならそれでいいよ
それはそれで正しいわけだから


195 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 21:00:26 ]
良いコード:動くコード
悪いコード:動かないコード

196 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 21:05:01 ]
クラスが主役 に一致する日本語のページ 約 290,000 件中 1 - 10 件目 (0.30 秒)
インスタンスが主役 に一致する日本語のページ 約 1,790 件中 1 - 10 件目 (0.06 秒)

197 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 21:11:37 ]
タイヤキの型とタイヤキそのもの
どっちも主役です(ゆとり教育的発想)



198 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 21:34:08 ]
もうこの手の話がしたい奴はOOPスレ行った方がいいよ。
あそこは>>175的なトンチキな自説をぶってるアホが延々同じネタをループしてて楽しいと思うよ。
俺は正直吐き気がするけどねああいうの。

ちなみに>>190は半分はいいこと言ってると思うんだよね。
OOPというアイデアの肝は、>>190の言う抽象化(より正確には仮想化と言うべきだと思うけど)された
仮想機械をより直感的に表現するコーディング手法ということだと思う。

ただ「実体=インスタンス」ってのは全然意味不明だが。

199 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 21:36:29 ]
インスタンスの和訳が実体だろ・・・

200 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 21:43:41 ]
>>188
LINQはオブジェクト指向とはまた別だろ。
関数型プログラミングのほうが近い。

201 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 21:45:09 ]
なんか、こう訳わからん事になっているから、少し書くと
たとえば、C++でいう所の仮想テーブルは、virtual などなくても class のみで作り出すことができる。
これは非常に重要なことで、仮想テーブルは書き換えられないが、自分で作った仮想テーブルは書き換えられる。
このような実装は、Strategyパターンと呼ばれる。
つまり、classを使った抽象化は実は必要なく、ただ『頻繁に出てくるので言語上にvirtualとして実装しておくと便利であるという程度の意味』しかないのだ。
オブジェクト指向を理解する上で、この点について理解しているかどうかは決定的だ。
理解せずクラスと継承を中心に置くとやれる事が一気に限定されてしまうのだ。
さらには、継承には各種問題点も指摘されてり、特に深い継承は良くないと最近はされている。
また原則、継承を考える前にインターフェイスを検討するべきとされている。

参考コーディング規約
www.kawabata.com/dotnet/CodingStdCS.pdf
参考サイト
www.objectclub.jp/


202 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 21:49:06 ]
>>199
話の文脈を読まなきゃ。
>>190の言う「実体」とは「クラスによって抽象化される前の何者か」。

たとえばGDIならビデオカードやプリンタのハードウェアのことを「実体」といっている。
少なくとも話の前半ではね。

203 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 21:51:16 ]
>>201
それって結局、包含と委譲のことだろ。クラス対インスタンスという話ではない。
継承だけがクラスの特徴ってわけじゃないぞ。

204 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 21:51:26 ]
>>202
確かに変だな。

205 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 21:53:21 ]
>>203
つってもインスタンスを大量生産するための鋳型以上の意味もないだろ?

206 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 21:55:38 ]
>>175
ひょっとしてインターフェイスと書くところをインスタンスにしてしまって
引っ込みが付かなくなったとか。それなら文脈があうが・・・

207 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 21:57:38 ]
>>206
インターフェイスもインスタンスの一つと見なしてよいものだよ。
インターフェイスは取得するものだ。



208 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 21:58:17 ]
>>207
またまた荒れるような書き方をするな。

209 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 21:59:06 ]
いったい君たちは何の話をしてるの?
誰か頭のいい人ドラゴンボールに例えてくれよ

210 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 22:00:06 ]
ドラゴンボールの主人公はヤムチャなのか天津飯なのかと言う話

211 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 22:27:53 ]
実装と概念は分離して語れよ

212 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 22:30:20 ]
↑といいつつ乖離して語る馬鹿


213 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 23:10:09 ]
主役はキーボードを打つキミだ!!

214 名前:デフォルトの名無しさん mailto:sage [2008/05/14(水) 01:52:33 ]
>>209
サイヤ人→クラス
悟空→インスタンス

215 名前:デフォルトの名無しさん mailto:sage [2008/05/14(水) 01:57:38 ]
スーパーサイヤ人→スーパークラス

216 名前:デフォルトの名無しさん mailto:sage [2008/05/14(水) 04:08:51 ]
ブルー将軍→サブクラス

217 名前:デフォルトの名無しさん mailto:sage [2008/05/14(水) 06:42:59 ]
クラスもメタクラスのインスタンスだから、
インスタンスが主役ということでおk、みたいな話か?



218 名前:デフォルトの名無しさん mailto:sage [2008/05/14(水) 06:58:38 ]
決定的な違いは、メタ視点を持てているかどうかだろうな
明らかに不自由な設計やコーディングをしているのは明白なのだが
目が見えていないので、それを理解するのが困難になっているような気がする。

219 名前:163 mailto:sage [2008/05/14(水) 09:30:42 ]
皆さん、いろいろとアドバイス頂き有難う御座います。

すこしスレが荒れ気味ですが、これは私の無知を175さんが丁寧に
ご指導してくださった点から始まっているかと思います。
原因は私にあります。スレを汚して申し分けありません。

最近良く思うのですが、OOPの浸透が何故遅いかと、
1)基本概念と実装に大きな開きがありすぎる。
2)考え方に様々な歴史や諸説があり、人や本によって解釈が異なる。
(人によって解釈が異なるのは、読んだ本の年代が大きく依存しているんでしょうか・・)
の2点に集約してるかと思います。

OOPが不慣れなものにとっては
具体的な実装論はなかなか本の中には出てこず、
また、こーいう現場的な定石というのか考え方が定まらなくて、
悩んでいることが多いんです。

だから、175さんを始め皆様より貴重なアドバイスを頂いた件は、
非常に感謝しております。

インスタンスの件は、2論に分かれているかと思いますが、
これは馬鹿な私にでも分かるように説明した為の、言葉の綾かと思います。

長文になってしまい申し訳ありません。
とても勉強になりますた。
皆様を師匠と仰ぎ、また伺わせて頂きます!!

220 名前:デフォルトの名無しさん mailto:sage [2008/05/14(水) 12:43:48 ]
くだらない哲学論争は後回しにして、とりあえずクラスの利便性(哲学論争クンはこういう言い方に反発するようだけど)
を体得するのがいいと思うよ。っていうかそれが一番重要。
大して難しいことじゃないから使ってれば自然とわかるよそれは。

くれぐれもOOPを外から強制された義務的なものに過ぎない、などと考えないこと。
便利だから使われてるんだよ。

OOPが浸透してないとは俺には思えないけど、もしそうであるのなら
それはOOPが「つかえねえ」からじゃなくてこの業界に馬鹿が多いからだよw

221 名前:デフォルトの名無しさん mailto:sage [2008/05/14(水) 14:16:24 ]
質問です
UDPで受信したメッセージをテキストBOXに表示する処理の方法論です。
今は、UDP受信を別スレッドで受信して。セマフォー同期ででString変数に渡し。
フォームのプロセスで、タイマー関数からセマフォーを同期で文字列を受け取って
テキストBOXに表示しています。
しかし、今一つスマートでないような気がしてなりません。もっと良い方法がないでしょうか?

222 名前:デフォルトの名無しさん mailto:sage [2008/05/14(水) 14:38:37 ]
普通に Control.Invoke でいいんじゃねーの?

223 名前:デフォルトの名無しさん mailto:sage [2008/05/14(水) 15:20:18 ]
タイマースレッド内に、Invokeで受信部分を入れてみたのですが。
ダメみたいな感じでした。
問題点1 Invokeスレッドが終了しない。
問題点2 結局、セマフォーで受信の確認を取るので処理的に同じ。
ただし、使い方が悪いのかもしれない。

別スレッドから、フォームに非同期イベントが出せればいいのだけど、その方法を知らない。
きっと有るような気がします。すごく初歩的な機能かも知れない…

224 名前:デフォルトの名無しさん mailto:sage [2008/05/14(水) 15:36:47 ]
223が何を言ってるのか全く分からない
Invoke スレッドて何?

225 名前:デフォルトの名無しさん mailto:sage [2008/05/14(水) 16:14:15 ]
>>224
んなこと言ったら、余計意味不明な説明が始まりかねん

で、結論
Invokeの意味を理解できてない
Invokeの使い方が間違っている

226 名前:デフォルトの名無しさん mailto:sage [2008/05/14(水) 16:18:18 ]
>>225
>Invokeの意味を理解できてない
その可能性もある。
>Invokeの使い方が間違っている
この問題にInvokeが適用できない。又は、別つの方法があるが使用したくない。

ちなみに、Invokeの中は一つのスレッドであることは理解していますよね?

227 名前:デフォルトの名無しさん mailto:sage [2008/05/14(水) 16:54:08 ]
>>221
Control.Invokeが解っていないなら、
codezine.jp/a/article.aspx?aid=139




228 名前:デフォルトの名無しさん mailto:sage [2008/05/14(水) 17:32:06 ]
>>222-227
出来ました。 結論:Control.Invokeが解っていなかった。無知でした。
申し訳ありません。そしてありがとうございました。

229 名前:デフォルトの名無しさん mailto:sage [2008/05/14(水) 21:33:17 ]
本当の主役はテレビの前のあなたです!!m9ビシッ

230 名前:デフォルトの名無しさん mailto:sage [2008/05/14(水) 23:31:56 ]
定数の取り扱いについての質問です。

定数宣言
public enum 定数
{
MASU = 81,
}

変数の定数宣言
public const int MASU = 81;


この場合、配列列データ_創る場合。
private int[] tbl = new int[定数.MASU];

private int[] tbl = new int[MASU];
どちらも同じに見えるのですが。前者を使用したほうがベターですか?
前者の方が速いですか?


231 名前:デフォルトの名無しさん mailto:sage [2008/05/14(水) 23:37:25 ]
enumハックを思い出した

232 名前:デフォルトの名無しさん mailto:sage [2008/05/14(水) 23:46:14 ]
キモい命名法だ

233 名前:デフォルトの名無しさん mailto:sage [2008/05/14(水) 23:58:18 ]
>>230
速さは一緒
値自体に意味があるならenumじゃなくてconstの方が適切
でもpublicならconstじゃなくてstatic readonlyにした方がいい

234 名前:デフォルトの名無しさん mailto:sage [2008/05/15(木) 00:14:07 ]
>>233
知らなかった知識です、ありがとうございます。

235 名前:デフォルトの名無しさん mailto:sage [2008/05/15(木) 00:35:48 ]
constと(static )readonlyは全く別物だから、
ちゃんと調べて使い分けるようにした方がいい

236 名前:デフォルトの名無しさん mailto:sage [2008/05/15(木) 02:28:29 ]
>>235
どこがどう違うかを書いた方がいい

237 名前:デフォルトの名無しさん mailto:sage [2008/05/15(木) 02:44:41 ]
自分で書けよ



238 名前:デフォルトの名無しさん mailto:sage [2008/05/15(木) 02:48:18 ]
constに出来るものをstatic readonlyにした方がいい理由ってなんだよww

239 名前:デフォルトの名無しさん mailto:sage [2008/05/15(木) 03:26:42 ]
>>238
メモリの節約。

240 名前:デフォルトの名無しさん mailto:sage [2008/05/15(木) 03:30:00 ]
↑アホ

241 名前:デフォルトの名無しさん mailto:sage [2008/05/15(木) 06:17:51 ]
基本的にconstはクラス内でprivateに定義してその中だけで使用する。
constをアセンブリやnetmoduleまたがりで参照した場合、副作用がある。

S.DLLでpublic const A = 10
M.EXEで S.Aの表示 10
public const A = 99 に変更してS.DLLだけを再コンパイル。
M.EXEを再コンパイルしない限り結果は10のまま。

242 名前:デフォルトの名無しさん mailto:sage [2008/05/15(木) 07:48:45 ]
constを他のアセンブリから参照すると、参照元のアセンブリにも定数が埋め込まれる。後で値を変えたらさあ大変。
数学定数みたいに、絶対に値が変わることがないもの以外は、static readonlyにしたほうが無難。
あとはSizeとかDateTimeみたいに初期化の必要なものを、定数っぽく扱いたいときに。

243 名前:デフォルトの名無しさん mailto:sage [2008/05/15(木) 09:05:11 ]
それは完全に枝葉というか性質というか…全然別という意味分からないだろ
constはコンパイル時に値が確定される定数、readonlyは書き込み不可な変数。

見えてくる違いとしては、constはコンパイル時に評価されるので使える範囲がちょっと広い。
定数式しか許されない属性指定内部やswitchのcase句にも使用可能。これらに使用される場合境界越えで
あってもconstにする必要がある。

ちなみにenumの個々の値はconstなのでenumを等価に置き換えるならconstになる。

244 名前:デフォルトの名無しさん mailto:sage [2008/05/15(木) 09:25:48 ]
enumの値が変わったら大変なことになるんだな

245 名前:デフォルトの名無しさん mailto:sage [2008/05/15(木) 09:27:54 ]
外部に公開している列挙体を不用意に変更しちゃマズいのか。

246 名前:デフォルトの名無しさん mailto:sage [2008/05/15(木) 10:09:30 ]
>>242
これは知らなかった。勉強になる

247 名前:デフォルトの名無しさん mailto:sage [2008/05/15(木) 14:15:35 ]
ところでなんでcaseには定数しか書けないの?



248 名前:デフォルトの名無しさん mailto:sage [2008/05/15(木) 14:33:21 ]
定数じゃないと、複数該当することもあるからじゃない?
まあ上から順番に比較するような仕様のやつもあるが。

249 名前:デフォルトの名無しさん mailto:sage [2008/05/15(木) 17:34:50 ]
あとジャンプテーブル変換

250 名前:デフォルトの名無しさん mailto:sage [2008/05/15(木) 18:23:06 ]
実装を簡単にするための手抜き

251 名前:デフォルトの名無しさん mailto:sage [2008/05/15(木) 22:20:36 ]
かといってVBのSelectCaseは自由すぎると思わないか?

252 名前:デフォルトの名無しさん mailto:sage [2008/05/15(木) 23:37:20 ]
selectっていうのは0,1,2,3,4...
みたいに連番で並んでると
それを関数ポインタの配列みたいにしてジャンプすることが出来る
だから定数じゃないとどうしようもない

253 名前:デフォルトの名無しさん mailto:sage [2008/05/16(金) 02:00:26 ]
バカばっかw

254 名前:デフォルトの名無しさん mailto:sage [2008/05/16(金) 08:37:30 ]
↑暴走中。

255 名前:デフォルトの名無しさん mailto:sage [2008/05/16(金) 10:48:23 ]
>>251
バグを引き起こしかねない問題を含まない限り、自由度は高いに越したことはないよ
C#は新規なんだから、switch case の構文にこだわるべきじゃないとは思った
もともと、switch は C の特殊 goto label の構文な訳だし、考え方が古臭すぎる。
for 文からの脱出に break を使いたくても、switchにとられてしまうとかダサいと思うので。

256 名前:デフォルトの名無しさん mailto:sage [2008/05/16(金) 11:37:15 ]
フォールスルー不可能にもかかわらずbreak必須って時点で(ry

257 名前:デフォルトの名無しさん mailto:sage [2008/05/16(金) 11:38:59 ]
たしかに。
この辺何とかならなかったのか。
C、C++からの移行を意識してるならswitch caseと別の構文にすればいいしな



258 名前:デフォルトの名無しさん mailto:sage [2008/05/16(金) 11:57:33 ]
>>252
stringにもswitchは使える
その場合はif(str=="a") /*case a*/ else if(str=="b") /*case b*/ else if…
みたいなコードにコンパイルされる

259 名前:デフォルトの名無しさん mailto:sage [2008/05/16(金) 16:01:00 ]
>>258
たくさんあるとDictionaryを使うらしいぞ






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<244KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef