トップページ⇒tech
1001コメント291KB

ふらっとC#,C♯,C＃（初心者用） Part21

■ このスレッドは過去ログ倉庫に格納されています
0001ななしぃ#2007/11/18(日) 15:53:41
このスレッドは
「どんなにくだらないC#プログラミングに関する発言でも誰かが優しくレスをしてくれるスレッド」です。
ほかのスレッドでは恐ろしくて書き込めないような低レベル、もしくは質問者自身なんだか意味がよく分からない質問など、
勇気をもって書き込んでください。
内容に応じて、他スレ・他板へ行くことを勧められる、あるいは誘導される場合がありますがご了承下さい。

前スレ: ふらっとC♯, C＃（初心者用） Part20
http://pc11.2ch.net/test/read.cgi/tech/1191036844/
0545デフォルトの名無しさん2007/12/09(日) 22:04:17
ベースクラスのフィールドにアクセスしたり、ベースクラスのコンストラクタを明示的に呼びたいってことか？
それならできる
0546デフォルトの名無しさん2007/12/09(日) 22:05:05
あるプログラムA（EXE、すでに起動して無限ループで待機中）でメソッドを提供し、
別のプログラムB（ASP）でこれを呼び出したいのですが、何かうまい仕組みが提供されてたりしますか？
プロセス間通信を自前で実装するくらいしか思いつかないのですが…。
0547デフォルトの名無しさん2007/12/09(日) 22:05:56
それ具象やん
0548デフォルトの名無しさん2007/12/09(日) 22:09:27
フィールドのアクセス修飾子をprivateではなくprotectedにすれば、派生クラスからもアクセスできるようになる。
ベースクラスのコンストラクタを呼びたければ派生クラスのコンストラクタを

public B() : base()
{
}

のように書けばいい
0549デフォルトの名無しさん2007/12/09(日) 22:10:01
>>545
すいません、同じ違いでした。

型名やフィールド名が"同じという意味です。

B.x
B.y

C.x
C.y

これらを一つ一つ宣言するより、親クラスから継承して
例えば全てに0等を入れて初期化する場合、コンストラクタも一緒に継承できると便利だと思うんですが……
0550デフォルトの名無しさん2007/12/09(日) 22:13:17
>>549
出来るから手動かしてみな
0551デフォルトの名無しさん2007/12/09(日) 22:19:28
>>546
リモーティング
0552デフォルトの名無しさん2007/12/09(日) 22:25:24
>>549
A.xとB.xは同じフィールドじゃなくて、たまたま名前が同じだけってこと?
protected void init(ref int x, ref int y);
みたいなの定義しといて、各コンストラクタから呼び出すとか
05535522007/12/09(日) 22:26:08
定義しといて→Aに定義しといて
0554デフォルトの名無しさん2007/12/09(日) 22:43:41
多分>>544は>>552みたいに複雑なことをやろうとしてるんじゃなくて、
継承とインスタンスがどのように挙動するかわかってないだけだと思うのだが･･･
0555デフォルトの名無しさん2007/12/09(日) 22:44:17
protectedの意味が分かれば終了だろ
0556デフォルトの名無しさん2007/12/09(日) 22:57:20
と、いうわけでアクセス修飾子の話でも。

public　何処からでもアクセス可能(アクセスレベルが低いと表現)
↑
protected　派生クラスはアクセス可能
↓
private　自分しか無理。(アクセスレベルが高い)

クラスAにposX、posY、graphic、というフィールドがあれば、
クラスAを継承したクラスBも、そのフィールドを持つ。
それらのフィールドのアクセスレベルをprotectedにしておけば、派生クラスでもフィールドに自由に代入・取り出しできる。
もしprivateだと、それぞれフィールドは存在するのに一切派生クラスからはアクセスできない、ということになる。
この場合はプロパティを基本クラスで作っておけばすれば解決できる。(というかgetとsetのアクセスレベルを分けるから大抵はこっち？かな)




