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

1 名前：名無C mailto:sage [2019/03/07(木) 06:35:41.12 ID:6L3KEJfe0.net] !extend:checked:vvvvv:1000:512 次スレを立てる時は↑を2行冒頭に書くこと（1行分は消えて表示されない為） 「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。 他のスレッドでは書き込めないような低レベルな質問、 質問者自身なんだか意味がよく分からない質問、 ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。 内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。 なお、テンプレが読めない回答者、議論をしたいだけの人は邪魔なので後述のC#相談室に移動して下さい。 C#に関係の無い話題や荒らしの相手や罵倒レスはやめてください >>980を踏んだ人は新スレを建てて下さい。 >>980が無理な場合、話し合って新スレを建てる人を決めて下さい。 ■関連スレ C#, C♯, C＃相談室 Part93 mevius.5ch.net/test/read.cgi/tech/1492818720/ ■前スレ ふらっと C#,C♯,C＃（初心者用） Part141 mevius.5ch.net/test/read.cgi/tech/1544839627/ ■コードを貼る場合は↓を使いましょう。 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/index https://docs.microsoft.com/en-us/dotnet/standard/class-libraries referencesource.microsoft.com/ VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured 542 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 12:00:49.48 ID:ASguEO4td.net] >>534 予期せぬ例外が起きたら発生箇所のスタックトレースを表示させてバグ修正に役立てるよ 客もその画面キャプチャを送ってくれる Execeptionにはそういうデバッグに役立つ情報入ってるからマジ便利だわ 543 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 12:01:52.85 ID:reMuF7mTd.net] >>535 客にスタックトレース見せちゃだめw 544 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 12:22:00.72 ID:yNGf8etVa.net] コンストラクタで例外を出すのが妥当なら出すべきだ しかし、例外を出すような責務は得てしてファクトリやリポジトリなど外部のクラスが担うことが多い傾向にある なので正確に言うと、オブジェクトの生成という責務を分離してない汚いプログラムはダメだ、なんだけど それが誤って拡散した結果、コンストラクタで例外を出すプログラムはダメだ、に拡大解釈されてしまったのだろう // コレは生成責務が分離されてないからダメだ class Hoge { public Hoge(int id) { var dto = DB.FindHoge(id); // 例外なげる m_id = id; m_name = dto.name; } // コレは責務が分離されてるからOK class HogeRepository { public Hoge Find(int id) { var dto = m_db.FindHoge(id); // 例外なげる return new Hoge(id, dto.name); // 実装次第で投げたり投げなかったり } // コレもOK 例外投げるが責務としては妥当 class Hoge { public Hoge(int id, string name) { if (id < 0) throw new BadHogeFormat("id"); if (UTIL.NotMatch(@"^H\d{8}$", name)) throw new BadHogeFormat("name"); m_id = id; m_name = name; } 545 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 13:20:27.71 ID:rUmkpmPg0.net] >>533 > コンストラクタで例外吐くのが望ましくないのはC++の話であって そんな話は聞いたことないが？ 546 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 13:38:48.88 ID:ibduGkrL0.net] C+の話は C+のコンストラクタとデストラクタの言語仕様をよく理解してない奴の誤解だから もともと正しくない 547 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 13:43:38.03 ID:bs+zTlgP0.net] >>539 お前はさっきから何の言語の話をしているんだ？ 548 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 13:45:42.92 ID:ibduGkrL0.net] 話しかけるなゴミが 549 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 13:46:18.87 ID:vrUpwJdGa.net] ダメも糞も引数が不適切なら例外投げるしかないねそもそもw もちろん（注意喚起とか）何らかの意図を持ってあえてコンストラクタではなく ファクトリーメソッドやTryCreateXxxxにする方法もあるけど、 少なくとも誰が考えても引数が不適切なら例外発生が予見できるなら コンストラクタで例外投げて何も問題ない 550 名前：デフォルトの名無しさん [2019/04/27(土) 16:53:30.48 ID:hssASZhyF.net] デストラクタで例外吐くのはあり？ 551 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 16:57:52.36 ID:krlg75LI0.net] どこならokとかngとかじゃなくて例外が発生したなら吐かなきゃ駄目 例外の前提を変えちゃ駄目 552 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 19:59:50.65 ID:UyCSNWt+M.net] >>543 基本的になし デストラクタの意味がなくなるから 553 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 20:00:47.02 ID:rUmkpmPg0.net] >>543 なし 554 名前：デフォルトの名無しさん [2019/04/27(土) 20:39:48.83 ID:ucBEJWSU0.net] デストラクタって解放し忘れたアンマネージドリソースの解放をするためにある奴でしょ？ ただそれだけの処理に例外とか要る？ 555 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 20:43:57.48 ID:xE/0VH9u0.net] >>547 どんな想定かわからないし入れたい人は入れればいいんじゃないの 556 名前：デフォルトの名無しさん [2019/04/27(土) 21:09:36.81 ID:ucBEJWSU0.net] C#のデストラクタは実行タイミングが不明な上に 他でキャッチできないからそのままクラッシュする事になるが それが目的なら 557 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 22:32:08.58 ID:krlg75LI0.net] デストラクタであろうと例外が発生したなら吐くべき デストラクタで例外なら大体最終的にアプリ落とす結果になるだろうけど 普通に設計すりゃまずデストラクタで例外が必要にはならんとは思うが 558 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 07:43:44.94 ID:Rwl5KJzI0.net] そりゃどこでも例外が出りゃ吐くべきだろ。デストラクタで出た例外は握りつぶせとでもいうのかよ 559 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 08:59:56.68 ID:vQlivpSSa.net] デストラクタの例外は運用に入ったらログ吐いて握り潰すしかない 開発中にどれだけ発見しきれるかが勝負 560 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 09:42:23.56 ID:3t4t6vYZM.net] 馬鹿しかいないのかな デストラクタで例外をキャッチすべきかじゃなくて デストラクタで例外を投げるべきかだろ 561 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 09:48:33.86 ID:3t4t6vYZM.net] どうみても例外をデストラクタで握りつぶすなんて話はしてない デストラクタで挙動がおかしな場合そこから自前で例外を投げるかどうかだろ どうしてこんな前提すらわからないのか？ 562 名前：デフォルトの名無しさん [2019/04/28(日) 10:20:38.37 ID:ddGaHMPJ0.net] デストラクタで例外投げるのは出来るけど デストラクタの呼び出し元はファイナライザースレッドになる故 デストラクタ以外の場所でキャッチして ログ記録したりは出来ないが、よろしいか？ 563 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 10:52:59.00 ID:F7dfQde00.net] ところで、C#ってコンストラクタで例外吐いたとき、インスタンスは生成されて戻されるの？ そのインスタンスのデストラクタは（実装してればどこかで）実行されるの？ 564 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 14:01:09.54 ID:Cfig35XD0.net] >>554 お前黙ってろよ… > デストラクタで挙動がおかしな場合そこから自前で例外を投げるかどうかだろ そんな話は>>545-546で既に終わってる 今の話は例えばデストラクタでファイルクローズした時そのメソッドで例外送出されたらどうするかって話な > どうしてこんな前提すらわからないのか？ わかってないのはお前だけ 565 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 14:02:16.88 ID:Cfig35XD0.net] >>556 > ところで、C#ってコンストラクタで例外吐いたとき、インスタンスは生成されて戻されるの？ されない > そのインスタンスのデストラクタは（実装してればどこかで）実行されるの？ されない 566 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 14:33:26.09 ID:18CJ+0uF0.net] ファイルクローズなんてデストラクタの仕事じゃないからクラス設計が間違ってる もしそうせざるを得ない理由があるならアプリ終了するだけ アプリ終了されて困るなら正しくクラス設計すればいい 567 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 15:52:04.90 ID:QPV4rne2d.net] >>559 例えばの話してんだからそこに文句付けるのはお門違い 568 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 17:06:19.94 ID:lUhOqb6w ] [ここ壊れてます] 569 名前：d.net mailto: >>560 例えだろうがなんだろうが結論は同じ [] [ここ壊れてます] 570 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 17:07:43.10 ID:3i1J1gafM.net] 年甲斐もなく疲れた お前らこんな所で何をやってんだ青瓢箪か？ 571 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 17:32:00.19 ID:+oA/oQuO0.net] ここでは例外の話でドンパチ よくのぞいてるVBAスレでもOn Errorの話でドンパチ どちらを見てるのかわからなくなってくる 572 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 17:38:04.38 ID:Cfig35XD0.net] >>559 > アプリ終了されて困るなら正しくクラス設計すればいい 具体的に書けないなら黙ってろってw 573 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 18:13:29.08 ID:KKCCRPTWa.net] デストラクタの中でファイル操作やクローズするのは間違ってるな そこで例外でたらどうしようもない ログ取るのも同じ 574 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 18:25:38.64 ID:kK/njqra0.net] メンバ変数を仕様上どうしてもDBから引っ張ってくるデータで初期化するしかなく、 コンストラクタ内でDB処理異常時に例外を吐く処理があります。 この場合コンストラクタ内では何もせず、インスタンス生成後にInit()のようなメソッドを 呼び出してもらうほうが使う側は楽でしょうか？ 575 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 18:31:50.14 ID:uWFo9H7Wa.net] そもそもC#でデストラクタに処理を書くこと自体が基本ありえないと思うんだけど・・・ リソースの解放なら（まともな構造のソースであれば）Dispose時に済ませるだろうし デストラクタにわざわざ処理を書いて、しかもその処理が例外を引き起こすパターンって 具体的にどんなのがありうるんだ？ 576 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 18:32:37.29 ID:lUhOqb6wd.net] >>566 コンストラクタで例外を吐いてください。 577 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 18:34:32.85 ID:lUhOqb6wd.net] >>564 ぜひ具体的に例示していただきたい。 578 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 18:39:48.98 ID:e0sCdFMHa.net] >>566 Init()を呼び忘れて使うリスクが出てくるので、インスタンス生成時に済ませたい派 ただDB関連では >>531-532 が言うように非同期処理をしたいだろうから 「コンストラクタはprivateにして、public staticなasyncファクトリを提供」が良いと思う インスタンス生成時に例外出る場合だと変数の宣言と初期化が分離するけど、C#だと初期化し忘れはエラーになるから許容範囲じゃないかな Foo foo; try { foo = CreateFoo(); } catch(BarException) { 何か復帰処理 } // 以下fooを使った処理 579 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 18:45:37.21 ID:3i1J1gafM.net] 器が小さい奴はすぐ引っ込みが着かなくなるから困ったものだ 580 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 18:46:32.36 ID:Cfig35XD0.net] >>569 MSがデストラクタからDispose呼んでるんだがw // Free any unmanaged objects here. で例外が発生するケースをどう扱うのか具体的に添削してやってくれ https://docs.microsoft.com/ja-jp/dotnet/standard/garbage-collection/implementing-dispose 581 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 18:47:40.42 ID:vQlivpSSa.net] >>566 >>537の考え方が正解 そういう時はファクトリーを使うという考え方が世界標準 582 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 18:56:32.95 ID:lUhOqb6wd.net] >>572 どう扱うも何もアプリ終了させろってだけだが？ ハンドリングすべきではないものをどうこうしよとしないで 583 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:02:39.46 ID:kMBz0MBMa.net] >>566 上にも書いたけど、あえてコンストラクタではなくstaticなTryCreateHogeみたいなのだけ提供して 注意喚起する方法もあると思うよ >>567 デストラクタの存在理由はClose/Disposeを忘れた場合のフェイルセーフなんで アンマネージドな共有リソースを占有するオブジェクトの場合はほぼ必須だし、 例外を投げるかどうかはともかく、デストラクタの中で例外的な事態が 発生することも普通にありえるとは思う。（例えばデバイスのクローズに失敗） 584 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:02:50.34 ID:lUhOqb6wd.net] どんなに丁寧に処理したって完全に例外を対応するなんてことは不可能 599の最後でちゃんとやれば良いokみたいに書いちゃったのが良くなかった ちゃんとやったって無理なことはある 585 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:06:45.39 ID:KKCCRPTWa.net] >>575 その使い方はダメだと思うけど… 586 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:09:47.55 ID:lUhOqb6wd.net] >>576 599じゃなくて559でした 587 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:10:36.56 ID:kMBz0MBMa.net] >>577 何がダメ？ フェイルセーフって意味分かりますか？ 588 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:17:31.79 ID:KKCCRPTWa.net] 無関係だけど一応答えるよ フェイルセーフって言うのは失敗しても安全な状態に落ち着くこと 例えば信号が壊れても青信号になるんじゃなくて赤信号になるような設計 ファイルクローズは別にフェイルセーフの概念と関係ない tryのfinallyはフェイルセーフじゃないよ 589 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:20:35.61 ID:Cfig35XD0.net] >>574 ああ、お前じゃ無理だったな、すまんw > アプリ終了されて困るなら正しくクラス設計すればいい とほざいてた>>559、出てこいやー 590 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:22:21.81 ID:fIrxxOza0.net] >>572 よく読め 591 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:22:22.23 ID:JJw12cyBa.net] リソースのライフタイムの管理とリソースを使用して何かする責務を別の責務として分離したほうがいい リソースの取得だけを分離する場合はファクトリーパターンが使われる ただしこの場合はリソースを閉じる責務とリソースを使用する責務が同じクラスに混在してしまう 結果としてデストラクタでの例外といった問題が連鎖して発生する これに対応するためにはファクトリーアイソレーションパターンを使う このパターンならリソースのライフタイム管理とリソースの使用を完全に分離できる コンストラクタでもデストラクタでもリソースの開閉に由来する例外は発生しなくなる 592 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:23:12.72 ID:KKCCRPTWa.net] デストラクタでたとえば解放忘れの大きなメモリを開放するとしても その前に他で大きなメモリを確保しようとすると死ぬ デストラクタでファイルのクローズ忘れをクローズしようとしても その前に他でファイルを開こうとするとエラーになる デストラクタでいろいろ開放しても何も助けてない 役に立ったとしても偶然であって実質はバグを握りつぶしてるだけ 593 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:25:35.89 ID:KKCCRPTWa.net] 今までアンカー売ってないけど>>579向け デストラクタで何か開放してもバグの温床になるだけ 594 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:26:43.51 ID:kMBz0MBMa.net] >>580 関係あるからw 同じことをくどくど書くのは嫌いだが、デストラクタの存在理由は コードの利用者がClose/Disposeを呼び忘れる、というヒューマンエラーに対するフェイルセーフ。 これは議論の余地はないよ 595 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:26:58.59 ID:KKCCRPTWa.net] みんなフェイルセーフって言葉を使うけど大体意味間違ってる 596 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:28:16.75 ID:uWFo9H7Wa.net] ああ、Dispose呼び出し忘れ対策のデストラクタか それなら、自分の場合は ・デストラクタには「Dispose(false)」以外書かない（trycatchもしない） ・Dispose()側が例外を投げるかどうかは解放するリソース次第 ・デストラクタの中に延々とリソース解放処理なりtry-catchが必要な処理なりを書いてるのだとすれば 　そのソースコードは根本的におかしい 597 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:30:31.27 ID:kMBz0MBMa.net] >>585 だから、デストラクタ「で」積極的にClose処理をするんじゃないの。 Close処理は普通にDispose/Closeに書くに決まっているわけだが、 使用者がそれを呼び忘れても最悪GCのお片付けのタイミングで Close処理が行われるようにするための仕組みがデストラクタ 598 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:32:19.82 ID:uWFo9H7Wa.net] ごめんもいっこ ・IDisposableなオブジェクトをDisposeせず使用している時点で実装不備とみなしてよい （フィールド変数だったらポカミスで解放し忘れはあるかもしれないけど、 　少なくともローカル変数ならusingを意図的に使ってない時点でコーダーが悪意を持ってると判断する） 599 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:32:33.80 ID:KKCCRPTWa.net] >>586 いつまで勘違いしてるのか？ フールプルーフとフェイルセーフは別物だからｗｗｗ 600 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:35:22.92 ID:JJw12cyBa.net] >>590 DIに管理させるからusingもDisposeもしないという構成は非常に多い 601 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:35:29.40 ID:KKCCRPTWa.net] 自分の使ってるコードで完結してるのにデストラクタでアンマネージなどのリソースを 開放するのは間違った使い方 いくら自信たっぷりに書いてるのか知らないけど間違ってる 602 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:44:53.23 ID:JJw12cyBa.net] >>593 知らない他人が何年後かに使うかもしれない だとしたら誤った使われ方でも最低限の安全性を確保できるように作るべき デストラクタでリソースを解放するのはアリ 603 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:47:01.57 ID:Cfig35XD0.net] >>582 そんなレスしかできないなら黙ってろよw 604 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:50:07.37 ID:KKCCRPTWa.net] >>594 IDisposable無視して放置する人を野放しにしないためにもデストラクタは不要だと思うわ デストラクタが呼ばれたか呼ばれないかで意図しないタイミングで不具合が出たりでなかったりするだけだろ そんなの余計に邪魔だろ 605 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:50:40.18 ID:uWFo9H7Wa.net] さすがに自前で生成してない（解放しなくていい）オブジェクトはわざわざ解放しないよ んーと、デストラクタを書かないといけないような処理があるならDispose(false)だけ書く、んだけど なにか間違ったこと言ったかな 606 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:53:00.38 ID:Cfig35XD0.net] >>590 > コーダーが悪意を持ってると判断する） お前の判断なんてどうでもいい MSはそんな判断してないからデストラクタからDispose呼んでるんだろうし 607 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:54:05.58 ID:uWFo9H7Wa.net] 書く必要がないデストラクタなら書かずに済ませるというのは同意 というか普段アンマネージドリソースなんて滅多にさわらないし まともにデストラクタを書いたのはいったい何年前だろう 608 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 20:00:46.55 ID:KKCCRPTWa.net] どうしてもデストラクタ使うなら解放忘れを解放するんじゃなくて デバッグ中に解放忘れてるぞコラということを伝える仕組みを作るほうがまともじゃないかな？ 自分の考えは>>584がほぼすべて 609 名前：デフォルトの名無しさん [2019/04/28(日) 20:04:36.28 ID:PHvM++pOM.net] >>566 ファクトリーメソッドを作って その中でInitすれば良かろう 610 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 20:21:04.08 ID:JJw12cyBa.net] 解放忘れを本気で潰そうと思ったらさっき書いたようにファクトリーアイソレーションパターンを使う Task ExecuteAsync(Func<ISomeResource, Task> job) { using (var resource = new SomeResource()) { await resource.OpenAsync(); await job?.Invoke(resource); await resource.CloseAsync(); } } サービス利用者には生成も解放もインターフェースを提供しない ExecuteAsyncを通さないとリソースにアクセスできないようにすれば解放忘れを完全に予防できる 611 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 20:28:37.93 ID:kMBz0MBMa.net] >>591 フールプルーフ（ばかちょん）は何をやっても致命的にならない、 というニュアンスの方が強い。 この場合はどっちでもいいと思うけどね 612 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 20:33:15.98 ID:3t4t6vYZM.net] >>603 ばかちょんじゃなくてバカヨケだぞ 適当なこと書くなよ 613 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 20:37:42.11 ID:kMBz0MBMa.net] >>604 それは直訳で、日本語では昔からばかちょんと言うんだよ 昔からというか昔はかもしれん。 俺もおじいさん先生からしか聞いたことない言葉だし まあポリコレの時代だしね 614 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 20:39:59.68 ID:3t4t6vYZM.net] バカチョンは意味が違う 615 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 20:42:39.60 ID:3t4t6vYZM.net] バカヨケ　失敗しないような仕組み バカチョン　誰でも使える 616 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 21:44:36.92 ID:nV7r0mI50.net] >>592 コンテナdisposeしたら、ついでに中身も自動でやってほしいよな・・・ 617 名前：デフォルトの名無しさん [2019/04/29(月) 12:55:34.62 ID:pjV/Nimc0.net] 横からすまんがさあ DIにMicrosoft.Extensions.DependencyInjection使ってるんだけど、これってコンテナから生成されたオブジェクトって永遠と生き続けるの？ どうやって開放するん？ 618 名前：デフォルトの名無しさん mailto:sage [2019/04/29(月) 13:05:11.30 ID:ehYnqzb50.net] >>609 Scopeでググれ 619 名前：デフォルトの名無しさん mailto:sage [2019/04/29(月) 13:39:51.85 ID:NUp+Ex1Ma.net] 基本的に生成元になったスコープをDisposeするとスコープ管理下のオブジェクトがまとめて消える スコープはCreateScopeで再帰的に生成できる BuildServiceProviderで作ったプロバイダーはルートのスコープに生えてるプロバイダーと考えればいい アッドシングルトンで登録したやつは親子関係にある全てのスコープで1つしか作れずルートスコープと寿命が同期 アッドスコープドで登録したやつは各スコープ内で1つしか作れず作ったスコープと寿命が同期 アッドトランジエントで登録したやつはスコープ内で何個でも作れて作ったスコープと寿命が同期 ASP.NET Coreでは暗黙的に1つのリクエストに1つのスコープを割り当てる 訂正あったらヨロ 620 名前：デフォルトの名無しさん [2019/04/29(月) 13:43:03.33 ID:pjV/Nimc0.net] Scope = Asp.net用みたいな気になっていて全然知らなかったよ、ありがとう ただDIなしの場合にusing句で書けるようなのはDIありでも簡単にかけそうだけど、オブジェクトを扱う箇所が数箇所に分かれてるときは難しそう・・・・ ScopeをDIコンテナに突っ込んだら突っ込んだでまた問題が増えるのかな・・・・ 621 名前：デフォルトの名無しさん mailto:sage [2019/04/30(火) 20:23:22.69 ID:IHLGrYrL0.net] System.Globalization.JapaneseCalendarでeraを取得しているんだけど Rが入ってこない・・・ Windows10でWindowsUpdateも最新なんだけど、何で入ってこないんでしょう 622 名前：デフォルトの名無しさん mailto:sage [2019/04/30(火) 20:28:08.43 ID:w+F7NKD3a.net] >>613 https://docs.microsoft.com/en-us/windows/uwp/design/globalizing/japanese-era-change > To test that your application works with the new era, you must advance your computer's clock to May 1, 2019 or later. PCの時刻設定を2019/05/01以降にする必要があるらしい 623 名前：デフォルトの名無しさん mailto:sage [2019/04/30(火) 20:38:50.44 ID:LbZ9KfXX0.net] まずまだアップデートはオプション段階だが、KB4493443入れてる？ 正式なWindowsアップデートは5月以降だよ 624 名前：デフォルトの名無しさん mailto:sage [2019/04/30(火) 20:45:03.73 ID:YvhWBPAF0.net] KB4493443って、Windows8.1用だったような。 ちなみに、Windows10, version1809用は「近日公開予定」だそうで。 https://support.microsoft.com/ja-jp/help/4469068/summary-of-new-japanese-era-updates-kb4469068 625 名前：デフォルトの名無しさん mailto:sage [2019/04/30(火) 21:35:51.80 ID:u6t/T7mma.net] もう元号とかやめて欲しいよねほんとw いい加減役所も西暦に一本化しろよ 626 名前：デフォルトの名無しさん mailto:sage [2019/04/30(火) 21:36:53.61 ID:TyGEr2d8a.net] 統一したら雑務が減っちゃうだろ 627 名前：デフォルトの名無しさん mailto:sage [2019/04/30(火) 22:02:27.50 ID:LbZ9KfXX0.net] >>616 訂正ありがと　手元にあるのが8.1で全部おんなじかと 628 名前：デフォルトの名無しさん mailto:sage [2019/05/01(水) 06:30:43.85 ID:+0nnIASf0.net] 皆さんレスどうもです まだ対応待ちってことですね・・・ とりあえずいまはテスト用にレジストリいじれるしかなさそうですね 629 名前：デフォルトの名無しさん [2019/05/01(水) 14:39:10.04 ID:NTU1YIA40.net] インデクサーってpublic T this[int I]{}みたいに定義するらしいけどさあ ここに出てくるthisの部分って、this以外も入りうる余地ってあるの？ 630 名前：デフォルトの名無しさん mailto:sage [2019/05/01(水) 14:49:13.86 ID:lxO04VNX0.net] >>621 無いよ this以外にするとインデックス付きプロパティって意味になると思うけど、c#には無い 631 名前：デフォルトの名無しさん mailto:sage [2019/05/01(水) 14:51:52.86 ID:U25K78xGa.net] >>621 https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/classes#indexers > indexer_declarator > : type 'this' '[' formal_parameter_list ']' > | type interface_type '.' 'this' '[' formal_parameter_list ']' > ; 入るのはthisだけで、this以外が入る余地はない 632 名前：デフォルトの名無しさん [2019/05/01(水) 15:04:58.50 ID:NTU1YIA40.net] ありがとう 無いものについてパッとわかるとか驚くぜ 633 名前：デフォルトの名無しさん mailto:sage [2019/05/02(木) 05:11:25.37 ID:fWQ7EMkU0.net] メモ https://www.enterprisedb.com/download-postgresql-binaries https://www.devart.com/odbc/postgresql/ https://visualstudio.microsoft.com/ja/thank-you-downloading-visual-studio/?sku=Community&rel=16 https://www.nuget.org/packages/MySql.Data/ https://www.nuget.org/packages/Npgsql/ https://www.nuget.org/packages/dotConnect.Express.for.PostgreSQL/ https://www.nuget.org/packages/Microsoft.Office.Interop.Excel/ https://www.pgadmin.org/download/pgadmin-4-windows/ https://dev.mysql.com/downloads/ 634 名前：デフォルトの名無しさん mailto:sage [2019/05/02(木) 06:26:48.77 ID:qeQLZJi00.net] そういうのはQiitaでやれ(Qiita警察激怒) 635 名前：デフォルトの名無しさん mailto:sage [2019/05/02(木) 12:04:50.67 ID:ir+Ne9RR0.net] メモ系ツールなんて山ほどあるのにわざわざこんなところに書くのか 俺こんなの調べてんだぜすごいだろ？みたいな承認欲求なのかね？ 636 名前：デフォルトの名無しさん mailto:sage [2019/05/02(木) 19:31:55.56 ID:Plm8DXbx0.net] 初心者ですが、乱数系列の初期化（Randomクラスのオブジェクトの生成）は どこに書くのが正解なんでしょうか？ 関数の中に書くと、関数が呼び出されるたびに初期化されるんじゃ？と思えるのでちょっと拙い 関数の外側にプログラムの初めの辺に書いておけばいいのかなあ？とも思うのですが、それもカッコ悪い 637 名前：デフォルトの名無しさん mailto:sage [2019/05/02(木) 19:36:11.39 ID:rtZHUO2Da.net] >>628 依存性として注入するのが定石 638 名前：デフォルトの名無しさん mailto:sage [2019/05/02(木) 20:19:04.27 ID:Plm8DXbx0.net] 依存性　注入で検索したらいろいろ出てきたので調べてみます 639 名前：デフォルトの名無しさん [2019/05/03(金) 03:27:08.36 ID:eVcW5sZJ0.net] >>628 最近のは年月日時分秒を整数にして種にしてるっぽいから、 毎回初期化の方がランダム性が高まるんじゃないかと思ってる。 640 名前：デフォルトの名無しさん mailto:sage [2019/05/03(金) 03:31:56.40 ID:t597qxt20.net] >>628 仕様次第 乱数の仕様を設計書に明記する必要がある 641 名前：デフォルトの名無しさん mailto:sage [2019/05/03(金) 12:41:41.06 ID:Xwdpydd1a.net] >>628 訳分からん解答が続いてるけど、素直に インスタンス固有である必要があるならコンストラクタに staticでよいなら静的コンストラクタに 書けばいいだけ。かっこ悪いとか、くだらないことに悩むのは時間の無駄。 この場合は不要だと思うけど、静的コンストラクタが実行されるのはそのクラスの 静的メンバーに初めてアクセスされたタイミングだと思ったので、その点は場合によっては注意 642 名前：デフォルトの名無しさん mailto:sage [2019/05/03(金) 12:51:40.57 ID:JARezKaea.net] >>633 嘘を教えるな そんな馬鹿な使い方をしたらテストできなくなるだろ

---

---

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

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