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

**名無C** ◆jPpg5.obl6 (ﾜｯﾁｮｲ 762c-FuHz) · 2019/03/07(木) 06:35:41.12

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

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

>>980を踏んだ人は新スレを建てて下さい。
>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。

■関連スレ
C#, C♯, C＃相談室 Part93
http://mevius.5ch.net/test/read.cgi/tech/1492818720/
■前スレ
ふらっと C#,C♯,C＃（初心者用） Part141
http://mevius.5ch.net/test/read.cgi/tech/1544839627/
■コードを貼る場合は↓を使いましょう。
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/index
https://docs.microsoft.com/en-us/dotnet/standard/class-libraries
http://referencesource.microsoft.com/

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

2019/04/27(土) 09:25:13.44

>>529
.NET Frameworkクラスもコンストラクタで例外投げるのに？

2019/04/27(土) 09:26:49.68

>>529
C++のその説は迷信だけど、C#では事実としてawaitができないという重大な制約があるからなあ
コンストラクタで例外を投げてはいけないわけではないが、そもそも例外を投げる可能性のあるような処理をコンストラクタでやらせることができるケースが少ないのは間違いない

**531** (ｱｳｱｳｴｰ Sa13-iwjh) · 2019/04/27(土) 09:33:56.80

もちろん、ArgumentNullExceptionのようにバグを検出してアプリを落とすことを目的とする例外は別だよ
そういうのを除けば、例外を投げうる処理ってのはだいたいIOを含んでいてawaitが必要になるケースが多い

2019/04/27(土) 09:36:37.55

いまだにオブジェクト倶楽部のをベースにしたC#コーディング規約なのかな
10年くらい前の時点でも悪評ぷんぷんだったのにどれだけ時代遅れなことしてるんだ

コーディング規約作ってる奴のスキルが低い／古すぎ／多言語の知識しか持ち合わせてなくて
クソな規約になってることはよくある
コンストラクタで例外吐くのが望ましくないのはC++の話であってC#ではそんなこと全然ない
例外すべて列挙しなきゃいけないのはJavaの話であってC#にもそれを持ち込むのはナンセンス

でも大抵規約のクソさ加減と規約作成者・組織の老害度は比例するんだよな
指摘しても直ることはないだろうから「これはクソなコードだ」と自覚を持ったうえで
規約通りのコードを書くしかない

2019/04/27(土) 11:46:22.17

>>527
それって制御できないって言ってるんだよね？
その時はtry catchで握り潰せばいいんだけど
君はどうなればいいと思ってるの？

ある日例外が起きてアプリが止まっちゃってもそれは時代の流れでしょうがないと思ってるってこと？

**デフォルトの名無しさん** (ｽﾌｯ Sd43-jluM) · 2019/04/27(土) 12:00:49.48

>>534
予期せぬ例外が起きたら発生箇所のスタックトレースを表示させてバグ修正に役立てるよ
客もその画面キャプチャを送ってくれる
Execeptionにはそういうデバッグに役立つ情報入ってるからマジ便利だわ

2019/04/27(土) 12:01:52.85

>>535
客にスタックトレース見せちゃだめw

2019/04/27(土) 12:22:00.72

コンストラクタで例外を出すのが妥当なら出すべきだ
しかし、例外を出すような責務は得てしてファクトリやリポジトリなど外部のクラスが担うことが多い傾向にある
なので正確に言うと、オブジェクトの生成という責務を分離してない汚いプログラムはダメだ、なんだけど
それが誤って拡散した結果、コンストラクタで例外を出すプログラムはダメだ、に拡大解釈されてしまったのだろう

// コレは生成責務が分離されてないからダメだ
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;
}

2019/04/27(土) 13:20:27.71

>>533
> コンストラクタで例外吐くのが望ましくないのはC++の話であって
そんな話は聞いたことないが？

2019/04/27(土) 13:38:48.88

C+の話は
C+のコンストラクタとデストラクタの言語仕様をよく理解してない奴の誤解だから
もともと正しくない