0557デフォルトの名無しさん2007/12/09(日) 23:00:22
フィールドをprotectedにしちゃうのはお勧めできない
初期化はたいてい基底クラスのコンストラクタを呼べば済む
0558デフォルトの名無しさん2007/12/10(月) 00:07:18
継承なんてすんなよ。
0559デフォルトの名無しさん2007/12/10(月) 04:22:03
てか、フィールドをprotectedにするのは禁止じゃなかったか。
プロパティなら良い。
0560デフォルトの名無しさん2007/12/10(月) 10:27:11
誰が？
0561デフォルトの名無しさん2007/12/10(月) 10:29:23
オレオレ
0562デフォルトの名無しさん2007/12/10(月) 11:25:16
とある機器からUDPでHTTP1.1なデータを送ってくるのですが
受信と解析するようなクラスはありますか？
0563↑2007/12/10(月) 11:28:01
受信だけはUdpClientでできるんですけど
0564デフォルトの名無しさん2007/12/10(月) 11:33:59
WebClient
0565デフォルトの名無しさん2007/12/10(月) 12:09:29
>>561
ttp://nasu.x0.com/blog/program/index_2.html
0566デフォルトの名無しさん2007/12/10(月) 15:03:48
例外が起こる前にifで避けるのと、起こってからtry-catchで対応するのとどっちがいいですか？
こういう時はtry-catchを使うという判断基準ってあるのでしょうか？
0567デフォルトの名無しさん2007/12/10(月) 15:09:44
モノによるけど私はifで避けれることはifで避けるようにしてる。
try-catchでしか回避できない仕様なら仕方なしに使う感じ
0568デフォルトの名無しさん2007/12/10(月) 15:29:29
例外をキャッチするとわけわかんなくなるから
ifで出来るものはifでやった方がいいよな
ArgumentExceptionとか例外が投げられること自体がバグの証明であるようなのは
どんどん投げるべき
そしてキャッチさせないべき
そのためにtryで囲ませないべき
tryで囲ませると往々にしてバグまで握りつぶしてしまう
05695662007/12/10(月) 15:57:42
事前に避けられそうな奴は避けるべきなんですね。
早速コード直してみます。
ありがとうございました。
0570デフォルトの名無しさん2007/12/10(月) 16:12:28
教えてください。
WebBrowserコントロールで、
Internet Explorer の [ファイル] メニューの [名前を付けて保存] メニュー オプションのような
機能を実装しようとしているのですが、
以下のようなコードですとエラーがでます。
どうすればいいんでしょう。。。

AxWebBrowser3.ExecWB( ShDocVw.OLECMDID_SAVEAS, ShDocVw.OLECMDEXECOPT.OLECMDEXECOPT_DODEFAULT);ですと
'ShDocVw' は現在のコンテキスト内に存在しません。
とエラーがでてしまったのですが。。。

0571デフォルトの名無しさん2007/12/10(月) 17:31:41
using ShDocVw;
0572デフォルトの名無しさん2007/12/10(月) 17:32:55
OLECMDID.OLECMDID_SAVEAS
0573デフォルトの名無しさん2007/12/10(月) 18:29:19
using ShDocVw;を追加したのですが以下のエラーが出ました。
型または名前空間名 'ShDocVw' が見つかりませんでした。
using ディレクティブまたはアセンブリ参照が不足しています。
0574デフォルトの名無しさん2007/12/10(月) 19:20:05
コントロールを削除してもソースにイベントハンドラが残るんですけど手動で削除するしかないんですか？
0575デフォルトの名無しさん2007/12/10(月) 19:44:30
勝手に消えても困るだろ？
0576デフォルトの名無しさん2007/12/10(月) 20:05:55
ほかから参照されていないとかの条件なら消すかどうかの選択肢はあってもいいかもね
0577デフォルトの名無しさん2007/12/10(月) 20:46:51
>>573
shdocvw.dll参照にいれたんじゃなくてWebBrowserコントロールか。

ShowSaveAsDialog ってメソッドがあるでしょ。
0578デフォルトの名無しさん2007/12/10(月) 21:18:12
ShowSaveAsDialog();は、AxWebBrowserにはないみたいです。
shdocvw.dllは、参照にいれる必要ないんですか？
0579デフォルトの名無しさん2007/12/10(月) 21:37:12
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=42629&forum=7
0580デフォルトの名無しさん2007/12/10(月) 21:42:19
どっちかの質問取り下げろやハゲ
0581デフォルトの名無しさん2007/12/10(月) 22:41:02
WebBrowserコントロールと書いておきながらaxWebBrowserなのか？
0582デフォルトの名無しさん2007/12/10(月) 23:05:26
>>566
おれはめちゃくちゃcatchしまくってるよ。
おかげでエラーチェックのifが少なくなって、ロジックが超すっきり。
0583デフォルトの名無しさん2007/12/10(月) 23:09:29
ifやめてcatchにする方が
どう繋がってるのか分かりにくい
0584デフォルトの名無しさん2007/12/10(月) 23:12:50
catchの方がコスト高いでしょ？
0585デフォルトの名無しさん2007/12/10(月) 23:19:28
たとえば、CSVを読み込んで、DBに入れるコードを書くとして、
TryPerse() でなくて、Prese()で、intに変換。
FormatExceptionが飛んだら、このCSVは不正ですって言って、処理終了。

