ふらっと 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/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
依存性として注入するのが定石

2019/05/02(木) 20:19:04.27

依存性　注入で検索したらいろいろ出てきたので調べてみます

2019/05/03(金) 03:27:08.36

>>628
最近のは年月日時分秒を整数にして種にしてるっぽいから、
毎回初期化の方がランダム性が高まるんじゃないかと思ってる。

2019/05/03(金) 03:31:56.40

>>628
仕様次第
乱数の仕様を設計書に明記する必要がある

2019/05/03(金) 12:41:41.06

>>628
訳分からん解答が続いてるけど、素直に

インスタンス固有である必要があるならコンストラクタに
staticでよいなら静的コンストラクタに

書けばいいだけ。かっこ悪いとか、くだらないことに悩むのは時間の無駄。
この場合は不要だと思うけど、静的コンストラクタが実行されるのはそのクラスの
静的メンバーに初めてアクセスされたタイミングだと思ったので、その点は場合によっては注意

2019/05/03(金) 12:51:40.57

>>633
嘘を教えるな
そんな馬鹿な使い方をしたらテストできなくなるだろ

2019/05/03(金) 13:16:48.56

private staticなら単体テストには支障ないだろ
厳密な再現性を求めるなら本来はシードを固定するべきだが

2019/05/03(金) 13:23:25.74

どっからテストとか出てくるんだw
意味が分からん

2019/05/03(金) 13:28:31.30

>>633
そもそも因果関係が逆だよな
キモメンが書いたコードがダサい

2019/05/03(金) 13:39:56.17

>>636
staticだとコンストラクタで実装を差し替えられないから単体テストの邪魔になりやすいというのは一般論としてはある
Randomを差し替える必要があるケースは極めて稀だが、上で述べたように厳密な再現性が求められるケースならありえなくもない

2019/05/03(金) 13:45:36.92

>>635
直近のN回が特定の数列の場合のテストとかしにくいだろちったあかんがえろ

>>636
テストしねーのかてめー？終わっとるな

2019/05/03(金) 13:57:48.60

>>639
横からすまんが、そのテストしにくい例ってのをコードで見せてくれんかな
学習のためにどうか頼むわ

2019/05/03(金) 14:05:21.52

>>640
例えばガチャを作ってるとして、0-999の乱数で0-9が出たらSSRを排出する仕様なら、
0と9と10くらいを決め打ちでテストしたくなるだろ？
まあそのために乱数生成器をモックしなきゃいけないような設計には再考の余地があると思うが、状況としては普通にありえるだろう

2019/05/03(金) 14:07:16.80

あなるあなる肛門肛門

2019/05/03(金) 14:07:36.88

すまん誤爆でした！！！

2019/05/03(金) 14:09:46.15

だから質問者はそんなこと聞いてないって...
どんだけ独りよがりの妄想展開するんだよ

2019/05/03(金) 14:11:43.11

>>644
うるせーばか子ね

2019/05/03(金) 14:16:40.44

現在時刻とか乱数みたいな制御しにくい値はインジェクションする
これ常識な
勉強になったねきみたち

2019/05/03(金) 14:47:40.00

>>644
カッコイイか悪いかだから
って問題があってカコワルイ
ってつければ質問者の望む回答

2019/05/03(金) 15:12:05.72

>>639
本末転倒だろう。
作るべき物の要件に合わせて乱数生成の挙動を定義して設計するのが優先すべき事項で、その実装をテストするためのコードは必要に応じて用意すればいいだろう。

2019/05/03(金) 15:31:58.12

>>648
それはアマチュアの考え方

2019/05/03(金) 15:33:51.16

>>649
スレタイ読め

2019/05/03(金) 15:38:42.54

どーでもええわ

2019/05/03(金) 15:58:52.41

教えてください。
以下のコードで、x の定義は問題ないのに y の定義だけコンパイルエラーになってしまいます。

==
const Exception e = null;
const bool x = e == null; // エラーなし、true が設定される。

const Type t = null;
const bool y = t == null; // CS0133 y' に割り当てられた式は定数でなければなりません。
==

何が原因でこのような違いがでるのでしょうか。
また、y を定数のままエラーが出ないように修正することは可能でしょうか。
よろしくお願いいたします。