2019/04/27(土) 13:43:38.03

>>539
お前はさっきから何の言語の話をしているんだ？

2019/04/27(土) 13:45:42.92

話しかけるなゴミが

2019/04/27(土) 13:46:18.87

ダメも糞も引数が不適切なら例外投げるしかないねそもそもw

もちろん（注意喚起とか）何らかの意図を持ってあえてコンストラクタではなく
ファクトリーメソッドやTryCreateXxxxにする方法もあるけど、
少なくとも誰が考えても引数が不適切なら例外発生が予見できるなら
コンストラクタで例外投げて何も問題ない

2019/04/27(土) 16:53:30.48

デストラクタで例外吐くのはあり？

2019/04/27(土) 16:57:52.36

どこならokとかngとかじゃなくて例外が発生したなら吐かなきゃ駄目
例外の前提を変えちゃ駄目

2019/04/27(土) 19:59:50.65

>>543
基本的になし
デストラクタの意味がなくなるから

2019/04/27(土) 20:00:47.02

>>543
なし

2019/04/27(土) 20:39:48.83

デストラクタって解放し忘れたアンマネージドリソースの解放をするためにある奴でしょ？
ただそれだけの処理に例外とか要る？

2019/04/27(土) 20:43:57.48

>>547
どんな想定かわからないし入れたい人は入れればいいんじゃないの

2019/04/27(土) 21:09:36.81

C#のデストラクタは実行タイミングが不明な上に
他でキャッチできないからそのままクラッシュする事になるが
それが目的なら

2019/04/27(土) 22:32:08.58

デストラクタであろうと例外が発生したなら吐くべき
デストラクタで例外なら大体最終的にアプリ落とす結果になるだろうけど
普通に設計すりゃまずデストラクタで例外が必要にはならんとは思うが

2019/04/28(日) 07:43:44.94

そりゃどこでも例外が出りゃ吐くべきだろ。デストラクタで出た例外は握りつぶせとでもいうのかよ

2019/04/28(日) 08:59:56.68

デストラクタの例外は運用に入ったらログ吐いて握り潰すしかない
開発中にどれだけ発見しきれるかが勝負

2019/04/28(日) 09:42:23.56

馬鹿しかいないのかな

デストラクタで例外をキャッチすべきかじゃなくて
デストラクタで例外を投げるべきかだろ

2019/04/28(日) 09:48:33.86

どうみても例外をデストラクタで握りつぶすなんて話はしてない

デストラクタで挙動がおかしな場合そこから自前で例外を投げるかどうかだろ
どうしてこんな前提すらわからないのか？

2019/04/28(日) 10:20:38.37

デストラクタで例外投げるのは出来るけど
デストラクタの呼び出し元はファイナライザースレッドになる故
デストラクタ以外の場所でキャッチして
ログ記録したりは出来ないが、よろしいか？

2019/04/28(日) 10:52:59.00

ところで、C#ってコンストラクタで例外吐いたとき、インスタンスは生成されて戻されるの？
そのインスタンスのデストラクタは（実装してればどこかで）実行されるの？

2019/04/28(日) 14:01:09.54

>>554
お前黙ってろよ…
> デストラクタで挙動がおかしな場合そこから自前で例外を投げるかどうかだろ
そんな話は>>545-546で既に終わってる
今の話は例えばデストラクタでファイルクローズした時そのメソッドで例外送出されたらどうするかって話な

> どうしてこんな前提すらわからないのか？
わかってないのはお前だけ

2019/04/28(日) 14:02:16.88

>>556
> ところで、C#ってコンストラクタで例外吐いたとき、インスタンスは生成されて戻されるの？
されない

> そのインスタンスのデストラクタは（実装してればどこかで）実行されるの？
されない

2019/04/28(日) 14:33:26.09

ファイルクローズなんてデストラクタの仕事じゃないからクラス設計が間違ってる
もしそうせざるを得ない理由があるならアプリ終了するだけ
アプリ終了されて困るなら正しくクラス設計すればいい