これでなんにも問題ありません。
0586デフォルトの名無しさん2007/12/10(月) 23:21:09
まあ終了する時は例外ほど便利なものはない
0587デフォルトの名無しさん2007/12/10(月) 23:53:12
趣味グラマか
0588デフォルトの名無しさん2007/12/10(月) 23:56:38
エラーコードはまだいいけど
null返してきたりスルーしやがるメソッドはうざい
0589デフォルトの名無しさん2007/12/11(火) 00:04:21
nullを返すのとbool TryHoge(out result)と例外返すのとどれがいい
0590デフォルトの名無しさん2007/12/11(火) 00:13:41
s@;w@mee;@s4ezdwh;
0591デフォルトの名無しさん2007/12/11(火) 00:42:53
例外
0592デフォルトの名無しさん2007/12/11(火) 00:43:34
TryParseよりParseがいいってか
0593デフォルトの名無しさん2007/12/11(火) 00:47:03
メソッドが不可避な例外を投げる場合、キャッチしなければバグになるわけだ
そしてそれがバグであるかどうかはドキュメントをよく読まないと分からない
TryHogeならばifで囲まれていない時点でバグであることが見た瞬間に分かる
どっちがいいかは分かりきっている
0594デフォルトの名無しさん2007/12/11(火) 01:22:57
というか、これは自分の想像だから間違ってたらただして欲しいんだけど、
昔のCの、intでエラーコードを返すタイプの関数から、
今の、voidでエラーが起きたときは例外を投げるタイプのメソッドに推移というか、
後者が主になったのは、なんらかの理由があるからじゃないの？
TryParseとかはその流れに逆行してるように感じたんだけど…
0595デフォルトの名無しさん2007/12/11(火) 01:25:42
そりゃ、TryParseのほうがタイプ量少なくて済むからな。軽いし。
ただし、boolを返すTryXxxを作るときは、例外を投げるXxxも用意することになってる。
0596デフォルトの名無しさん2007/12/11(火) 01:34:04
例外には2種類あって、ArgumentExceptionのように投げられること自体が呼び出し側の
ミスによるものであり、除去すべきバグであることが明らかなものと、
ネットワークのサーバがダウンしている、ファイルが存在しないといった
正しい呼び出し方をしたとしても起こりうるエラーがある
大半は前者だ。バグだから直さなきゃいけないというのを通知するのには例外は適している
失敗の可能性が不可避なメソッドならば、例外を用いずによりわかりやすいTry〜のような
形を用いるべきだ
Tryの形式なら一目でバグと分かるのに、わざわざ例外を使って
バグと分かりにくいコードを書かせる必要なんか皆無だ
どちらにもいえることだが、例外はキャッチするものでは無い
0597デフォルトの名無しさん2007/12/11(火) 01:50:28
要するにポリシーとしては、使い方に因らないエラーが発生する場合は例外を投げ、
使い方に因ってエラーが発生する場合は戻り値で返せということですかね？
0598デフォルトの名無しさん2007/12/11(火) 01:58:51
正しい呼び出しをしてない場合は例外を投げ
正しい呼び出しをしてもエラーが不可避である場合はboolかなんかを返せということを俺はいいたい
0599デフォルトの名無しさん2007/12/11(火) 02:01:03
君C#向いてないよ
0600デフォルトの名無しさん2007/12/11(火) 02:02:45
>>599
>>596のようにしない方がいい理由がなにかいえるのか？
0601デフォルトの名無しさん2007/12/11(火) 02:05:45
Try形式だと基本bool値しか返ってこないけど
エラーに関してもっと詳しい情報を渡したい時には>>596のスタンス的にはどういう方法をとるの？
戻り値？引数？
0602デフォルトの名無しさん2007/12/11(火) 02:06:52
あ、割り込んじゃったけど>>601≠>>599です
0603デフォルトの名無しさん2007/12/11(火) 02:08:06
>>601
outでエラーの詳しい情報をobjectにして戻すのがいいと思っているが
それこそ例外をoutで返したらいい
0604デフォルトの名無しさん2007/12/11(火) 02:15:27
.NetFrameworkでそういった作りになってる物があるかな。
0605デフォルトの名無しさん2007/12/11(火) 02:19:16
投げずに渡す、か
正直それは考えた事なかったな
0606デフォルトの名無しさん2007/12/11(火) 02:22:15
.NET FrameworkにはTryParseのような一部のものしかそういう設計をとっていない
それは誤りだが今さら変えられない
.NET Frameworkで例外を返すのが使い物になるのはそれが共通であり
プログラマなら大抵そのクラスの動作を知っているからだ
自作のクラスでそれをやるのは死亡フラグそのものだ
0607デフォルトの名無しさん2007/12/11(火) 09:47:13
日本語でおｋ
0608デフォルトの名無しさん2007/12/11(火) 10:17:45
文字列をint型にキャストするには
　int.Parse(hogehoge)
等の方法でやっていますが、
変換する型そのものを文字列等で指定する方法がありますでしょうか？
0609デフォルトの名無しさん2007/12/11(火) 11:43:08
結局Win32のカオス具合をなぞってるだけだな
0610デフォルトの名無しさん2007/12/11(火) 11:51:29
>>608
それはキャストじゃなくて型変換（Convert）だろ。
TypeConverter/TypeDescriptor でも使えば？
0611デフォルトの名無しさん2007/12/11(火) 12:25:54
>>606
TryParseは2.0になって利便性のために新たに付け加えられたのであって、
決して「誤り」ではないよ。
0612デフォルトの名無しさん2007/12/11(火) 12:28:32
outで返すとC#でしか使えないことないか？

