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

2021/03/23(火) 12:58:24.10

!extend:checked:vvvvv:1000:512
次スレを立てる時は↑を2行冒頭に書くこと（1行分は消えて表示されない為）

「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。
他のスレッドでは書き込めないような低レベルな質問、質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。
内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。
なお、テンプレが読めない回答者、議論をしたいだけの人は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスや酔っぱらいレスはやめてください
>>980を踏んだ人は新スレを建てて下さい。>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。

■前スレ
ふらっと C#,C♯,C＃（初心者用） Part149
http://mevius.5ch.net/test/read.cgi/tech/1608085775/
■関連スレ
C#, C♯, C＃相談室 Part94
https://mevius.5ch.net/test/read.cgi/tech/1553075856/
■コードを貼る場合は↓を使いましょう。
http://ideone.com/
https://dotnetfiddle.net/

■情報源
https://docs.microsoft.com/ja-jp/dotnet/standard/class-libraries
https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/
https://docs.microsoft.com/en-us/dotnet/standard/class-libraries
http://referencesource.microsoft.com/
・Insider.NET > .NET TIPS - ＠IT
https://www.atmarkit.co.jp/ait/subtop/features/dotnet/dotnettips_index.html
・DOBON.NET　.NET Tips
https://dobon.net/vb/dotnet/index.html
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2021/05/04(火) 14:50:23.97

初心者にまったく役に立たない話はここでしなきゃいいのでは？

2021/05/04(火) 14:52:35.33

別にね、アスペクト指向はルールベースでも良いのよ。
Rubyなんかだと命名でフックしたりするようにね。

2021/05/04(火) 15:04:03.10

>>741
属性はAOPに必須ではないが、ないと非常に大雑把な実装になり、挙動のコントロールが難しくなるため、実用上はほぼ必須だよ
太平洋横断に船は必須ではない、と言うようなものだ、最後の旅にならないといいね

いやいや、何もわかってない人にこそ、属性とはただのラベルでしかない、と説明したほうがいい
ただのラベルということを理解してないと、元の質問者のように属性には開発者メッセージを出力したり、色んなことができる、なにか不思議な力がある魔法の道具なのかな、と誤って認識してしまうんだ
1. 属性には本当にラベル以上の意味は何もないし、何もしない
2. 何かするのは、そのラベルを見て処理をするクライアントプログラム
3. 何をするかは、そのクライアントプログラム次第で全く異なる
これが属性の基本の基本な
このシンプルな3つの事実を教えないで、有耶無耶にはぐらかすと、初心者が属性を理解できなくなってしまう

2021/05/04(火) 15:07:33.04

ほぼ必須といったのは誤解を生むかもしれないな
デコレータのようなより洗練された機構が無く、AOPをメタプログラミングで実装する以外の選択肢に乏しい言語にとっては、ほぼ必須と訂正しておこう

2021/05/04(火) 15:16:46.55

だから、そんな話はしてないの。AOPとか。
デコレータの話が蛇足な上、その根拠のAOPの話が蛇足だったのよ。

属性はただのラベルではない。
誰かが読み取るためのラベル。
それはシリアライザだったり、コンパイラだったり、Webサーバのランタイムだったり様々だけど。
だから、Obsoleteなんかが意味を成すんであって。

現実的にC#の属性はAOPのためのものではない以上、蛇足そのものでしょ。
だから頭でっかちだと言ってるんだよ。

「ただのラベル」こそ「うやむやにはぐらかしてる」でしょ。

2021/05/04(火) 15:18:25.60

ふらっと C#,C♯,C＃（議論用） [無断転載禁止]©2ch.net
https://mevius.5ch.net/test/read.cgi/tech/1469538912/

2021/05/04(火) 15:18:59.72

じゃああっちで。

2021/05/04(火) 15:42:18.40

デコーダ太郎は責任とってクビ吊れ

2021/05/04(火) 15:43:52.50

>>746
>属性はただのラベルではない。
>誰かが読み取るためのラベル。
それをただのラベルっていうんだよ
読み取る側がそのラベルを見て何らかの作用を起こすまではなにもしない
まさにただのラベルだな

2021/05/04(火) 15:54:23.06

>>750
しつこいわ。

2021/05/04(火) 16:04:50.31

>>751
ええと
ブーメランってご存知？

2021/05/04(火) 16:08:55.98

お前の理想以外聞き入れないなら、ブーメランでもなんでもないわ。

2021/05/04(火) 16:10:37.11

というブーメランなのでした
ちゃんちゃん

2021/05/04(火) 17:28:51.83

>>723
ビルド時にカスタムのエラーや警告を出したいなら
Code Analyzer使って属性をチェックすればいい