2019/04/28(日) 15:52:04.90

>>559
例えばの話してんだからそこに文句付けるのはお門違い

2019/04/28(日) 17:06:19.94

>>560
例えだろうがなんだろうが結論は同じ

2019/04/28(日) 17:07:43.10

年甲斐もなく疲れた
お前らこんな所で何をやってんだ青瓢箪か？

2019/04/28(日) 17:32:00.19

ここでは例外の話でドンパチ
よくのぞいてるVBAスレでもOn Errorの話でドンパチ
どちらを見てるのかわからなくなってくる

2019/04/28(日) 17:38:04.38

>>559
> アプリ終了されて困るなら正しくクラス設計すればいい
具体的に書けないなら黙ってろってw

2019/04/28(日) 18:13:29.08

デストラクタの中でファイル操作やクローズするのは間違ってるな
そこで例外でたらどうしようもない
ログ取るのも同じ

2019/04/28(日) 18:25:38.64

メンバ変数を仕様上どうしてもDBから引っ張ってくるデータで初期化するしかなく、
コンストラクタ内でDB処理異常時に例外を吐く処理があります。

この場合コンストラクタ内では何もせず、インスタンス生成後にInit()のようなメソッドを
呼び出してもらうほうが使う側は楽でしょうか？

2019/04/28(日) 18:31:50.14

そもそもC#でデストラクタに処理を書くこと自体が基本ありえないと思うんだけど・・・
リソースの解放なら（まともな構造のソースであれば）Dispose時に済ませるだろうし

デストラクタにわざわざ処理を書いて、しかもその処理が例外を引き起こすパターンって
具体的にどんなのがありうるんだ？

2019/04/28(日) 18:32:37.29

>>566
コンストラクタで例外を吐いてください。

2019/04/28(日) 18:34:32.85

>>564
ぜひ具体的に例示していただきたい。

2019/04/28(日) 18:39:48.98

>>566
Init()を呼び忘れて使うリスクが出てくるので、インスタンス生成時に済ませたい派
ただDB関連では >>531-532 が言うように非同期処理をしたいだろうから
「コンストラクタはprivateにして、public staticなasyncファクトリを提供」が良いと思う

インスタンス生成時に例外出る場合だと変数の宣言と初期化が分離するけど、C#だと初期化し忘れはエラーになるから許容範囲じゃないかな
Foo foo;
try { foo = CreateFoo(); }
catch(BarException) { 何か復帰処理 }
// 以下fooを使った処理

2019/04/28(日) 18:45:37.21

器が小さい奴はすぐ引っ込みが着かなくなるから困ったものだ

2019/04/28(日) 18:46:32.36

>>569
MSがデストラクタからDispose呼んでるんだがw
// Free any unmanaged objects here.
で例外が発生するケースをどう扱うのか具体的に添削してやってくれ
https://docs.microsoft.com/ja-jp/dotnet/standard/garbage-collection/implementing-dispose

2019/04/28(日) 18:47:40.42

>>566
>>537の考え方が正解
そういう時はファクトリーを使うという考え方が世界標準

2019/04/28(日) 18:56:32.95

>>572
どう扱うも何もアプリ終了させろってだけだが？
ハンドリングすべきではないものをどうこうしよとしないで

2019/04/28(日) 19:02:39.46

>>566
上にも書いたけど、あえてコンストラクタではなくstaticなTryCreateHogeみたいなのだけ提供して
注意喚起する方法もあると思うよ

>>567
デストラクタの存在理由はClose/Disposeを忘れた場合のフェイルセーフなんで
アンマネージドな共有リソースを占有するオブジェクトの場合はほぼ必須だし、
例外を投げるかどうかはともかく、デストラクタの中で例外的な事態が
発生することも普通にありえるとは思う。（例えばデバイスのクローズに失敗）

2019/04/28(日) 19:02:50.34

