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

2019/12/11(水) 22:12:11.28

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

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

■前スレ
ふらっと C#,C♯,C＃（初心者用） Part145
https://mevius.5ch.net/test/read.cgi/tech/1570446977/
■関連スレ
C#, C♯, C＃相談室 Part95
https://mevius.5ch.net/test/read.cgi/tech/1508168482/
■コードを貼る場合は↓を使いましょう。
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/
・Insider.NET > .NET TIPS - ＠IT
https://www.atmarkit.co.jp/ait/subtop/features/dotnet/dotnettips_index.html
・DOBON.NET　.NET Tips
https://dobon.net/vb/dotnet/index.html

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

2020/01/18(土) 13:20:05.43

>>500
これはフィールドに依存、これは静的関数みたいな別けは何基準でしてる？
少なくとも自分の中での基準は明確にしておきたいんだけど全然わからん
使い方次第だろうけどあとからコロコロ変わるのよね……

2020/01/18(土) 13:36:35.87

プロパティにフィールドのラッパー以上の仕事をさせない
処理を必要とするものはメソッドにする
ジェネリックコレクションもそうなっている

オブジェクト指向信者だから単純な静的関数はあまり使わない

2020/01/18(土) 14:33:05.38

バッキングフィールドに値を代入するのだって処理ですよw

2020/01/18(土) 16:29:01.29

System.Text.Jsonでdictionaryやsortedlistのkeyがint時のエラーって直ったんじゃないの？　また復活したの？
> https://github.com/dotnet/corefx/issues/40120

2020/01/18(土) 18:56:57.97

>>503
アスペかな

2020/01/18(土) 19:08:15.28

違うよw
端的に
＞処理を必要とするものはメソッドにする
こんな方針間違ってます。
羹に懲りてなんちゃらそのものだね。

2020/01/18(土) 20:01:07.67

先輩方、Blittableな構造体の実装だけを動的に付け替える方法って何か無いもんですか？
巷で持て囃されるストラテジパターンは参照を使う都合で非Blittableになってしまうので、今はメソッドをenumで指定して愚直にswitchで振り分けていますが、発火の度に分岐を走らせるのはとても優雅とは思えんのです

2020/01/18(土) 20:08:54.79

アスペの考える「処理」の定義がおかしいだけ

2020/01/18(土) 20:09:57.73

Blittableというワードを始めてみた

2020/01/18(土) 20:14:33.94

内容により
配列やリストや辞書などいろいろ使えるとだけｗ

2020/01/18(土) 20:19:12.71

https://docs.microsoft.com/ja-jp/dotnet/framework/interop/blittable-and-non-blittable-types
Bittableって俺も初めて聞いたわ
要はCの構造体みたくサイズがきちんと定まる型ってことか

2020/01/18(土) 20:38:16.33

Blit = 転送する
アンマネージド⇔マネージドに（素直に）転送可能ってことかな

2020/01/18(土) 21:30:37.18

>>507
Blittableに自身を引数に取るdelegeteをIntPtrで持てばええんじゃね

2020/01/18(土) 21:49:52.66

>>513
あざっす大先輩
Cと同じように関数ポインタを使えというのは素晴らしいアイデアなのですが、C#での具体的なやり方が分からんのです
なのでそこのところ詳しくご教示頂けるとありがたいです

2020/01/18(土) 21:52:47.38

using System.Memory

2020/01/18(土) 22:30:29.21

その構造体をrefで渡す必要がないなら構造体をクラスでラップすればいいだけでは？
refで渡す必要があるならこんな方法しかない気が
struct MyStruct:IDisposable
{
　　public int X;
　　public void RegisterAction(Action<MyStruct> action)
　　{
　　　　ActionTable.Add(this, action);
　　}

　　public void Action()
　　{
　　　　ActionTable[this](this);
　　}

　　public void Dispose()
　　{
　　　　ActionTable.Remove(this);
　　}

　　private static Dictionary<MyStruct, Action<MyStruct>> ActionTable
　　　　= new Dictionary<MyStruct, Action<MyStruct>>();　　　　
}

2020/01/19(日) 00:19:29.45

>>510
あくまでもこれを押す俺

2020/01/19(日) 01:04:08.98