パラノイア的に統一性に拘らないのであれば（というのは、これに病的に固執する奴っているからね）
値を返さないメソッドに関してだけ例外を返すようにする（返値が必要なのは普通に例外投げる）
というやり方の方が俺は好きだな。
06136112007/12/11(火) 12:28:47
>>606
TryXの使い方のガイドラインあるから読んどけ
http://msdn2.microsoft.com/ja-jp/library/ms229009(VS.80).aspx
0614デフォルトの名無しさん2007/12/11(火) 13:29:25
>>612
outが嫌なら戻り値用の構造体を作ったっていい
>>613
パフォーマンス上の理由なんてのは的外れだ
その例外がめったに起こらなければ起こらないほど
例外のキャッチし忘れは深刻なバグになる
起こるか起こらないか分からないようなエラーが起こるものが
通常のメソッドと見た目全く同じに用意されていて
エラーにそなえてtryで囲めというのは間違い探しをしろといっているようなものだ
単に無駄だ
バグであることが分かりやすくなるように設計するべきだ
0615デフォルトの名無しさん2007/12/11(火) 13:30:22
平日の昼間っから暇なんだなあ
0616デフォルトの名無しさん2007/12/11(火) 13:41:10
なんでここは3行にまとめられない奴ばっかりなんだろ
0617デフォルトの名無しさん2007/12/11(火) 13:57:19
例外のキャッチし忘れはむしろ深刻にはならない。
0618デフォルトの名無しさん2007/12/11(火) 14:09:17
めったにないことだけどある環境では100回に1回ぐらい例外が投げられることがある
catchしてないのにテストをすり抜けてパッケージソフトとして出荷されてしまった
どうなる？
0619デフォルトの名無しさん2007/12/11(火) 14:14:53
例外は絶対投げちゃダメ！とかTryParseは誤り！とか言う事が極端だな
共有すべき普遍的な知識と自分だけの信念は区別しないと
0620デフォルトの名無しさん2007/12/11(火) 14:16:17
そんな事言ってる人居たっけ
0621デフォルトの名無しさん2007/12/11(火) 14:18:28
>>619
TryParseは正しい
正しく呼び出してもエラーが起こりうる場合例外は投げるべきじゃない
とは言った
0622デフォルトの名無しさん2007/12/11(火) 14:27:16
ちなみにTry〜を使うべきだと俺が考えるものには
メソッドが成功するかどうかが自分のプログラムの状態以外の要因で決まるもの(ハードディスクとかNetworkとか)と
それが正しい呼び出しであるかをテストする機能も正しい使い方のうちに含むもの(TryParse)と二通りある
0623デフォルトの名無しさん2007/12/11(火) 14:33:13
ここふらっとスレなんだけど。
0624デフォルトの名無しさん2007/12/11(火) 14:51:59
だからだろ
0625デフォルトの名無しさん2007/12/11(火) 15:12:12
>>618
キャッチし忘れのバグの方がキャッチもしくは例外をかわした場合のバグより
深刻にはならないって言ってるだけだよ。
0626デフォルトの名無しさん2007/12/11(火) 15:17:39
ある環境では100回に一回発生する例外を
常にちゃんと認識しててきっちり対処出来るんなら別だけどな。

あくまでバグがあった場合の話で、
バグがないならその方がいいに決まってる。
0627デフォルトの名無しさん2007/12/11(火) 15:29:08
>>626
しかしある種の例外は確率は低いけど不可避なわけだ
>>622の前者のようなのはそうだ