2019/05/03(金) 16:01:49.32

>>652
結果によってtrueやfalseになるようなんは定数と呼ばん

2019/05/03(金) 17:46:27.38

>>652
例外はTypeで==演算子が再定義されてるからみたいなので、

const bool y = t == (object)null;

一応これで文句言われないみたい

2019/05/03(金) 17:53:37.68

あ、なんか例外とか意味不明なこと書いてるけど突っ込まないでねw

2019/05/03(金) 18:53:11.77

>>654
え？
それ通るの？
怖い

2019/05/03(金) 19:21:25.35

言語仕様の「定数式」の項を見れば別に不思議はないんだけど、
他人の書いたコードでこういう式を見たら一瞬「何の意図でこんな式を書いてるんだ？」
と思っちゃうね。

2019/05/03(金) 20:24:56.25

>>653
レスありがとうございます。
定数のまま、というのは const を付けたまま、という意味のつもりだったのですが、
表現が不適切だったかもしれません。失礼いたしました。

>>654
ありがとうございます！うまくいきました。
ちなみにいろいろ試してみると、
string は == が定義されているもののエラーが出ないようです。
さすがに string は特別ということのようですね。
（ただ、typeof(string).IsPrimitive は false にだったりして
　いまいちしっくりきませんが。。。）

==
const string s = null;
const bool z = s == null; // エラーなし、true が設定される。
==

何にせよ、問題はすっきり解消いたしました。
適切なアドバイスどうもありがとうございました。

2019/05/03(金) 20:25:45.58

>>657
実際に const を使いたかったわけではなく、
問題の切り分けを行った結果として >>652 のように質問させていただいたのですが、
言われてみれば確かに何がしたいのかわからない・・・。

もう少し元の問題に近いコードを提示するなら、以下のような感じです。

==
const Type t = null;
if (t == null) Console.WriteLine("t is null.");
else Console.WriteLine("t is not null."); // 警告なし

const Exception e = null;
if (e == null) Console.WriteLine("e is null.");
else Console.WriteLine("e is not null."); // CS0162 到達できないコードが検出されました
==

2019/05/03(金) 20:54:20.72

>>659
いやいやいや、俺はおたくにケチつけたわけじゃないよw
const bool y = t == (object)null;

こういうのはぱっと見て意図が分からないと言っただけ。
むしろ「マジックナンバー」を避けるのは良い習慣ですよ

2019/05/03(金) 20:57:46.12

>>658
＞string は == が定義されているもののエラーが出ないようです。
上にも書いたけど、その辺のモヤモヤはC#の言語仕様の「定数式」の箇所を見れば解消するよ。
VSのインストールフォルダに入ってる

2019/05/03(金) 21:13:39.41

ひょっとして、ES6あたりの感覚で代入onlyの変数を宣言したくてconstキーワードを使おうとしてるのかなと思ってみたり
readonlyなローカル変数みたいな構文ってC#にはまだないんだよね

2019/05/03(金) 22:02:39.62

>>660
> const bool y = t == (object)null;
> こういうのはぱっと見て意図が分からない
そうですねｗ
式の意味を考えるなら t == (object)null は
ReferenceEquals(t, null) と書くのがわかりやすいんでしょうけど
const うんぬんの話の中でこれはダメですし。

ちなみに今ふと思いついて試してみたんですが、
t is null も == の定義には依存しないものの定数扱いにはならないようです。

>>661
ありがとうございます。
言われてみると、そもそも C# と CLR の役割自体が正確に区別できていないような
気がしてきたので、これを機会に勉強してみようと思います。

2019/05/03(金) 22:03:15.73

>>662
質問させていただいたのは、
>>659 のコードみたいに CS0162 の警告が出てほしいのに
出てくれない場面があったからです。

でもたしかに readonly なローカル変数はあってもいいですよね。

あと、引数のみに依存して副作用もないメソッドについて
↓みたいな書き方が許されたらいいのに～とか妄想しましたｗ

==
static class MathEx
{
　　public const double Square(double x) => x * x;
}

static class MyConstants
{
　　public const double SquarePI = MathEx.(Math.PI);
}
==