実際に処理が分岐してんのに分岐してないようにみせるのって何がいいんだ？

同じルート通ってるのに違う処理呼ばれてんだろ？
ドキュメントにそれの記述がない状態でそれということを理解するためには
ブレークで止めてステップ実行でもするしかないじゃないか？
お前がスマートだと思ってるコードは他人には読み難いだけのクソコードである可能性を心配したほうがいいな
心が壊れてしまう前に
何十年もそんなくだらないことに時間を割いたあとでは大変だ

2020/01/19(日) 01:46:20.77

大変なおつむからどうにかしとけ生ゴミ

2020/01/19(日) 02:12:12.57

>>518
まあ、誰しも最初からわかってるわけではないので、言ってることがわからんでもない
LINQわかりにくいからループ回せやみたいなもんかな？

〉実際に処理が分岐してんのに分岐してないようにみせるのって何がいいんだ？
まずその捉え方が間違い
actionのメリットをググれば残りの疑問も解消する

2020/01/19(日) 02:20:46.05

>>518
C言語の関数ポインタも認めない派?

2020/01/19(日) 08:12:00.36

>>514
正直なぜBlittableなのか、参照型ではだめなのか、という話から詰めた方がいいと思うけど

struct Foo {
　public int data;
　public IntPtr fn;
}

static class FooDo {
　public static Do1(ref Foo x) {}
　public static Do2(ref Foo x) {}
}

こんなのをMarshal.GetFunctionPointerForDelegate/GetDelegateForFunctionPointerで相互変換する
厳密にBlittableじゃなくて値型で良いならdelegeteそのままで持てば良いけど

2020/01/19(日) 08:13:14.51

>>520
ねーよ
だって俺が他人のソースを読むときに一番嫌なのは見えにくい動作だもの
ここが隠れてわかりにくい時点でその組み方に何の魅力も感じない
たくさん処理が分岐してるのであればそれを明示的に記述したい
思いっきりswitch caseで書きたい
ソースにhtmlのようなフォント設定機能があったら太字にしてサイズは72ぐらいで表示したい

2020/01/19(日) 08:57:48.92

>>523
小学校からの通知や町内の回覧板に漢字が使われていたら、｢俺は漢字は読めねーんだ！覚える気もしねぇ。俺が読めるようにひらがなだけ使え！｣って言ってるようなもんだな。
難読漢字を多用してるならともかく、常用漢字も読めないならお前が勉強しろよ。

2020/01/19(日) 09:07:37.25

>>523
〉だって俺が他人のソースを読むときに一番嫌なのは見えにくい動作だもの
誰だってそれは同じ

〉ここが隠れてわかりにくい時点でその組み方に何の魅力も感じない
それは、共通処理が隠れてわからないから全部インライン展開しろやと言ってるのと同じで、バカの理論。
引数にactionがある時点で、呼び出し元で処理を指定するのが判断できる
そういう共通処理なんだなとわかる
使い方もわかる
わかりにくいところはない
この程度のことをわかりにくいと思うなら、相当センス無いよ

〉思いっきりswitch caseで書きたい
actionを知らなくて（使い方に慣れてない。メリットを理解できてない）そういう人も多いからどちらでもどうぞ
action書けるとこは全部書けとも思ってない。メリット大なとこだけ書く（書き直させる）だけでも可と思ってるので

2020/01/19(日) 09:16:15.41

>>525
判断できる、じゃねーよアホか
明示的に書くと何でダメなんだ？
明らかに判断しなくちゃいけない手間が入ってるじゃん
そしてそこにメリットがない

2020/01/19(日) 09:19:15.16

俺の価値観はさっきレスした通り
わかりやすい、明示的に、を何より優先する
お前のactionの処理は全部でいくつあるのかソース中を検索かけて隅々まで見ないとわからないじゃないか
欠陥コード乙

2020/01/19(日) 09:25:38.63

君の価値観なんて興味ないよ

2020/01/19(日) 09:27:56.48

>>528
涙を拭けよ

2020/01/19(日) 09:32:32.58

言わんとすることはわかるけど
まあ複数の場所に100個caseのあるswitchが出てくるとくじけることがある

2020/01/19(日) 09:33:49.54

