ふらっと 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/17(金) 22:38:25.08

>>477
そもそもシステム開発部署には派閥なんてない
営業の派閥とか気持ち悪すぎ、どんだけいるんだよ不必要なのにｗ

2020/01/17(金) 22:38:46.32

金の話は営業に任せとくわ

2020/01/17(金) 22:40:39.99

営業に逆らったらクビになるから
こういう真実味のある話は嫌いなんですね、わかります
それに皆さんが不満はないのは、ある程度給料を貰ってるからでは？
皆の幸福を全体で考えるなら、どう考えても営業は邪魔でいらない
こんな奴らが苦労人ぶるのは俺は不愉快極まりない

2020/01/17(金) 22:41:01.13

頑張って相手にしてる人もいるけど、アフィブログに転載するための種まきじゃねえの？

2020/01/17(金) 22:41:34.48

>>479
自分の身近な不満を感情のままにぶちまけてるだけで、他人を納得させるような論理的、合理的な説明を一切していないのに、なんで納得させられると思ってるの？

2020/01/17(金) 22:41:58.76

>>480
あるものを無いとか言っちゃう？理解できないものは、見ないタイプ？
そんなやつに売れるシステムなんてねーよ。

2020/01/17(金) 22:45:10.80

そんな単純な話じゃ金が動かない
金が動かなきゃ何もできない
金を動かせる人間と話ができなきゃ開発がスタートしない

そうやって他職種を罵倒するようなやつは君が嫌がる営業と同じだということに気付いてない

2020/01/17(金) 22:47:54.20

マ板でやれよ

2020/01/17(金) 22:48:29.59

>>475
ここにいる人達がすごい技術を持った集団だなんて本気で思ってるのか？
もしそうだとしたら世間を知らなすぎというか技術者に過剰な夢をみているか、自分を含めた技術者というものを特別視し過ぎだ。
もしくは、自分の主張を受けいれてもらおうと、不必要に相手を持ち上げているのではないか？それが意図したものかそうでないか知らないが、もし無意識に癖でやってるなら改めた方がいいぞ。

2020/01/17(金) 22:48:36.57

そんなことよりC#の話しようぜ

2020/01/17(金) 22:50:00.79

>>487
そうだった、すまんかった

2020/01/17(金) 22:56:37.76

>>488
常に技術力を磨いてる技術者と、休日もコネや接待のことしか考えてない
営業はどっちが頭良いと思うんですか？
営業は、確かにちょっとしたテクニックで相手に好かれたりするこつとか
そういうのは得意かもしれません。小手先のテクニックを磨いて、そこに
論理なんて全くないんですよ。流されやすい人間の心理なんかを心得てるにすぎないんですよ。
論理的に考えている水準が全然違う。例えば簡単なC言語のプログラムだって、大学1年
の時は全く手に負えないわけじゃないですか？そんなこともできないの？ってのが
生涯続いて取り返しがなくなってるのが営業の人達だと思うんですね。

2020/01/17(金) 22:59:49.23

>>486
だから悪しき営業文化があるだけじゃないですか？
規模の大きい企業だと営業を通すしかないですからね。
あの部署のあの技術者さんと直接対話したい！あの人となら
良い付き合いができそうだ
ってそういう試みをしてる人がいてもコンプライアンスで禁止されるから
できないだけじゃないですか

2020/01/17(金) 23:11:33.03

誰も賛同してくれなくて違和感を感じる
俺以上にもっと深い視点で切り込んでさらに否定的になってくれたりしないのか

2020/01/17(金) 23:13:28.58

>>483
都合が悪いといつもアフィ扱い

2020/01/17(金) 23:21:25.90

>>493
単純にスレチだから

2020/01/17(金) 23:52:09.27

相手すんなよ…

2020/01/18(土) 00:30:53.67

副作用の削除や参照透過性を何処まで突き詰めるのかにいつも悩む

2020/01/18(土) 01:01:21.51

伸びてると思ったらマ板向けの話かよ

2020/01/18(土) 09:09:16.54

無職・だめとかメンヘラ板の間違いだろ

2020/01/18(土) 09:19:42.14

>>497
最低限副作用があるかないか分かるような書き方をしたい

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

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