ふらっと 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/21(日) 09:21:47.18

>>440
出来合いのソート処理を利用するなとか誰か言ってんの？

2019/04/21(日) 09:22:37.85

独習3版読んでないとーしろはqueueも実装できないし、回帰とかも理解しないんだろ。

2019/04/21(日) 09:39:42.10

>>440
初心者がソートを勉強しないと自分の書いたコードがなぜ遅いかわからない

ソートが魔法か何かで何でも一瞬で並び替えられると思ってしまうと終わり
そこから進展はない

ソートの回数を減らすように考えたりソート自体を行わないでうまく処理することを学ばないといけない

2019/04/21(日) 09:43:13.42

ソートがボトルネックになった時に最適化を迫られたら弄るしかないじゃんね

2019/04/21(日) 09:50:14.96

ソートがボトルネックになったらじゃなくて普通にソートを使うときには必ず気に掛けるべき

ループの中にソート入れてるコードがあったりする
ループ出た後に一度やればいいだけなのにと思うがそういう所に思いが至らないんだろう

2019/04/21(日) 10:02:50.79

今なんねーよ流石に

2019/04/21(日) 10:09:09.80

メソッドの中でソートして戻り値返してるのにもらった側でもソートしたりとか
無駄なことをする可能性はどこにでもある

他人に見られたときにこいつ馬鹿だなと思われないようなコードを書く練習をしよう

2019/04/21(日) 10:17:01.49

listのsortメソッドって安定ソートだっけ？

2019/04/21(日) 10:19:40.66

>>444
それは細かい最適化よりも設計を見直すべきだと思うよ
物事を大域的に見ることができず小手先のハックだけでなんとかしようとするのはプログラマが陥りがちな非常に悪い癖だから注意

2019/04/21(日) 10:24:24.53

小手先のハックじゃなくて基本だろ

どこでソートするかなんて基本中の基本

2019/04/21(日) 10:25:31.30

無意味な仕事を無くすように働きかけるのではなく、無意味な仕事を無駄に最適化しようとするのは低学歴な意識高い系プログラマあるある

2019/04/21(日) 11:39:31.85

>>448
https://docs.microsoft.com/en-us/dotnet/api/system.collections.generic.list-1.sort
> This implementation performs an unstable sort
ついでにいうとArray.Sortも不安定ソートで、Enumerable.OrderByと.ThenByは安定ソート

2019/04/21(日) 12:31:18.60

ソートはプログラムを覚えるために勉強するもので
実用上はライブラリ使えばいい

ただ、勉強するネタとしては割と上質なもの

2019/04/21(日) 12:34:57.35

(回答する方も)初心者スレらしくていい流れだね

2019/04/21(日) 12:46:19.25

こういうの、listにロックをかけたのに何で同listを使う後続処理がすぐ実行されちゃうの？
https://paiza.io/projects/e/EbjQiWv8ebNkW4bbkAY_YQ

using System.Collections.Generic;
using System.Threading.Tasks;
using System;

public class Hello{
public static void Main(){
var list = new List<int>();
for(int i=1; i<=1000; i++)
{
list.Add(i);
}

Task.Run(()=>{
lock(list){
Task.Delay(10000);
}
});
Console.WriteLine(list[123]);
}
}

2019/04/21(日) 12:51:36.48

まだ、そんな産廃機能いじってんのか

2019/04/21(日) 13:00:01.62

>>455
https://ufcpp.net/study/csharp/sp_thread.html#lock
lock文はMonitor.EnterやMonitor.Exitを使った糖衣構文であって
Monitor.Enterでロックを取得する(=既にロックされているなら、それが解放されるまで待つ)
例示コードではTask中ではlockしているもののConsole.WriteLine箇所はlockがないので、すぐに実行される

2019/04/21(日) 13:12:13.25

>>455
lockの使い方が間違ってる(>>457)のと、Task.Delay()の使い方が間違ってる。
Task.Delay()は通常awaitして使うがlockステートメント中では使えないので、Task.Delay().Wait()するか代わりにThread.Sleep()にする。
後、Task.Run()で作ったタスクが実行開始されたか考慮していないから、大抵はConsole.WriteLine()が先に実行される。

2019/04/21(日) 14:40:03.19

>>441
俺だよ俺

2019/04/21(日) 15:32:01.70

ありがとう、このコードだと欠陥だらけなのか・・・・
使用箇所ごとにLockが必要なのか、それとタスクより先に次の行が実行されてる可能性が高いのは全く気づいてなかった
ただ、
＞Task.Delay()は通常awaitして使うがlockステートメント中では使えないので、Task.Delay().Wait()するか代わりにThread.Sleep()にする。
っていうのはどういうことなの？Lock外にスレッドを返されちゃうのかしら？