似たようなクラスが100個あっても挫けるw

2020/01/19(日) 09:36:41.75

何だ、センス以前に真正バカだったか。
こういうのを老害（ゆとりバカ）と言うんだなw
真正バカと議論しても無駄なので無視（NG）っと

2020/01/19(日) 09:37:18.43

しかもクラス100個が国産牛の脂肪ように間に入ってる
それらのactionの数だけそこを通るんだ
どう考えてもswitch caseのがいい

2020/01/19(日) 09:38:38.35

老害staticおじさんの思考回路だな
こういうのは非つっようない限り関わり合いにならないようにするに限る

2020/01/19(日) 09:42:42.21

>>522
マジであざっす！

2020/01/19(日) 09:45:42.06

明示的に書いてあるほうがいいってのは数が少ない場合に限る
明示的に書いてあっても数が増えると同時に考えなければならない事項が増えて脳に多大な負担がかかるようになる
だから細かいことは気にしなくてもうまく行く仕組みを確立して脳の負担を減らすことの重要性が増す

というのがコードリーディングの観点での評価
他にもリビルド不要で拡張可能であるかどうか
開放閉鎖の原則を満たすかどうか
といった観点でも評価ができる

2020/01/19(日) 09:47:57.84

>>536
は？
むしろ多いときほどいいだろ

2020/01/19(日) 09:48:44.90

>>525
> 誰だってそれは同じ
同じじゃないだろ
必要ないものは見たくないのが普通だと思うぞ…

2020/01/19(日) 10:32:09.72

コンパイラやバイトコードのツール類は巨大なsweichがドカーンと鎮座してるけど
内容がはっきりしてるからわかりやすい
検索したら内容は終えるし

そうじゃなくて内容に応じて動的に変わる場合はそれじゃ賄えないのでdelegate使うけど追うのは大変なのはわかる
でもそれはswich caseに落とし込めない
落とし込むとバグの温床になる

2020/01/19(日) 10:35:49.15

>>538
必要ないものを書くんじゃねーよ
削除しとけ真正バカ2号

2020/01/19(日) 10:36:30.94

>>537
多いときほどswitchは悪い
数多の案件で膨大なswitchが開発者を苦しめた実績がある

2020/01/19(日) 10:52:59.80

>>541
どこ？

2020/01/19(日) 10:59:47.28

>>540
匿名掲示板で人に指図とかバカすぎるわ
そもそもどうやって削除するんだよw
できるならお前のアホレスから削除しとけ

2020/01/19(日) 12:14:24.61

このまえ相談室で暴れてた人と同じ人かｗ

2020/01/19(日) 12:21:15.99

相談室ってまだあったのか
無くなったんだと思ってたｗ

2020/01/19(日) 12:34:19.33

enumに実装が書けないのでと言う話も書いておこう

2020/01/19(日) 12:41:58.91

ガイジの相手をするなガイジ予備軍が

2020/01/19(日) 16:10:31.36

とガイジが申しております

2020/01/19(日) 18:32:06.96

>>465
「tsv」という呼称では呼ばれていなかったがタブ区切りデータは普通にあった
個人的にはアセンブラとか機械語だけで書かれてるプログラムが使ってることが多かった印象

他には「:」区切りや「;」区切りも割と良く見かけた

2020/01/19(日) 18:36:52.64

>>469
切れたことならあるよ

2020/01/19(日) 18:40:17.51

>>484
感情はあくまで感情だから合理的に納得させる必要は無いでしょう

2020/01/19(日) 18:41:50.89

>>482
逆らっても首になるとは限らない
もしその程度で首になるような会社なら辞めた方が良い
営業に対しては言いたいことを言った方が良い

2020/01/19(日) 18:49:45.09

>>549
古いMakefileがそだねー

2020/01/19(日) 21:12:21.07

昔はレコードデリミタ/フィールドデリミタといってプログラムごとに適当に決めてたな。

2020/01/19(日) 21:17:27.74

ascii コードの30 = rs/31 = us
がそれだよ

2020/01/20(月) 13:02:26.55

1E
1F
って書いて欲しい

2020/01/22(水) 05:35:21.57