どんなに丁寧に処理したって完全に例外を対応するなんてことは不可能
599の最後でちゃんとやれば良いokみたいに書いちゃったのが良くなかった
ちゃんとやったって無理なことはある

2019/04/28(日) 19:06:45.39

>>575
その使い方はダメだと思うけど…

2019/04/28(日) 19:09:47.55

>>576
599じゃなくて559でした

2019/04/28(日) 19:10:36.56

>>577
何がダメ？
フェイルセーフって意味分かりますか？

2019/04/28(日) 19:17:31.79

無関係だけど一応答えるよ

フェイルセーフって言うのは失敗しても安全な状態に落ち着くこと
例えば信号が壊れても青信号になるんじゃなくて赤信号になるような設計

ファイルクローズは別にフェイルセーフの概念と関係ない
tryのfinallyはフェイルセーフじゃないよ

2019/04/28(日) 19:20:35.61

>>574
ああ、お前じゃ無理だったな、すまんw

> アプリ終了されて困るなら正しくクラス設計すればいい
とほざいてた>>559、出てこいやー

2019/04/28(日) 19:22:21.81

>>572
よく読め

2019/04/28(日) 19:22:22.23

リソースのライフタイムの管理とリソースを使用して何かする責務を別の責務として分離したほうがいい

リソースの取得だけを分離する場合はファクトリーパターンが使われる
ただしこの場合はリソースを閉じる責務とリソースを使用する責務が同じクラスに混在してしまう
結果としてデストラクタでの例外といった問題が連鎖して発生する

これに対応するためにはファクトリーアイソレーションパターンを使う
このパターンならリソースのライフタイム管理とリソースの使用を完全に分離できる
コンストラクタでもデストラクタでもリソースの開閉に由来する例外は発生しなくなる

2019/04/28(日) 19:23:12.72

デストラクタでたとえば解放忘れの大きなメモリを開放するとしても
その前に他で大きなメモリを確保しようとすると死ぬ

デストラクタでファイルのクローズ忘れをクローズしようとしても
その前に他でファイルを開こうとするとエラーになる

デストラクタでいろいろ開放しても何も助けてない
役に立ったとしても偶然であって実質はバグを握りつぶしてるだけ

2019/04/28(日) 19:25:35.89

今までアンカー売ってないけど>>579向け

デストラクタで何か開放してもバグの温床になるだけ

2019/04/28(日) 19:26:43.51

>>580
関係あるからw

同じことをくどくど書くのは嫌いだが、デストラクタの存在理由は
コードの利用者がClose/Disposeを呼び忘れる、というヒューマンエラーに対するフェイルセーフ。

これは議論の余地はないよ

2019/04/28(日) 19:26:58.59

みんなフェイルセーフって言葉を使うけど大体意味間違ってる

2019/04/28(日) 19:28:16.75

ああ、Dispose呼び出し忘れ対策のデストラクタか
それなら、自分の場合は
・デストラクタには「Dispose(false)」以外書かない（trycatchもしない）
・Dispose()側が例外を投げるかどうかは解放するリソース次第
・デストラクタの中に延々とリソース解放処理なりtry-catchが必要な処理なりを書いてるのだとすれば
　そのソースコードは根本的におかしい

2019/04/28(日) 19:30:31.27

>>585
だから、デストラクタ「で」積極的にClose処理をするんじゃないの。

Close処理は普通にDispose/Closeに書くに決まっているわけだが、
使用者がそれを呼び忘れても最悪GCのお片付けのタイミングで
Close処理が行われるようにするための仕組みがデストラクタ

2019/04/28(日) 19:32:19.82

ごめんもいっこ
・IDisposableなオブジェクトをDisposeせず使用している時点で実装不備とみなしてよい
（フィールド変数だったらポカミスで解放し忘れはあるかもしれないけど、
　少なくともローカル変数ならusingを意図的に使ってない時点でコーダーが悪意を持ってると判断する）

2019/04/28(日) 19:32:33.80

>>586
いつまで勘違いしてるのか？