2021/05/05(水) 09:44:41.21

昨日は頭のおかしい人が大活躍してたみたいだな
策っとNGしときましょう

2021/05/07(金) 00:21:29.88

WebClient使ってWebサイトのhtmlを文字列として取得したいんですが、
読み込みに数十秒かかるような重いページだと、途中でエラーします。
そんなページでもエラー無く読み取る方法有りますか？

2021/05/07(金) 00:26:59.06

Irvine

2021/05/07(金) 00:34:48.56

>>758
それはC#から呼び出して使えますか？

2021/05/07(金) 00:39:08.58

>>757
HttpClientクラス使った方が良いと思うけど
WebClientクラスの場合は、GetWebRequest()をオーバライドして
WebRequest.TimeoutプロパティとHttpWebRequest.ReadWriteTimeoutプロパティを設定

2021/05/07(金) 00:43:50.02

>>760
ありがとうございます。
>GetWebRequest()をオーバライド
は既に試したんですが、相変わらずエラーで中断します。
>HttpClientクラス使った方が良いと思うけど
それは何故でしょうか？

2021/05/07(金) 02:50:42.19

どんなエラーが出るのよ

2021/05/07(金) 03:48:20.57

DLしたいサイトのURL教えてもらっただけでだいぶはかどるよね。

2021/05/07(金) 04:25:10.15

中華から攻撃受けてるときの重いふたばとか

2021/05/07(金) 04:39:35.33

デフォルトだとタイムアウトが足りてないだけなんじゃないの?

2021/05/07(金) 05:39:50.22

> 途中でエラーします。
エラーしますとか変な日本語使う奴の相手はしない

2021/05/07(金) 08:08:05.60

エラーいたします。

2021/05/07(金) 08:28:13.14

エラーがございます

2021/05/07(金) 08:44:51.51

エラーなさる

2021/05/07(金) 11:18:16.60

エラーになられます

2021/05/07(金) 11:23:53.77

エラー仕る

2021/05/07(金) 12:35:02.79

エラー参上

2021/05/07(金) 12:37:58.01

>>764
ふたばってもう誰も見てないだろうけどどんな理由で攻撃してくるの？

2021/05/07(金) 15:59:09.92

尖閣諸島を渡せ

2021/05/07(金) 18:28:13.92

エラー渡し

2021/05/07(金) 21:30:40.73

エラー呼吸

2021/05/07(金) 21:31:58.32

さくらタンのエラー画像キボンヌ

2021/05/08(土) 00:36:51.80

