ふらっと 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/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が楽

2019/05/04(土) 21:27:48.58

>>679
厳密に他のスレッドとの同期を取らなきゃいけないなら>>682の言うようにBlockingCollection使うか毎回ロックだろうし、
ループ中は他のスレッドによるlstの変更を反映しなくていいならループに入る直前だけロックしてコピーしておけば済む
ケースバイケースだよ
一つ一般的なアドバイスをしておくと、並列処理のコツはデリケートな前提をなるべく設けずに極力ロバストな設計をすることだ
要件が許す限りにおいて、少々処理の順番が入れ替わったり処理間の同期が取れてなかったりしても問題にならないつくりにするのが理想

2019/05/04(土) 22:09:10.98

非同期処理は複数のスレッドが同じデータを弄ろうとすることによる不整合は起きないけど
コールスタックは複数になるから
同じデータに触ると訳ワカメになる事があった

2019/05/04(土) 23:16:04.81

(||ﾟДﾟ)ﾋｨｨｨ!(ﾟДﾟ||)
じゃあ>>679みてーな処理を書いたら
スレッドセーフなんて関係なく
バグるんだね
こぇえええええ
じゃなくて終わったわ
今まで組んだもんでテキトーにやった箇所全部終わってる気がする

2019/05/04(土) 23:28:33.99

まあ複数スレッドで同時並行処理するときにはそのへん慎重を期さないと
再現困難なバグを埋め込んじゃうからねえ
同時に読み書きする可能性のある変数を安易に書き換え/差し替えしちゃダメ

2019/05/05(日) 05:07:07.08

マルチスレッドの恐ろしさは、たまにしかバグらない事。
ほとんどは正常に動くから、質が悪い。
必ず、バグらないだろ

それで喧嘩になる事も多い。
マルチスレッドは、ベテランでもバグるからやめろと言っても、
ほら、バグらないでしょ？と、突っかかってくる

その時には、バグらないと言うと、
千回実行しても、バグらないでしょ？と、突っかかってくる。
でも、その時にはバグらない

バグる立証をするのが難しい

だから、Ruby をやった人は、関数型言語のElixir をやる。
他の言語の人は、何を言っても、そのテスト回数でバグらないと言ってくるから、質が悪い

1万回実行しても、10万回実行しても、その時にはバグらないものなんだよ。
何回バグらないで実行すれば、正しいと認めるのか、と問われても困る

2019/05/05(日) 06:10:17.07

ｱｸﾏﾉｼｮｳﾒｲ

2019/05/05(日) 08:46:40.02

>>687
喧嘩になるのはマルチスレッドのバグのせいではなくお前の頭がバグってるから

2019/05/05(日) 08:57:36.80

エビデンスとれてりゃ突きつけるだけなのに

2019/05/05(日) 10:34:54.98

>>687
マルチスレッドはバグるからやめろってなるのでなく、バグが無いように作れよ。

あと、お前の意見を相手が聞き入れず喧嘩になるのは、お前がいつもバカなことを言うから相手は当然受け入れる気にならず、お前にはその自覚がなくて｢何でアイツは僕の言うことを理解してかれないんだウワアーーー｣ってなってるからだぞ。

2019/05/05(日) 10:45:50.32

>>687
なんでバグが起こってるのか原因特定出来てなくてワロタ

2019/05/05(日) 10:48:34.16

スレッドセーフは単発のメソッドが競合しないだけで
一連の処理についての動作保証をするものではないと

マルチスレッドはやらなくていいならそれに越したことはないけど
絶対に駄目というわけではなく

排他処理を組まないことが害悪

2019/05/05(日) 11:21:06.67

排他制御をしなくても安全に並列処理できるように設計することが大事
まずはロック、クリティカルセクション、ミューテックス、セマフォ、といった待ち時間を発生させるタイプの機能を使ったら負け、というルールで設計に挑戦してみるといい
大半の並列処理でそんなものは必要ないこと、それらを使わないほうが圧倒的に設計とプログラムが綺麗になることを体験するべき

2019/05/05(日) 11:29:03.77

シネ