>>625
間違ってるのにエラーを返さない、例外を投げない
それはただのバグだが防ぐのは難しい
しかし例外のキャッチし忘れは簡単に防げる
防げるものは防いだほうがいいし、それが深刻になる場合だってある
0628デフォルトの名無しさん2007/12/11(火) 16:37:32
http://ufcpp.net/study/csharp/oo_exception.html

例外（exception）とは、本来ならばプログラム中で起こってはいけないことが起こってしまうことをいいます。
堅牢なプログラムを作成するためには、例外が起こったときでもプログラムが異常な動作をしないよう、
しっかりと例外処理（exception handling）を行う必要があります。

0629デフォルトの名無しさん2007/12/11(火) 16:44:57
ここが隔離スレになってるから有効に使ってくれ。
C♯, C＃相談室 Part34
http://pc11.2ch.net/test/read.cgi/tech/1162467959/l50
0630デフォルトの名無しさん2007/12/11(火) 17:04:09
今時戻り値だの構造体だのでエラー情報ずらずら返されたら
どうしようかと思うよ。
0631デフォルトの名無しさん2007/12/11(火) 17:18:14
じゃあメソッドの頭にTryとつけるだけでもいい
エラーが不可避ならばそれを分かりやすく示すべきだ
tryで囲んでないのが一目でバグと分かるように
0632デフォルトの名無しさん2007/12/11(火) 17:25:00
しかし例外の型は何が飛んでくるかわからないからな
バージョンアップで新しい例外が投げられるようになってキャッチできない可能性もあるし
outなり構造体なりで返ってくれば不可避な例外の基本クラスは分かるから
それを投げれば、バグによる例外を含まずにキャッチできる
とにかくcatch{}やcatch(Exception)だけはやってはいけないんだ
0633デフォルトの名無しさん2007/12/11(火) 17:47:00
catch(Exception ex) { ログ保存(ex); throw ex; } は時々やる。
0634デフォルトの名無しさん2007/12/11(火) 17:48:33
だからね、例外が深刻な状況につながることはあまりなくて、
むしろキャッチした上でのバグが深刻な状況につながるんだといってる
0635デフォルトの名無しさん2007/12/11(火) 17:53:23
深刻って何だろう
0636デフォルトの名無しさん2007/12/11(火) 17:58:59
>>633
それやるとデバッガが例外が起きた瞬間でブレイクしてくれないだろ
例外のメッセージの何十倍もその瞬間のブレイクの方が有用だし
0637デフォルトの名無しさん2007/12/11(火) 18:20:55
ケースバイケース
0638デフォルトの名無しさん2007/12/11(火) 18:43:20
>>634
何が言いたいのかよく分からん
それでどうするべきだと言ってるんだ？
0639デフォルトの名無しさん2007/12/11(火) 18:43:43
デバッガの使い方をまず身につけろよ。
最終的にはまず大抵どっかでキャッチするんだから
キャッチしたらアウトなんてのは使い物なならんだろ。

ただ、あえてやってるんじゃないなら
throw e;
はやめとけ。
throw;
でいい。
0640デフォルトの名無しさん2007/12/11(火) 18:45:34
とにかくキャッチすべき、キャッチしないバグは深刻
っていってるみたいだから、
キャッチするバグの方が大抵深刻だよっていってるだけ。
0641デフォルトの名無しさん2007/12/11(火) 18:47:10
ああちょっとちがうか…
キャッチしないバグは、深刻度は比較的低いってこと。
0642デフォルトの名無しさん2007/12/11(火) 18:48:48
何が起きてるか分からない、例外が飛んでこないバグに比べたらね。
0643デフォルトの名無しさん2007/12/11(火) 18:51:03
誰か例外関係のガイドライン書いてちょうだい
0644デフォルトの名無しさん2007/12/11(火) 18:55:18
>>639
大抵どっかでキャッチする時点でデバッガの使い方を間違えている
少なくとも開発中はバグによる例外はキャッチすべきではない
ブレイクすべきだ
キャッチするのはバグを握りつぶす効果しかない

バグでない不可避な例外の場合はキャッチして処理しなきゃならない
その場合でも不可避な例外の基本クラスを設けるとか、必要な処理はやらなきゃならない
漫然と例外を使うとひどいことになる
特にどっかでキャッチされるなんてのは最低の使い方だ

>>640
全然違う
俺はキャッチすべきでないといってる
確率的に低い不可避の例外をキャッチしないことは深刻なバグに繋がる
なら最初からboolを返すなりメソッドシグネチャに書いておくべきだ
■ このスレッドは過去ログ倉庫に格納されています