2019/04/21(日) 16:07:55.74

>>459
よおキチガイ

2019/04/21(日) 16:32:29.56

>>460
Task.Delay()だけだと完了を待ってないから、実質無いのと同じ

2019/04/21(日) 17:35:25.00

>>460
ピーコックアンダーソンの非同期動画みてみればすぐに理解できるぞ

2019/04/21(日) 22:18:43.95

速度がどうとか言うんだったらc#なんか使うなよと少し思いました

2019/04/21(日) 22:35:33.45

>>464
少しってなんだよ！

2019/04/21(日) 23:52:50.47

>>465
a little

2019/04/22(月) 04:23:42.26

じゃあ残りの大半は何を思ってたの

2019/04/22(月) 19:50:45.64

ソートってポインタやmalloc, memcpyとか使ってこねくり回すのが楽しいのにC#だとイマイチだよね

2019/04/22(月) 20:39:27.38

独自に作成したユーザコントロールをdataGridViewのカラムに追加する処理を作成しているんですが
追加したものをそのまま削除するとうまく削除出来ず、一方のユーザコントロールが必ず画面上に残ってしまうんですが
なぜでしょうか？原因がわからず悩んでいます
どなたか教えてください

//①ひとまず空のデータを作成してdataGridViewに格納
DataTable dt = new DataTable();
dt.Columns.AddRange(new DataColumn[] {new DataColumn(), new DataColumn(), });
dt.Rows.Add(new object[] { "", "" });
this.dataGridView1.DataSource = dt;
//②ユーザコントロール１をdataGridViewに追加
UserControl1 userControl1 = new UserControl1();
this.dataGridView1.Controls.Add(userControl1);
userControl1.Location = this.dataGridView1.GetCellDisplayRectangle(0, 0, true).Location;
//③ユーザコントロール２をdataGridViewに追加
UserControl1 userControl2 = new UserControl1();
this.dataGridView1.Controls.Add(userControl2);
userControl2.Location = this.dataGridView1.GetCellDisplayRectangle(1, 0, true).Location;
//④追加したユーザコントロールを削除→何故かユーザコントロール２だけが残る
dataGridView1.Controls.Clear();

**469** (ﾜｯﾁｮｲ c23e-HmQt) · 2019/04/22(月) 20:40:58.08

ちなみに私が試したのはvisualStudioの2017です

2019/04/22(月) 20:42:29.96

c#だと遅くて無理みたいな高尚なプログラム触ってないからよくわからん
cppとc#でどれくれい違うん？

2019/04/22(月) 20:52:55.67

>>471
何するかによるし言語仕様理解せずにコーディングすればC++だろうがC#だろうが遅くはなる
早くしたけりゃどの言語だってコンパイラが吐くコード見ろになるし極論アセンブラしてろになる
シビアな演算速度求められるようなソフトじゃなきゃ気にするような速度は無い
個人的にいろいろ開発してて速度面で困ったことはない

2019/04/22(月) 21:35:41.32

特定のアプリを監視して表示された文字（画像）をテキストにするアプリ作ったけど
c#だとチェックに1秒、c++とGDIのDLLだと0.01秒とかそんな感じだった

c#で作って必要ならc++にコンバートするのでいいと思う

2019/04/22(月) 21:59:37.22

>>468
unsafe使えば

2019/04/23(火) 00:01:21.36

画像処理とかその部分はunsafeとかcだろ。それぐらいは当たり前

2019/04/23(火) 00:14:05.59

別にC#でいくらでも早くできるけどそれしないでC++より遅いってそりゃそうだよねとしか
GCの恩恵受けてunsafe使わずセーフティな状態でしょ
突き詰めたC++と突き詰めたC#なら.NETで動く分C#が不利なのは仕方ない
突き詰める必要がない部分で恩恵を受けられるんだから、処理速度以外にメリット感じないなら速い言語やればいい
言語なんて所詮道具なんだから適材適所

2019/04/23(火) 00:15:59.36

sleepが1ms単位指定なのに平気で30msくらいかかったりする

2019/04/23(火) 00:21:34.72

>>477
Windowsの仕様なのでC#と関係なく発生するよ

2019/04/23(火) 00:22:35.63

OSの内部クロックのせい

2019/04/23(火) 02:07:58.81

>>473
そりゃあおまえさんのコードが糞なだけや

2019/04/23(火) 02:09:14.72