2019/05/03(金) 22:05:09.07

何度もすみません。。。上の妄想コードは間違いです。
正しくはこちら。

==
static class MathEx
{
　　public const double Square(double x) => x * x;
}

static class MyConstants
{
　　public const double SquarePI = MathEx.Square(Math.PI);
}
==

2019/05/03(金) 22:55:31.79

実質的に定数ならJITコンパイル時に定数に置き換わるからそんなものは要らん

2019/05/03(金) 23:53:26.41

decimalの定数は内部的にアレだけどな

2019/05/04(土) 07:03:09.32

>>667
詳しく

2019/05/04(土) 13:03:57.01

>>668
横からだけど https://ufcpp.net/blog/2016/12/tipsprimitives/ のことだと思う

2019/05/04(土) 14:32:15.09

List.Addって、複数のスレッドから同時に呼び出したらデータが壊れる可能性ってあるの？

2019/05/04(土) 15:00:48.03

>>670
スレッドセーフじゃないからlock制御を自前で持つか、System.Collections.Concurrentのコレクション使うべき

2019/05/04(土) 15:23:49.46

Queueの出し入れもlock必要だし、マルチスレッドはめんどいよな。
なんでConcurrentDictionaryはあるのにListは無いのか

2019/05/04(土) 15:37:29.51

>>672
使い道がない

2019/05/04(土) 15:38:02.55

個人的にはスレッド自体に特定のスレッドからのデータを受け取る処理がある方が好き

2019/05/04(土) 15:57:05.65

別々のスレッドから生成された値を集めたいなら、
各スレッドで別のバッファ(List)に値を書き込んでから最後に単一スレッドでマージするのが定番

2019/05/04(土) 17:20:59.03

スレッドセーフって実はどういう動作するのかよく知らないぜ

2019/05/04(土) 17:27:01.27

>>676
わかる
エラーがでなかったらそれがスレッドセーフ！！

2019/05/04(土) 20:18:11.93

APIのマニュアルにおいて「スレッドセーフ」という言葉が用いられる場合、たいていは「複数のスレッドからアクセスされても例外を出さない、プログラムがクラッシュしない」というような意味です。

しかしプログラムの目的によっては、例外が出ないだけでは不適切です。

例えば対象が、100個のデータを管理する変数だとします。
その100個のデータに対して、1つ目から順に処理するスレッドと、50個目から変更するスレッドが同時に動いたらどうなるでしょうか？　結果は不定です。
この例では、排他処理 (C#なら lock ステートメントなど) と呼ばれる処置が必要になります。

ってググって出たサイトで拾った

2019/05/04(土) 20:25:20.65

つまり

for(int i=0;i<lst.count;i++)
{
unk un=lst[i];
略
}

みたいなプログラムを組んだとき
どっかでいきなり要素をゼロにされて死ぬってことは
スレッドセーフだろうがどうだろうが可能性はあるってことだよね

ってことを考えるとスレッドセーフである意味ってあんまりなくて
排他処理は絶対実装しないと駄目だよね？ってこと？
誰か違うと言ってくれ

2019/05/04(土) 20:59:32.71

スレッドセーフはメソッド内などで一貫性を保てる作り

排他制御が必要な場面でやってないなど作り手のロジックミスには対応出来るわけがない

2019/05/04(土) 21:06:21.08

スレッドセーフである意味

あるオブジェクトがプロパティAを持っててメソッド内で
b=aaa(A)+bbb(A);
を計算しようとしても複数のスレッドからアクセスされることを考慮されていなければ
最初のAと次のAが違う場合があり計算結果が期待したものにならないかもしれない

スレッドセーフはこういう場合でもちゃんと計算される仕組みを持つ

2019/05/04(土) 21:07:23.59

>>679
その処理は要素数チェックと要素アクセスが分かれているから、間に他スレッドからの処理が割り込み得る
System.Collections.Concurrent系のコレクションは、
例えば「要素があるなら取得」のようなまとまった処理がatomicになっているので、他スレッドからの割り込まれない(＝スレッドセーフ)
どっかのスレッドで詰めて、別のスレッドでループ処理、がやりたいのならBlockingCollectionが楽