単一のページ内で、Blazor ServerとBlazor Webassemblyを混ぜて使うことってできないのですか？
主にBlazor Webassemblyを使いたいものの、乗っ取られると危険な処理はBlazor ServerのビルドインSignalRに全部まかせたいんです

2020/01/24(金) 09:56:09.28

>>557
普通にサーバーサイドはREST API書けや
Blazorに固執する意味がわからない

2020/01/24(金) 10:59:53.85

>>558
ちゃんとできる人ならそれもいいかもしれませんが、私のレベルで手を出すのは危険なのです

2020/01/24(金) 11:40:10.55

意味がわからん
Web APIなんて枯れきった技術だろう
Blazorはバグだらけで、問題があったら自分でソース見たりgithubのissue上げたりできない奴は手を出してはいけない代物

2020/01/24(金) 12:12:18.20

あなたは優秀なのかもしれませんが、私はマイクロソフトの技術者の足元にも及ばないので勘弁してください

2020/01/24(金) 12:33:53.87

百姓は畑を耕してろ
一丁前にコードを書くな

**デフォルトの名無しさん** (ｽﾌｯ Sd7f-er59) · 2020/01/24(金) 16:03:06.25

お百姓さんにはかなわないけどね
米作ってる人が一番尊い

2020/01/24(金) 16:32:47.40

上流でウンコしていたぞ(猪が)

2020/01/24(金) 17:28:13.96

Blazorは表面的には簡単に見えても
本質的には難易度高いはずだけどな
(見えないところで無理してる分)

サーバサイド技術は基本的な知識だから学習するに越したことは無いよ
つーけ後で結局手詰まりになる

2020/01/24(金) 18:26:34.95

blazor clientはシンプルなアーキテクチャでいいね

2020/01/24(金) 18:45:27.77

Blazorって普通は使う局面ないよな

2020/01/24(金) 18:48:38.24

金出してくれる人が居ないと使わないな

2020/01/24(金) 18:50:59.25

開発側の利点で顧客が金を出してくれることはほぼないから無理
将来のメンテナンスコスト考えると普通にjs使うだろう

2020/01/24(金) 19:02:01.81

まあWPFみたいにすぐに負債になるのがわかりきってるし、
自分のスキル的にも時間の無駄でしかないわな

2020/01/24(金) 19:03:04.46

MSがこういうものを金をかけて開発してるのが納得いかない
無駄でしかないのに

2020/01/24(金) 21:32:32.32

Blazorは意外と業務系で普及するんじゃねえかと思ってる
業務系はJS不得手な人材沢山いるからC#でサクサク開発できるメリットがデカイ

2020/01/24(金) 22:20:15.50

WebAssemblyの実用化楽しみ
MSは開発がんばって欲しい

2020/01/24(金) 22:53:56.32

WebAssemblyを基盤にしているからSilverlightみたく捨てられることは無いとは思うけどね

2020/01/24(金) 22:59:42.67

js不得手マンだけどjs周りをもっと使いやすくしてくれればそれでいいのよ
TypeScript使えば良さそう？だけど触ったことない

2020/01/24(金) 23:04:24.05

blazorアイデアはいいんだけどいかんせんバイナリサイズがでかいのがどうにかしてほしい（サーバーサイドの方にはあまり将来性がないように見えるので）
せめてcorert経由するようになれば軽くなるんじゃないかと思うんだが

2020/01/25(土) 01:41:58.91

>>572
HTML/CSSはどのみち必須なんだから、クラシックなMVCアプリならほとんど変わらんよ
Blazorの意義はJSをゴリゴリ書かなくてもSPAを作れることにあるわけだけど、業務系でそんなもん要求されない

2020/01/25(土) 08:09:35.21

業務系は巨大で複雑なUIが多いからSPAのほうがうまくハマる
今は高度なJSスキルが必要だから避けられてるけどC#で書けるって理解されたら業務系でも採用が増えるだろうね
JSを排除できるメリットはかなり大きい
それに加えてMVCよりBlazorのほうが構文とアーキテクチャが直感的で簡単なのもポイント
BlazorはHTTP/HTMLの事情を詳しく知らなくても書けるように出来てる
MVCはHTTP/HTMLフレンドリで必要な前提知識が多いから業務系では採用しにくい

2020/01/25(土) 08:16:01.45