OSにクロックはないでしょうw
いやスケジューリングとかタイムスライスとかそんなことが言いたいんだとは思うけど

2019/04/23(火) 02:35:38.55

>>481
え…

2019/04/23(火) 07:53:20.75

TickCountの事だと思う。

2019/04/23(火) 11:11:38.25

awaitのついた文の次の文を実行する際に、await前と同じスレッドに帰ってきてもらうことってできないの？

2019/04/23(火) 11:25:52.45

元のスレッドがそういうことできる機能を持ってればできるよ
WinFormやWPFのGUIスレッドはメッセージループで実現してて
それらの場合はGUIスレッドでawaitすればGUIスレッドに戻ってくるのが既定だし

2019/04/23(火) 12:18:02.90

Pythonでカラー画像をRGBごとに分割して出力するスクリプトを書いたんだけど、
opencv使わずにC#でも出来るのかな？
C#でもnumpyみたいなの無いの？

2019/04/23(火) 12:20:58.93

どんだけ馬鹿なんだよ

2019/04/23(火) 13:00:40.13

>>486
numpyってrubyですか？

2019/04/23(火) 15:41:23.24

>>486
まんまは無いけど部分的にだったら何らかのライブラリで補完できるんじゃないかな？
これとか
https://numerics.mathdotnet.com

2019/04/23(火) 16:29:44.88

>>485
コンソールアプリ等だとなかなか難しいんかな

2019/04/23(火) 16:33:48.41

>>490
Task.WaitAnyとかでできんもんか？

2019/04/23(火) 17:58:47.89

>>484
いやいや最初から同じスレッドですからww
そもそも同一メソッド内で別のスレッドを起動することはあっても
実行中に途中のスレッドに切り替わるとかそんなのありえへんwww

2019/04/23(火) 19:05:14.26

>>492
しょうもない嘘をつくな

2019/04/23(火) 19:28:13.89

誤解が誤解を生む

仕様について理解が足りない

2019/04/23(火) 19:35:04.22

ネタじゃなくて本気で変な誤解してるのか...
メソッドの途中で行が変わると別のスレッドで実行されるとかそんな言語怖くて使えないよwww

2019/04/23(火) 19:36:05.31

お前は勘違いしてる

GUIとCUIで仕様が違ってる

2019/04/23(火) 19:50:14.81

await/asyncは単なるTask非同期処理を簡易的に書ける糖衣構文
次にawaitの次をどのスレッドになるかはその時の状態次第

GUIではそれでは困るのでデフォルトで同じスレッドが処理をするようにしてあるだけ

2019/04/23(火) 20:19:35.25

訳のわからん勘違いをしてるのはどっちだよ
自信満々で馬鹿じゃないマジで

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

https://ufcpp.wordpress.com/2012/11/12/asyncawait%E3%81%A8%E5%90%8C%E6%99%82%E5%AE%9F%E8%A1%8C%E5%88%B6%E5%BE%A1/

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

deligate

2019/04/23(火) 20:36:54.48

>>495
https://ideone.com/7wVOXT

2019/04/23(火) 20:41:16.72

勘違いをしているのは俺の方だった...
申し訳ないですw

2019/04/23(火) 21:04:08.70

すなおでいいんでない？

2019/04/23(火) 21:19:00.48

煽る時点で目糞鼻糞

2019/04/23(火) 21:57:22.24

同じスレッドに戻ってきてもらうのに、簡単な方法ってないのかな・・・・

2019/04/23(火) 22:10:23.58

>>505
>>490を見るに、コンソールアプリで特定スレッドで処理したいみたいだけど、どういった理由？
GUIなら、時間がかかる処理は別スレッドで、画面更新は絶対にUIスレッドで、といった使い分けがあるけど
CUIで特定スレッドを意識する理由がちょっと思いつかないんだ

2019/04/23(火) 22:42:29.23

>>506
WebAPIサーバを作りたく、その中で扱うデータについてトランザクション処理みたいなことをしたかったんです
通信関連でAwaitが多用されている中でも、データのロックをできるだけ減らしたい、またうっかりミスしてロック外に出ないでほしいと思ったんです

2019/04/24(水) 00:21:10.86

>>507
それを聞いても、「特定スレッドで絶対に処理したい」が主目標にはならない気がする
「ロックにReaderWriterLockSlimを使っていて、ロック取得と解放は同じスレッドで行う必要がある」のような状況ならまだ分かるんだけど
もしもこの状況であるなら、SemaphoreSlimでロックするようにすれば、WaitOneAsyncで待つスレッドと、Releaseするスレッドを別にできる(=間でawaitできる)
万一本当に何か理由があって特定スレッドで処理を続けたいのなら、Taskをawaitするのでなく.Wait()で待つようにすれば、スレッドは切り替わらなくなる