フールプルーフとフェイルセーフは別物だからｗｗｗ

2019/04/28(日) 19:35:22.92

>>590
DIに管理させるからusingもDisposeもしないという構成は非常に多い

2019/04/28(日) 19:35:29.40

自分の使ってるコードで完結してるのにデストラクタでアンマネージなどのリソースを
開放するのは間違った使い方

いくら自信たっぷりに書いてるのか知らないけど間違ってる

2019/04/28(日) 19:44:53.23

>>593
知らない他人が何年後かに使うかもしれない
だとしたら誤った使われ方でも最低限の安全性を確保できるように作るべき
デストラクタでリソースを解放するのはアリ

2019/04/28(日) 19:47:01.57

>>582
そんなレスしかできないなら黙ってろよw

2019/04/28(日) 19:50:07.37

>>594
IDisposable無視して放置する人を野放しにしないためにもデストラクタは不要だと思うわ

デストラクタが呼ばれたか呼ばれないかで意図しないタイミングで不具合が出たりでなかったりするだけだろ
そんなの余計に邪魔だろ

2019/04/28(日) 19:50:40.18

さすがに自前で生成してない（解放しなくていい）オブジェクトはわざわざ解放しないよ

んーと、デストラクタを書かないといけないような処理があるならDispose(false)だけ書く、んだけど
なにか間違ったこと言ったかな

2019/04/28(日) 19:53:00.38

>>590
> コーダーが悪意を持ってると判断する）
お前の判断なんてどうでもいい
MSはそんな判断してないからデストラクタからDispose呼んでるんだろうし

2019/04/28(日) 19:54:05.58

書く必要がないデストラクタなら書かずに済ませるというのは同意

というか普段アンマネージドリソースなんて滅多にさわらないし
まともにデストラクタを書いたのはいったい何年前だろう

2019/04/28(日) 20:00:46.55

どうしてもデストラクタ使うなら解放忘れを解放するんじゃなくて
デバッグ中に解放忘れてるぞコラということを伝える仕組みを作るほうがまともじゃないかな？

自分の考えは>>584がほぼすべて

2019/04/28(日) 20:04:36.28

>>566
ファクトリーメソッドを作って
その中でInitすれば良かろう

2019/04/28(日) 20:21:04.08

解放忘れを本気で潰そうと思ったらさっき書いたようにファクトリーアイソレーションパターンを使う

Task ExecuteAsync(Func<ISomeResource, Task> job) {
using (var resource = new SomeResource()) {
await resource.OpenAsync();
await job?.Invoke(resource);
await resource.CloseAsync();
}
}

サービス利用者には生成も解放もインターフェースを提供しない
ExecuteAsyncを通さないとリソースにアクセスできないようにすれば解放忘れを完全に予防できる

2019/04/28(日) 20:28:37.93

>>591
フールプルーフ（ばかちょん）は何をやっても致命的にならない、
というニュアンスの方が強い。

この場合はどっちでもいいと思うけどね

2019/04/28(日) 20:33:15.98

>>603
ばかちょんじゃなくてバカヨケだぞ

適当なこと書くなよ

2019/04/28(日) 20:37:42.11

>>604
それは直訳で、日本語では昔からばかちょんと言うんだよ
昔からというか昔はかもしれん。

俺もおじいさん先生からしか聞いたことない言葉だし
まあポリコレの時代だしね

2019/04/28(日) 20:39:59.68

バカチョンは意味が違う

2019/04/28(日) 20:42:39.60

バカヨケ　失敗しないような仕組み
バカチョン　誰でも使える

2019/04/28(日) 21:44:36.92

>>592
コンテナdisposeしたら、ついでに中身も自動でやってほしいよな・・・

2019/04/29(月) 12:55:34.62

横からすまんがさあ
DIにMicrosoft.Extensions.DependencyInjection使ってるんだけど、これってコンテナから生成されたオブジェクトって永遠と生き続けるの？
どうやって開放するん？

2019/04/29(月) 13:05:11.30

