C#, C♯, C＃相談室 Part95

2017/10/17(火) 00:41:22.60

■Visual Studio 2017 Community(無償の統合開発環境)等はこちら
http://www.visualstudio.com/downloads/

■コードを貼る場合はこちら
http://ideone.com/

■前スレ
C#, C♯, C＃相談室 Part94
http://mevius.2ch.net/test/read.cgi/tech/1492843013/

■次スレは>>970が建てる事。
建てられない場合は他を指定する事。

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

2020/01/04(土) 20:09:00.48

c++スレにいた長文マンかなこいつ

2020/01/04(土) 20:44:38.22

>>660
まあそこはツッコミ来るかとは思っていたが…。

ぶっちゃけ、その通りだ。そしてそれで問題ないんだよ。
結果を確認しに行けば確かに出来ている（ようにしか見えない）からね。
時間軸上で遅延が発生するだけで、論理的な動作としては全く問題ない。

これは例えばJavaScriptでは大昔から実装済みで、getElementsByClassNameがそうなってる。
https://developer.mozilla.org/ja/docs/Web/API/Document/getElementsByClassName
これで問題が発生しているケースなんてない。
馬鹿が「getElementsByClassNameは圧倒的に速い」みたいなブログを書いている、というのは結構あったが。

ただ、まあ、何らかのフェンス構文自体が必要なのは認める。
しかし、当然だがフェンス自体は不要なら書かないものだし、
普通に「返り値を使う」いわゆるお行儀のいいプログラミングをしている限り、実際に不要だ。
だからじきに、みんなが「await って実は要らなくね？毎回お約束的に書かされるだけだろ。」
と思いだした頃に、廃止されるんじゃないかな。
そしたらその階層を取り扱う必要もなくなり、Taskも廃止できる。

2020/01/04(土) 20:59:50.92

>>657 >>662
awaitの結果を必ずしも使うとは限らないのに、本気で言ってるの？
async Task<void>のメソッドなんていくらでも作ることあるだろ。
そりゃ、async Task<bool>にでもしてtrueでも返すようにして、if文で判定するとかはできるけど、そんなの正直言ってasync/awaitからの退化だよ。
C#では非同期実行の方が基本的にはあえてさせることなんだから、awaitなくしたとして
コードを読んでてもわからないところが非同期になっていたら結構困ると思うけどなぁ。
なんでもかんでもどうやらある程度経験が豊富そうなJSを基準に考えちゃうみたいだけど、非同期が当たり前のJSとはとりまく環境が違うと思うよ。

2020/01/04(土) 21:49:39.49

await不要って園児並みに相当バカ
無くなったら何が困るかの簡単なことに気づかないとか、普通の人でもわかることだよw

2020/01/04(土) 21:59:07.73

そろそろ冬休み終わるから謎の長文更新も途切れるかね？

2020/01/04(土) 22:10:43.14

冬休み関係ない人かもしれない

2020/01/04(土) 22:16:18.30

前にも言ったがそんなに素晴らしいものなら、C#の言語チームに提案してこい
誰にも相手にされんだろうが、ここでグダグダと怪文書を書き込み続けるよりは生産的だろ

2020/01/04(土) 23:11:07.21