2019/05/05(日) 12:22:10.03

ぱられるふぉーってのを使えば良いんじゃね？
知らんけど

2019/05/05(日) 12:32:51.31

>>694
うーん、でも>>679みたいなこと
やった時点で終わりってまともじゃねぇよ
コードで一瞬でもすきを見せたら終了みたいになっちゃうじゃん

お前の理想はなんかあるんだろうけど
他人が叫ぶスレッドセーフに頼っちゃ駄目だよ
アプリの仕様として排他処理を盛り込むべき

2019/05/05(日) 13:01:26.26

>>697
だからさ、>>679みたいなforループ自体をスレッドセーフにする一番簡易な表記方法がlockなんだよ
これ以上簡単に書くことはライブラリをどんだけ上手く作っても無理

2019/05/05(日) 13:15:03.75

>>698
それって記述が簡単ってだけでしょ？
ロック中にアクセスしたらどういう動作するの？
次回に回すの？
待機して待つの？
そういうのってスレッド毎にステータスを持たせて
マトリックスで管理しないと制御できてると俺は認めない

ジジイだから

2019/05/05(日) 13:34:55.82

VisualBasic大先生を怒らせてしまったようだな

2019/05/05(日) 13:41:27.68

>>698
だからさ
そんな不安定なロジックを書かなくても良いようにちゃんと設計するのが並列処理の王道なんだよ
lockブロックは最初の一回を書くときは楽かもしれんがだんだん難しくなるぞ
そのコレクションを使う全てのプログラマが並列性を意識して正確に排他制御をコーディングしなければならない
これは実用的なシステムの規模になるとかなり大きな負担になる

2019/05/05(日) 14:02:39.93

そもそもロックって論外なんだわ

世の中の並列処理の目的ってのはほぼ2種類に分類されるんだよ
①インフラストラクチャ処理中にCPUを待たせたくない
②消費コア数を増やして暇なCPUを働かせたい

よーするにCPUを無駄にしたくないわけ
でもロックしちゃうと問答無用でCPUが何もせずに止まっちゃう
ロックすると並列処理をする目的そのものに反してしまう
なのでロックは基本使わず最後の手段ってわけ

この辺りは(やや古い本だが)Microsoft Pressのプログラミング.NET Franework第4版やEffectiveシリーズでも解説されてることだね
どちらも良書なので脱初心者を目指しているだろう君達は是非とも読むべきだ

2019/05/05(日) 14:08:00.64

その通り
極端な話、並列処理なんてそれぞれ別のサーバーで実行させりゃいいんだよ
それがレイテンシやコストなどの問題で無理なら代わりにプロセスを分ければいい
そもダメならリクエストやワーカー単位でスレッドを分け、といった具合に、共有するリソースを最小限にすることを優先する

2019/05/05(日) 17:40:50.25

ジジイだから能力低いだけだろ

2019/05/05(日) 18:00:00.04

非同期処理全盛の時代にこれじゃ、世の中やばいコード(or非同期処理のつもりが同期処理されてるコード)だらけだろうな
Qiitaとか見ててもやばい奴だらけだ

2019/05/05(日) 18:04:40.39

>>705
今時lockだもんな、笑えない深刻さ
お前のコード、めちゃくちゃブロックされてんだけど、って同僚の誰かが教えてやればいいのに見て見ぬ振りは可哀想だ

2019/05/05(日) 18:09:44.07

そもそも、世のサンプルプログラムの多くが欠陥品なのが諸悪の根幹なのかもな
劣化コピーしちゃうQiita屋とかコピペプログラマが全部危険なコードを書いてしまう

2019/05/05(日) 18:19:48.84

一番パフォーマンスの良いMutexを使ってる人がどれだけいるやら

2019/05/05(日) 18:23:53.97

>>708
よくねえよw
OSリソース消費する処理に速度を期待するな

2019/05/05(日) 18:27:02.59

他人に迷惑をかける基地外はシネ

2019/05/05(日) 18:33:04.85

webサーバでスレッド一個で処理を完結するようにはなっていないだろ

2019/05/05(日) 18:33:17.95