>>609
Scopeでググれ

2019/04/29(月) 13:39:51.85

基本的に生成元になったスコープをDisposeするとスコープ管理下のオブジェクトがまとめて消える
スコープはCreateScopeで再帰的に生成できる
BuildServiceProviderで作ったプロバイダーはルートのスコープに生えてるプロバイダーと考えればいい

アッドシングルトンで登録したやつは親子関係にある全てのスコープで1つしか作れずルートスコープと寿命が同期
アッドスコープドで登録したやつは各スコープ内で1つしか作れず作ったスコープと寿命が同期
アッドトランジエントで登録したやつはスコープ内で何個でも作れて作ったスコープと寿命が同期

ASP.NET Coreでは暗黙的に1つのリクエストに1つのスコープを割り当てる

訂正あったらヨロ

2019/04/29(月) 13:43:03.33

Scope = Asp.net用みたいな気になっていて全然知らなかったよ、ありがとう
ただDIなしの場合にusing句で書けるようなのはDIありでも簡単にかけそうだけど、オブジェクトを扱う箇所が数箇所に分かれてるときは難しそう・・・・
ScopeをDIコンテナに突っ込んだら突っ込んだでまた問題が増えるのかな・・・・

2019/04/30(火) 20:23:22.69

System.Globalization.JapaneseCalendarでeraを取得しているんだけど
Rが入ってこない・・・
Windows10でWindowsUpdateも最新なんだけど、何で入ってこないんでしょう

2019/04/30(火) 20:28:08.43

>>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以降にする必要があるらしい

2019/04/30(火) 20:38:50.44

まずまだアップデートはオプション段階だが、KB4493443入れてる？
正式なWindowsアップデートは5月以降だよ

2019/04/30(火) 20:45:03.73

KB4493443って、Windows8.1用だったような。
ちなみに、Windows10, version1809用は「近日公開予定」だそうで。
https://support.microsoft.com/ja-jp/help/4469068/summary-of-new-japanese-era-updates-kb4469068

2019/04/30(火) 21:35:51.80

もう元号とかやめて欲しいよねほんとw
いい加減役所も西暦に一本化しろよ

2019/04/30(火) 21:36:53.61

統一したら雑務が減っちゃうだろ

2019/04/30(火) 22:02:27.50

>>616
訂正ありがと　手元にあるのが8.1で全部おんなじかと

2019/05/01(水) 06:30:43.85

皆さんレスどうもです
まだ対応待ちってことですね・・・
とりあえずいまはテスト用にレジストリいじれるしかなさそうですね

2019/05/01(水) 14:39:10.04

インデクサーってpublic T this[int I]{}みたいに定義するらしいけどさあ
ここに出てくるthisの部分って、this以外も入りうる余地ってあるの？

2019/05/01(水) 14:49:13.86

>>621
無いよ
this以外にするとインデックス付きプロパティって意味になると思うけど、c#には無い

2019/05/01(水) 14:51:52.86

>>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以外が入る余地はない

2019/05/01(水) 15:04:58.50

ありがとう
無いものについてパッとわかるとか驚くぜ

2019/05/02(木) 05:11:25.37

メモ
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/

2019/05/02(木) 06:26:48.77

そういうのはQiitaでやれ(Qiita警察激怒)

2019/05/02(木) 12:04:50.67

メモ系ツールなんて山ほどあるのにわざわざこんなところに書くのか
俺こんなの調べてんだぜすごいだろ？みたいな承認欲求なのかね？

2019/05/02(木) 19:31:55.56

初心者ですが、乱数系列の初期化（Randomクラスのオブジェクトの生成）は
どこに書くのが正解なんでしょうか？

関数の中に書くと、関数が呼び出されるたびに初期化されるんじゃ？と思えるのでちょっと拙い
関数の外側にプログラムの初めの辺に書いておけばいいのかなあ？とも思うのですが、それもカッコ悪い

2019/05/02(木) 19:36:11.39

>>628
依存性として注入するのが定石