>>663
> コードを読んでてもわからないところが非同期になっていたら結構困ると思うけどなぁ。
これはその通り。だから俺の理想は以下のコードになるけど、
これはおそらくプログラミング理論的には>>659より汚いコードだとされる。(抽象度が落ちてる）

Coffee cup = PourCoffee();
Console.WriteLine("coffee is ready");
Egg eggs = async FryEggs(2);
Bacon bacon = async FryBacon(3);
Toast toast = async ToastBread(2);
ApplyButter(toast); // ここでtoastが完了してないときだけは結果待ちで止まる
ApplyJam(toast);
Console.WriteLine("toast is ready");
Juice oj = PourOJ();
Console.WriteLine("oj is ready");

async_fence(); // これ以前のasync関数はこれ以降は完了していることが保証される
Console.WriteLine("eggs are ready");
Console.WriteLine("bacon is ready");
Console.WriteLine("Breakfast is ready!");

現行からの変更点としては、
・キーワードawaitをasyncに変更、書く場所は同じ、ただしwaitせず実行して貫通
・キーワードasyncは呼び出し側に明示的に付け、定義側には要らない
・必要ならasync_fence()でフェンス、無ければ実行結果が使われるときに自動的にフェンスされる
・Egg/Bacon/ToastはTaskではなく値、よってキャンセル等は面倒だがどうせしないからよし
ただこれだと async を async()として関数化してリッパーにすれば現行のC++等で実装出来そうな気がしてきた。
これは勝手にやってみるかも。

> 非同期が当たり前のJSとはとりまく環境が違うと思うよ。
コミュニティとしては君らの方が慣れてないだけで、プログラミングとしては大して変わらんよ。
JSもI/O以外は全部同期だし、非同期部分は限定されてる。(なおgetElementsByClassNameは非同期ではなく遅延評価)

2020/01/04(土) 23:27:22.94

仕様を劣化させてるだけじゃん…

2020/01/04(土) 23:40:07.01

>>668
暇だからリファクタリングしてあげた

var cup = PourCoffee();
Console.WriteLine("coffee is ready");
var eggs = FryEggsAsync(2);
var bacon = FryBaconAsync(3);
var toast = await ToastBreadAsync(2);
ApplyButter(toast);
ApplyJam(toast);
Console.WriteLine("toast is ready");
Juice oj = PourOJ();
Console.WriteLine("oj is ready");
await eggs;
await bacon;
Console.WriteLine("eggs are ready");
Console.WriteLine("bacon is ready");
Console.WriteLine("Breakfast is ready!");

コイツの管理者はコードレビュー大変そう

2020/01/04(土) 23:47:15.01

毎日毎日赤っ恥書きながらも上から目線を崩さない姿勢はだんだん可愛く見えてきたなｗ

2020/01/04(土) 23:59:24.33

>>670
それはawaitで書けばほぼ現行通りだろ、というわけか。
まあその通りだが、呼び出し側に async が付いているのがミソなんだよ。
今はそれが Task<TResult> だから明示的だが、var になると明示的でなくなる。これがよくない。

また現行の await は事実上フェンスとして使われているから、
君が書き直したその通りなのだけど、俺は既に言ったが、
「フェンスは出来るだけ使わない」（というよりこれは常識とされる）ので、ここが気に入らない。
書かずに済むのだから書かすなよ、だ。

そして現行の関数宣言部、 async を付けるわけだが、これは意味的に要らん。
(現行の仕様でも特に要らないはず）
ジョブの最上位関数はマルチスレッド/シングルスレッド./同期/非同期関係なく同一に書ける。
それをどう呼び出すかで同期/非同期等切り分けるべきであり、
定義側にわざわざ async と非同期専用みたいに書くのが気に入らない。
同期で呼び出したら同期で動作するだけの関数なのに、だ。

2020/01/05(日) 00:05:02.27

>>670
ああ、だから俺は、違いは

同期：
var eggs = FryEggsAsync(2);

非同期：
var eggs = async FryEggsAsync(2);

だけにして欲しいな、ということ。
現行のコードに async を挿入するだけでコアが余っていれば非同期でその関数が実行され、高速化する、ということ。

2020/01/05(日) 00:17:31.34

言語の感想文はブログで書け
薄っぺらい知識なのを宣伝してるだけだぞw

2020/01/05(日) 00:37:05.87

>>672
あなたの考える仕様はvarの比ではなく、暗黙的でわかりにくい
普通に変数にアクセスしているだけなのに、非同期処理と待ちが入るなんてはっきり言って迷惑

それと呼び出し先を非同期/同期の両方に対応させる設計は良い習慣ではない
・CPUバウンドなら同期的
・IOバウンドなら非同期的
大まかにこの基準で切り分けて、それをシグネチャで明示したほうがいい

2020/01/05(日) 02:47:09.06

C#の仕様策定プロセスはオープンなんだからこんなところでウダウダ言ってないでgithubで提案してみれば？
ツッコミ入って「C#コミュニティはクソ！」って言い出す未来しか見えないけどさ

2020/01/05(日) 04:32:02.28

まさかと思うけど、asyncなメソッドはawaitしないと呼び出せないとか思ってるんじゃないか

2020/01/05(日) 09:05:43.12

>>675
varがわかりにくいというのはお前の慣れの問題。

> 待ちが入る
待っているのは同期設計だ。
毎行で「前行の終了を待つ」からブロッキングと呼ばれる。

> それと呼び出し先を非同期/同期の両方に対応させる設計は良い習慣ではない
そんなわけあるか。もう一度言うが、非同期ってのは呼び出し方法であって、ジョブそのもの（関数）の性質ではない。
例えば、MatrixMulという重たい計算があったとする。
すると、日常的にC#で並列をこなすお前らは、これを高速化する為に、Task<TResult>に分割するわけだろ。
その場合、MatrixMulは「同期関数」だが「非同期」で実行される。
「非同期」ってのは関数の性質ではなく、呼び出し方であって、逆に、「非同期関数」を「同期」で呼び出すことも当然出来る。
だから被呼び出し関数に async を付けること自体がナンセンスなんだよ。
付けるとしたら、呼び出し部分か型で、
var eggs = async FryEggs(2);
AsyncTask<Egg> = FryEggs(2);
であって、お前の流儀は
Task<Egg> = FryEggsAsync(2);
なんだろうけど、これはナンセンスなんだよ。ハンガリアンならぬ、アシンカリアンでしかない。

だから、今の仕様は
A. 非同期に慣れてないC#erへの補助輪
B. ヘルスバーグが中二病全開
C. 実はコンパイラの都合で、async付けてくれればパッチ当てがメチャ楽だったから適当こいて付けさせた
のどれかで、俺はBだと思うけど。

なお気持ち悪さではSQLをべた書きするLinqの方が上だと思う。
でも linq を使った関数に一々 linq を付けることもないし、
同様に parallel を使ったら parallel を付けて回る、ということもないんだろ。
await 使ったら async 付ける、ってのは全くナンセンスだよ。
非同期は、今後は、今のお前らが思っているほどは特別なものではなくなるんだよ。これはもう確定してるだろ。

2020/01/05(日) 09:35:53.95

>>678
async/await考えた人が元々asyncは必ずしも必要ないと言ってるのに、何をさも自分が考えたように言ってるんだ？

awaitいらねーとか真正アスペかよ

2020/01/05(日) 10:52:51.13

>>678
自分はvarがわかりにくいとは思ってない
>var になると明示的でなくなる。これがよくない。
あなたがvarをよく思ってなさそうなので、あなたの考えた謎仕様のほうがそれより遥かにわかりにくいですよ、と言っただけ

>そんなわけあるか。もう一度言うが、非同期ってのは呼び出し方法であって、ジョブそのもの（関数）の性質ではない。
これも間違い
例えば、ネットワークやファイルなどIOバウンドな処理は、CPUとは異なるデバイスで処理されるので、原理的に非同期にするしかない
呼び出し先の性質によって非同期が確定する典型例

CPUバウンドの場合、呼び出し先で非同期をサポートすることも可能だが、基本的にそうする必要は無い
スレッディングのコストは無料じゃないのだから、呼び出し先はすべて同期的に実装して切り替えオーバーヘッドを減らしたほうが、全体的なパフォーマンスが向上する
UIと止めずに応答性を高めたいだとか、非同期にする明確な理由が出来たらそこで初めてTask.Runすればいい

上で基本的にと書いたのは、CPUを食い尽くしてでもいいから時間的に早く処理を終わらせたい、という理由で並列化する場合があるからだ
この場合は、プログラムを並列処理用に最適化して設計するのが定石だ
なので、この場合に関しては逆に非効率的な同期版をサポートする理由がなくなる

asyncが構文として不要なのはわかってるが、そんなつまらない話はあなた以外はだれもしてない

2020/01/05(日) 11:21:56.38

なんで比較にLINQが出てくるのかめちゃくちゃ謎
SQLっぽい書き方のLINQしか知らないのかな？
メソッド拡張の方のLINQはmap/filter/reduceと書き方がちょっと違うだけの単なるメソッドを呼び出し
してるだけなんだけど。

2020/01/05(日) 11:33:14.86

>>680
657 デフォルトの名無しさん (ﾜｯﾁｮｲ 797b-s4wZ) sage 2020/01/04(土) 19:37:21.95 ID:kFIotbKU0
こう説明されれば「あ、確かにawaitいらねえな」とはすぐに分かるだろ。
多分君らが非同期にだいぶ慣れた頃にawaitは廃止されると思うよ。

>>680
asyncが構文として不要なのはわかってるが、…

asyncもawaitも不要なんですね、真正アスペ君w
たったこれだけのシンプルな間違いさえわからない、自分で理解できてない
これが真正アスペでないと誰が言えようかw

2020/01/05(日) 12:17:09.89

awaitは必要だぞ

2020/01/05(日) 14:01:08.94

>>680
なるほどお前が全然分かって無いというのは分かった。

根本的に勘違いしていると思うのだけど、ジョブの中身を同期専用/非同期専用で設計することはない。(というか、できない？)
既に言ったが、MatrixMul、要は行列の掛け算が100ジョブあったら、4CPUならそれを4個ずつ積むだけだ。
このとき吐けた順にガンガン積んで処理していきたいなら、
「非同期」にして最初から全部キューイングしてディスパッチャに任せるだけ。
ジョブ自体が「非同期」ではなく、ジョブの処理の仕方が「非同期」なんだよ。
MatrixMulを非同期専用に書き換える、なんて事はない。というか、出来ない。

> 例えば、ネットワークやファイルなどIOバウンドな処理は、CPUとは異なるデバイスで処理されるので、原理的に非同期にするしかない
これもない。というか、C#にしても、他の言語にしても、ファイルオープンは通常は同期だ。
ここはJavaScriptのスレではないのだが、それを間違えたか？

これについては「JavaScript 10k （またはc10k)」でググってくれた方がいいと思う。
Sleepがない方がパフォーマンスが出る！というのがJavaScriptの宗教だから、蕩々と説明してあるはず。
ただしJavaScriptもメジャーになってしまったし、おそらく以前ほど叩かれなくもなっているので、最近はこの話題も聞かないが。

I/Oを非同期として分離する必要があるのは、JavaScriptがSleep無しのシングルスレッドアーキテクチャだからであって、
Sleepありのマルチスレッドアーキテクチャならその必要はないし、C#含めて通常の言語は全部これだよ。

2020/01/05(日) 14:56:44.29

なんか言い争ってる両者ともそもそも同期非同期の意味が分かってない予感w

2020/01/05(日) 14:57:08.99

>>684
>要は行列の掛け算が100ジョブあったら〜
これは呼び出し先を同期的に実装して、呼び出し元で非同期実行してるパターン
>>680で言うと
>CPUバウンドの場合〜
の段落のこと
このパターンでは呼び出し先は同期版だけサポートすればよく、非同期版までサポートする必要はない
無意味に同期/非同期の両方をサポートしなくていい

>C#にしても、他の言語にしても、ファイルオープンは通常は同期だ。
違う
ファイルIOは背後で非同期的に処理されているが、APIの中でブロックしているから同期的に見えているだけ
昔は言語側の非同期サポートが洗練されていなかったため、妥協してこういう書き方に落ち着いた
C#ではTaskとawaitが導入されて、非同期処理の記述が大きく改善されたため、
原理的に非同期なものは余計なことをしないで、非同期なものとして作れば良い、ということになった
このパターンでは呼び出し先は非同期版だけサポートすればよく、同期版までサポートする必要はない

処理の性質によって同期版か非同期版のどちらかだけを作ればよろしい

2020/01/05(日) 15:01:43.69

こんなくだらん喧嘩の起きる余地がないGoが流行るのも納得

2020/01/05(日) 15:26:07.93

>>686
> 無意味に同期/非同期の両方をサポートしなくていい
無意味も何も、普通に作ったら両対応にしかならないと思うぞ。
逆に、そうならないのなら、コーディングを見直した方がいい。

後半については、多分お前の「非同期」は一般の意味とは違うと思うが、
同期APIと非同期APIの両方が用意されている場合、今後は非同期APIだけ使え、というのはお前の自由だ.。
ただ現実として世の大勢は同期APIで、そしてこれで全く問題ない場合が多く、そうはならないと思うけど。
（例えばファイルなら中身がないと次の処理が出来ず、話を進めようがない事が多い）
なお非同期縛りが心地よいのならJavaScriptを勧める。あれは宗教的にそうなってる。

今はAPIの中身についての話なんてしてない。それがお前流の逃げならそれでもいいが、
ここは「C#でどう書くか」の階層の話をするところであって、APIの中身ガーとか言うのなら最低限先にそう言っておくべきだろ。
ただ俺はそれについてつき合う気はないが。（他の人が食いつくのは自由）

2020/01/05(日) 15:40:34.39

そもC#はSTAとMTAの両方、なんなら混在する環境に対応しなければならないので
どっちかで綺麗に書けるかけるからこうすべきだってお花畑はなかなか通用しないのよね
結局C#においてはasync/awaitもTaskの中で頻発する特定のパターンを楽にしてくれるだけ

>今後は非同期APIだけ使え
新規のAPIではMSはそういう方針だねえ（winrt）

2020/01/05(日) 18:06:33.11

WPFではファイル操作関数を同期的に呼び出せたが、UWPだと許されない。
ちっちゃいファイルの読込みでGUIの遅延も体感できないぐらいだけどダメなんだ。
ちょっとしたプログラム書く時に面倒だね。

2020/01/05(日) 18:11:57.59

>>690
async/awaitあるから普通は問題無くかけるけど、コンストラクターでファイル弄るときは面倒なんだよな

2020/01/05(日) 18:23:07.47

>>690だけど、ちょっと間違った。
同期的には書けるけど、プライマリスレッド(GUI)からだとダメなんだ。

2020/01/05(日) 19:12:31.63

GUIアプリならネイティブスレッドのコストは問題にならないから、
GUIをフリーズさせたくないならイベントハンドラでスレッド起こしてあとは全部同期で書くのが一番シンプルで分かりやすい
最近のC#のasync信仰はWebで膨大なリクエストを捌くときの話で、WinのGUIアプリには全くと言い切っていいほど関係ないよ

2020/01/05(日) 19:23:11.93

>>693
guiのイベントでawaitじゃあかんの？

2020/01/05(日) 19:34:01.01

>>694
もちろんawaitはするよ。
await Task.Run(() => {
//あとは全部同期処理
})
イベントハンドラでこう書くだけ。
コントロールを触るときにInvokeが必要なことさえ忘れなければこれでいい。
ちなみにGoはこの考え方を更に突き詰めて、スレッドを独自の軽量な仕組みに置き換えることでWebも全部同期で書けるようにしてるね。

2020/01/05(日) 19:38:18.63

invokeしても死ぬときあんじゃん？

→運が悪かったと諦める
→解決するまでひたすら回避策を突っ込んでいく
→マイクロソフトに電話かける
→上記を制限時間いっぱいまで全部やってみる

2020/01/05(日) 20:03:16.92

ファイルオープンは同期的とかいう謎の断定の声もあるけど、
UWPだとオープンも非同期なんだね。

https://docs.microsoft.com/ja-jp/windows/uwp/files/quickstart-reading-and-writing-files

アクセスするストレージへがローカルストレージだけじゃなくてクラウドストレージなのも一般的になってきたから、
ファイルを開くために必要な一連の操作もタイムアウトして失敗する可能性を考えなくちゃならなくなったということなのかな。

2020/01/05(日) 20:08:14.69

>>695
なんだ… それなら

〉最近のC#のasync信仰はWebで膨大なリクエストを捌くときの話で、WinのGUIアプリには全くと言い切っていいほど関係ないよ

とちゃうやん
頭ではわかっているのに言い方が間違ってる（言い方が悪い）人時々いるよな

2020/01/05(日) 20:47:26.26

>>695
GUIスレッドでawaitしたらブロッキングしてダメじゃん。
結局、同期呼び出しとおんなじになるよ。

2020/01/05(日) 20:59:12.88

>>699
UIスレッドでawaitしてもブロッキングにはならないと思うけど。
await以降のコードがawaitしている処理が終わったら実行されるだけで、
処理中は一旦asyncのメソッドを抜けてイベントループに戻るよ

2020/01/05(日) 21:07:50.78

>>698
695の場合、どうせ後続に何も書かないんだからawaitはあってもなくても一緒じゃね
警告を抑制する以上の意味はないだろう

2020/01/05(日) 21:15:43.37

>>699
awaitを誤解してる
Task.Wait()みたいにブロッキングはしない
awaitより後ろの処理が自動的に継続タスクになるから同期処理っぽく見えるだけ

2020/01/05(日) 22:16:53.04

>>701
実行ボタンの場合、何も書かないほうが稀だと思うけど

2020/01/05(日) 22:31:27.48

>>703
処理結果の反映にInvoke使うんなら不要でしょ

2020/01/05(日) 22:43:52.66

>>704
ボタンの連打対策が必要とか、普通にプログラム書いてる人ならわかると思うんだけど

2020/01/05(日) 22:53:53.05

>>705
だからInvokeでできるよそれ
Runから戻る必要はない

2020/01/05(日) 23:03:25.02

もしかして705はBeginInvokeと勘違いしてるんだろうか
InvokeはUIスレッド上で実際に処理が完了するまで呼出元のスレッドをブロックするから、連打対策のような用途にも使えるんだよ
なぜかコピペサイトではBeginInvokeだけ紹介されてることが多くて、意外とInvokeの方は知られてなかったりするんだよね
よく理解しないで使ってデッドロックさせるアホがいるからかな

2020/01/05(日) 23:09:20.18

何を争ってるのかよく分からんけど、連打対策になるって主張もよく分かんないねw

2020/01/05(日) 23:12:07.22

いや、そもそも処理終了後にEnabledを戻すだけならBeginInvokeでもいいか
細かいことを言えばInvoke/BeginInvokeだと一度メッセージループに処理が返ってしまい連打を防ぎきれない可能性があるから
無効化の方はRunの前にやっておく方がベターだけど、いずれにせよ後続処理はRunの中からInvoke/BeginInvokeで問題ないね
(というか振る舞いは等価)

2020/01/05(日) 23:13:02.39

継続ブロックがUIスレッドに戻ってくるからInvoke不要ってのがasyncイベントハンドラの価値じゃねえのん
逆にメリットそれだけだからTaskに包んで書こうが構わんやろって向きもあるんだろうけど

マそもそも同期コンテキストの前提がおけないライブラリ内のコードでは
継続ブロックがどのスレッドで動き出すかわからないなんてことも普通にあるので
ConfigureAwaitとか必要悪ともお付き合いせにゃならんのが辛いところネー

2020/01/05(日) 23:19:25.32

>>706
それはTaskだけでなんでも出来るからawaitなんかいらないよ言ってることにならない？
もちろんInvoke使えばできるだろうけど、アニメーションなんかが絡むとコールバックだらけになりそうな気がする。

Task.Runの中のInvokeにはプログレスバーを進める、テキストエリアにテキストログを出す、
みたいなあまり本質的でないUIの変更にとどめておいて、本格的な処理結果の表示はawait以降に書く、なんてのも
コードの読みやすさの確保のためには有効な手順じゃないかな。自分はそうしてる。

2020/01/06(月) 00:46:28.60

>>709
実際にそんなソース書くようなやつはセンス無いから、営業や総務に異動させるわ

2020/01/06(月) 18:16:42.26

ファイルサーバにC#のサービスを常駐させてクライアントからリクエスト受けたらdosコマンドを実行したいのですがどういう技術で実現出来るでしょうか？
単純にサービスだとリクエストをどう受ければ良いのだろうと悩んでおります

2020/01/06(月) 18:26:36.55

そんなもんApacheでも立ててCGIでええやろ
C#なんぞ要らん

2020/01/06(月) 18:33:44.24

昔なんですけどwebサーバ立てないでリクエスト受け付けるサービス作ってた人が居たんです
そんなこと出来るんだと思った数年後の現在調べてみても何の技術か解らず
C#で作られていたのは覚えてるのですが

2020/01/06(月) 18:38:57.81

サービス作った人にやり方を聞けばいいのでは

2020/01/06(月) 18:42:12.36

>>713
https://dobon.net/vb/dotnet/internet/tcpclientserver.html
ソケットで受けてProcess.Startとかすればいけると思うけどあまりお勧めしない

2020/01/06(月) 18:48:18.84

System.Net.HttpListenerのこと言ってる？

2020/01/06(月) 21:20:55.59

>>715
TcpListener/TcpClientでSocketをそのまま使うかWCFかな

2020/01/06(月) 21:47:44.44

>>713
どうやって実現するかを考える前に
解決したい問題を定義することからはじめたほうがいい
そうしないと適切な選択肢を発見できない可能性が高いから

このケースで問題の定義ってのは
「どういう処理を、どういう理由で、どういう制約の中で実行したいのか」

2020/01/07(火) 00:56:13.00

>>715
そりゃ、Ruby でも、socket モジュールで、TCP サーバーを作れるけど、そんな面倒な事はしない。
Sinatra を使えば、ルーティングまで出来るし、

他にも、PowerShell から、1-liner で、
Rubyで作られた、遅い標準ウェブサーバーの、WEBrick も起動できる

ruby -run -e httpd . -p 8080

そのフォルダに、index.html があれば、
何も考えなくても、これでブラウザからアクセスできる

http://localhost:8080

2020/01/07(火) 01:21:55.02

IIS Expressは?

2020/01/07(火) 01:28:51.16

C#で作られたらしいのになぜか他言語推しするやつｗ

2020/01/07(火) 07:07:29.19

WCFという言葉を聞いた事があるのでそれかと思います
調べてみます
ありがとうございます

2020/01/07(火) 07:12:14.82

>>717
古い技術だから推奨されないのでしょうか
後学のためにお伺いしたいです

2020/01/07(火) 16:22:44.68

.NET 5で何か変わると思う？

2020/01/07(火) 17:03:30.97

.NET5は4.x以前とは全くの別物であり、何もかも変わると思っておけばいい
業務ドカタは永遠に4.8から移行しないだろうから、Web系との間で深刻な分断が生じることになる

2020/01/07(火) 18:26:40.26

未だにwin7な企業もわんさかいるし4.8は向こう5年くらいは現役になっちゃうだろうねー

2020/01/07(火) 18:51:41.45

ぇー
4.8から5に移植する必要がでてくるの？

2020/01/07(火) 19:12:37.85

そんな変わらんから

2020/01/07(火) 20:12:30.06

>>730
WebFormsが使えないから、既存の.NETアプリの半分くらいは完全に死亡するよ

2020/01/07(火) 20:26:57.89

あとヤバいのはWCF&.NET Remoting死亡あたりだな
経験上、Classic ASP.NETは使ってるつもりがなくてもユーティリティ類を使ってしまってるケースが結構多くて、大規模なアプリはだいたい死ぬ

2020/01/07(火) 20:32:52.17

あと厄介なのがNuGetの依存関係ね
SDKのバージョンを上げるとだいたいNuGetパッケージのバージョンアップ祭りになるんで、だいたいどっかの破壊的変更を踏んで逝く

2020/01/07(火) 22:31:07.85

>>728
まだVB6アプリが現役なんだぜ
FW4.8は2050年くらいまで持つんじゃね？ｗ

2020/01/07(火) 23:04:37.23

>>734
VB6はC#より早いしWinFormsと見た目もそれほど変わらんからな

2020/01/07(火) 23:20:19.80

VS2010以降の操作性に慣れたらVB6には戻りたくないわ

2020/01/07(火) 23:26:15.05

.NET CoreはLTSでも3年でサポートが切れる
もし.NET5も同じならドカタITでは互換性以前に検討にも値しないレベル

2020/01/08(水) 00:38:18.01

Java8的な感じで残りそうな気もする
4.8で打ち止めなら枯れて安定してるし

2020/01/08(水) 17:07:05.84

WinFormのTextboxやRichTextBoxを使用して、
エスケープシーケンスの様に文字単位で色を変えることは可能でしょうか？

String str = "例文：\red赤\r\n \green緑\r\n \black黒\r\n"; // \red \green \blackは仮想のエスケープシーケンス
TextBox.Text = str;

例えば上記で、赤・緑・黒の色がそれぞれ変えるのは可能でしょうか？
それともエスケープシーケンスは改行やTABにだけ対応していて、
色までは対応していなくて不可能でしょうか？

2020/01/08(水) 17:42:23.45

\redって赤と復帰文字+edの区別つかないじゃん

それはともかくRichTextBoxとRTFを使えばまあ似たようなことはできる
RTFを一から書くのは拷問だけど

2020/01/08(水) 18:32:11.60

>>739
ちょっと何言ってるのかよく分からないけど、
C#のコードでエスケープシーケンスを含む文字列リテラルを書いた時、
それがそのままバイナリになると勘違いしてない？

あれ、コンパイラが対応する文字に置き換えてるんだよw

2020/01/11(土) 10:46:33.04

C#でできることってすべてF#で（多少複雑になったとしても）実現できますか？
同じ共通言語基盤上にあってもC#だけで可能なことってあるんでしょうか。
（もちろん、どちらも計算完備なのでC#でできることは
それこそBASICでもできるでしょうが、そういう意味ではなくて
.NET上での共通性の話です）

2020/01/11(土) 12:49:57.55

>>742
もちろん
チーム全員が関数型言語に習熟しているならあえてC#を選択する理由はないよ

2020/01/11(土) 16:36:56.68

>>743
ありがとうございます。

（ちなみにですが、関数型っていうか対話的に実行できる仕組みが欲しかったんですよね）

2020/01/14(火) 09:13:37.09

https://www.atmarkit.co.jp/ait/articles/1710/03/news018.html
一応C#も対話的に実行できる

2020/01/14(火) 09:19:18.61

>>745
へーこれってどんな仕組み？コンパイル必要としてないの？

**742** (ﾜｯﾁｮｲ 7e28-V2kM) · 2020/01/15(水) 18:27:50.06

>>745
知りませんでした！
折角教えてくださった>>743様には申し訳ないのですが
C#インタラクティブを使ったほうが私めの望みを満してくれるので
そちらにします。

2020/01/15(水) 21:17:39.40

なんだと…ｺﾞｺﾞｺﾞｺﾞ

2020/01/15(水) 23:02:14.43

C# Interactive, 64bitで実行できるようになるのはいつなのかねえ。便利なんだけどたまに困る。
xamarin workbookとかも代替であるんだろうけど。

2020/01/16(木) 00:16:18.83

誰だってわかりやすくて書きやすい言語でプログラミングしたいに決まってんじゃん

C#はまだわかるけど難解ぶってるオナニー言語は滅んだ方がいいね

2020/01/17(金) 01:22:15.96

まあ、たしかに　defun(((((( なんか嫌だもんな。

2020/01/24(金) 22:14:55.39

forおじさんなるキーワードを知ったんだけど今forは使っちゃいかんの？
c#には直接関係ないけどさ

2020/01/24(金) 22:23:17.00

他にbetterな方法がある場合でも、とにかくforをつかえってのを揶揄してるだけでしょ

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

マーティンも今どきforは臭いからパイプライン使えみたいなこと言ってたな

2020/02/04(火) 07:23:29.54

ifとforで何重にもネストさせるやつ未だにいるからな
レビューで暴言吐きそうになって困るからやめてほしい

**デフォルトの名無しさん** (JP 0H2e-5BC/) · 2020/02/04(火) 08:13:40.65

>>755
for回さなくていいって記事読んだとき「なんじゃこりゃ～」って叫んだわ
あ、おわかりのとおりわたし爺ですw

2020/02/04(火) 12:44:04.58

見た目だけじゃなくて処理効率も変わるのかな？
C#みたいな言語だとforだろうがmapだろうがコンパイラがよしなに最適化してくれそう（適当）

2020/02/04(火) 19:03:41.12

実際意味は違うので用途次第ということ

2020/02/04(火) 22:00:23.17

期待通りの順番で処理してもらえるのか？
不安なんでfor使ったりすることあるね。

2020/02/04(火) 22:07:47.88

順番が気になる処理はなるべく書かない