それを資料に纏めて、金持っている
人を説得しないと。普及しないと思うよ。

2020/01/25(土) 09:56:59.74

BlazorはいいんだがRazorはどうにかして欲しいねぇ。WPFとか使えるようになればいいが。

2020/01/25(土) 11:56:16.01

swtich分って必要なんですか？
普通に変数1個にして外部ファイルで設定すればいいだけじゃ？

2020/01/25(土) 12:16:51.33

必要な引数も違うのにどうやって分岐無しで呼び出すの？

2020/01/25(土) 12:47:14.80

1=りんご
2=バナナ
3=キウイ
4=いちご
5=みかん

こんな感じのテキストファイル作ればいいだけじゃ？

2020/01/25(土) 12:49:28.83

>>583
相談室でやれ

2020/01/25(土) 13:42:09.40

>>583
引数がそれぞれ0,4,7,17,5とか変わったらどうやって呼び出すの？

2020/01/25(土) 14:13:33.17

>>583
それがクラス定義だった糞プログラムのメンテ担当したことあるけど、正直殺意沸くレベルだった

2020/01/25(土) 14:20:20.86

文字列やバイナリを処理する辺りでswitchが出てくるのは仕方ないにしても、それ以外でswitch文が出てきたらほぼ設計ミスだろうな

2020/01/25(土) 14:22:56.55

ごめん、入力を受け付けるようなものは使ってもミスでも何でもないな

2020/01/25(土) 14:29:09.12

>>583
それでいいと思うなら、もうそれでいいよ。
switchが役立つと思う場面に出会ったことがないなら無理に使わなくていい。
普通にプログラミングの学習をしたり実際に何か作り始めれば、そう遠くないうちに役に立つと思える場面に出会うはず。

2020/01/25(土) 14:30:38.90

重複したswitchや長大なswitchが悪いのであってswitch全てが悪いわけではない
拡張するときに不便を感じたら多態に置き換えればいい

2020/01/25(土) 14:46:40.30

>>583
使い道がないのはお前の存在も同じだから
中央線にでも飛び込んで死ね

2020/01/25(土) 14:56:41.64

プログラミングに限らずどのフィールドでもそうだけど、
イキってる系の連中の主張は話半分に聞いておくのがいいと思うよw

2020/01/25(土) 15:17:19.02

>>583
条件文をマッピングテーブルで置き換えるという古典的なリファクタリング方法の一つ
どちらかが常に優れてるわけではなく状況に応じて選択するもの

C#のバージョンや分岐の数によっては
コンパイラがswitch文をdictionaryのlookupに変換してる

2020/01/25(土) 15:30:40.16

>>593
それ今は迷信
Roslyn移行後のC#コンパイラはswitchのcase数が多い場合はハッシュに基いた二分探索のようなコードが生成される

2020/01/25(土) 17:27:27.49

>>578
同感
業務系アプリをブラウザで動かしたいっていう潜在要求は多いと思う

2020/01/25(土) 18:16:56.04

>>594
Roslynから変わったのは文字列で分岐される場合のみの話

文字列比較でhash tableをlookupするんじゃなく
数値比較で事前にハッシュしたsort済みarrayをlookupするようになってる
細かい部分を抜きにすると数値をキーにしたSortedDictionaryのlookupと同じ
でこういうのは今の>>583には不必要な知識

2020/01/25(土) 22:26:55.47

流れよく分かんないんだけど
つまりenumで分岐して処理呼び出す場合はswitchと配列のどっちが何倍くらい速いの？

public static int Execute(this Test type, int value){
　// 無難にベタ書き
　switch(type){
　　case Test.One: return Method(value);
　}

　// 配列からメソッドを呼ぶ
　return methods[(int)type](value);
}

こんな風にenumに処理持たせてやりたいんだ俺

2020/01/25(土) 22:30:01.75

ケースバイケース
どっちが早いのかは実測が基本
どっちも最適化等々で逆より早くなりうる可能性がある

2020/01/25(土) 23:36:00.99

単純な配列はいつでも最速だと思ってたが違うのか？
読むのが単なる値じゃなくて処理な時点で誤差レベルだと思うが

2020/01/25(土) 23:53:16.79

XLAT