(*´Д`)ﾊｧﾊｧ

2021/05/08(土) 11:24:07.14

くだらん

2021/05/08(土) 12:22:03.93

#region って使わない方が良いのですか？
プライベートメソッドがたくさんあるとき隠すのは駄目ですか？

2021/05/08(土) 12:29:25.27

好きにしたらいいよ
長いコードをリージョンで隠すより
短く書いたほうがいいと思うがね

2021/05/08(土) 13:33:49.15

ウザい
使うメソッドの周辺に置いておいてよ
publicとかprivateでリージョン切るやついるけどセンスの欠片もないな

2021/05/08(土) 13:41:33.11

積極的に使いたいとは思わないな＞#region

2021/05/08(土) 14:09:56.67

レガシーコード解読してるときに、コメントがてら一先ずregion使った

2021/05/08(土) 14:14:41.59

#region使わんといけないほどになったらクラス分けてほしいな
実際にはなかなかそういう自由はないかもしれないけど

2021/05/08(土) 14:16:26.79

分ける方向がクソなときにウザい
１つのpublicにいくつかのprivateがくっついてるのに
publicやprivateでリージョン切るなや下手クソ

2021/05/08(土) 14:18:11.82

>>780
身もふたもないけど使い方次第だね。

#regionディレクティブはコードを分類するのとあまり見る必要がないコードを隠すのに
使えるけど、後者の使い方はあまり必要がない

自分はデカいクラスでMSのドキュメントみたいにメンバーを種類ごとに分類するのに使ったり、
ある程度以上の規模のFormで例えばメニューのイベントハンドラを分類するのに使ってる

2021/05/08(土) 14:21:20.00

拡張のcodemaidで適当に分けてもらう

2021/05/08(土) 14:21:52.55

private隠す#regionは使うけどな。どのへんがダメ？

2021/05/08(土) 14:25:10.15

隠したくなるということは、隠さないと鬱陶しいぐらい長いコード、ということだから、そのあたりだろうね

2021/05/08(土) 14:28:22.99

呼び出し階層を無視して十把一絡げに「private」だけで括ろうとするのはどうかなとは思う

2021/05/08(土) 14:34:26.57

コードスメル的な意味かな？具体的に何が悪いのかよくわからんけど。

2021/05/08(土) 14:34:33.08

/// <summary>
/// ・・・
/// </summary>
private int mHoge;

/// <summary>
/// ・・・
/// </summary>
public int Hoge { get => 0 == this.mHoge ? 1 : this.mHoge; }

で、それぞれに同じコメント書くのが非常にだるい。
なにかうまい方法ないですか？

2021/05/08(土) 14:44:03.29

>>793
コレどう？

<inheritdoc> - C# プログラミングガイド | Microsoft Docs https://docs.microsoft.com/ja-jp/dotnet/csharp/programming-guide/xmldoc/inheritdoc

2021/05/08(土) 14:50:55.43

>>794
ぉぉ、コメントも継承できるんですね。
ありがとうございます、やってみます。

2021/05/08(土) 15:26:30.05

>>789
privateの意味を誤解してる気が

privateの意味はそのコードを利用する側の人は見る必要がないって意味だよね？
ソースコードを見てる人はその時点で「利用する側」か？
普通は違うよね？書く側の人に対して隠す意味は普通はない。

もちろん「まず見る必要がないから畳んでおきたい」需要が絶対にないとまでは言い切れんとは思うけど。

2021/05/08(土) 15:28:42.58

ちなみに、VSのエディタにはメソッドのシグネチャ以外の部分を畳む機能もあるけど俺はあれは嫌い。
ただの食わず嫌いかもしれないが

2021/05/08(土) 15:42:24.39

>>797
あー、それそれ。併用してCのヘッダみたいにして見てる。
ヘッダ代わりに毎回インターフェースを定義するのも面倒だしね。

2021/05/08(土) 16:10:59.65

長大なメソッドの中身をregion使って折りたたんだら短く見えるからいいよね

2021/05/08(土) 16:27:25.48

コンストラクタとかで引数チェックする場合ってDebug.Asset使う？　ifと組み合わせて例外投げる？

2021/05/08(土) 17:12:49.71

macOSに新しい.NET Core SDK/ .Net 5 SDKを入れ続けていると、何バージョン分もディレクトリが掘られて増えていきます
公式では、いらないものを単純にディレクトリごと削除して良いようなことが指示されていますが、これらのディレクトリのパスをdotnetコマンドに知らせている設定部分はどこにあるのですか？

2021/05/08(土) 17:41:35.40

ありがとうございますm(_ _)m
#region は気を付けます

2021/05/08(土) 18:05:57.33

>>800
コンストラクタで例外投げたくないな
引数はフィールドにセットするだけでそれ以外は基本しない
検証するなら別のメソッドにするかコンストラクタ隠蔽して検証しつつインスタンス返すstaticなメソッド作る

2021/05/08(土) 18:15:04.80

20年前に見たような話で頭がくらくらする

2021/05/08(土) 18:24:03.67

まあまあ

2021/05/08(土) 19:33:57.25

>>800
普通にifで調べて、普通に例外を投げてくれ
引数がおかしいならArgumentExceptionとか適当なのあるでしょ
引数が増えるとifを書くのがしんどくなるかもしれないが、そのときは関数化しよう

そもそもDebug.Assertは滅多に使わないものと考えていい
デバッグビルドとリリースビルドで挙動が違うというのは、それだけで本番でしか発生しないバグを生みかねないものなので、可能な限り避けるべきだ

コンストラクタで例外を投げたくないとか言ってる人は、気にしなくていい
昔はそういう流派もあったんだな、とでも考えてくれ

2021/05/08(土) 19:50:29.55

.net frameworkのコンストラクタでもそうやってた
今のは知らん

2021/05/08(土) 19:57:02.17

コンストラクタで例外投げろ
それ以外はゆるさない

XXX.Create("test");の戻り値nullチェックみたいのはバグの温床だから許さん

2021/05/08(土) 20:01:04.70

UnhandledExceptionの処理やるだろうしコンストラクタで例外投げてもいいと思うけどね

2021/05/08(土) 20:22:02.19

最近はそうなのか
自分も認識改めるわ

2021/05/08(土) 20:24:43.64

9.0のrecordってデータベースとのやり取りに使うシンプルなクラスには積極的に使っていったほうがええんかね？

2021/05/08(土) 20:46:20.44

単純計算の時間って完全に比例するんですか？
繰り返し処理で
10万回　2桁同士の掛け算を行う。
12万回　2桁同士の掛け算を行う。

これって後者のほうが平均とると必ず時間がかかるんですか？

2021/05/08(土) 20:51:21.18

コンストラクタで例外投げるかどうかは宗教論争感あると思うので棚上げにしてます。質問が悪かったです
自分が聞きたいことはDebugあるいはTraceのAssertメソッドの使い所でした

>>806
使い所ないんですかね
どんな値が渡されるのかわからない関数などは例外処理、その逆（外部に公開しない関数）の値チェックになら使えそうなのかなと思ったんですが
.Net1.1やその前からあるみたいなので、テストフレームワークが流通してないころに使われてた過去の遺産なのかな

2021/05/08(土) 22:58:15.52

>>812
汎用PCの場合
速度なんか測ったって
その場合はそうだったんだろとしか言いようがない
裏でウィルスバスターや
セキュリティソフトや
会社の監視ソフト
WindowsUpdateなど
色んな複合要素がありすぎてみんな速度なんか測るのやめちまったよ

2021/05/08(土) 23:37:30.49

>>813
検証処理が非常に高価な場合はDebug.Assertを使う理由にならんこともないが、そんなことは滅多にないよ
ほとんどの場合、検証は安価であり本番で検証をスルーしてしまうリスクとは比べるまでもない
C言語のようにほんの些細なオーバーヘッドすら嫌うような言語とは考え方が違う

2021/05/08(土) 23:47:06.02

そもそもアサーションをいつの段階で期待してんだ
まさか実運用環境をデバッグビルドで走らせるのか

コンストラクタでの例外は、やるなっていう言語が存在するのは確かだが、宗教以前に言語の問題
C#では別に問題なかったはず

2021/05/08(土) 23:50:56.30

Debug.Assert()はバグってる原因を探る時に、想定通りの値になっているかを確認する時に使うな
確認が終わったらソースから消すけど、万が一消し忘れても影響無いし
Trace.Assert()は使ったことない

2021/05/09(日) 00:29:36.29

803だけど昔「コンストラクタで例外投げたりアカンぞ」みたいなことを本で読んだ記憶があったんだがいま読み返したら完全に自分の記憶違いだった申し訳ない

2021/05/09(日) 00:51:47.19

職場でExcelVBAとACCESSをある程度動かせるようになったので、ステップアップしてC#を勉強してみたい。
勉強用のサイトやオススメの本などあったら、教えて頂けませんか？

2021/05/09(日) 01:01:53.07

2D格闘ゲームって3Dのapiがなくても作成可能ですか？
何か昔っぽいゲームを作りたくなってワクワクしてます。
環境はvisualstudioです。

2021/05/09(日) 02:07:45.79

誰か助けて。WebView2を使ったプログラムなんだけど
以前動くやつを作ったプロジェクトを今日久しぶりに触ったら
「System.NullReferenceException: 'オブジェクト参照がオブジェクトインスタンスに設定されていません。'」
と出てまったく動かなくなってしまってた… 一行も弄ってないのに
本当に何にも触ってないんだけど一体何が悪いのか。

2021/05/09(日) 02:15:39.31

>>820
速度イラネってなら別だが、2Dでも細かい事やろうとするとC#の手に余る
せめて描画エンジンはC/C++で書いた方がいい

**821** (ﾜｯﾁｮｲ 9f02-dxvU) · 2021/05/09(日) 02:55:26.73

原因が分かった。プロジェクトのディレクトリを移動すると動かなくなるみたい。
でも何故なの？どこを修正したら良くなるか誰かおしえて！

2021/05/09(日) 03:56:24.54

>>823
WebView2ランタイムが見つからないんだとエスパーすると、
ソース内でWebView2ランタイムの場所指定してるとこ要チェック。

2021/05/09(日) 08:16:13.97

>>819
c#でググるとすぐ出てくる入門サイト。
何故かというと、今後も何か調べるときにすぐ出てくるサイトだから。

2021/05/09(日) 09:32:19.94

>>819
ネットで漁る
独習C#
実戦で役立つ C#プログラミングのイディオム/定石&パターン

2021/05/09(日) 09:44:58.83

例外投げちゃいかんのはデストラクタでは

2021/05/09(日) 12:02:06.30

いやコンストラクタで例外投げるな、投げたい時にはファクトリーメソッドを使え、
という議論は確かに見たことある。

自分はコンストラクタで例外投げたいと思ったことがないので興味が持てず
詳細はよく覚えてないけど、それなりに説得力はあったような気がしたけどな

2021/05/09(日) 12:22:22.59

自分の知らんところでコンストラクタ使われたら例外拾えないとかそんな腐った理由だろう

何があってもインスタンスが帰って来る状態が欲しいんだろうがその後処理を誤ると簡単に詰む
そんな甘いことを言ってるとバグ作るだけ

2021/05/09(日) 12:33:09.11

>>825-826
アドバイスありがとう！

2021/05/09(日) 12:44:50.59

コンストラクタで例外投げるとオブジェクトが中途半端に作成されたものがゴミとして残るからだよ

2021/05/09(日) 13:18:38.53

・コンストラクタで例外おきるとデストラクタが呼ばれない説
　⇒確認できた
・デストラクタが呼ばれないのでGCされずにメモリリークが起きる説
　⇒確認できず。list.add(new Hoge())を1000回で、Hogeコンストラクタ内で例外起こすかどうかで確認。
　　例外起こさなければ使用メモリ増えるけど、例外ありの方は増えない。やり方が悪い？

メモリリーク云々はC++とかの話が元みたいで、それも例外投げるなではなく投げる場合は適切に参照を削除してから投げろみたいな話だったと思うのだが、
c#の方は問題ないのか？
標準ライブラリにもコンストラクタで例外返すやつあるのでそれの実装が見たい

2021/05/09(日) 13:21:46.98

残って気持ち悪いとしたらDispose持ちのネイティブリソースだろうけど
そのへんクリーン書こうとしたらファクトリメソッドでもやること変わらんでしょ

2021/05/09(日) 13:23:44.08

古いガイドラインだけど
＞✔ 必要な場合は、インスタンスコンストラクターから例外をスローします。
だからダメってことはないんだよね

コンストラクターのデザイン - Framework Design Guidelines | Microsoft Docs
https://docs.microsoft.com/ja-jp/dotnet/standard/design-guidelines/constructor

2021/05/09(日) 13:33:06.24

ちょっと大きめのメモリ割り当てたら1回の例外発生時にGC呼び出されてるのも確認できた

2021/05/09(日) 13:38:09.58

>>813
> どんな値が渡されるのかわからない関数などは例外処理、その逆（外部に公開しない関数）の値チェックになら使えそうなのかなと思ったんですが
ざっくりその認識で正しいよ
内部的にはあり得ない状態ならAssert投げる
デバッグ終えたら削除とかアホのやること
注意すべきなのはassertの条件の所に副作用を含む式を書いちゃいけないことぐらい

2021/05/09(日) 13:42:03.78

そもそもなんでもかんでもエラー処理を例外任せにするのが間違ってるような

2021/05/09(日) 13:46:49.04

C#ではコンストラクタで例外が出るとファイナライザが呼ばれないことから
コンストラクタでは例外を出すべきでないとする派閥が昔は存在した

しかしこれが問題になるのはコンストラクタでアンマネージドリソースを確保してDisposeで解放するパターンを採用したクラスだけだ
ネイティブライブラリをPInvokeで呼び出すような低レベルの仕事では気を付ける必要があるが
そうでなければ気にしなくてよい

またそのようなアンマネージドリソースを扱う場合でもC#ではSafeHandleを実装して使うことになっている
SafeHandleを使う側はリークをことさら恐れる必要はない
コンストラクタで例外を投げてもよろしい

2021/05/09(日) 13:48:56.57

>>833
例外投げるなら、その前に既にnewしたものを全部綺麗にDisposeしなきゃいけないわけだけど
そこまで考慮して正しく実装されたコンストラクタなんてドカタのコードで見たことないな
自分でthrowしなくても呼び出し先から例外が飛んでくるケースもあるから、本来は常に考慮が必要
あくまで可能性の問題としてだけど、コンストラクタで例外を投げるとDispose漏れが起こりやすいのは事実だと思うよ
漏れを完全に防げなくても、GC任せで問題にならない程度に頻度を抑えることはできる

2021/05/09(日) 13:53:06.35

>>836-837
ちょっと何いってるのかわからないw

>>838
なるほどね。
コンストラクタで例外投げてもほとんどの場合
問題がないことはよくわかったけど、
それでも個人的にはやっぱり避けるかな。

コンストラクタで例外が飛んでくることを想定してないプログラマが多い気がするから。
あえて違和感を感じさせるためにファクトリーにすると思う。
まあ屁のツッパリ程度の効果しかない気もするが。

2021/05/09(日) 13:53:17.09

>>836
プログラマが内部的にありえないと考えている状態が実際に発生するかしないかはプログラマにはわからない
それがバグというものの性質だ
バグはプログラマの意識の外からやってくる
プログラマが間違えるからバグが発生する

なので絶対に起こらないから本番では外しちゃえなどと安易に考えずに
俺の考えではまあまず起こらないと思うけどもし起こったらやばいから念の為に残しておこうと考えたほうがよい