> うっかりミスしてロック外に出ないでほしい
これが「ロックを取得したけど、解放を忘れる」ことを指すのであれば
try {} finally {} や、ラップクラスを作ってIDisposable実装してusing() {} するのが対策になるかもしれない
取得と解放がメソッドを跨いだりするなら面倒くさくなるけど……

2019/04/25(木) 23:50:01.61

https://ideone.com/TM1zJh
if (ob.volume == volume)この部分なのですが
左辺は引数で取ったobのメンバ変数であることは分かるのですが右辺はどのメンバ変数なんでしょうか？
入門書のコードなのですが…

2019/04/25(木) 23:52:47.61

>>509
6行目

2019/04/25(木) 23:54:19.01

いや、thisって答えた方が良いのか

2019/04/25(木) 23:59:26.79

19行目にも同じ構造があるけどそっちはすんなり入ったんだろうか

2019/04/26(金) 00:01:25.44

>>510
メソッドを呼び出したob1のメンバってことですかね？
理解できました。ありがとうございます

2019/04/26(金) 23:30:08.64

コンストラクタ内で例外をthrowするのはご法度ですか？

**デフォルトの名無しさん** (ｽﾌｯ Sd43-jluM) · 2019/04/26(金) 23:43:18.42

>>514
定石ですよ

2019/04/27(土) 00:06:35.36

>>514
ご法度ではないし、むしろインスタンスを正しく構築できないなら積極的にthrowしてほしい
例えばStreamReader(String)の場合、ArgumentException系列から
FileNotFoundExceptionやDirectoryNotFoundExceptionのIOException系列までthrowする

2019/04/27(土) 00:38:42.27

悪いとは言わないけど、最近はあまりコンストラクタで例外投げるような処理やらなくなったなあ
何故かと考えたら、async/awaitのせいだと気付いた
コンストラクタではawaitできないから、昔みたいにコンストラクタでファイル読んだりするのはほぼ無くなった

2019/04/27(土) 00:45:53.35

あとDIと相性が悪い
DI使ってると、コンストラクタで例外投げたらそもそもアプリが起動しない

2019/04/27(土) 02:44:50.91

ドキュメントもコンストラクタで投げる可能性のある例外一覧が必要になるけど
実際あげきれなくて手薄になりがち
そうなると設計できない
例外の種類でその後の動作をハンドリングしたいときに動かしてみて
キャッチの種類を分けるしかない
仕様書に書いてあるこのエラー出せないんすけど？
このときの例外増やしてもらえます？
→入れた引数から判断できるでしょ？とかキチガイかよって

2019/04/27(土) 02:55:41.53

>>519
例外の種類を完全に把握できないのはコンストラクタに限ったことではないだろ

2019/04/27(土) 03:07:26.16

>>520
そもそも例外嫌いなんよ俺
ビジネスロジックだとほぼ全部把握しないといけないのに
丸っと渡されると困るだけじゃん

2019/04/27(土) 03:45:53.67

その例外を全部把握しなきゃいけないというのがアホな考えなんだよ
予期できないのはExeceptionとしてまとめてキャッチして処理しとけばなんの問題もないね

2019/04/27(土) 06:32:15.89

どっちも乱暴だな

2019/04/27(土) 07:35:46.92

例外は握りつぶすのが定石

2019/04/27(土) 08:12:46.03

>>522
設計書になんて書くん？
俺んとこ例外使うなら設計書に書いてない例外出しちゃうと大変なんだよ
MSのドキュメントも全部はねーし
マジ厄介
でもお客の言い分もわかる気がするんだよね
流石に何が来るかわかりませんってのはどうなの？
って思う

2019/04/27(土) 08:15:07.62

>>522
ああ、だから例外返さないよねそれ

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

例外の発生要因なんてあらゆるものがあるんだから全部明示しろというお客の主張が不条理
設計書に例外全部明示しろとか要求されたことないね

2019/04/27(土) 08:51:37.56

規約が足かせになってる場合は無視したほうがいい
スキル低い人が大昔に作った規約かもしれないし

例外は復旧可能かつ復旧したいものだけキャッチして対処
それ以外はアスペクトでまとめて処理すればいいよ

2019/04/27(土) 09:11:45.63

コンストラクタで例外がってC+出身者みたいだな

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

話しかけるなゴミが