Mutexは相変わらずスレッドをブロックするうえにMonitorよりも消費リソースが大きい
その代わりプロセスを超えて待機処理を実装できるというものだ
よーするにlockよりもっと遅いんだよ

2019/05/05(日) 18:34:49.31

>>712
実務で使ったことないんだろ
黙っとけや

自分だけの小さなアプリしか作ったことないんだろ

2019/05/05(日) 18:37:30.50

>>713
もう無理だよ笑わせないでw
もっともパフォーマンスの良いミューテックスwwwwwww
実務で使ったことないだろwww
学生さんですかwwww

2019/05/05(日) 18:38:33.24

5分で確認できることをできない老害

2019/05/05(日) 18:41:05.51

Mutexはロックがいらないスレッド同士でもロックしちゃうのが使いづらいな
回避できるのかはしらんが

2019/05/05(日) 18:41:10.65

そもそもスレッドがとまると言ってるけどCPUのスレッドと.netのスレッド混同してそう

2019/05/05(日) 18:41:50.97

>　でもロックしちゃうと問答無用でCPUが何もせずに止まっちゃう

これ笑う所？

2019/05/05(日) 18:45:15.15

ロックしちゃうと問答無用でCPUが何もせずに止まっちゃうわけないだろｗ

2019/05/05(日) 18:47:01.12

え？lock中にアクセスしようとしたらどうなるの？

2019/05/05(日) 18:48:17.37

ロックが取得できないだけ

2019/05/05(日) 18:48:31.54

お前のPCは8スレッドぐらい動かしたら止まるの？

2019/05/05(日) 18:51:01.09

>>719
うるせーなスマホで長文書くとミスるんだよ
スレッドがブロックされるってことだ

2019/05/05(日) 18:51:41.98

>>723
ググってきたのかよ低能さん

2019/05/05(日) 18:52:07.51

>>721
そんときのコードってどう書くの？

2019/05/05(日) 18:53:42.23

>>724
調子のんなよ重箱の隅つつきマン

2019/05/05(日) 18:55:47.24

>>726
lockとMutexのパフォーマンスのベンチ比較して
結果を出せよ
それまで書き込みするな

2019/05/05(日) 19:00:35.89

>>727
はぁ？
言い出しっぺのてめーがパフォーマンス一番良いミューテックスのベンチ出せや
一番ってんならロックと比較なんてケチくせえこと言わんで他の排他制御機構とも比較しろよ？

2019/05/05(日) 19:00:46.75

どう見ても間違っている内容で煽られると人はどう思うのか
どう考えても仕組み上Mutexのほうが遅い

2019/05/05(日) 19:07:06.98

>>725
普通に取得できるのを待ってるな
まあ、ロックが取得できるまで制御を戻したりはしておらんわ

2019/05/05(日) 19:12:25.48

>>730
だよね
ちょっと調べてるけど
普通の排他処理組んでおきたくて

lock
ReaderWriterLockSlim
UpgradeableReadLock

なんか普通の排他処理したいだけなのに
たくさん出てきちゃったぞ
これ全部使っても
ん？排他処理できてんのか？
って疑問が晴れない
この言語非同期処理の対応手薄なんだよねまだ
時期尚早として触らんことにしたｗ

2019/05/05(日) 19:21:47.99

LockやMutexは初心者本の範囲内だからしらんのはまずいよ

2019/05/05(日) 19:45:53.31

非同期のチートシートないの？

2019/05/05(日) 19:57:32.38

https://qiita.com/tadokoro/items/28b3623a5ec58517d431
測った人によると
nterlocked > lock > SemaphoreSlim > Semaphore > Mutexだってさ

2019/05/06(月) 02:20:35.00

並列処理なら.netなんだからF#でSTM使え。
何で関数型言語が注目されたんだよ。
並列処理に有利だからだろ。

2019/05/06(月) 04:59:30.75

マルチスレッドなんか無理！
だから、Ruby の人は、Elixir を使う

作るのに何百年も掛かる、人類の成果、Erlang VM + Ruby = Elixir。
ErlangVMを、Rubyでラップしたもの

Elixirの小プロセスなら、10万プロセスも余裕！
パイプラインと同じ

関数型だから状態を持たない。
ただ、データを変換していく関数をつなげていくだけ！

2019/05/06(月) 07:40:48.06

>>736
Rubyにマルチスレッドは、無理！
RubyはいわゆるGILといって、同時に複数のスレッドが走らないような排他制御がVMレベルでかかっている
これはVM自体がスレッドセーフでないクソ実装であることに起因する制約である
もちろんC#にはそんなものはないし、ベンチマークだとErlangより速い

2019/05/06(月) 12:19:36.88

Windows8.1/10の令和対応アップデートでWinFormsの画面レイアウトが崩れるらしいね

2019/05/06(月) 12:48:42.80

お前んとこのWinformsいつもレイアウト崩れてんな

2019/05/06(月) 12:59:34.99

>>738
俺のとこも昨日発生した
AutoScaleModeをNoneにして対応できたから令和のせいではないと思う

2019/05/06(月) 13:02:49.51

>>739
は？崩れてねーし
OKボタンが画面外にいって押せないだけだ

2019/05/06(月) 21:06:24.34

画面レイアウトがクソみたいに崩れたぞ死ねや

2019/05/06(月) 21:19:39.33

>>740
どうやってやるのそれ？
visual studio開いた時点ですでに崩れてて手動で戻すしかなさそうなんだが。

【警鐘】[改元][Windows][.NET] 「令和」対応パッチで画面が横に伸びる、文字が見切れる ― Windows Update 手動更新はちょっと待った方がいい
https://qiita.com/CodeOne/items/22004635d3c7cc533e5e

2019/05/06(月) 21:32:21.57

>>743
デザイナ表示壊れてんのなら.Designer.csの中身書き換えるしかないんじゃね
AutoScaleMode.FontをAutoScaleMode.Noneに全部置換したらいい

2019/05/06(月) 21:39:51.78

>>744
ありがとう
form1.csのデザインのAutoScaleModeをNoneにしたけど何も起こらなかったからあきらめてたけど、そっちを修正したら解決したわ。

2019/05/07(火) 00:11:46.09

>>740
令和を1文字で表すやつのために、フォントをいじったんだが、そのときに既存の文字の幅が変わったらしい
なのでまあ、令和対応のせいだと言えばそうなんじゃね

つか明日からどれだけ影響出てるか考えると鬱だわ

2019/05/07(火) 01:24:56.82

納期直前でGW返上してる最中にこの不具合対応しなきゃいけなくなってかなりイラッとした

2019/05/07(火) 08:16:44.51

https://devblogs.microsoft.com/dotnet/introducing-net-5/
.NET Framework 終了のお知らせ
Coreへ移行できないドカタは永遠に4.xに取り残されることが決定したようだ

2019/05/07(火) 08:55:31.55

>>748
すげーな。２０年以降毎年バージョン上がる予定か
2020 .net5
2021 .net6
2022 .net7
2023 .net8

.net4で停滞した１０年とは一体

2019/05/07(火) 08:58:10.52

Java interoperabilityって何なんだよ…

2019/05/07(火) 09:30:59.37

>>748
出来損ないは過去に葬った方が世の中のためだぁ

2019/05/07(火) 10:21:58.95

バージョンを頻繁に上げるのは、
成熟していないってことでは？

2019/05/07(火) 11:33:46.06

FrameworkからCoreに移行できないのはどういう場合ですか？

2019/05/07(火) 11:59:10.66

え、winformはどうなるの？？

2019/05/07(火) 12:06:04.60

最近のmicrosoftかなり攻めてるな

2019/05/07(火) 13:10:26.59

.net frameworkからcoreなんてどこかちょろっといじったらいいだけじゃないの？
VB6からVB.netほどの変化はないんだろ？

2019/05/07(火) 13:37:50.62

>>753
そんなワケのわからんもん使こて何かあったらどないすんねん！責任取れるんかい！
わりとこれ

2019/05/07(火) 13:46:35.16

別に移行しなくてもいいですけど保守には特別料金いただきまっせ