TOP カテ一覧 スレ一覧 100～終まで 2ch元 削除依頼
Visual Studio 2019 Part3
Vim vs Emacs Part2
【統計分析】機械学習・データマイニング24
C#,C＃の宿題片付けます。
WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part22
C言語なら俺に聞け 153
Rust Part5
人工知能ディープラーニング機械学習の数学 ★2
Ruby 初心者スレッド Part 63
関数呼出しはgoto文である

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


1 ：2017/10/17 ～ 最終レス ：2020/04/18
■Visual Studio 2017 Community(無償の統合開発環境)等はこちら
http://www.visualstudio.com/downloads/

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

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

■次スレは>>970が建てる事。
建てられない場合は他を指定する事。
VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured

2 ：
■過去スレ
C#, C♯, C＃相談室 Part90
http://echo.2ch.sc/test/read.cgi/tech/1455160063/
C#, C♯, C＃相談室 Part91
http://echo.2ch.sc/test/read.cgi/tech/1467142749/
C#, C♯, C＃相談室 Part91 (実質Part92)
http://echo.2ch.sc/test/read.cgi/tech/1467211515/
C#, C♯, C＃相談室 Part92 (実質Part93)
http://echo.2ch.sc/test/read.cgi/tech/1485589613/
C#, C♯, C＃相談室 Part94
http://mevius.2ch.sc/test/read.cgi/tech/1492843013/

3 ：
■関連スレ
初心者の質問向けはこちら

ふらっと C#,C♯,C＃（初心者用） Part132
http://mevius.2ch.sc/test/read.cgi/tech/1507543256/

4 ：
Dictionary.TryGetValueってどんなシーンで使う？

5 ：
ワッチョイスレは既に立っていますので重複です
C#, C♯, C＃相談室 Part93
http://mevius.2ch.sc/test/read.cgi/tech/1492818720/

本スレ誘導
C#, C♯, C＃相談室 Part95
http://mevius.2ch.sc/test/read.cgi/tech/1508180530/

6 ：
>>4
DictionaryにTryGetValueがあるの初めて知った
ValueからKeyを逆引きするときはLINQで済ませちゃうから使うことないかな

7 ：
>>4
キーの有無とキーがあったら対応する値を取得したい時でしょ

>>6
> ValueからKeyを逆引きするときは
意味不明なんだが...

8 ：
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

3RP0W

9 ：
QBP

10 ：
PictureBox に次々と画像を表示すると、使用メモリがどんどん増えます。

PictureBox.Image.Dispose() を呼んでも変わらず、強制GCも利かず。

皆さんは、どの様に対処されてます？

11 ：
日本語入力中の文字列や変換途中の文字列を取得してリアルタイムに出力したいんだが
どうやったらいい？

12 ：
壊れてなければリアルタイムに表示されとるやろ普通
何をいっとんのやコイツ？

13 ：
C#でJavadocのようなドキュメントを生成するツールを探していますが何かないのでしょうか？

14 ：
>>13
https://github.com/EWSoftware/SHFB

15 ：
>>14
ありがとうございます。
確認します。

16 ：
独習C# 新版買った人いますか？
async/await周りの記述は詳しいでしょうか？
async/await以降のマルチスレッド本が欲しい(async/await前のは持ってます)んですが、
おすすめを教えてください

17 ：
リアクティブプログラミングの本とか？

18 ：
イディオムかな

19 ：
>>10
Pic.Imageに設定したやつをディスポしてないんじゃね？

20 ：
>>19
呼んでるんだがなぁ。

半年以上前の書き込みにレス、ありがと。

21 ：
ある程度は増えるがフィールドなどで抱え込んでいない限りGCがそのうち片付けてくれる
片付けるタイミングは環境によっても変わるのでどうしようもない
if (Image!=null) Image.Dispose;
Image=null;
GC.Collect();
と並べておくと何とかなるかもしれないが、これで駄目だったこともあるｗ

22 ：
using(Image){/*NO OP*/}が一番楽じゃねえの？開放。

23 ：
>>22
あたりまえだけどusing抜けたら画像が表示されなくなるからPictureBoxの画像を次々と差し替えるのには適さない

24 ：
Microsoft Reportで文字を印刷しています。
フォントを MSゴシックにすると、漢字も文字化けすることなく表示できるのですが、
Unicode文字 （例　?　）だと、文字化けしてしまします。
対策はないでしょうか？

25 ：
Windows8のコマンドプロンプトでcsファイル実行しても操作可能なプログラムとして認識されていませんとか出るんだけどどうしたらいいかな
VSみたいなアカウント登録が必要なのは論外だからアカウント不要な開発環境で

26 ：
>>25
VSはアカウント登録しなくても使えるよ

27 ：
直接csc叩け

28 ：
>>25
notepad.exe + csc.exe

29 ：
何で論外になるのか知らんけどVS嫌ならVS codeにでもすれば？
つうかcsファイルが開けないってだけならサクラエディタでも入れれば？

30 ：
>>25
csファイルの存在するディレクトリにcdした後、

notepad hoge.cs

31 ：
csファイル実行って書いてるから
csファイルが実行可能形式かスクリプト言語だと思っている？？？

32 ：
notepad.exe は、メモ帳だろ。
notepad は、メモ帳を使うコマンドだろ

エディタは関係ないだろw

33 ：
コンパイルしないと実行ファイルにならないで

34 ：
コマンド？
exeがなかったらexeつけたファイルがあるか探索するだけだよ

csファイルを実行したんだろ
登録された拡張子じゃないからどうすりゃいいのって質問でしょ

どんだけ読解力無いの

35 ：
まあ24への回答だったら
馬鹿には無理
で十分よ

36 ：
■「C#」「Visual studio」「Windows EXE実行ファイル」のリリースについての質問です

Visual studio(C#)でコンパイルした、
Windows EXE実行ファイルのリリースについて質問です。

バッチシステムとしてタスクスケジューラーで起動させますが、
頻繁にシステム改修があり、都度リリースが必要です。

しかし、システム実行中にリリース(EXEファイルの上書き)を行うと、
起動中のため上書きエラーとなります。

実行中のEXEに対して、
次回の実行分から最新のシステム改修を反映させるには、
どのようにしたら良いでしょうか？

以下私の案がございますが、スマートではありませんし、
実行開始に時間がかかるデメリットがございます。
他にスマートな案はございますでしょうか？

起動に関するフレームワークなどあるのでしょうか。

<案>
1.処理開始時に本体EXEファイルをコピーして実行版EXEファイルを作成する(同一のEXEファイル)
2.実行版EXEファイルを起動する
3.実行中でも本体EXEファイルは上書き可能なため、本体EXEファイルに対してリリース(EXEファイルの上書き)を行う

37 ：
>>36
同じファイルを上書きしなきゃだめ？
versionごとにフォルダ切ってスケジューラの古いのを削除、新しいのを登録
ってすれば解決しそうだけど

38 ：
>>36
一般的には起動時に更新が存在するかをチェック。
あれば更新してから実行。
この時、自分自身は更新できないから回避方法は大きく２つ。
・更新時に別プロセスを起動して更新させる。
・起動用プロセスがチェック、更新、実行プロセスの起動を行う。

自分なら後者を使う。

39 ：
この人あらゆるサイトにマルチポストしてますね

40 ：
ちょっとググっただけで2ｃｈ以外で五ヶ所くらい見つかるな
本人か別の人が貼りまくってんのか。どっちにしても春爛漫な人のようだ
マジレスした人お疲れ

41 ：
C#でセレニウムにチャレンジしています。
Chromeを起動すると「Chromeは自動テスト ソフトウェアによって制御されています」と
メッセージが表示されてうざいです。

これを非表示にする方法はないでしょうか？

42 ：
マルチンポ

43 ：
>>41
君には無理

44 ：
C#でセレニウムにチャレンジしています。
Chromeを起動すると「Chromeは自動テスト ソフトウェアによって制御されています」と
メッセージが表示されてうざいです。

これを非表示にする方法はないでしょうか？

45 ：
無理よー無理無理

46 ：
うざいメッセージはNGに突っ込むと非表示になるよ

47 ：
C#でセレニウムにチャレンジしています。
Chromeを起動すると「Chromeは自動テスト ソフトウェアによって制御されています」と
メッセージが表示されてうざいです。

これを非表示にする方法はないでしょうか？

48 ：
C#でセレニウムにチャレンジしています。
Chromeを起動すると「Chromeは自動テスト ソフトウェアによって制御されています」と
メッセージが表示されてうざいです。

これを非表示にする方法はないでしょうか？

49 ：
まだやってたの(苦笑)

50 ：
BOTでしょ。気になるならNGにしとき。

51 ：
varでも使っとけや

52 ：
C#でセレニウムにチャレンジしています。
Chromeを起動すると「Chromeは自動テスト ソフトウェアによって制御されています」と
メッセージが表示されてうざいです。

これを非表示にする方法はないでしょうか？

53 ：
そろそろ通報しとくか

54 ：
C#でセレニウムにチャレンジしています。
Chromeを起動すると「Chromeは自動テスト ソフトウェアによって制御されています」と
メッセージが表示されてうざいです。

これを非表示にする方法はないでしょうか？

55 ：
docsに.NET Framework 4.8対応の表記並んでいたからリリースされたのかと思ったら18日からか

56 ：
Quoraでこんなスレッドを見つけた：
https://www.quora.com/Why-is-C-so-much-better-than-Java-yet-not-as-popular
「Why is C# so much better than Java, yet not as popular?」
[Q] C#はまだ人気がないのに、なぜ、Javaよりそんなに優れているのでしょうか？
[A]
I am a Java guy, yes, but this has nothing to do with the following.
I don’t agree with you on C# being “so much better than Java”.

私はJava野郎です、はい。でも、そのことは、以下に述べることとは直接関係有りません。
「C#が Javaよりそんなに優れている」ということに私は賛同しかねます。

57 ：
この文章で一番重要なのは、2018/08/24 の時点で、「C#はまだ人気が無い」
と書かれていること。

本場アメリカでは、C#は人気がないらしい。実際、C++のスレッドは、C#の
スレッドの3倍弱程度存在している。そして、Javaは、C++の数割り増し程度。
つまり、C++ を 1.0 とすると、

Java : C++ : C# = 1.3 : 1.0 : 0.36

程度の人気。

58 ：
ジェネリック、ネイティブコード、そしてC＃がJavaよりも優れていることに
ついての他の多くのことについて、デリゲートなど、あなたがコメントで
述べたものはすべて無意味です。これらの機能は、どちらかの言語を使用する
プログラマの95％には使用されていないか、または必要とされていません
（私はその割合を引き下げただけです。まったく意味がありません）。

C＃がJavaでできないことはありません。それに加えて、Javaは本当に、
絶対にそして明白にクロスプラットフォームです。私は毎日クロスプラット
フォームのソフトウェアを書くためにそれを使います。一方、C＃はMicrosoft
のファン用です。私のすべてのプロジェクトでMicrosoftスタックを使うよう
に制限されたくはありません。私はVisual Studioが神の地球上で最高のIDE
であると認めますが、それはそれについてのみのことです。

59 ：
「C＃開発者よりもはるかに多くのJava / Python /他の言語の開発者がいる」
と書かれている。

60 ：
KotlinはSwiftに似ていて、JVM上で動くSwift、という感覚なんだそうだ。

61 ：
「その名前にもかかわらず、C＃はC ++よりもJavaに近いです。」

62 ：
アメリカでは、MS以外の大手IT企業で、C#を使用しているところはほぼないらしい。
逆にJavaはほぼ全ての大手IT企業が使用していると書かれている。
驚き・・・。

63 ：
Java guyだからわかんないんじゃないの？
カツ丼食ったことない人に、カツは不要、必要とされてないと言われてもなんの説得力も無い。

単にJavaで開発してる人の周りにはJavaで開発してる人だらけなだけっしょ。

64 ：
別に他の人がC#使ってるかどうかなんてどうでもいいし
自分が書き易けりゃいいよ

65 ：
C++は置いておくとしてJavaがC#に勝る点なんて
ジェネリックもデリゲートも使えないようなエンジニアものどきの数くらいだろ

66 ：
.NET5が出たら本気出すってことか？

67 ：
確かにCOBOLからJavaに置き換える案件は多い

68 ：
>>65
Quora英語版によれば、
・言語の使い勝手は言語そのもの良し悪しだけでなく、トータルで決まる。
　（ただし、言語そのものもC#がJavaよりそんなに優れているわけではないとのこと。）
・Javaは今までに形成されたエコシステムがかなり大きい。
・JavaはかなりMultiplatformだが、C#はそこまでには至っておらず、
　ほぼWindows限定になる、とされている。
・C#がJavaよりも優れた点は、Javaそれほど使用頻度の高いものではない。
・Javaの開発環境は無料だが、C#の開発環境はかなり高価。
・C#はMSの独占的なもの。
・今までJavaを使ってきて、C#に乗り換えるのは大変。
・C#が数としては使われているとしても、愛されているわけではないが、
　Javaは愛されている。

69 ：
>>68
>JavaはかなりMultiplatformだが

VM上で動いているんだから当たり前だと思うが・・・
つか、いろいろと私見が入っていて参考にならんわ

70 ：
私見というか私怨すら感じるｗ
javaの魅力が伝わってこない

71 ：
C#がMS独占っていうけどjavaはoracle独占じゃないの？

72 ：
正しくはJCP独占
なぜならTCKに合格しなければJavaであることは認められず、TCKを管理してるのがJCPだから
JCPはOracleの傀儡だろという意見は受け付けます

73 ：
JCPで検索かけたら・・・ｗ

74 ：
>>70
本場アメリカと2chとの違いかも知れん。

75 ：
Java EEは今後JCPを使わず
https://www.infoq.com/jp/news/2018/01/no-jcp-for-javaee/

＞オラクルは今後のJava EEの拡張に対してJCP (Java Community Process)を使うことを支持、推奨していない。

76 ：
そんなに本場アメリカを啓蒙するなら本場アメリカに行けばいいにでは？

77 ：
>>68
主観というかJavaを愛しすぎて履かせた下駄すら見えなくなってるな。

78 ：
>>68
10年前ならまあどういしただろうけど、おじいちゃんの意見は今更どうでもいい

79 ：
unityもあるしな

80 ：
Coreもどーせ頓挫すると思ってたが存外ガチにやってきてるな
>>68何時の記事か知らんけど全く現状に即していない

81 ：
javaと聞くとCOBOLと同じ感情を抱くようになった
特にラムダ機能以降

82 ：
実際今のJava使いなんてコボラー2世みたいなもんだろ

83 ：
元からじゃね？

84 ：
https://ideone.com/i0dL3Z

こういうコードで、AKlass.Foo()がどのクラスから呼ばれたか判断する方法ってある？

85 ：
AKlass.Foo()って呼ばれたらどうするんだよ
どう書こうがAKlass.Foo()の呼び出しにコンパイルされるからそのままじゃ無理
InheritedKlassとAnotherInheritedKlassそれぞれにFooを定義して
protectedなAKlass.FooCoreを呼び出すとかすれば？

86 ：
やっぱりそうするしかないか
適当に自動生成させる方法考えよう

87 ：
WPFでの開発をやりたいのですが
prismを使った開発手法が一般的なんでしょうか

88 ：
>>87
一般的だったんだけど、MSの手を離れてからどうにも信憑性が薄くなったような…
機能自体は便利になってるんだけど、ベースクラスの削除とか平気でやるからバージョンによってテンプレートが使えなくなる印象
それでも使わないと面倒が臭すぎるから使うけど

89 ：
>>88
ありがとうございます
そうなんですね。。でもまぁ初心者が自前で全部シコシコするよりは全然ですよね
ちょっと頑張って勉強してみます
ちなみに、 Prirm.Coreと Prism.Wpfの両方を入れればいいのですか？

90 ：
答えはyesです

91 ：
>>89
WPF初心者ならまずはPrism使わずにコードビハインドにイベントベタ書きするのをおすすめする

92 ：
>>91
ありがとうございます
・コードビハインドでの実装
・prismを使わない場合のMVVMの実装
・prismを使った場合の実装
をそれぞれ一通り確認して、仕組みの勉強は軽くだけですがしてみました
今後開発するにあたって仕組みの理解を深めつつ、どの手法で行うのがいいのか聞いてみました
formの経験はそこそこあるのですが、WPFは初めてなのでアドバイス助かります

93 ：
DDDを体現するためビジネスロジックは全て日本語で表現しようと思うのですがC#の仕様的に発生する不都合って何か考えられますか？

94 ：
全て日本語で表現したらキーワードが構文エラーになるのでは
例えば制御文がビジネスロジックではないとは言いますまい

95 ：
C#は日本語問題ないでしょ

96 ：
日本語にすることで理解しやすくなるんならOK

97 ：
変数やデービーのカラムを日本語にすると、たしかにシステム的にわかりやすい気はするんだけど、コーディングの時に変換しなきゃいけないめんどうくささがあるのよ。コーディングするときって、せいぜいコメンティングぐらいしか変換しないので書きづらい

98 ：
ぴゅう太の日本語ベーシック思い出してしまった

99 ：
日本語使うと入力補完は効きにくくなるだろうな

100 ：
>>99
コード書く側として痛いですねそれ
でもドメインと共通の言葉を持つ方が要件洗い出しで有利ですからね
悩むなぁ

101 ：
要件洗い出しは関係ないですね
要件とコードの対応と言うべきですか

102 ：
ハンガリアン記法+日本語名というのを考えたことはある
これならVSの入力補完が多少は効くはず

実践したことはない

103 ：
class FileInfoファイル情報 {
public string FilePathファイルパス { get; }
}
こんなんでよくね（適当

104 ：
>>97
>>103 みたいに変換せずにそのまま書けばいいんじゃね？

105 ：
変換もあれだけど、そもそもガリガリコード書くときにime使わんめえ

106 ：
法律とか簿記の用語とかバンバン出てくるようなやつは全面漢字の方が仕様ととのチェックが楽だった
〜に係る〜、とかそんなの

107 ：
グローバリゼーションが絶対ありえないなら有効かもなー

今までコード補完使いまくるから強引に英語化していたけど、
法律関連とか無理に英語化しても結局コード補完で悩みそうだし、
日本語のままがいいなんてケースもあるんだな

適切な英語に訳すことができたとしても
大きいプロジェクトなら大量の用語の日本語と英語間の対応を全員が把握するなんて困難だもんな

108 ：
やはり日本語は有効ですね
クライアントが日本人なら属性とクラスとメソッドは日本語で書きます

109 ：
バリバリのjava使いはクラスに日本語使うなんてファックすんぞと怒りますがC#erは意外と受け入れてくれそうで良かったです
流石に先進的です

110 ：
買収劇を繰り返して競争相手をなくして言っているような企業には、
著作権法で守る必要はない。独占禁止法や不正競争防止法に条項を
追加して、著作憲法によう保護が適用されないようにし、
ライセンスを無視してコピーして使って良いことにしなければならない。
そういう法律を作ろう。MSのやり方は我慢の限度を超えている。

111 ：
買収劇を繰り返して競争相手をなくして行っているような企業には、
著作権法で守る必要はない。独占禁止法や不正競争防止法に条項を
追加して、著作憲法による不正コピーの禁止が適用されないようにし、
ライセンスを無視してコピーして使って良いことにしなければならない。
そういう法律を作ろう。MSのやり方は我慢の限度を超えている。

112 ：
ハナちゃんのパパ？

113 ：
FuncかActionで表現した方が定義やIntelliSenseを見たときに分かりやすいから
デリゲートを自分で定義して使うのではなくFunc、Actionを使え、という主張を以前見たことがあるのですが、どう思いますか？

114 ：
どう思いますかって言われても困ると思うよw

115 ：
インテリセンスのない環境でコードを見たときにって話なら分からんでもないけど
インテリセンス前提で自作クラスが分かりにくいとか、どういう主張なんだか理解できん

116 ：
インテリセス云々以前の問題でFunc Action の方が見易い

ってか、いい加減　return void を認めて、その二つを統一してくれ！

117 ：
Predicateみたいに可読性への寄与度から専用の方が好ましい場合もあるし、
EventHandlerみたいにジェネリックの型パラメータを制約したい場合もあるよ

何でも汎用のFuncやActionがあれば用が足りると思うのはあまりに単細胞

118 ：
>>108　ユーザから見えるのは英語だが、内部では一部日本語も使ってる。

英語だけで命名しようとすると「なんにしようか」と悩むんだよな。
悩んでつけたやつってパっと頭に出てこないから。。

119 ：
List<XXXX> abc;
このXXXXを変数で指定するのはどうしたらいいのでしょう？

class XXXX {}というクラス定義をSystem.Reflection.Emitをつかって動的に生成しているのですが、
List<>のような使い方はどうしたらいいのかで詰まっています

120 ：
>>119
型を変数に格納し動的にジェネリックの型指定をしたい https://social.msdn.microsoft.com/Forums/vstudio/ja-JP/cb8828d1-cd21-409c-bfb6-23db768e65aa/22411124342279325968123952668432013123752120530340123951247212?forum=csharpgeneralja

121 ：
なんとかなりそう。ありがとう

122 ：
>121
後学のために教えてほしい
なんでList<Object>ではだめなの？

123 ：
listは例で出しただけで実際は別の扱ってる
クラスの中でtypeに応じて処理してるから、objectだと処理をしてくれない

124 ：
それはインターフェース作るべきでは…？

125 ：
そういうクラス作っててインターフェース用意してないのはMSだから、こっちとしてはどうしようもない
オープンソースライブラリだから作り直すって手もあるにはあるけどｗ

126 ：
自分の設計力不足をMSのせいにするなよ

127 ：
>>125
答え出てるじゃん
自分で作りなよ

128 ：
typeに応じてやる処理を抽象化すればinterfaceのリストで事足りるってことじゃないんか

129 ：
>>10
結局これは
https://mevius.2ch.sc/test/read.cgi/tech/1563258983/31
こういうことだったんだな
ファイナライザは確認してないがDisposeした後に2回動かすと確かにちゃんと片づけられる
GC.Collect使わなくてもある程度まで積みあがったら片付けられたけど自分の環境で試したら１ＧＢまでそのままだったｗ

130 ：
ファイナライザが実装されているオブジェクトは
自分でDisposeを呼ばないまま参照されなくなった場合
GC二回後にメモリが回収される（ファイナライザ待ちは世代昇格されるのであくまでGC.Collectでフル実行した場合の回数）

という仕組みなのでそれで問題が解決するなら結局どっかでDispose忘れてるんじゃねという話に戻るだけだょ
まあそもそもDisposeでファイナライザ抑制してなかったり
フレームワーク側で無駄に参照掴んでたりってパターンもあるから誰が戦犯かはそれだけじゃわからんけど

131 ：
C#の国際規格についてちょっと聞きたい。そんな高級な質問じゃないんだけど……。

https://www.ecma-international.org/publications/standards/Ecma-334.htm
C# 5.0相当のISO/IEC 23270が2018年に公開されたけど、これに対応する日本産業規格って発行されるのだろうか？
そして発行されるとしていつごろになるんだろう。
この辺りの動向についてご存知のかたいます？

132 ：
知らんけど
ISOの2003版がJISの2005版、2006版が2008版になってるから
今回も2020版ぐらいになるんじゃね

133 ：
東京五輪の影響で規格化が遅れそう…

134 ：
スレッド数が64を超えるcpuアフィニティの設定てどうするの？

135 ：
VScodeで脳死プログラミングができると聞いたのですが本当ですか？

136 ：
昔のWin32アプリは、WinMain関数のnCmdShow引数で表示方法を得られましたが
int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow);

WinFormアプリはどうやって得ればよいのでしょうか？

137 ：
GetStartupInfoを使う
MINIMIZE/MAXIMIZEだけならFormのWndProcをオーバーライドしてbase.WndProc後のm_Msg==1の時のthis.WindowState見るというのも

138 ：
>136
ありがとうございます
諸事情によりEXEとフォーム持つDLLが分離しているため
APIで取得することにしました

139 ：
今までほぼformアプリの開発しかしてきてないんですが、ASP.NETの開発やらないといけなくなりました
習得は結構大変ですか？おすすめの書籍などあれば教えていただきたいです

140 ：
わいも知りたい

141 ：
FindIndex使えばループ書かなくても一行で済むじゃん綺麗じゃんと思ったんですけど、時間測ったらループ回すのより10倍くらい遅いんですよ
でも10倍って言っても0.00001と0.0001のオーダーでの差でぶっちゃけ体感時間には全く差が無し
そんな高速化が求められるようなプログラムでも無いんですが、こうなったら速度と可読性のうちこっちを優先させるみたいな基準って無いですかねぇ

142 ：
まず可読性を優先、体感でわかるレベルで問題になるところ「だけ」速度を考えろ

143 ：
https://kakaku.com/prdcompare/prdcompare.aspx?pd_cmpkey=K0001020506_K0001013459_K0001020508_K0001020509&pd_ctg=0150&spec=101_1-1-2-3-4,102_2-1-2-3-4-5-6,103_3-1-2-3,104_4-1-2-3-4-5-6-7-8-9-10-11-12-13-14-15,105_5-1-2

144 ：
・変数名は意味の読み取れない1文字2文字ばかり
・関数名は中身と一致してない上に連番
・意地でも動的配列を使わずに宣言の際に要素数100とか宣言する
・複数のオブジェクトを使いたいときはわざわざ
public class Persons
{
public n = 0;　// 要素数
person[] arr = null;
]
みたいなクラスを作る

そんなC#を書く隣の上司をなんとかする方法を相談したい……（スレ違い）

145 ：
サルでも解るシリーズの書籍を誕生日に贈る。

146 ：
プルリクで却下できないん？

147 ：
メソッドの戻り値がどのようなものなのか、コード上で分かりやすく修飾する方法ってないのでしょうか？
雰囲気としてはこんな感じに書きたいのですが、こういう需要ってないんでしょうか・・・・
(FirstName : string, FamilyName : string) Name(){return ("aiueo", "700");}

148 ：
>>147
そういうのはタプルよりもFirstNameとFamilyNameプロパティ持ったPersonクラス作るほうがわかりやすくない？

149 ：
ドキュメンテーションコメントでも書けばいいんじゃ

150 ：
tupleを返す
class/struct作ってその型で返す
out引数使う
お好きなのをどうぞ
個人的には場合によりけりでどのパターンも使う

151 ：
コード見て思ったけどもしかしてtupleに名前つけられるのを知らないだけだったりする？

152 ：
え、tupleに名前付けられるの?
Item1とか分かりにくすぎて嫌だからクラス作ってたけど名前つけられるならtupleでいいな

153 ：
(string FirstName, string FamilyName) Name(){return ("aiueo", "700");}
って書けるよってことでしょ
using Name = System.Tuple<string, string>;
usingでaliasは設定できるけどこっちは使いみち少ない

154 ：
tupleのitem1とかにはプログラマが自由に命名できるしVSの補完候補にもちゃんと出てきてくれるよ
その1箇所でしか使わないような内容ならtupleで十分

155 ：
まじか、全然知らなかったよ
ありがとう

156 ：
>>144
その上司も含めてコーディング規約を作ればええやん

157 ：
>>156
互換性を保つために、.NET2.0相当の記述方式とする
これマジでありました・・・

158 ：
>>157
それで皆が納得してるなら従うしかないな

159 ：
「互換性を保つため」とかならまだしも「今までこれでやって来たからこのままで問題ないだろ」って言ってそう

160 ：
LINQ分からん奴が言いそうね

161 ：
ワイの上司は使わなくてもいい新しい機能容赦なく使ってくるので困る…

162 ：
たしかにそれはそれでうざいかも…
でも今使わない機能でも知っておくのはいいことだよ

163 ：
えーそんな上司羨ましいけど
こんな書き方あるんですね！みたいに話せそうで楽しそうじゃん

164 ：
使わなくていい、のレベルによるかな
使うべきではないところで無理に新機能入れるのはやだな
慣れてないがために可読性が…くらいなら入れてほしい
var初期の頃とか後者な感じ

165 ：
>>164
> 慣れてないがために可読性が…くらいなら入れてほしい
> var初期の頃とか後者な感じ
そのレベルなら>>161も別に困らないだろ

166 ：
>>165
だから入れてほしいいうてるやん
前者だったらやだないうてるやん

167 ：
>>166
日本語不自由なの？
> var初期の頃とか後者な感じ
なら>>161もいちいちレスなんてしないだろうってこと

168 ：
>>167
今でもたまに居るのに初期の頃なんてvar反対派がどれだけいたと思ってんの？
日本語得意だと159のレスだけでそんな背景まで読み取れんの？

169 ：
>>168
昔の話をいつまでも引きずる爺乙
お前みたいな奴が拗らせると>>144の上司みたいになるんだろうなw

170 ：
>>169
？？？
日本語不自由はそちらじゃないのか？キャッチボールになってないぞ

171 ：
vs2019なんだけどvar書いたら明示的な書き方に変更しねぇ？ってメッセージ出してくるのではーんそういう方針になったんかと思ってたんだけどあれぇ？

172 ：
>>170
そりゃお前みたいな頭の硬い爺とキャッチボールなんて成り立たんしw

173 ：
>>171
デフォルトがそっちなだけで逆にも設定できるけどね

174 ：
大量にキューに入れておいた情報を順次取り出して
10程度の芸列でどんどん処理していくのは
どういう感じで書けばいいですか。
とりあえず直近では処理の結果は個別にファイルにサクセイ・書き込みです。

175 ：
>>174
>10程度の芸列でどんどん処理していくのは
芸列とはなんですか？

>とりあえず直近では処理の結果は個別にファイルにサクセイ・書き込みです。
「個別にファイル作成・書き込み」の意味をもっと詳しく。

176 ：
>>174
芸列クラスと芸行キューを使う感じで書けばいいと思います。
https://docs.microsoft.com/ja-jp/dotnet/api/system.threading.tasks.parallel
https://docs.microsoft.com/ja-jp/dotnet/api/system.collections.concurrent.concurrentqueue-1

177 ：
すみません。
芸列ではなくて並列でした。

>>175
ファイルをダウンロードして保存していく処理です。

>>176
ありがとうございます。
やってみます。

178 ：
FormのMainMenu内のMenuItemとしてPanelやUserControlを表示するにはどうすればよいでしょうか？

179 ：
すみません打開しました。

private UserControl1 UserControl1 = new UserControl1();

var menuItem = new ToolStripControlHost(UserControl1);

((ToolStripDropDownMenu)toolStripDropDownButton1.DropDown).ShowCheckMargin = false;
((ToolStripDropDownMenu)toolStripDropDownButton1.DropDown).ShowImageMargin = false;
toolStripDropDownButton1.DropDown.AutoSize = false;
toolStripDropDownButton1.DropDown.Size = new Size(UserControl1.Width, UserControl1.Height);
toolStripDropDownButton1.DropDown.Items.Add(menuItem);

180 ：
メニュー項目をグレイ表示にしたりチェック記号など付けたいような場合、
MFCではOnUpdateXxxx()ハンドラでCCmdUIを使ったり、メニュー項目に
IDM_XXXXの様なID番号を付けておいて、そのID番号で操作することが
出来たのですが、C#で同様の事をしようとすると項目の表示順がそのまま
反映された0から割り振られた番号を使う必要があるようです。でもそれだと、
新しい項目を途中に追加した場合に番号がずれてしまいます。MFCと同様に
IDM_XXXX のようなID番号を付けたり、Updateハンドラで処理するような
方法はないのでしょうか？

181 ：
MenuItemなりToolStripMenuItemなりのインスタンスを使えばいい
デザイナで配置してるならフィールドに置かれてる
変数名はデザイナでNameプロパティを変えれば追従する

182 ：
>>180
MenuItemなら分からんけどToolStripMenuItemならTagプロパティがある
ただその用途だと各Itemをフィールドの配列かListで別管理したほうが楽

183 ：
>>181
有難うございます。
メニュー項目に対応するインスタンス変数が存在していることすら知りませんでした。

184 ：
Formアプリケーションを作っているとき、
例えば、Form1.cs, Form1.Designer.cs
Form1.resx(Form1.ja.resxなどになる場合も有りますが)
が組みになって作成されます。
Form1.csは人間がコードを書くためのもの、
Form1.Designer.csはIDEのデザイナが作成するもの
のように役割が決まっているそうですが、これらを互いに
関連付けているのはファイル名や拡張子なのでしょうか。
それとも、どこかに関連付いていることが記述されている
ファイルがあるのでしょうか？？？

185 ：
csprojファイルに書いてある

186 ：
>>184
お聞きしたいのは、
xxx.cs と xxx.Designer.cs のようなファイル名の「パターン」によって関連付けられて
いるのか、それとも、どこかのファイルに、書き方はわかりませんが、例えば、
Relation{ "xxx.cs", "xxx.Designer.cs" };
や
Form "xxx.cs" {
Designer : "xxx.Designer.cs"
};
のような感じで関連付けを書いてあるファイルがあるのか、ということです。

187 ：
>>186
だからcsprojファイルに書いてある

188 ：
>>186
クラスがpartial。
VSから見たときの関連性と言う意味では多分ファイル名だけど、コンパイルする時としてはpartialで同じ名前のクラスは纏められる。

というか昔はファイルわかれてなくて、regionの中に居た気がする。
partialが使えるようになった時にファイル分かれた。

189 ：
csprojで、DependentUponになってるけど、ファイル名変えたら変な事になった気がする。
変えても良いんだっけ？

190 ：
>>184
はたぶん自動的にサブタイプになる設定がどこかに定義されてるかを聞きたいんだろうな…

191 ：
>>187
こんな風になっています。例えば、クラス名が Form1 で、ファイル名も Form1.cs
になっていますが、もしクラス名とファイル名を異なるようにしてしまったり、
Form1Designer.cs のファイル名を変えて、WindowsFormsApp1.csproj の中の、
Compile Include を変えたりしてしまった場合、果たしてどうなるのでしょう。

【Form1.cs】
namespace WindowsFormsApp1
{
　　public partial class Form1 : Form
　　{
　　　　・・・
　　}
}

【Form1Designer.cs】
namespace WindowsFormsApp1
{
　　partial class Form1
　　{
　　　　・・・
　　}
}

192 ：
>>191
【WindowsFormsApp1.csproj】
<ItemGroup>
　<Compile Include="Form1.cs">
　　<SubType>Form</SubType>
　</Compile>
　<Compile Include="Form1.Designer.cs">
　　<DependentUpon>Form1.cs</DependentUpon>
　</Compile>
　・・・
　<EmbeddedResource Include="Form1.en.resx">
　　<DependentUpon>Form1.cs</DependentUpon>
　</EmbeddedResource>
　<EmbeddedResource Include="Form1.ja-JP.resx">
　　<DependentUpon>Form1.cs</DependentUpon>
　</EmbeddedResource>
　<EmbeddedResource Include="Form1.ja.resx">
　　<DependentUpon>Form1.cs</DependentUpon>
　</EmbeddedResource>
　<EmbeddedResource Include="Form1.resx">
　　<DependentUpon>Form1.cs</DependentUpon>
　</EmbeddedResource>
　・・・
</ItemGroup>

193 ：
>>184
Visual Studioの設定や機能の話は該当するＶＳのバージョンのスレでやってくれ

194 ：
>>191
試してみれば？

195 ：
VSが入れ子表示してるファイル名と、コンパイラがコンパイルするクラス名は別の話だからな
VSが入れ子表示する話やデザイナファイル作る話ならVSスレ行ってやってくれ

196 ：
緊急で質問です。
Windowsフォームのコンボボックスにて、フォーカスされた時の背景色を青ではなく薄水色にしたいのですが、やり方がわかりません。
ネットで調べてもほとんど引っかかりません。簡単なソースコードサンプル付きで教えてくださる優しい方がいらっしゃいましたら、よろしくお願い申し上げます。

197 ：
>>196
それは緊急ですね。
ネットで調べるとたくさん引っかかりますよ。
https://stackoverflow.com/a/13212571/
https://stackoverflow.com/a/11650321/
https://stackoverflow.com/a/24476009/
https://docs.microsoft.com/en-us/dotnet/api/system.windows.forms.combobox.drawitem

198 ：
>>196
緊急とか書くと自分の都合しか考えない身勝手な奴だと思われるよw
いやマジで。
すでにからかわれてるけど。

やっつけならこれでいいのでは？
ちゃんとやるならCombobox継承してOnDrawItemをオーバーライドする
private void comboBox1_Enter(object sender, EventArgs e)
{
　　var bc = comboBox1.BackColor;
　　comboBox1.BackColor = Color.Azure;
　　EventHandler leave = null;
　　leave = (sencer, ev) =>
　　{
　　　　comboBox1.BackColor = bc;
　　　　comboBox1.Leave -= leave;
　　};
　　comboBox1.Leave += leave;
}

199 ：
>>191-192
プロジェクトファイルをバックアップしておいてから、
クラス名・ファイル名などを変えて、プロジェクトファイルがどう変わるか、

diff・VSCode などで、比べてみれば？

200 ：
>>199
ソリューションエクスプローラー上の、Form1.cs上で、右クリックして、
出てくるメニューから「名前を変更」を選んでファイル名を変更したところ、
Form1.Designer.csのファイル名も連動して変更される現象を発見しました。

201 ：
>>200
さらにこのとき、クラス名も Form1から新しいファイル名に対応したものへと
自動的に修正され、*.csproj 内の関連名も全て変更になります。

202 ：
これからGUIデスクトップアプリ作り始めるなら、.net framework 4.8と.net core 3.0 どっちがいいの？
.net core のほうはGUIデザイナがないのがなんか気になる。
今書いたGUIデザインソースが.net 5 でGUIデザイナが出てきた時にうまく認識されずに全部書き直しになるんじゃないか不安になる。

203 ：
Blazorがいいよ

204 ：
Client-side Blazorすら正式版が出てないのに。

205 ：
Unoがいいよ

206 ：
>>202
ソースは使い回せるから好きなほうでいいよ
デザイナほしいなら.Net Framework

207 ：
.NetCoreでMingw64のBashで表示できるプログラムって作れないのですか？

208 ：
>>207
そもそも、Windows上のbashはWinアプリなら全て実行できます。

209 ：
CefSharp使うと一瞬画面が消えるんですけどなんとかなりませんかね？

210 ：
C#で作ったコマンドラインアプリで例外が原因でアプリが終了した場合の
終了コード（バッチだとERRORLEVEL%で見れる値）が仕様でどうなってるか教えて。

単純にMainでSystem.Exception投げるだけのプログラム組んだら-532462766だったけど、
typeof(System.Exception).GetHashCode()あたりかなと思ったけど違ったし……

211 ：
returnで終了コード返すのはダメなの？

212 ：
実用上はtrycatchしてreturnすりゃ問題ないけど、これ何の値なのかなーと。

213 ：
16進数に変換してググると何か分かるかもね

214 ：
/h　-h 等でヘルプを出力がよくあるパターンだな

215 ：
>>210
16進数に直すと、 0xE0434352 で、16進数の最後の3つは、ASCII CODEの
"CCR"になっており、「時間の霧で意味が失われる」という意味の頭字語
になっていて、corexcep.h の中の EXCEPTION_COMPLUS で定義されている。

https://stackoverflow.com/questions/35294313/exit-code-when-unhandled-exception-terminates-execution
On Windows, a .NET process normally exits with the SEH exception code value,
the one that got the process to crash and terminate. Usually -532462766
(aka 0xE0434352) for a managed exception. Last 3 hex pairs spell "CCR",
an acronym whose meaning is lost in the fog of time, declared as
EXCEPTION_COMPLUS in corexcep.h. Sample question is here.

https://github.com/dotnet/coreclr/blob/master/src/inc/corexcep.h

#define EXCEPTION_MSVC 0xe06d7363 // 0xe0000000 | 'msc'
#define EXCEPTION_COMPLUS 0xe0434352 // 0xe0000000 | 'CCR'
#define EXCEPTION_HIJACK 0xe0434f4e // 0xe0000000 | 'COM'+1

216 ：
>>223
"CCR" は、「時間の霧で意味が失われる」という意味ではなく、
昔は何らかの英語の言葉の略語だったが、今となっては何の意味だったか
誰も思い出せなくなってしまったよく分からない略語、という意味らしい。

217 ：
>>215
おお、詳細な情報ありがとう。

こっちも仕様をあたってみたけどC#の言語仕様もCLIの方もそれらしい記述は見当たらなかった。
まぁ英語苦手だし見落としてる可能性もかなり高いけど。

218 ：
XML処理しなきゃいけなくなってコード組んだんだけどXDocument×LINQの組み合わせが楽すぎた
XML扱う上でC#は最強の言語なのではなかろうか。併用するライブラリの都合上C++/Pythonも考えたけど勝負にならんかったわ
他にXML使うのに便利な言語ってなんかある？

219 ：
powershell

220 ：
xslt

221 ：
以前に、const での定義名は、defineで定義したものに上書きされることがあるので
全部大文字で名前を付けないでPascal形式で付けるのが正しいらしいって質問をしたものだけど
そもそもC#ってdefineで定数作れないな
それでもPascal形式で名前つけたほうが良い？

222 ：
MS推奨はPascal

223 ：
>>221
Pascalにする慣習だしMSもそう推奨しているから従うだけ
命名規約はそれが存在し統一されていること自体に意味があるのであり、機能的な理由付けを求めることはナンセンス

224 ：
昔はXML最強だと思ってたけど
jsonやyamlの天才的な手抜きにに触れて考えが変わった

225 ：
>>221
constであることを意識させる必要がもしあるならFOO_BAR形式は決して悪くないと思う。
ただ、その必要性があるケースってよく考えるとあんまりないんだよね。

226 ：
ぶっちゃけMS自身もconstが全部大文字だったりPascalだったりしてる
細けェことは気にすんな
命名なんて気分だ気分

227 ：
C++→C#と来て久しぶりにC#に戻ったらC++の面倒くささに驚いた

228 ：
C++に戻ったらの間違い

229 ：
>>224
JSONはいいかげんコメント書けるようにしろよ

230 ：
>>229
コメントというデータを仕込めばいいんじゃね？

231 ：
ラベルダブルクリックでテキストがコピーされるのに初めて気づいた
何でこんな余計な機能つけるんだよ。せめてプロパティでオンオフできるようにしとけよ

232 ：
>>230
そういうバッドノウハウに頼りたくない

233 ：
JSONの"再発見"者ニキ「JSONにコメントを書けないようにしておいてよかった」

234 ：
>>232
じゃあ、RFC4627 に口出しできる立場になって、自分で提唱すれば？

235 ：
何がじゃあだよガキかw

236 ：
どこがガキなのかわからん

237 ：
えっ？
いきなりRfCとか言い出す>>234なんてガキの思考そのままだろw

238 ：
なるほどガキらしい考えだ
ママに聞かせて褒めてもらいな

239 ：
規格が気に入らないなら、それを変更するように影響を与えないといつまでも変わらない。
規格が気に入らない。可能な代替案も気に入らない。って喚いてるだけじゃん。
どっちがガキだよlol

240 ：
>>239
敵対する言語の信奉者や作者が批判してしている可能性もあるんだから、
委員会に提案しない事が後ろ向きとは限らない。

241 ：
>>239
そういうのを書生論って言うんじゃないかな？w
その実現可能性ってどの程度？
まあ、ガキだよねやっぱり。悪いけどさ。

そもそも>>229の人はそんな話（どうやったら変えられるか？）なんかしてないんじゃないのかな。
病気の人をからかう意図はないけど、アスペルガーとかじゃなかそんなの普通に分かるよね

242 ：
ふらっとだけじゃなくここでも人格批判かよ
板違いだから余所でやってくれ

243 ：
>>239
ほんそれ
叩いてる奴らはバカ類だからほっとけ

244 ：
>>241
> アスペルガーとかじゃなかそんなの普通に分かるよね
せめて日本語がまともに使えるようになってから出直してこいよ

245 ：
>>243
いや、C++を直して欲しくて書いているとは限らない。
良いアイデアを敵に与える必要はないので、提案などするひつ世はない。

246 ：
>>245
あれ、JSONの話だった。

247 ：
>>240
よくわからないんだけどC#と敵対してる言語ってなに？

248 ：
大多数のC#erが敵と感じることが多いのはVBじゃないかな
MS的には敵はGoやJavaと言いたいだろうけど、まだまだC#は(Unityを除けば)Windowsでしか使われておらず、プラットフォームの制約で仕方なく選ばれる言語の域を出ない
その上でVBを選ぶかC#を選ぶかは完全に好みの問題なわけで、
そこで好みを優先できる組織ならそもそもサーバーにWindowsなんか採用しないよね

249 ：
>>247
自分の好きな言語を広めたいと思っている人も居るわけですよ。

250 ：
>>249
答えになってないんだけど
君が「C#と敵対している」と考えてる言語って何？

251 ：
>>250
黙秘権を使います。

252 ：
>>248
もともとunsafeなんかはC#だけだったけど
最近のバージョンは他の部分でも差が付いてるので
好みの問題だけじゃなくなってきてる

253 ：
さすがに今どきVB.NETは有り得ないんじゃね？

254 ：
ここ数年VBなんて見てないわ
他の選択肢が多すぎて選ぶ人なんて居ないだろう

255 ：
1. 設定値を入力する画面がある
2. 設定値を入力して登録ボタンを押すと、設定値保管用クラスの変数に値を渡す
3. 他クラスは画面の値でなく、設定用保管クラスの変数の値を参照する

みたいなクソ仕様のアプリを書いてしまいました。
なんで直接、設定値入力画面の入力値を参照しないのか・・・。
仕様を直したいんだけど、もうクソ長いコード書いてしまっていまさら直すのも数日かかりになりそう。。。

256 ：
>>255
これやっぱり直すべきでしょうか・・・・。
工学系の院生の研究用アプリです。

257 ：
普通じゃね？シリアライズするなら当然そうしねーか？

258 ：
C#関係ないようなｗ
設定値の復帰させるとかでも一括で管理する部分あった方が取り回し楽になるし何がクソなのかもわからない
>>256
むしろ該当部分組みなおすのに数日かかってしまう形になっているのが問題では

259 ：
>>255
言ってること誤解してるかもしれないけど、
UIの入力をダイレクトに設定に反映しないのはMSのお作法的には
むしろ正しいんじゃないの？

適用かOKをクリックするまで入力が設定に反映されず、キャンセルボタンを
クリックすると何もなかったことになる仕様なんだよねたぶん？

まあ、仕様が適切かどうかは要件次第だと思うんで、あんまり教条主義的に考えない方が...
要は使いやすければそれでいいんで

260 ：
大まかな設計は悪くないと思うけど、
2. 設定値を入力して登録ボタンを押すと、設定値保管用クラスの 「変数に値を渡す」
3. 他クラスは画面の値でなく、設定用保管クラスの「変数の値を参照する」 (画面の値でも同様によくない)
って仕組みは直した方がいいんじゃないかな
一箇所仕様を変えたら全部が狂うとか、変なことが起きてくるんじゃないの

261 ：
>>260
まさにそこなんですよね。。。
他クラスで使用しているときに値を変更されないように2、3を実装したんですけど、単に画面を入力できないようにロックすればよかった。

2の変数の名前とか少し替えるとどこで参照先を全て直さなければいけない。
この仕様直したいんですけど、時間がかかるのと単純作業を繰り返すので、
考えただけで目眩がします。

262 ：
え？何が悪いのかさっぱりわからん
～すればってのも俺には的外れに見える

263 ：
>>261
変数の名前ならVisual Studioの機能で簡単に一括変更できるぞ
https://docs.microsoft.com/ja-jp/visualstudio/ide/reference/rename?view=vs-2019

264 ：
変数名の変更はVSの機能で一発で済む
vsじゃなくても最近のIDEなら標準的な機能じゃないかな？

書いてある設計自体は普通でクソだとは思わん
設定値が1万個くらいあってそれを1個のclassに全部ぶち込んでるとかだと整理したほうがいいんじゃね？って思うけどそういうわけでもないんでしょ？

画面ロックすればよかったって言ってるってことはあとから値変えられて困ってるってこと？
登録ボタンなんて作らずに画面上の設定値が変更されたら即座に設定値管理用classに反映させればいいのでは？

265 ：
>>264
それやると設定値にチェックが必要なとこで詰むぞ
やめるべき

266 ：
>262
同じく、何がくそ実装なの分からない
普通はGUIの変数を直参照しちゃってるから>>255の2,3みたいに直したいって悩みそうなもんだけど

267 ：
開始日、終了日の入力で
開始日から終了日の期間に制限がある場合とかバインドに弱い
開始値、終了値も同様

268 ：
>>265
いや、何も詰まないけど？
反映するときにチェックして異常値であることがわかればいいじゃん
登録ボタンで登録時にチェックしてエラーとするのと何らかわらん

設定値保持classは常に正常な値のみを保持する
って要件ならそら無理よ

269 ：
>>261
前の書き込みじゃわからなかったけど、主要な心配は、コードの保守性の問題じゃなくて処理中の入力に対する問題なの？
もし後者なら本当に作り直しレベルかも・・・・・

270 ：
WPFとかだとそういう風に組むのが推奨されてるし

271 ：
>って要件ならそら無理よ

このことを「詰む」って言ってたんではないかと

272 ：
DocumetViewとかMVVMパターンでは普通の実装だね。

273 ：
>>268
だからいつ？
ちゃんと考えて
開始と終了の期間に制限があるんだよ
組んだことないの？

274 ：
>>266
>>269
1　画面に数値を保持して、開始ボタンを押すと画面入力はロックする
3　クラスは1の画面上の値を直接読みに行く
とすると2はいらなかったのかなと。
2があると、設定を増やしたり変数名を変更するたびに1→2→3全部直さなければいけず、
保守が面倒くさいので、後でソースを見た人にブチ切れられないかと・・・。
あと、画面上なら間違って他クラスから値を書き換えることはしないと思うのですが、
変数だと他クラスから不用意に値を書き換えてしまわないか不安で。。。

275 ：
自分で途中からクソ仕様と思い始めてしまったんですが、これが標準なんですかね。
だとしたら安心して引き継げるのですが。
正直面倒くさくて直したくないorz

276 ：
>>274
画面に範囲guyのヤツブチ込んでも誰も死なんの？
コントロールだから絶対に想定guyのヤツは来ないはないよ

277 ：
>>274
>変数名を変更するたびに
vsなら参照してるところもすべて書き換える機能あるよ

278 ：
>>275
引き継ぐならそのままにしてあげたほうが良い
わざわざ手間をかけて設計を壊して後任の恨みを買う必要はない

279 ：
>>274
ちょっとした吐き捨ての設定ならそれで問題ないかもしれないけど、入力の項目が多くなってアプリを開いてあの設定を保存して呼び出したいってなった時とかどうすんの？とか結局仕様と設計の問題じゃないか？

280 ：
>>275
てか、WinFormなの？ それともWPF？
自分のこだわりがないならとりあえずフレームワークの流儀に倣ってりゃいいんじゃね

281 ：
画面遷移されたら消えるの？
たまたま今回画面遷移せんの？
問題が起こりまくるから止めろと言っておく
コントロールの不正な入力を完璧にガードするのはよく知ってる奴でも結構難しいときあるし

282 ：
>>273
ユーザーが設定値を変更したとき
そうやって突っ込むってことは
>設定値保持classは常に正常な値のみを保持する
って要件はないんだよね？
開始終了とか関係なくユーザーが設定した値保持するだけじゃん
mvvmとか見たこと無いの？

283 ：
>>282
開始に1980/01/01
終了に1980/02/01
が設定されてたとき
期間に3ヶ月って制限がかかってたときに
開始と終了に2019/09/01-2019/10/01を設定したいとするわな？

よし、じゃ、開始に2019の・・・エラー!（終了に1980/02/01が入ってるので）
じゃ、終了に2019の・・・エラー!（開始に1980/01/01が入ってるので）

詰んだじゃん

284 ：
>>277
それやったんですけど、なんか変更されないところも出てきて・・・。
ここ以外で変なことやってるのかもしれません。

285 ：
>>281
開始ボタンをおしても、設定入力画面は開いたままで画面遷移させてないんですよね。

286 ：
みなさんのお話を聞いていると、
登録ボタンを押して、変数記録クラスに画面の値を記録させるというのはクソ仕様ではなかったんですね。
ホッとしました。

287 ：
>>283
エラーになる設定に値を設定への操作を許可してりゃ詰んでないじゃんｗ
そもそもそういう操作を禁止するなんて話どこにあった？
ユーザーの操作は何も制限なんてする必要は無い
設定保持classが現在入力されている設定値が正常か否かだけを分かってればいい

288 ：
画面に入力された文字は変数記録クラスに記録させて、
変数記録クラスを参照していると、

「あれ、この変数って画面ではどこのことだっけ？」

とかなるのは自分の頭がクソ仕様ということか・・・。

289 ：
この理論、パスワードは8文字以上でって制限だと
1文字目を打ったタイミングでエラー出して入力ボックス消すってことか？
そんでコピペ以外で8文字以上打つことができずに詰んだってか？
そんなびっくり仕様どこにあるの？

290 ：
>>288
そこは間違いないな

291 ：
だからワンクッション置かないと駄目だよねって話

292 ：
>>288
変数記録クラスで変数を入れておくのをプロパティにしておけば、VSの機能で参照先をすぐに探せる

293 ：
>>289
開始終了は入力中だけじゃなく
killfocusやvalidatedでもだめでしょ？

294 ：
>>293
だからダメだったら何なの？
不正な値が入力されたらそうであることが参照するclassがわかればいいだけ
登録ボタン形式であっても登録時にチェックして正常異常を判定するのだから異常入力をユーザーに通知できるタイミングの違いでしか無い

何も詰まないのに詰むでしょ？考えて？組んだこと無いの？
って勝手に操作入力制限の要件足して突っかかってくるのやめてね

295 ：
>>294
元は
>>264
の
>登録ボタンなんて作らずに画面上の
>設定値が変更されたら即座に
>設定値管理用classに反映させればいいのでは？
って発言に対するレスな

296 ：
>>295
反映させ方にもいろいろあるから開始/終了の制限があっても別に詰まないよ
質問と関係ないからもうやめれ

297 ：
>>295
そんなん分かってるよ
設定値管理用classが異常値を保持するだけで何も詰んでない

298 ：
>設定値が変更されたら即座に
>設定値管理用classに反映させればいいのでは？

これ、バリデーションとか無い場合の方がやっかいだよね。
ユーザーは10を入力したかったのに1で処理されちゃうとか。

299 ：
個人的に割とよくある設計だと思ってる
入力したタイミングからエラーチェックして早めにユーザーに通知できるメリットがでかい
webなんかではよく見る形式
で、そんなよくある設計を詰むよ、なんて言って初学者（かどうかわからんが）に対して無意味に敬遠させるべきでは無いと思う

300 ：
>>296
え？コントロールの値を直接参照してるのにどうやるの？
無理ゲーじゃね？

301 ：
>>299
ガチでどうやるの？
範囲指定があった時点でOKボタン的もんが必要でしょ？

302 ：
MVVMを持ち出してる割にVMとMがごっちゃになってるように見える

303 ：
>>301
何を無理だと感じているのかさっぱりわからん
from/toが範囲外になったってユーザーがそう入力してるならその値を保持するだけ
で処理に進む段階で異常値があるなら進ませない
登録ボタン形式なら異常値があるなら受け付けない

処理に進むのを実行ボタンとすれば
前者なら異常値があれば実行ボタンを無効化しておき、設定値が全て正常になったタイミングで有効化する
みたいな要件が実現しやすい

304 ：
>>303
即時反映の話はどこいったん？

305 ：
さらに設定値を参照してる奴全員に異常値の対応をさせるってありえなくね？

306 ：
>>304
その値を保持する
ってのが反映だ
根本から話がずれてる

307 ：
>>305
そんな仕様どこに書いてあった？

308 ：
なんかすでに議論に勝つためだけに頑張っちゃってる感じ？

309 ：
登録ボタンと実行ボタンがある前提で登録ボタンの方は無くせる、と言っているのかな？

310 ：
>>301
入力中はアンダーラインを引いたりメッセージを出して通知はするが間違ってても即保存する
入力された不正な設定値を読み取る時に無視するあるいは警告を出して無視するはたまたエラーを出して失敗させる
後々設定をアプリ外から弄ることも視野に入れると読み取り時にデータの正確性を保証したほうがいい

311 ：
UI→登録ボタンによるチェック処理→設定値保持class
UI→チェック機能を有した設定値保持class
こんだけ
前者はチェック処理で弾けば設定値保持classには異常値が入っていないことが担保できる
後者は設定値保持class自身が正常と判断してるかどうかで異常値があるかどうかを判断する

別に前者の設計が一概にダメとは思わないしこういうこともよくするが後者が詰むという理論は理解できん

312 ：
>>274
一般的には読みやすくメンテしやすくするため
画面からの入力を処理する役割と設定値を管理する役割は別のクラスに持たせる
ただ簡単なプログラムなら画面クラスに設定値管理の役割を持たせるのでも別に構わない

他クラスから不用意に値を書き換えられないようにするのはそいうふうに設定管理クラスを作ればいいだけ

レス見る限り他のクラスの変数を
プロパティやメソッド経由せずに直接設定したり直接参照してる風に読めるんだが
もしそうなら役割ごとにクラスを分離したのに密結合してるのが一番の問題
でもブチ切れるレベルの人ならササッと書き換えるから心配する必要ないと思う

313 ：
>>274
いやいや、2みたいなものは要るし、3は一番ダメだよ
問題なのはフィールドを他クラスのオブジェクトから読み書きする点で、ここをプロパティーやフレームワークの内部コマンドに置き換えたりしないと徐々にコードが酷くなっていくよ

314 ：
この一連の流れは相談か？

315 ：
そうだんですよ川崎さん

316 ：
正直最初の質問が結局何を質問してるんだか俺にはいまいちよく分からないんだけど、
こんな雲をつかむような話でよくレスが50も進むよねw

まず質問者が何を聞きたいと思ってるのかを明確にするのが先だと思うんだけど

317 ：
>>255の質問内容はわかるだろ
既に>>270, >>272で答え出てるし本人ぽい人も>>286で一応納得してる
レスが伸びてるのは場外乱闘してる基地害が２匹いるっていういつのも流れだからスルーでいい

318 ：
>>317
漠然とは、ね。
逆にいうと漠然としか分からない

～だろ？w
頭悪そう

319 ：
いや、わからないならスルーしとけよ
別にお前がわかる必要はないんだしw

320 ：
また昨日の続きかよ

321 ：
自分がわからないのは質問者のせいだ
って思い込んでる人は一定数いるからw

322 ：
該当クラスがどこのネイムスペースから
なのかすぐわかる方法ってない？

323 ：
>>322
型名ならマウスオーバーでポップアップ表示されない？
変数ならF12で以下同文

324 ：
>>323
メモ帳しか使えない
すぐわからない？
ideが前提なの？
javaだと省略しないのに

325 ：
名前空間を省略せずに書けばいいだろ

326 ：
javaだってするだろ

327 ：
>>324
C#に限らず最近の言語はほぼIDEや高機能エディタ前提だと思うが

328 ：
>>324
ライブラリの型ならC#と一緒にググればすぐ出てくるでしょ

329 ：
vscodeすら入れられないの？
メモ帳縛りとかコンパイルもめんどいやん
てかコンパイラ単体で持ってきたの？

330 ：
昔はviとかで普通にコーディングしてたが
今更メモ帳でコーディングする気にはなれんな
今のIDEとかもう便利すぎる

331 ：
dotnet buildでいいからコンパイルは楽でしょ

332 ：
今時viだってコーディング支援あるしね

333 ：
インデントもわざわざ打たなきゃならんでしょメモ帳・・・

334 ：
>>329
WindowsならC#コンパイラcsc.exeが標準で入ってる。

>>324
でもなあ、IDE無しでは効率悪いでしょ。
規模にもよると思うけどVisualStudio入れられないならC#諦める選択肢もある。
といって代わりに何を使うかで良いのがあるとも思えないけど。

335 ：
クラウドIDE良いよ
インストール不自由でも使える

336 ：
vim
https://youtu.be/X0vVVHGFotc?t=306

makeファイルとかの下りは今は不要

337 ：
メモ帳しか使えない環境だからいくら紹介しても無駄だぞ

338 ：
最初にメモ帳でC#に特化したエディタ作る
以降はそれで開発

339 ：
C言語はC言語で書かれてると聞いたことがあるような…
最初にどう始めたかは知らない
アセンブラか他言語で始めてCに移行だとは思うが

340 ：
セルフホスティングやな

341 ：
そんなことも知らないのかよ

cの場合は最初にクロスコンパイラを作るから、新しいプラットフォームでもアセンブラは不要。
て、さっきwikiで読んだ

342 ：
原初の環境では機械語直入力だ

343 ：
>>341
そのクロスコンパイラとやらはなんの言語で書かれてるんだ？

344 ：
もちろんCだよ。

gccに関して言えば、まず、Cで書かれた自分自身のサブセットを別のCコンパイラでコンパイルしてから、自分自身のサブセットで自分自身をコンパイルする。

だから今後Cコンパイラがアセンブラで書かれる必要はまったくない。書きたければ書くのは自由だが。

なお、最初のCコンパイラはBで書かれたものとDECマシン向けのアセンブラで書かれたものがあり、Bコンパイラはすべてアセンブラで書かれていた。

僕くらい博識になるとこんなの常識だね。明日には忘れるけど

345 ：
まるでC博士だな
大したやつだ

346 ：
いきなりネイティブのコンパイラは無理っぽいわ。

347 ：
>>344
gcc は確か C++ で記述されていたはず、C++ のサブセットなんてどんなものなんですかね？

348 ：
元々はただのCだぞ

349 ：
>>348
ずいぶん昔に gcc は c++ になってしまいましたよ…

350 ：
元々はって日本語わからんのかな

351 ：
昔のc++はcのコードを一旦出力してcコンパイラでバイナリを作っていたな

352 ：
>>341
> アセンブラは不要。

と書きながら

>>344
> なお、最初のCコンパイラはBで書かれたものとDECマシン向けのアセンブラで書かれたものがあり、Bコンパイラはすべてアセンブラで書かれていた。

とか自称博識がアホすぎるw

353 ：
>>350
では質問を変えましょう

その昔の to C トランスレータの頃のC++は、控えめに言って C++98/03 の範囲の何パーセントくらいがカバーできていたのでしょうか？

354 ：
かわいそうに、馬鹿なのだな

355 ：
>>354
コテでググったら各所で問題児扱いされている奴だったわ

356 ：
>>352
よーく読んでみ

357 ：
>>352
バーンドブレードアタッチメントな僕の知識に反論しようとは笑止千万。

前者は今後出てくる新しいPFに関する記述で、後者は当初のコンパイラに関する記述なので、なんの矛盾もない。

358 ：
>>357
> 前者は今後出てくる新しいPFに関する記述で
誰もそんな話はしてない
Wikipediaレベルのチンケな知識自慢は要らんよw

359 ：
だめだこいつ…ｗ

360 ：
>>359
自己紹介乙ww

361 ：
XMLを知る前に、気づいたらJSONを使ってた。関数があるから便利だよな。
しかも今はJSON.NETがあるからデータ構造すら気にしなくていい。。

362 ：
>>141 扱うデータ量にもよりそう。

あんまりたいしたことがないデータ量なら for のほうがとても早いが、
あるオーダーから指数関数的に for のほうが遅いということもある。

for だって最適化されてるし、関数にはオーバヘッドがある。

363 ：
まあ一般的に業務ならデータ量は多いはずだから関数のほうが早いんだろうな。

趣味レベルだと扱う量がたいしたことないから、極端に言えばＳＱＬを使うよりも
テキストのデータベースのほうが遥かに早い。

データインサートのときは適当に自分なりの符号を作ってテキストを挿入し、
引くときは正規表現で引くみたいな。

364 ：
しかし言語系って同じ概念なのに用語がいっぱい作られていて一々用語の意味を
調べるたびに「一緒ジャン」ってなるな。

データ型名や関数名からそのまま新しい用語ができているって感じがする。。

365 ：
今日もつまらないことで2chは盛り上がっております

366 ：
using/disposeについて確認したいんだが、
あれって厳密には「リークする」ではなくて、
「解放のタイミングが不明で、場合によっては問題が発生することもあり得る」なだけだよな？
https://docs.microsoft.com/ja-jp/dotnet/standard/garbage-collection/using-objects

具体的にはGDI+オブジェクトのGraphicsやBrush等について、
MSDNのドキュメントもほぼusingなしで記述されているので気になっている。
https://docs.microsoft.com/ja-jp/dotnet/framework/winforms/advanced/how-to-draw-a-line-filled-with-a-texture
一応、using使えということになっていたはずだが？

そこで色々ググって見ると、どうやら以下のようだが、あってるか？
・try-catch で finally にdisposeが入ってなかったとき、（≒つまりusing使わなかったとき)にも、
　例外が発生したその時のリソースも、参照が切れ次第、いつかはGCによって回収される。
・GDI+リソースはシステムリソースで、場合によっては枯渇するから、作法としては不要になり次第解放すべき。
・とはいえ32bit化でこの辺の問題は大幅に緩和され、GDI+はプロセス毎の上限は10,000になってる。
　だから余程酷いことをしない限りこれに引っかかることはない。

結果、作法としては正しいがほぼ命中しない問題に関して一々using使うのもウザイ、
ということでMSDNのドキュメントがusing無しになってる、ということで合ってるかな？
(なお関係ないとは思うが俺が使っているのはVC++/CLIとForms)

367 ：
サンプルプログラムに厳密性を求めるな　ってだけ

368 ：
サンプルだから本質には関係ないところをバッサリ省略してるだけでしょ
ガチな例外処理とか入れられても見辛いだけだし
それと同じ話

369 ：
まあサンプルをコピペしちゃうレベルなら他にもっとまずいところはいくらでもあるだろうから、
少々Disposeが先延ばしになるくらいは無視しても問題ないかと

370 ：
>>255
周回遅れだが一応参戦。当該院生が冬休みでもう一度読んでいることを期待する。
他の人も言っているとおり、設計としては253で正しい。直す必要はない。
なおその点はForms->WPFで思想が修正された点であり、（つまりFormsが駄目だった点）
これも他の人が既に言っているとおり、「最新のフレームワークの流儀」で設計するのが妥当。
判断する能力がないなら、とにかく「最新の流儀」に乗っかるのが
無駄に嵌るのを未然に防ぐ適切な方策となるのでそうすべき。

構成としては、おそらく、
「設定値変更画面(V)」「設定値保管用クラス(M)」「他クラス（多分演算ルーチン）(EXE)」で、
これはMVCの通りであり、V-M, M-EXE 間は結合しているがV-EXEは結合していない。
これに対して、誰か（≒老害）に指摘されたのだと思うが、君が253の時点でいいと思っている構成は、
「設定値変更画面(V+M)」「他クラス（多分演算ルーチン）(EXE)」となっており、Mが分離していない。
（=EXE側がVを知っている必要がある）
この構成の利点は、
・コードが多少少なく済む
点であるが、結局使い勝手が悪いので、ずっと改善していくと最終的に253みたくMVCに分離することになる。

371 ：
>>261
といっても分かりにくいだろうから具体的に指摘すると、
君の問題は、間違った方策で解決しようとして、余計におかしくなっていることだ。
> 他クラスで使用しているときに値を変更されないように2、3を実装したんですけど、単に画面を入力できないようにロックすればよかった。
これは「画面をロック」ではなく、演算開始時に「設定値保管クラスのコピーを演算ルーチンに渡す」とすべき。
これにより、一つの実行画面から多数の演算ルーチンを並列に起動したり、
或いはGUI無しでコマンドラインから起動することも普通に可能となる。
（つまりプログラムとしての汎用性/柔軟性が上がっている）

「クラスのコピー」ってのはディープコピーだが、単純に値が入っているクラスなら、
Cなら構造体の代入、つまり
SomeClass myCopy = reference;
の1行で事足りる。或いは通常、関数呼び出しには構造体への「ポインタ」を用いているはずだが、そこを構造体の「値」に変えればいいだけ。
C#だとstructは値型だったと思うので、設定値保管用『struct』なら自動的に上記が常に行われる構造になるが、
余程小さくない限りそれでは使いにくい筈なので、設定値保管用『クラス』で正しく、何らかの方策でディープコピーをした方がいい。
インミュータブルに組んでいればシャローコピーでも行けるようには出来るはずだが。

372 ：
>>367-369
つかこれ、どれくらいgraphicsヘビーにすればヒットするんだ？
以下はヒットしているようだが、俺はヒットしない。
https://sorayukinoyume.hatenadiary.org/entry/20121029/1351525436

俺のは40k個Brushを作ってそのまま放置、それを1秒ごとに再描画、
みたいな感じだが、OutOfMemoryなんて起きない。
（ただし、カクつく事があったから今はDisposeを入れてしまったが)
プログラムは演算結果をGUIで表示するもので、演算ヘビーだが、
演算自体はC++ネイティブなのでGCは行われない。
（演算ルーチンではマネージドメモリを消費しない）

なお以下とかは正しいように思う。
https://uchukamen.com/Programming/GC/
https://ladybug.hatenadiary.org/entries/2004/01/10
https://ufcpp.net/study/csharp/rm_gc.html
https://divakk.co.jp/aoyagi/csharp_tips_using.html
https://www.codeproject.com/Articles/48701/Using-GDI-Objects-the-Right-Way
（なお最後はシステムで10,000が上限だと言っているが、これはプロセスの間違いだと思う。《他でそう書いてあったところもあった》
また、タスクマネージャーで見る限り、俺のPCでは全体で10,000は越えているし。
なお一番使っているのはJane2chの8,653だった。Jane糞だなオイ。
chromeは各プロセス毎に600-800位、俺のプログラムはどうやっても50-70を推移してる）

MSも馬鹿じゃないからサンプルコードはそれなりに正しいはず。
絶対にこう書け、なら必ずそう書く。そうでないのはその必要が「普通は」ないからだ。
逆に、普通にサンプルコードで問題が発生するようなら、クレーム来まくりで大変だから、当然のように修正される。
それが為されてないのは、それなりに使用に耐えるコードだからだ。

という感じなのだが、お前らこれヒットするのか？
VC++/CLIとC#だとGC周りがだいぶ違うって事か？

373 ：
>>372
DC(Graphics)は不要になった時点でDisposeした方がいいと思うけど、
PebとかBrushとかFontとか、このあたりがIDisposable実装してるのは
たぶんWin9xを想定してるんだろうねw

.NET 1.1とかの時代に、Win2kやXPではそこまで神経質にならなくていいよ、
って記事を結構読んだ記憶がある

374 ：
多いから糞って単純な話でもないだろ。表示しているオブジェクトが多いなら仕方がない。
explorerもウィンドウを大量に開くとモリモリ消費する。

375 ：
>>374
いやJaneはガチでリークしてると思うぜ。

俺のPC内での今の順位
1. Jane2ch 8,677 ←増えてやがるし
2. explorer 1,340
3. chrome 826
以下chromeが20個ほど続く。

字しか表示しねえJaneでどうやって8,677個になるんだよ？
フォントや色でも精々100だろ。
そもそも複数ページ表示してるchrome越えてる時点でだいぶおかしい。

376 ：
>>373
そのわりにusingガーというのが多いのはなんでだ？
若干Java的オブジェクト指向（オブジェクト指向が唯一絶対神であり、それ以外は認めない）に近い偏見を感じる。
GCなんて手抜きの為の機構であり、逆に言えば、GC使っている以上、書かなくて済む事は書かない、というのが正しいだろ。
全部書け、ならC++を使って全部書き、GCなんて使っている軟派野郎はR、とあるべき。

C#でusingって、なんか違うくね？
まあ現実的にヒットするなら致し方ないとして、俺が試した限りでは、どうにもヒットしないように見える。

それとも
> DC(Graphics)は
これはdevice context だけは即時解放した方がいい、ということか？
具体的にはGetHdcメソッドを有する連中だが、見た目Graphicsだけかな。
だとすると俺がやってるBrushでは再現しないのも納得だが、
かといってGraphicsを10,000取得とかいう使い方もないとも思うが。

377 ：
何をグダグタと気にしてるのかよーわからんな
どうせそのうち回収されるんだから無駄に残ってるのが気にならねえならどうでもいいだろ
精々Janeみたいに過剰に確保されてるのを観測されてクソクソ言われるのが自分のアプリになるだけだ

378 ：
つか本来は実際に画面に表示されてる間だけアンマネージリソースを確保すればいいわけで、設計が手抜きなんだよ
まあ、そういう思想でスマートなリソース管理をしてるWPFはゴミのように遅いわけだがw

379 ：
>>376
なんかちょっと被害妄想激しいよw

IDisposableを実装してたら絶対Disposeすべき、という教条主義を展開してる記事って
あんまり読んだ記憶ないけど、まあusingブロックは十分コンパクトに書けてかつ便利なので、
Disposeしなくてもいい、という確信が持てないなら素直にDisposeするのが普通に安全牌だよね。

※ 個別にDisposeを呼ぶんじゃなくてusingを使え、という趣旨の記事ならいくつか読んだことある

380 ：
>>377
俺自身は「usingを使うべき」とされる解説ページでお約束的に出される
・そこで例外が発生してdisposeされずに抜けてしまった場合、リークする
が間違い（というか誇大)だと見ているのだが、これが間違ってるかどうかをここで尋ねている。


俺の認識に間違いがないとすると、
俺が試した限りではヒットすることが難しいのに、何故ここまでusingにこだわるのか？というのが疑問になる。
勿論こだわるのもありだが、C#ってそういう言語でもないし。

なお俺のはdisposeしてなくて50-70だぞ。
そこで上記の通り、Brushを40k個作ってもだ。
(もっとも、多すぎてGCが常に速攻行われているだけかもしれないが)

JaneStyleは調べたところOpenJaneからの派生で、OpenJaneはDelphiで、これはGC無しらしい。
つまりモロにリークしてるだけだよ。

381 ：
尋ねてるって言うけど、君の求めてる通りの回答以外は認めないんでしょ
聞くだけ無駄じゃん

382 ：
>>379
> Disposeしなくてもいい、という確信が持てないなら素直にDisposeするのが普通に安全牌だよね。
つまりこれ。
実はDisposeしなくていいんじゃねえの？というのが俺の疑問。

ヒットしている人がいるから何か要件はあるのだろうけど、俺が試してる限りではヒットさせようがないように見える。
とはいえ、ヒットする可能性がある限り、解説ページ等では「Disposeしなくていい」とは書けない。
だけどほぼ必要がないことはMSも認めてるからサンプルページではusingなんて使っておらず、
usingについてのリンクすらない、というように見える。
(つまりサンプルページを確認しているレベルの奴がヒットさせようがなく、
余計な混乱を防ぐ為にも書かない方がいい、とMSが判断してる。
まあ>>367-369はモロにそう言ってるわけだが)

ただこの状況でも、自分だけが使うならともかく、他人も使うとなると、
using使わないわけには行かない、というのは認める。
だからなんだかなあ、みたいな感じになってる。

結局のところ、これは俺の環境のみならず、
.NETが動くありとあらゆる環境に於いて問題なく動くプログラムを作る為の作法であって、
MSがusing使えと言う以上、書くしかない、ということか。
それが俺のPCでは再現不能だとしても、それはたまたまでしかない、ということであって。

383 ：
c#のListをイテレーションするサンプルをウェブで探していたんだけど、インデックスでアクセスして回しているコードがよく見つかるんだけど、
Listのデータ構造はリストではないの？

384 ：
>>382
上に書いたWin9x環境を特に想定した実装、というようなケースを除けば
そのクラスを作ったプログラマは「不要になったらDisposeを呼んで欲しい」と思っているから
IDisposableを実装している。

だからDisposeしなくてもいい、という確信が持てないなら（以下略

385 ：
>>383
「リスト」だとデータ構造が説明できてないと思うのだが
List<T>は配列で実装してるよ

386 ：
GC任せではなく明示的にメモリを開放していかきゃ動作に支障をきたすような少メモリな環境だって世の中にはある

387 ：
>>383
.NETではIListは順序が定義され効率的なランダムアクセスの可能なデータ構造
従って、リンクリストはIListを実装しない

388 ：
>>384
なるほど確かにその通りだ。

設計者が想定したとおりに使うのが安牌であり、
書いておけば済む物を、特段メリットもないのに書かずに済ませて後で嵌るのは生産性が悪い、というのはC#的には当たりだ。
呼ぶか呼ばないかは使用者が判断するものではなく、設計者がIDisposableを実装するかどうかで示し、それに従え、ということか。

まあ長期的に見てその思想が正しいんだろう。
なるほど納得した。

389 ：
>>383
つhttps://docs.microsoft.com/ja-jp/dotnet/api/system.collections.generic.linkedlist-1?view=netframework-4.8

390 ：
disposeされなくてもデストラクタで解放されるが、
かなり高コストな処理が発生するそうな

https://ufcpp.net/study/csharp/rm_disposable.html#idisposable

391 ：
>>390
それは嘘。というか誇大広告。

オブジェクトの寿命が1GC分伸びるだけ。それが深刻になる状況なら、
ファイナライザリストをそもそも作らず、必ずusing/disposeしろ、という設計思想が妥当。…(A)
或いは、ファイナライザリスト内だけ2GC世代分GCするとか、そういうフレームワーク設計も可能。…(B)
いずれにしても、.NETはそうしてない＝それは大した問題ではない、とMSが判断している証拠。

といってもGCも進化しつつあるし、この辺もじきに整理されるのかもしれん。
C#8.0のusingはソースコードとしてはほぼ完成型だし、
> using var font1 = new Font("Arial", 10.0f);
> https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/keywords/using-statement
型によっては using var でしか宣言出来ない（＝静的に確保出来ない＝ローカルでしか持てない）ようにすれば、
上記(A)の思想を体現出来る。それが本筋かもね。
形式的にはVC++/CLIのpin_ptrと同じだから、実装する気になればMS的にはすぐだ。
https://docs.microsoft.com/ja-jp/cpp/extensions/pin-ptr-cpp-cli?view=vs-2019
制限はそこに書いてあるが、以下。
> 固定ポインターは、スタックの非静的ローカル変数としてのみ宣言できます。
> 固定ポインターは、以下として使用することはできません。
> 関数パラメーター
> 関数の戻り値の型
> クラスのメンバー
> キャストのターゲット型
「関数パラメータ」に使えない、と書いてあるが、これは言い方が悪くて、
「関数の仮引数の型には使えない」が正しく、実引数として渡す場合はキャストされるので普通に使える。
言葉だと分かりにくいが、
pin_ptr<double> ptr_d;
を void somefunc(double*) に渡すとdouble*に自動的にキャストされるので普通に使える。
これと同様の制限だと、「その関数を抜けた後も保持していて欲しい」オブジェクトには使えないが、
GDI+オブジェクトに関してはこの方向でもコーディングは可能のように思える。

392 ：
>>391
> オブジェクトの寿命が1GC分伸びるだけ。それが深刻になる状況

じゅうぶん現実的な状況でなり得るよ。Gen1以上のGCを舐めてる
それが許容できるかは要件次第
ゲームプログラミングでなくとも極力排除すべき要素

そういえば「ガクガクするから結局Dispose呼び出した」とか自分で言ってたね
なんでガクガクしたの？

> 型によっては using var でしか宣言出来ない（＝静的に確保出来ない＝ローカルでしか持てない）ようにすれば、

論外。ネイティブリソースを持った時点でスタックにしか確保できない型しか作れない言語の出来上がり
ファイナライザを作らずDisposeを強制するというのはそういこと

大した問題じゃないから、ではなく潜在的に負荷を抱える可能性の排除とリソースリークへのセイフティを天秤にかけた結果だよ

> VC++/CLIのpin_ptr

それC#で言うunsafeなfixed相当。関係無い

393 ：
Disposeしないで挙動を調べた結果、問題ないんだったらそのリソースに関してはDisposeしなくていいってことがわかるだけじゃない？
それを一般化してusingなんか使う必要がないのだ/Disposeはファイナライズのときにされるので十分なのだってのはおかしいような。

一々いろんなIDisposableのオブジェクトの挙動を調べてたら検証時間がかかってしょうがないし、
今調べた挙動が将来的にずっと同じである保証もないから、Disposeしてね、と言われているものに関しては、
Disposeされるものだと思って設計変更される可能性がある、と考えて、
問題のないタイミングで行儀よくDisposeしてトラブルの種を潰すってだけの話だと思うんだけど

逆に、使い尽くしてDisposeしなくていいってわかってるんだったら
（例えば自作クラスで、なんかのハンドルを握ったままになったりしないという保証があるなら）
どうぞご自由に、って思うけどね

「自転車ってうちの近くの舗装の綺麗で平坦な道路では手放し運転できるのに、なんでハンドルなんかついてるんだ？いらなくね？」って言ってるようなものだと思うけどね。

394 ：
なるほど！と読んでたら最後の例えでよくわからんようになった…

395 ：
>>392
いや多分、みんな求め過ぎなんだよ。
C++erが特にそうだが、C++を何でも出来る言語にしようとしてる。
それと同じく、君もまた、C#を万能言語にしようとしてないか？
つまり、簡単に書け、かつ、最速な言語に、ということだ。

> それが許容できるかは要件次第
俺に言わせれば、ゲームプログラミング等のパフォーマンスクリティカルな状況でC#を使う選択自体が間違ってる。
実際、ゲームは今でもC++が主流で、それはパフォーマンスの問題からだろ。
そういえばUnityはC#だが、（俺はゲーマーでないから詳しくないが)
あれは紙芝居ゲーとかそういう全くパフォーマンスとかどうでもいい系向けではないのか？
グラゴリゴリのゲームをC#で書いて、C++に勝てるとでも思っているのか？

> なんでガクガクしたの？
知らん。ただ、Disposeしてなかったから試しにしてみたらとりあえず直った。
だからGCなのだろうとは思うが、それ以上は確認してない。
ただ、2-3画面毎だったから、Brushで言うと100k毎くらいだ。

396 ：
> 論外
いやお前の不勉強具合が論外だよ。少なくともRustはそっちを目指している。
もうちょっと単純簡潔な表現のページもあったはずだが見つからないので、グダグダしているが以下。
> 意味論への影響
> スタックアロケーションはRustの言語自体へ影響を与えており、したがって開発者のメンタルモデルにも影響しています。
> Rust言語がどのように自動メモリ管理を取り扱うかは、LIFOセマンティクスに従っています。
> ヒープアロケートされユニークに所有されたボックスのデアロケーションさえも、
> スタックベースのLIFOセマンティクスに従っていることは、この章を通して論じてきたとおりです。
> 非LIFOセマンティクスの柔軟性（すなわち表現能力）は一般的に、
> いつメモリが解放されるべきなのかをコンパイラがコンパイル時に自動的に推論できなくなることを意味するので、
> デアロケーションを制御するために、ときに言語自体の外部に由来するかもしれない、動的なプロトコルに頼らなければなりません。
> （Rc<T> や Arc<T> が使っている参照カウントはその一例です。）
>
> 突き詰めれば、ヒープアロケーションによって増大した表現能力は（例えばガベージコレクタという形の）著しい実行時サポートか、
> （Rustコンパイラが提供していないような検証を必要とする明示的なメモリ管理呼び出しという形の）
> 著しいプログラマの努力のいずれかのコストを引き起こすのです。
> https://doc.rust-jp.rs/the-rust-programming-language-ja/1.6/book/the-stack-and-the-heap.html
と公式は言ってはいるが、Rustの取っつきにくさはここにあって、
要するに既存言語のノリでやったら全然コンパイルが通らないらしい。（俺はやってなから知らんが）
ただし、スタックアロケーションの方が効率も管理も楽なので、スタックアロケーション出来るものはスタックに、という理屈は合ってる。
問題はそれだと柔軟性、つまりデタラメなコーディングが出来なくなる点で、

397 ：
> 天秤にかけた結果だよ
というのはその通りで、C#は色々なことを天秤にかけて「丁度いい言語」を目指している。
だから、「最速の言語」では今現在ないし、今後ともあり得ないことも自覚してないといけない。
繰り返すが、パフォーマンスクリティカルな状況でC#を使うこと自体が間違いだ。これは今後共だ。


> それC#で言うunsafeなfixed相当。関係無い
確認したが、fixed相当なのはその通り。それで、何故関係ないと言えるのか？
usingで書けるということは、同じ構文のfixedでも書けるということ。
pin_ptrは型なのでグダグダ制限が付いているが、usingやfixedは構文なのでそもそも制限する必要がないだけ。

まあここら辺の理屈はさておき、実際、GDI+リソースをクラスメンバとして持つ必要がどこにある？
例えばGraphicsをControl.CreateGraphicsから生成するのなら、Controlを持っておき、その都度生成することは出来る。
これにより、永続コンテンツ（クラスのメンバ）として持つのは回避出来る。
この制限を付ければ、Graphics自体が「生成されたスコープを抜ければ常に破棄される物」となり、
言い換えれば君の言っているとおり「スタックにしか確保出来ない型」になるが、
usingなんて付けなくてもリソースリークが発生することは原理的になくなるし、
ファイナライザという機構も不要になるので、GC自体も単純化し、高速化する。
とは言ってもここら辺はフレームワーク根幹の設計思想であって、今更グダグダ言っても始まらないが、
Rustで.NETをサポートしたらusingみたいな糞は入らないだろうよ。（原理的に不要）

どの言語スレもそうだが、若干みんな信者になってしまっていて、公平に見れてない。
C#8.0のusingは「書く」前提なら完成型だと思うが、「書かない」方向を目指すことも出来、実際、Rustはそっちを目指してる。
それを糞だと判断するのも自由だが、理解出来ない/知らないのは君の問題だよ。
俺に言わせりゃ、コールグラフなんて抜けるんだから、
usingなんて書かなくとも「このリソースが永続化することはない」というのはコンパイラ側が判断出来ることで、
なら自動的にusing扱いにして、そうじゃないところだけwarning出してくる、というのが理想だと思うが。

398 ：
unityでも3Dゴリゴリのゲームは作るよ
というかスマホで3Dゲームの高クオリティ開発ならunity
1択なくらい。unrealはまだスマホ市場少ない
unityはスマホが多いがコンシューマもPCもそれなりにある
ゲーム以外のARVR分野もかなりunityは多い

言語パフォーマンスより開発パフォーマンスが優先された結果だと思う
だからといって処理速度をないがしろにできるわけじゃない

399 ：
>>393
いや長期的に見た生産性の為にusingを書いてトラブルの種を潰しておく、というのは納得した。
俺がいくら試しても、俺環境で俺の使い方での結果でしかないから、公式に従った方が得策だ。


ただし言語としてそれが最高か、と言われれば、俺はusingなんて書かなくてもなんとかしとけ、という思想。
つまり、

C#： using書け、ただし、書き忘れても大体何とかなるようには作ってある
Rust： そもそも変数はスタック上にしかアロケートしないので、usingとか原理的に不要
俺： 勝手にコンパイラが色々チェックして、可能なところは自動的にやって、駄目なところだけwarning出してこい

ということ。ただしこれは理想論であって、現実はそうではないのはもう認めてる。
ただそれにしても、「GDI+オブジェクトがスタック上にしか確保出来ない」がそんなに糞だとは思わない。
実際、俺はこれでほぼ組んでいるはずだし。

400 ：
Rustは普通にヒープ使うぞ？
なんか勘違いしてるようだが、そもそもスタックだけで用が足りるんなら所有権だの何だのとRustの高度なリソース管理は要らん
C++のRAIIや、それこそC#で変数をデフォルトでusingにした程度で十分だ

401 ：
>>398
> 言語パフォーマンスより開発パフォーマンスが優先された結果だと思う
> だからといって処理速度をないがしろにできるわけじゃない
C#の開発パフォーマンスがいいのは認める。
とはいえ、原理的な速度というのはあって、
正直、C++erの「GC使わないけどスマポ使え」ってのはロジック的に間抜け（矛盾してる）と思うが、
Rustの「全部スタック動作と連動」というのは原理的に正しく、逆に言えば、この方法でないとCを越えられない。
だから、根幹の思想は何だかんだで重要で、GDI+に関してはusngではなく「スタック縛り」の方が妥当だったように思う。
ファイルリソースは永続化出来ないとイテレータが使えないのでusingじゃないと無理っぽいが、
GDI+リソースは特に永続化する必然性が無く、大量に生成し、破棄するものだからだ。
パフォーマンス上は断然「スタック縛り」が有利で、
それでコードが書けなくなる/書きづらくなる、ってこともないと思うのだが。

と言ってもMSも気づいているだろうし、当然考えてもいるだろうし、
Rustにも手を出してはいるから必要なら出してくるんだろうけど。

402 ：
>>400
他言語の「ヒープ」と同等の動作では全くない、ということ。

403 ：
>>402
具体的にどう違うのか説明してね
Rustのメモリ管理は、端的に言えばスマポしか使えない縛りを入れたC++に過ぎないよ

404 ：
>>399
呼び出しの静的解析だけで、コンパイラ側が自動でusing付けるとか、現状の言語仕様でいけるもんなのかなあ。
行けそうなケースがあるのはわかるけど、すべてのケースで問題なく動作するというエビデンスはなんかある？
あと、俺に言わせりゃ静的解析で出来るだろとのことだけど、設計実装難易度も十分に低いと見積もってて、なんでやらないんだ、と言いたい、ってことなの？個人的には難易度は未知数だと思うんだけどなあ。

405 ：
>>404
参照がスコープ外に持ち出されていないかどうかを判断する必要があるだろうけど、それには
rustのように関数呼び出しに情報を受け渡す拡張が必要になるだろうね。
どうせ文法を拡張するなら、C++/CLIのようにusingより簡単な記述でDispose()の必要性を
判断できるようにする方が現実的かも。

406 ：
>>404
> 設計実装難易度も十分に低いと見積もってて、なんでやらないんだ、と言いたい、ってことなの？
いや違う。ぶっちゃけ、信者的態度で言われたから言い返してるだけだな。

現実問題として、Rust公式でも述べているとおり、ヒープ+GCの使い勝手は素晴らしく良く、
「コードの書きやすさ」という意味においては現状最高だろう。
だからC#がこれを採用しているのも理に適ってる。

ただし問題は、それを信者的に素晴らしいと君らが捕らえている点で、
これはC#が魔法を使ったわけでもなんでもなく、
単純に、速度を捨てて書きやすさを取っているだけだと正しく認識しろと言っている。
だからパフォーマンスクリティカルだと分かっている状況でC#を使うのが間違いだし、
それはファイナライザが実装されているからGCが1世代分伸びるのも問題だ、というときも該当する。
そこまでのパフォーマンスを求めるときに使う言語ではないし、出来る言語でもない。これは今後共だ。

解決策は既に述べたとおりだが、ここに関してはMSが「間違えた」というのは厳しいが、でも、間違いだとは思う。
usingは「書く」前提ではC#8.0で完成しているが、
問題は、「それが書かなければならない型だ」とユーザーが認識しなければならない点で、
そもそも知らなければ抜けるし、そのためのファイナライザでシステム的に遅いGCになる事を許容しなければならない。
（というほど俺は遅くはならないと思うが、お前らはファイナライザが問題だと言うので）
なら、最初から「スタック縛り」にしてしまえば、SyntaxErrorで落とせるし、GC機構そのものが不要になる。
このときの問題点は多少コーディングの自由が奪われることだが、現実として、
PenやBrushをクラスメンバとして永続させる必要なんて無いし、
GraphicsやFontも生成元『マネージド』情報(既に述べたがControl等）を代わりに持つことによって回避出来る。
結果、馬鹿みたいに「GDI+オブジェクトはその都度生成して、その都度廃棄」なコードになってしまうが、
SyntaxErrorにならなければリソースリークは原理的になくなり、
GCも簡素化/高速化し、using周りの仕様も覚える必要がない、ということになる。

407 ：
俺が思うC#の利点は、「無駄に覚えなければならない仕様」がほぼ無いことであり、
これは、C++が何でも出来る言語にしようとしている反面、
ほぼ使いもしない仕様を覚える必要がありすぎる状況になっているのと対極的ではある。
ただ、俺に言わせれば、usingも覚えるべき仕様ではない。
「GDI+リソースを持つクラスはスタック上にしか置けません」の仕様だと、何も覚えなくて済み、リーク周りの問題もない。

ただこれは完全に後出しで、MSが間違いを犯したわけではない。
彼等は単純に現状の仕様に乗るようにしてきただけであり、
未来の改訂で「スタック縛り&using廃止」になるのも十分ありうるし、俺はそれを望む。
ただMSはおそらくパフォーマンスよりも書きやすさに振ると思うので、微妙だとは思うが。

> 呼び出しの静的解析だけで、コンパイラ側が自動でusing付けるとか、現状の言語仕様でいけるもんなのかなあ。
要は
Brush xxxxx;
{
// ここで永続化されなければよい
}
なので、中身を辿りきれるかどうかに尽きる。
具体的には、ヒープ上のオブジェクトに保持されているとかが無ければいい。（といってもC#は全部ヒープだが）
解析に問題になるのは関数ポインタを動的に使われるケース（テーブルジャンプ等）だが、
そういうのはほぼやらないから現実的には大半の場合は解析可能だと思う。

> 行けそうなケースがあるのはわかるけど、すべてのケースで問題なく動作するというエビデンスはなんかある？
こんな物はそもそも必要ない。
解析可能なら自動でusing付けろ、解析無理(かつユーザーがusing付けてない)ならwarning出せ、のベストエフォートでいい。
現実的にこれで問題ない。

というかJavaScriptのJITが既にこれに近いことをやっていたはずで、
要は「この関数を抜けたら破棄されると静的に解析済みの変数は最初からスタックに配置する」で、
解析無理なら従来通りヒープに置いてＧＣ、可能な物は纏めてスタックに置いてGC回避で高速化、みたいなことになってたはず。
だから.NETもそれをやればいいだけ。

408 ：
君が冒している最大の勘違いは、「C#開発者の皆が自分と同じくusingの不便を感じている」という前提を置いていることだ。
実際にはもうFormsの開発なんてC#ではマイナーな部類になりつつあり、
現在の主流であるWeb開発ではDisposeなんか滅多に使わない。
Webのパフォーマンス改善の観点で言えば、(君の愛する)スタックにしか置けない特殊な構造体の導入等により、
C#のGCに極力頼らない高度なメモリ管理は実は一部では既に実現されている。
usingはもはや滅多に使わない機能であり、それほど力を入れて改善されるべき対象ではないんだよ。

409 ：
信者的信者的ってなんのこと言ってんだコイツ？
ファイナライザ持ちがDispose呼ばないと昇格オブジェクトが増えてやばいって警告に
誇大広告だのほざいてるのは自分じゃねえか
自分のコードでDispose呼ばずにフルコレクトかましてガクガクさせながら「自分はそれほどでもないと思う」とかなんのギャグだよ

410 ：
>>407
JITだからできることでコンパイラじゃできなくない？
何が気になるかって言うと、コールスタックの解析とかをコンパイル時点でやり始めるってのは停止性問題を取り扱うみたいなむりがあるんじゃないのかってこと。
ごく簡単な例だったら問題ないだろうけど、そのごく簡単な例ってわずかじゃないのかな。

411 ：
それをコンパイラ(というか型システム)でやろうとした結果がRustだね。
ちなみに彼は知らないようだが、Rustのメモリ管理がスマートであると言われる所以は、
エスケープしていないオブジェクトの生存管理などではなく(そんなものはC++でとっくの昔に実現されている)、
エスケープした「ヒープ上の」オブジェクトも正しく追跡して破棄できること。
それがプログラマにどれだけの負担を強いているかは>>396の通り。

412 ：
>>408
Formsが過去の遺産で糞で既にVSからデフォで除外済みなのは知ってる。
ただし俺は移行するよりはそのままメンテする方を選んでいるだけ。

usingについては、C#8.0(2019/09リリース）で改訂されているのだからobsoleteとは言わんだろ。


まあそれはさておき、Web開発ってのは以下で、現状のC#の主力はWPFではなくこれだって事か？
https://docs.microsoft.com/ja-jp/visualstudio/ide/quickstart-aspnet-core?view=vs-2019
見た目サーバーアプリで、つまりPHPの代替のように見える。
なら実際の描画はやる必要がないから、そりゃGDI+オブジェクトを掴むことはあり得ないわな。

> Webのパフォーマンス改善の観点で言えば、(君の愛する)スタックにしか置けない特殊な構造体の導入等により、
> C#のGCに極力頼らない高度なメモリ管理は実は一部では既に実現されている。
調べてみたが、Span<T>, stackalloc, ref struct 等か。確かにこれらは悪くない。
こういう小回りも利くところがMS主導言語のいいところではある。
実際にコードを書く奴らが主導している匂いがする。
ただな、こういうマニュアル調整は本来C#が目指しているものではないだろ。

GCを使う＝変数等の寿命について一々考えたくない、であって、
実際、C++だと考えることが多すぎて、開発に手間がかかる＝開発効率が悪くなる。
だからそこをランタイムに丸投げして、ユーザーは本来書くべきコードだけに集中出来るのがよいのであって、
あれこれ弄れば速くなります、なら、最初からC++等使え、でしかない。
とはいえ、折衷策として出してきたのは悪くないが。

JavsScriptの良い点は、「何も考えなくてもJITが勝手に速くしてくれる」事であって、
俺はこの点が最高に気に入ってる。
ちゃんと弄れば速くなります、なんてのは、面倒＝開発効率が下がる。
ただしC#はスクリプト言語レベルの手抜きを目指しているわけでもないから、割と妥当なラインなのかもしれんが。

413 ：
えらい散らかった論調だな。もう少し端的に話せんか？

414 ：
>>410
JITで出来ることとコンパイラで出来ることは違うが、今回に関しては同じだよ。
（関数単位でJITしてる限り同じ）

普通に考えれば分かると思うが、関数内の変数なんてその関数出たら破棄される物が大半で、
仮に内部でさらなる関数呼び出しに関連している物が全部追跡不可能だったとしても、十分効くんだよ。

完全にやり切ろうとするのはそりゃかなり無理だよ。でもそれは必要ないんだ。

415 ：
極論 vs. 極論でなんともw

416 ：
>>411
> ちなみに彼は知らないようだが
実際知らんからRustの話は君に任せる。

俺はRustはどういうコンセプトでどういう状況かを遠くから眺めているだけで、
「このコードが動かないんです！」みたいな悲鳴をチラ見してるだけだからな。
ただ、その中に「ヒープ上のオブジェクトすらも勝手に解放されるのかー！！！」みたいな話もあった気がするが。
スマポ限定なだけだというのなら、あれは関数呼び出しによる所有権移転で解放されただけの話か。
まあそうかもしれん。
いずれにしても俺はRustのコードは書いてないし、直近で書く予定もないので、Rustについては君に任せる。

417 ：
どうせ過疎スレだし、BGMこれでガンガンやって欲しいw
https://youtu.be/BvmqYM1xpZA?t=28

418 ：
トヨタの車をブレーキを踏まずに運転できる人なら、usingはいらないよ

419 ：
うぜーから個人ブログでやれよ

420 ：
正直半分ぐらいしかわからないけど、たまには盛り上がるのもいいよ

421 ：
2週間に1度ぐらいのペースで、わけのわからん話題で盛り上がってる気はする

422 ：
ふらっとじゃなくこっちで暴れる分には好きにしたらいい
こっちでNGしとけばふらっとで見なくて済むし

423 ：
>>420
半分しか分からないのは、オブジェクトの寿命を考えずにコーディングしているからだ。
ただしこれがGC言語の魅力でもあり、一々グダグダ考えていると魅力半減ではあるが、
そうは言っても、上達したいのなら、考える癖は付けた方がいい。

これについては、禿(ストロウストラップ＝C++創始者）の
「ドキュメントを作成すべきコードのサイズには下限があるが、
コーディングする前に考えるべきコードのサイズには下限がない」
が当たってる。なまじ出来るようになるとどうとでも組めるようになるが、それがいけない。
本来このコードはここにあるべきか？というのを考えながらコーディングした方がいい。

usingに関しては、そもそもGDI+オブジェクトが永続化されるのが間違いで、
それはVに状態を持つということだから、MVCから見てもアウトだとすぐ分かるだろ。
本来は、GDI+オブジェクトに関しては、
・usingの中でしか使えない
・スタック上にしか置けない
（まあこの2つは等価だが)みたいな制限を課されたとしても、まともな設計なら制限にすらならないんだよ。

で、戻るが、これが分からないのなら、それはオブジェクトの寿命を考えてないからだ、となる。

といっても分からないだろうから、具体的に説明すると、
例えばドベタな将棋ソフトを作るとしよう。
CPUと対戦するだけの将棋ソフトで、ドベタに、
ユーザーが入力（指す）→画面の更新→CPUは考える→指す(画面の更新)→アイドル（ユーザー入力待ち）、の無限ループだとしよう。
これでMVCなら、
M： 盤面と持ち駒情報
V： 画面表示
C： それらのグルー
であって、画面はその都度最新状態に更新されているのだから、
アイドル状態で残っているオブジェクトはどう考えてもMの「盤面と持ち駒情報」だけでいいだろ。
だからアイドル状態にてV用のGDI+オブジェクトが捕まれたままになっている時点で設計がおかしいんだよ。
この点、Janeは再起動してみたが相変わらずGDI+は8,657なので、明らかに糞設計だと断言出来る。

424 ：
画面の更新は、当然関数であり、
画面の更新はこの中でしか行われないのだから、当然、この関数を出ればGDI+オブジェクトは破棄していい。
だから、全てのGDI+オブジェクトは、どこかで
void some_funciton_0(){
using (var someGDIobject = ... ){
some_function_1();
}
}
みたいにusingで囲めるポイントが必ず存在する。例えば、ど頭でCreateGraphicsするなら以下となる。
void redraw_board(){
using (var gr = someControl.CreateGraphics()) {
some_function();
}
}
これは寿命という意味では、関数の一番頭でCreateGraphics＝この関数と変数grの寿命を同期させているわけだが、
この関数以外に画面更新関数がなく、常に全面更新完了して抜けるのだから、
grはどう考えてもこの関数の外で使われることが無く、これで問題になりようがないだろ。
だから変数を寿命順に入れ子にし、結果的に関数コールも同様に並び、変数の寿命とスタックの動作が完全に一致する、というのがC流で、
動作としてはこれが一番無駄がないから、この設計で組まれた場合に速度ではどうやっても勝てない、ということになる。
別にこれが難しいとか制限が厳しいとかいうわけでもなく、要するに無駄なく普通に組めばこうなる。
だからまともな設計に於いて、GDI+オブジェクトに
・usingの中でしか使えない(＝スタック上にしか置けない)
という制限を課すのは、制限にすらならない。
これが問題になるようならそもそも設計がおかしい。

ただ、現実論として、度重なる仕様変更によりプログラムの設計というのはおかしくなって行くもので、
多少設計がおかしくてもなんとでもなる言語じゃないと困るのだが、
それにしてもGDI+オブジェクトは上記制限を課されても全く問題ないと思う。回避手段もあるし。
というかマジな話、MVCにしてればV用オブジェクト掴みっぱなしなんてあり得ないし。

425 ：
GDI+だけがアンマネージドリソースではないんだが
そんな狭い前提で話されてもなぁ

426 ：
ちょっと言い方が本質的でなかったから言い直すと、

ある関数内で必要とされるリソースに対して、
・その関数突入時には掴んでおらず、
・その関数脱出時にはリリースしててよい（＝その関数の中でしか使わない）
場合は、必ずブロックスコープの入れ子で対応出来る。(A)

となる。Cはある意味これしか無く、これを「不自由だ」とする人達はGCに向かったが、
結局C的上記手法に回帰してる。これはC++もそうだし、C#もそうだ。
C#8.0のusing、何度も言っているが書く場合は完成型だが、意味的にはC++のデストラクタと同じでしかない。
なら36年前に開発済みの手法であり、C#1.0からこれでよかった。
それを19年かけて再開発して、何も知らない若者がありがたがるという、間抜けなことをやっている。

ここら辺がLinusがC++を嫌う理由で、C++も同様に仕様を引っかき回した挙げ句、C的手法に回帰してる。
なら最初からCで書け、Cで出来る範囲しかC++は認めない、というのも、酷い言い方だが確かにそうでもある。
同様に、C#も、usingの間抜けさに気づくのに8.0までかかったんだから、
C#12.0位で上記縛りを付けて廃止する方向になるのではないかな。
MとVを分離するのは現在既に常識だし、Vを分離している場合にはGDI+リソースについては上記(A)は必ず成立する。
ファイル等のその他アンマネージドリソースについては後回しになるだろう。
言語/プラットフォームとしての整合性/統一性が取れないが、C#は整合性より実質的利益を選択するはず。

427 ：
お前らは多分気づいていないんだろうけど、C系言語は「関数を抜けたらローカル変数は全て破棄される」為、
動作効率はいいが、関数を頻繁に抜ける＝GUIとは絶望的に相性が悪い。
GUIの場合は各イベント関数がトップレベル関数(C#コンソールアプリでいうmain)になるから、
上記「入れ子」での変数処理にかなり無理が発生してしまう。（アーキテクチャ的に無理）
ここら辺は最初からGUI用に設計されているJavaScript等をやってみれば分かる。
JavsScriptの場合は全部の関数がクロージャ付きだから、クラスと関数の区別もなく、関数に変数が紐ついてる。
だから、C系言語だとグダグダになるGUIも、JavaScriptなら比較的綺麗に書ける。
C#はいい言語だし、1つ学ぶならC#という選択も悪くはないが、他言語をやりさえすればあっさり見えることはある。

JavaScriptは糞だ糞だと言われて久しく、AltJSもやたら作られたが、いまだに殺しきれないのは、
結局のところ根幹のアーキテクチャ「全関数がレキシカルスコープのクロージャ付き」がGUI向けに圧倒的にフィットするからだ。
同様に、C#含めてC系言語がやたらあるのに、Cを殺しきれないのは、結局のところ、Cの根幹のアーキテクチャ
「変数の寿命とスタックの動作を一致させ、最速を得る」が圧倒的に素晴らしいからだ。
「変数の寿命を考えて設計しろ」なんてのは今も昔もそう言われてないが、（ただCにはそれしかないから言わずもがなだったが）
C#もC系ではあるのでC的手法で設計した方がフィットするのは事実。
寿命なんて考えたこと無かった奴は考える癖を付けた方がいい。
そして可能であればJavaScript等の「コンセプトがそもそも違う」言語を触ってみた方がいい。
そうすれば、C系言語が何を捨てて何を取ったかも分かるようになる。
具体的には（歴史的にはおかしい言い方だが）、GUI対応を捨てて速度を取っている。

428 ：
なお余談だが、そのGUIをグダグダにならないように設計として対処しよう、というのがMVCであり、
これはやった方がいいのは事実だが、酷い話、
JavaScriptほどGUIと相性がいいとMとVが混ざっていようがなんとでもなってしまうのも事実で、
これの最たる物がjQueryであり、jQuery自体ではなく使う奴の使い方の問題なのだが、レッテル貼られて丸ごと廃棄されようとしている。
ただここら辺も、やれば、C#なんてGUIにはまるで向いて無く、
だからMVCだバインディングだと手の込んだ仕掛けを作って誤魔化さないと駄目なのだ、というのが分かるようになる。
だからまあ、設計の善し悪しが分かるようになってきたら、他言語を触ってみればいい。
（分からないうちに触っても文法コレクターにしかなれず、意味無いから止めとけ）

429 ：
FormがBackgroundプロパティを持たないでどうやって背景色を指定するのかな？
再描画の際にしかBrushのGDI+オブジェクトは使用されないのだから常にBrushがGDI+リソースを持ち続ける必要がないという主張であるなら、パフォーマンスを度外視すればその通りかもしれん。
しかしBrushがGDI+リソースと一対一対応するのではなく必要なときにだけ内部的にGDI+リソースを作るような設計思想なら、
そもそもBrushのusingが一切必要ないようなアーキテクチャが十分に実現可能なんだよ。
言語をいじるまでもない簡単な話。

430 ：
今日も知ったか君が暴れてるw

431 ：
予防線張ることに必死過ぎて何言ってんのかわからなくなってる典型だなこりゃ
自分の発言を自分で否定しながらお花畑垂れ流してる底抜けのアホ

432 ：
オブジェクト指向ではリソースは依存性として分離して注入するのが良い習慣とされる
なのでローカルスコープでいきなりリソース確保みたいなコードを書くことは稀だ
C#やJavaの世界ではリソースのライフタイムはDIコンテナが管理するものであってスタックに同期させるものではない

433 ：
>>432
彼の主張は置いといて、生成タイミングの制御のためにDIでファクトリーオブジェクトを注入するのはよくあるパターンだぞ

434 ：
cでもmallocしてりゃどこかで開放は要るだろ。
理屈すり替えて楽しいか？

435 ：
>>429
> パフォーマンスを度外視すれば
GDI+オブジェクトの生成ってそんなに重いのか？

> そもそもBrushのusingが一切必要ないようなアーキテクチャが十分に実現可能なんだよ。
その通りだ。だから.NET自体がボロいんだよ。

元々はGDI+オブジェクトのリソースが限られていたから、win98までは文句を言わず俺が言っている
「使うときだけ生成、使い終わったらすぐ解放」
しかなかった。これを「面倒」と思ったのか単にボケているだけなのか、
リソースが大幅に増えたこともあって問題にもならなくなった為、掴みっぱなしも出来るようになった。

.NET自体はWin32APIを隠蔽する為の物で、これ自体は良く出来ている。
ただ、俺は、君の言うとおり、もう一枚多く隠蔽して、usingが一切不要のフレームワークにした方がいいと思うけど。
もしGDI+オブジェクト生成が問題になるほど重く、キャッシュしたいというのなら、直接自前でGDI+オブジェクトを掴む必要がある。
だから.NETは今のアーキテクチャなのだ、と捕らえることも出来るが、
実際はそうではなく、単に皮を被せただけで、その皮の厚さが不適当だっただけだと思うよ。
まあこれはすぐに修正出来る話でもあるけど。

436 ：
>>432
> オブジェクト指向ではリソースは依存性として分離して注入するのが良い習慣とされる
そうだ。ただ、これがGUIとは絶望的に相性が悪いんだよ。
実際、Formsはこれで、各コントロールが値を保持してそれを参照する、というアーキテクチャだが、
事実としてこれは使いにくくて、WPFでばっさり修正されてるだろ。
(例としてはまんま>>255で、彼が253の時点でいいと思っているアーキテクチャがFormsのものだ。
だから俺は253はFormsしか知らない老害に文句を言われたのだと思っている）

一応Webは当初は（というか一応今も）Javaでもクライアントコードを書けることになっている。
ただ、JavaとJavaScriptだと書きやすさのイージーさの次元が違っていて、喧嘩にならないんだよ。
一応アプレットが遅いだの色々理由が付けられてるけど、
俺はJavaScriptの方が圧倒的に楽に書ける、というのが本質だと思うよ。
(仮に速くてもJavaは駆逐されてたと思う）

不幸なのはGUIが出てきた時の覇権言語がCであった為、
有無をいわさずGUIもCでやり、そしてそれを今でも引きずっている点だ。
そしてその後はOOPが覇権を取ったから、GUIもOOPだという事になるのだが、これがまた間違いで、
これを盛大にやらかしたのがFormsだ。
MVCのMなんて、OOP（特にJava)で禁忌とされるグローバルそのものだろ。
C系言語の変数管理そのものがGUI向きではないんだよ。
そしてOOPの変数局在化思想もOOP向きではない。結果、Formsは二重に間違いを犯してる。

437 ：
>>436
最後訂正
x そしてOOPの変数局在化思想もOOP向きではない。
o そしてOOPの変数局在化思想もGUI向きではない。

まあ分かると思うけど紛らわしいので一応。

438 ：
うーん、なんかさすがに「アインシュタインは間違っている！」と主張するトンデモ本作者的な主張は草不可避w

439 ：
>>438
それが信者的態度だよ。
お前はC#以外の言語をいくつも知っていて、C#/.NETの良さ/悪さをちゃんと識別出来るのか？

ただしこれはC#だけではなく、どの言語スレも割とこの傾向の奴が多いのも事実だが。
ただその態度は目を曇らせるから止めた方がいい。

C#が覇権を取れておらず、今後とも取れそうにもないのにも理由があるし、
JavaScriptが糞糞言われてもやたら蔓延っているのにも理由がある。
お前が何を好きかはお前の自由だが、何故そうなっているのかが分からないようなら単なる馬鹿でしかない。
勿論馬鹿であり続けるのも君の自由だが。
> https://www.youtube.com/watch?v=Og847HVwRSI
> https://mevius.2ch.sc/test/read.cgi/tech/1571315884/69

440 ：
そんなに良いものなら実装してC#チームにマージリクエスト出したら？
ここで演説しても全く時間の無駄だよ？
実装するのにスキル不足なら機能リクエストでもいい
C#はオープンソースなんだからさ

441 ：
今でもJavaでもクライアントコードを書けることになっている、とか、どの世界の話だろう？
あと、自分は432じゃないけど、
> それが信者的態度だよ。
> お前はC#以外の言語をいくつも知っていて、C#/.NETの良さ/悪さをちゃんと識別出来るのか？
というぐらいなら、C#以外の言語使えばいいんじゃない？って思ってしまう。
実際自分はプラットフォームに合わせて、アプリケーションの使いかたに合わせて8言語ぐらいから選んで使ってるけど。

あと、C#が覇権を取れていないとは全く思わないけどな。Windowsで適当なアプリ作るなら普通みんなC#で書くんじゃないの？
UnityだってC#だし。

442 ：
>>440
俺は.NETを使っているのであって、C#は使ってない。

ただ、usingをどうするかは思想の問題であって、技術的に不足しているわけではないので、提案しても通らないとは思う。
（作ってる側も知っててそうしているはず）


>>441
そう思うならそれでよし。
C#は良い言語だし健闘している方だが、Javaと食い合うなら死ぬのはC#だ。(俺はJavaが死んで欲しいのだが)
OracleはJavaを技術的に成長させることは出来なかったが、ある意味余計なこともしなかった為、
プラットフォームとしては既に膨れあがってしまった。
後はC#で成果が出た仕様を順に取り入れていけば、「C#には負けない」言語にはなる。（勝てもしないが）
同じような仕様で並立すると、死ぬのは小さい側のC#なので、当然C#は新規機能を追加して逃げ続けるしかない。
これはこれで恩恵はあり、そうこうしているうちに勢力逆転出来ればいいが、今のところその芽もないだろ。
(Unityがそうだというのならそれでいいが）

> Windowsで適当なアプリ作るなら普通みんなC#で書くんじゃないの？
俺は知らんが多分Python。大体ネット上ではブッ叩かれているが。
その動画見ても一応トップだし。

443 ：
ずーっと勝ちだの負けだのふわっふわなことこだわってるのなこのド近眼馬鹿
手前で他の言語持ち出してきて突っ込まれたら知らんから解説譲るとか逃げてるし
まさに無意味な頭でっかち文法コレクター（笑）を自ら体現してる
クスリでもキめてんのか？

444 ：
>>442
> 俺は知らんが多分Python。大体ネット上ではブッ叩かれているが。
いやいや…
実情を知らなすぎだろう？C#なら実行ファイルの入ったフォルダごと渡したら実行できるようになるけど、
Pythonだと環境を作ったりとか結構めんどくさいぞ。大体GUIを考えたらPythonとか最悪でしょ。
「お前はC#以外の言語をいくつも知っていて、C#/.NETの良さ/悪さをちゃんと識別出来るのか？ 」とか言ってる割にはトンチンカンすぎる。

一応言っとくと、C#しか書けないからこう言ってるわけじゃなくて、Pythonもガンガン使って仕事してるからね。

あと、JavaはもうほとんどSIer専用言語みたいになってるから、C#と直接比較するのもナンセンスでしょ。
スーパーコンピュータで科学技術計算する分野では今でもFORTRANが主役だけど、そこ以外で使わないだろ。それと一緒。
最強言語なんてのはない。色々なニーズに合わせて言語（プラットフォーム）を選んで何でも書けばいいんだよ。
手続き型言語だったら考え方は大して変わらないからね。

445 ：
>>444
そりゃお前の現状認識がおかしいと思うぞ。

インストールすら大変なら、Pythonがここまで蔓延ることはない。
何故かよく出てくるFORTRANガーってのも、FORTRANなんて実際もう誰も使ってない（と聞いている）し、
今のFORTRANは昔のFORTRANとは別物（と聞いている）ので、FORTRANを持ち出すのもおかしい。
それはVBを持ち出してBASICがまだ使われている、と言っているに近い。（はず）
多分お前もFORTRAN信者に嘘を吹き込まれているだけだと思うが、
冷静に考えれば見抜けるはずだが、FOTRAN全盛時代の連中はもうリタイヤかその辺であって、コードなんて書いてない。
あれはスパコンのCOBOL扱いになってるはずだが。
（もしかしてベクトルはFORTRANしか受け付けないのかな？これはあり得るが）

まあいいが。
いずれにしてもお前らが何故そんなに信者化するのかはいつも疑問だ。

446 ：
自分が作ったものだけ動かすなら楽だもの。Python。
envで環境作らないといかんくなったらめんどくさい。

お前あんまり知らねえだろ。

447 ：
>>445
開発用PCでプログラミングするだけで十分な場合と、デプロイが必要なアプリケーションを作るのは違うんだよ。
Pythonが流行ってるのはデプロイが必要なアプリケーションでなければ、かなり楽できるから。
デプロイするのは結構大変だよ。インターネット接続不可の環境でpipを使うのはめちゃくちゃ難しいし。

仕事でプログラム作ってアプリ納品したことないでしょ。その経験がなければプログラミングを語るなとは思わないけど、
納品という観点でみたらナンセンスすぎるんだよ。よくも上から目線で「お前の現状認識がおかしい」と言えるね。

あと、PythonでGUIアプリケーションを書くことに関してはスルーかな？

FORTRANの下りも、聞きかじった知識だけじゃん。
科学技術計算でよく使われるBLASっていう線形代数のライブラリがあるんだけど、githubで見る限り半分はFORTRANで書かれてるよ。
https://github.com/xianyi/OpenBLAS/
4,033 commitsとか書かれてるところの下の棒押してみ。

Fortran 49.3% Assembly 26.7% C 21.2% C++ 1.4% Makefile 0.8% CMake 0.4% Other 0.2%
って出てくるから。

あと、書かれてるコードも昔のFORTRANそのものでしかないコードだよ。
https://github.com/xianyi/OpenBLAS/blob/ce3651516f12079f3ca2418aa85b9ad571c3a391/lapack-netlib/SRC/dgebd2.f

これを今でも皆コンパイルして使ってるわけ。スパコンだけじゃなくて、PCでもね。

んで、プログラマーじゃなくて、研究者はいちいち他の言語とか覚えたくないから、今でもこういう乗りのFORTRANを使ってるわけ。
http://www.chem.konan-u.ac.jp/PCSI/DL_POLY/still_FORTRAN.pdf

どうしてろくに自分で調べもせずに聞きかじったそれっぽい言葉を信じちゃうのか。
「いずれにしてもお前が何故そんなに知ったかするのかはいつも疑問だ。」

448 ：
自分とは違う意見=信者、と言うレッテル張り

449 ：
>>447
もう意味がないから終わりでいいが。

> インターネット接続不可の環境
今更ねえし。それがC#なら楽チン！（とも思えないが、仮にそうでも）それが売りになるとでも？

> あと、PythonでGUIアプリケーションを書くことに関してはスルーかな？
当たり前だがGUI用のツールキットも死ぬほどあったはずだよ。ググればいくらでも出てくるでしょ。

> 4,033 commitsとか書かれてるところの下の棒押してみ。
それで飛んでいった先が
> C 3950
> Fotrran 3720
なんだが。コミットが多いだけでコードの数はCの方が上だし。
それ以前に今時のML向けのCUDAやOpenCLじゃFOTRAN使えねえだろ、と思ったが、
CUDAにはFortran出てるのな。ちょっとびっくりだわ。

> これを今でも皆コンパイルして使ってるわけ。スパコンだけじゃなくて、PCでもね。
君本人がFORTRAN書いているのか？それならまあそれでいいが。
そのスライドなかなか面白かったけど、2010年代がねえだろ。そういうもんだよ。
京がCとFORTRANのユーザー割合を公開していた気がしたが、出てこないんだな。

> 研究者はいちいち他の言語とか覚えたくないから
これはその通りだけど、だからこそ、年代的にFOTRANはほぼ絶滅してて、
今時はPythonで書かせろゴラアで、NumPyだCythonだが出てきてるわけだろ。

もし君がFORTRANを実際に書いているのなら、それだから君の周りにFORTRAN使いが多いだけであって、
やっぱり君の現状認識は間違ってると思うぜ。

450 ：
結局このスレで長文垂れ流して何がしたかったのかは永遠の謎だった

451 ：
>>447
すまん、名前(TensorFlow)が出てこなかったので分かれてしまったがついでに。

GoogleのTensorFlowもPython,/C/Java,/Goであって、FORTRANは動かない。
CUDAは既に書いたようにFortranも出ているようだが、
元々はそもそも出す気もなく、ユーザーも「C++のサポートを」とは言っていたけどFORTRANについては言ってなかったと思うけど。

BLASのFORTRANをUpdateしている連中は、どこで何向けを流しているんだ？
現在のHPCはFORTRANなんて見てないと思うのだが。（上記CUDAやTensorFlowしかり）

452 ：
GUI Programming in Python
https://wiki.python.org/moin/GuiProgramming

453 ：
python製のwindowsアプリって何かある？

454 ：
凄えなGitHubの見方もまともにわからねえのかコイツ…
ここまで全方位に雑な上から目線キャラ初めて見たｗ

455 ：
現時点でwinアプリ開発で採用される言語のトップにpythonなんか入るわけ無いと思うけど
普通にC++/C#/VB辺りじゃない？
VBは国内だけかな？

この次あたりはどれも似たようなもんでそこにpythonが入るとかならまぁわかる。
javaはwinアプリなんかで使われてるのかはわからんけど

456 ：
ある程度の知識が広く浅くあるタイプの人間で技術屋以外に対して上手く話をして言いくるめるのが得意そうな感じ
あんま知らんけどSIerってこんな感じの人間なのかな？って見える

457 ：
言い訳と反論が得意なイメージ有るけど。

458 ：
>>449
> 今更ねえし。それがC#なら楽チン！（とも思えないが、仮にそうでも）それが売りになるとでも？
いくらでもある。当然売りになる。というかセキュリティ要件で満たさなきゃいけない。

> 当たり前だがGUI用のツールキットも死ぬほどあったはずだよ。ググればいくらでも出てくるでしょ。
で、使おうとしてみたことあるの？Pythonしか書けないってんじゃなければWinFormsの方がましとすぐに気がつく。

あとgithubのグラフの読み方は間違ってる。コミット数じゃなくて、コードの総量。

> 京がCとFORTRANのユーザー割合を公開していた気がしたが、出てこないんだな。
さっきのPDFに書いてあるとおり、FORTRANが1位だよ。

459 ：
>>449
> 今時はPythonで書かせろゴラアで、NumPyだCythonだが出てきてるわけだろ。
その辺は科学数値計算よりデータサイエンス系で盛り上がってるだけで、
色々余計なレイヤーがかぶさってるPythonが数値計算でnumpy、Cythonがあったとしても採用されにくいと
思うけどな。それこそメモリまわりの挙動とかで。

あと、tensorflowを例に挙げてHPCがどうこうと言ってたけど、ディープラーニングとかHPCの1ジャンルでしかないし、
ディープラーニングの分野ではFORTRANが使われてない、以上のことを示してないよ。

で、なんでそんなに他人の違う意見に対して「自分は正しい。お前の現状認識は間違ってる」と自信満々に言えるの？根拠は？
聞いてる限り聞きかじりの知識ばかりで実際に作らずに良し悪しを決めつけてるようにしか思えないんだが。

460 ：
ここはC#スレだぞ

461 ：
ワッチョイスレなんだから各自NGすればよろし

462 ：
日経Linux 2020/1月号に、
米田聡の記事「AI で鳩を自動認識、ラズパイ4 で3倍速」が載っている

TensorFlow Lite を使う、Google のEdge TPU の2製品、
Coral USB Accelerator, Coral Dev Board

CUDA なら、CPU の1/50 ぐらいの時間になる

ここは、C# のスレなので、以降は他のスレで議論してください！

463 ：
>>458
概ね全面的に水掛け論だからまあもういいが、一応反論だけはしておく。

> いくらでもある。当然売りになる。というかセキュリティ要件で満たさなきゃいけない。
いや逆じゃね？ローカルにUSBメモリ刺してexe/dllを直インストールなんてセキュリティが厳しい要件で許可されるのか？
まあいいが。

> Pythonしか書けないってんじゃなければWinFormsの方がましとすぐに気がつく。
だから言ったとおり俺はPythonを使ってない。
> WinFormsの方がまし
ただ、これはない。Formsは壮絶にゴミだ。それはHTML/CSS/JavaScriptを使えばすぐ分かる。
同様にWPFもゴミだが、Formsよりは数倍ましだ。
そしてWPFがHTMLに寄せたのはMSもそっちの方が断然いいと判断したからだ。
ただ、まだCSSが当てられないのが相当痛い。だから次は丸々HTML/CSSに寄せるはず。
（というかWeb開発では事実上そうでしかないが)

そもそもPythonもそっちに動いているっぽいだろ。>>452の頭の2つ、
> Cross-Browser Frameworks
は多分それだよ。Pythonでローカルに鯖を立てて、それをブラウザで見るんだよ。(かそれに近い形式）
というか俺なら最初からそうする。
つまり計算用PythonはJSONインタフェースだけ付けて終わりで、後は全面的にHTMLの恩恵を受けられる。

HTMLの良さが分からないのは、君が知らないからでしかない。といっても別に難しいものではないから、やってみればいいんだよ。
やれば、悲しいくらいに簡単にGUIを作れて、Formsとか本当にゴミだと実感出来るようになる。

464 ：
> あとgithubのグラフの読み方は間違ってる。コミット数じゃなくて、コードの総量。
間違いは認めるとして、いずれにしてもナンセンスだからこれは止めよう。
BLASはAPIであって、当たり前だがOpenBLASは一つの実装でしかなく、
Cにもポートされているのだから当たり前のように同量のソースはあるし、
そもそもcommit回数を競ったところで意味がない。
BLASが使われるのがFORTRAN経由かC経由か、他の実装も含めての割合が問題であって、それはGitHub見てても分かりようがない。
君が示したのは、「今でもFORTRAN向けBLASの一つの実装がアップデートされている」という事実だけでしかない。
（それでも俺にとっては十分驚愕だが）

> さっきのPDFに書いてあるとおり、FORTRANが1位だよ。
本当にそうだったら「うええ、老害め」みたいに記憶に残ってるはずなんだがなあ。
と言っていても本当に水掛け論だから、こちらも調べたが出てこない。
ちなみに文部科学省のアンケートは出てきたが、これにはユーザー割合は載ってない。（ただし2006年の資料であり、相当古い）
https://www.mext.go.jp/b_menu/shingi/gijyutu/gijyutu2/022/shiryo/__icsFiles/afieldfile/2012/06/11/1321896_7.pdf
インストールされているのはFORTRAN100%、C92%なので、その当時はCが使えないスパコンってのも存在したのも事実のようだ。(P19)
> その他、スーパーコンピュータセンターからのコメントから、ＦＯＲＴＲＡＮ７７からＦｏｒｔｒａｎ９０への移行、
> あるいはＣ＋＋
への移行等、より記述性や生産性の高い言語への移行が進んできている印象を受けた。
君は移行すらしてない、という見解なんだろ。なんだかなあ。

> それこそメモリまわりの挙動とかで。
何が言いたいのか分からん。
Cのdllを呼んでるだけだぞ。C#でならunsafeでCのdllを呼んでるのと同じ。
全く問題ないし、関係ないよ。だからこれについてはC#でも何でもいいわけだが。

465 ：
> ディープラーニングとかHPCの1ジャンルでしかないし、
> ディープラーニングの分野ではFORTRANが使われてない、以上のことを示してないよ。
今寄ってたかってホットなのは明らかにここだし、これを外して何を言うんだ？
問題は、こういった新しい環境ではFORTRAN向けの環境整備なんてされてない、ってことなんだよ。
だから正確には、「新しいHPC環境ではFORTRANは使えない」だよ。

俺は君が
> スーパーコンピュータで科学技術計算する分野では今でもFORTRANが主役だけど(>>444)
という明らかな嘘を言ったことを咎めている。
「環境自体がない」んだからそんなわけがないだろ。
何も知らない若い奴らが信じてしまう可能性もあるのだから、明らかな嘘をついてミスリードするようなことはするな。
色々見解が違うのはいいとしても、これはねえよマジで。

466 ：
WPFはHTMLに寄せたんじゃねえよ。
XMLとしてvalidだろ。

467 ：
>>466
C#er的公式見解がそうなのは知ってる。
ただ、機構は丸パクしてるだろ。

HTML/CSS/sjavaScriptのよい点は
A. テキストで書くだけ。ボタンなら"<button>Click Me</button>"だけ。
B. CSSが当てられる。
C. イベントがバブルする。
D. JavaScriptから値を弄ってもイベントは発生しない。
E. イベントは非同期、つまり必ずキューイングされる。

で、WPFは（といっても俺は使ってないが）
A. はまあ許容範囲（もうちょっと簡単に書かせろよとは思うが）
B. 出来ないのが悲しい
C. 問題なし
D. E. 知らない。Formsはイベントが発生してしかも同期イベントなので地味にこれがものすごく使いにくくて糞。
　直っていることを期待するが、そもそも俺はWPFを結果的にスキップしそうになってる。

だろ。AはXMLからとしても、Cはパクったろ。
そしてCは地味に素晴らしい。
といってもFormsから移行した奴らは活用してないかもしれんが。

468 ：
VSCode で良い。
markdown も表示できるし

Python は、Jupyter Notebook でも良い。
Julia, Ruby でも使えるし

VSCodeは、Electron だから、Node.js + Chromium だろ。
Ruby の標準サーバーを立ててもよいし

469 ：
>>468
ルビ糞は教祖様推奨のEmacsを使えカス

470 ：
コントロールに適用したいStyleがあるので、Generic.xaml を作成して、
App.xaml で ResourceDictionary.Merge Dictionaryしました。その中で自作のコンバータークラスを使いたくて定義したのですが、どうしても認識してくれません。ビルドは通るのですが、実行時に見つからないエラーがでます(xaml parse exeption)
同じ定義を App.xaml の中で、Generic.xamlをマージする前に書くと、何故か実行時にエラーも出ませんし、ちゃんと動きます。
Generic.xaml の中でコンバーターを定義することは出来ないのでしょうか

471 ：
テキスト送信して相手にレンダリングさせるものと自身のウインドウ環境に直接レンダリングするものを本気で横ならびで比較する時代になったのね

472 ：
>>471
なったというか、いわゆる(短期的な)「生産性」ってのは、どうでもいいところで如何に手を抜くか、でもあるからね。
グラが勝負なら自前でレンダリングしかないが、
>>255とか俺とか、>>458もほぼ確実にそうだと思うが、
計算ソフトの初期値設定をするだけ、みたいなGUIに時間かけて凝っても意味無いんだよ。
そこは「計算」に凝るべきであって、とりあえず多少遅かろうが表示出来れば何でもいいんだよ。

というか、こういうのを分かっててお前らはC#を選んでいるんじゃないのか？
ならまあ、お前らが奇妙なほどに信者化するのも分からなくもないが。

ちなみにUnity、内部エンジンはC++で上位スクリプトだけC#か？なら確かに芽があるかもしれん。
しかしこの構成なら、じきに上位スクリプトもPythonで書かせろ、になるとも思うが。

473 ：
>>467
機構のどこが丸パクリなんだよ。
Cだけじゃねえか。
Formsでもイベントのさばき方次第だろ。全然Forms触ってねえだけじゃねえか。
で、イベントも普通はそう捌くんじゃなくて、バインディングするもんだよ。
何意味不明な事言ってんだよ。

474 ：
語れば語るほど行毎に突っ込みどころ量産してるのが凄い…
釣りでガイジのフリやってるなら大したもんだわ

475 ：
> ちなみにUnity、内部エンジンはC++で上位スクリプトだけC#か？なら確かに芽があるかもしれん。
> しかしこの構成なら、じきに上位スクリプトもPythonで書かせろ、になるとも思うが。

なんでこんな予測になるのか意味不明
unityから使用できるjavascriptが廃れた経緯があるのにまた変更なんかこないよ
ゲーム開発においてスクリプト言語が来る時代は来るかもしれんがそれはunityにはこんだろう
新しいエンジンが来たときにその時代に沿った新しい言語が採用される可能性はある

476 ：
実際にUnityで選択肢として使えたjsとpythonがC#に駆逐された経緯とか知ったらこのキチガイ脱糞しそう

477 ：
>>473
逆だろ。Bはこれからパクる、Cはパクリ、D/Eは直っていればパクリ、直ってなければ糞だ。

あとFormsはバインディングできない。（から自前でやるにはReflectionすることになり、これが糞）
ただバインディングについては、
バブルされたイベント拾ってそこでバリデーションして問題なければ反映、アウトなら戻す、
みたいな方が格好悪いが結果的に楽な気はする。
(既に言ったとおり俺自身がWPF使ってないから全てに於いてバインディングだけで上手く行くのかは分からない。
勿論全く問題ないならバインディングした方がいいけども)


>>475
>>476
おお、その釣り針は喜んで食いつくから、駆逐された経緯とか書いたページがあれば紹介してくれ。
つってもちょっと（席を）外すが。

478 ：
食いつかんで良いから自分の浅はかな知識で事を語っていることを認識し悔い改めていただきたい
知りたきゃご自身でお調べ下さい

479 ：
>>477
WPFがバインディングが基本だと言っとろうが。
FormsにもDataSourceと言う概念があって出来んもんでもないしリフレクションも必要ではない。

480 ：
>>467
> B. CSSが当てられる。
> B. 出来ないのが悲しい
書くのが異様に面倒だけどスタイル定義はできるよ
てか、よく知らないならROMってれば？

481 ：
>>479
> DataSource
ああそれは確かに俺は触ってないわ。何かあったけど放置してた。

一応軽く見てみたが、ちょっと使ってみないと分からんね。
.NETは若干かっこよさを追求しすぎていて、既に言った
「フォームの値をプログラムから変更してもイベントが『同期』で発生する」
もそうだけど、格好良く自動連動を目指したのだろうけど、余計に使いにくくなってる。
同様に、余計なイベント接続が行われている可能性もあるから、実際に使えるかどうかは試してみないと分からん。
JavaScriptの場合はもっとドベタに
「プログラムから変更したらイベントは発生しないから、必要なら自分で呼べ」
でしかないから、本当にドベタにユーザーが挙動を定義出来る。

言ってしまえば、JavaScriptはライト層向けにできていて、
.NETはプロ向け（.NETのことを隅々までよく知っている前提）だと言えなくもないが、
ちょっとチューニングを失敗しているように思う。
結果、JavaScriptの方が取っつきやすいから、最近はどうでもいいUIはだいたいWebアプリになってるだろ。


>>480
これか？
https://www.atmarkit.co.jp/ait/articles/1009/07/news096_2.html
これは確かにCSSの一部だが、これでは全然足りない。
スタイルを適用したいのはコントロールそのものに、ではない。
CSSが美味しいのは、左右はもちろん上下ですら表示位置を簡単に入れ替えられること。
だから見た目全く違う物も同じHTML構造を取れ、結果、
同じ関数からお約束のHTMLを吐き出して後はCSSでも当てて、みたいな手抜きがあっさり出来る。
（見た目毎に出力関数を用意する必要がない）
CSSの表現能力についてはWeb系の馬鹿共がよく「CSSでここまで出来る！」みたいなページを作っているから見てみればいい。

482 ：
詳細を突っ込まれると
そうだね、けどこの面では…的な論理展開ばっかだけど自分で気にならないの？
これを繰り返してるうちに自身の主張が何かよくわからなくなって無意味に多方向にdisを撒き散らしてるだけになってる

483 ：
>>481
> CSSが美味しいのは、左右はもちろん上下ですら表示位置を簡単に入れ替えられること。
それはコンセプトの違い
WPFはXAMLでコントロールの位置を変えればいいだけ
データとはバインディングで繋がってるから位置を変えてもDataSourceはいじる必要はない

484 ：
>>481
自動連携なんて目指してない。
変更したならイベントが起こって然るべきだからイベントが起こるんだよ。

485 ：
>>478
以下は読んだ。
https://blogs.unity3d.com/jp/2017/08/11/unityscripts-long-ride-off-into-the-sunset/
開発側の人的資源の問題と、C#のIDEが素晴らしいからだな。
まあ妥当といえば妥当。（というかそう読めるように書いてあるもんだが）

そもそもJavaScriptが動くとは知らなかったし、信者でも無いから、ダメージもないのだけど。
まあそれ以前に俺はここだからC#の話をしているだけであって、
JSはJSでそれなりに糞だから、JSスレでならJSの悪口言ってるよ。

C#のIDEが圧倒的にいいのは事実だよ。あれと同じ物を自前で用意するのは無理だ。

486 ：
>>485
で、unityはそのうちpythonになるだろうという君の主張はどうなったの？
また同じ論理展開で主張が飛んでるよ？
そんなの知ったこっちゃないってのなら始めからズレた主張しないでね

487 ：
>>483
だからそれが駄目だと言ってるんだよ。
XAMLを変更＝HTMLを変更と同じで、それだと、全く同じ関数とか使えないんだよ。
XAMLを弄って変更した場合、文書階層が変わるから、バブルしてくるイベントも経路が変わってしまうだろ。
すると、イベント周りも修正が必要になってくるだろ。

CSSだけで位置変更出来れば、本当に表示位置だけを変えられる。
バブルしてくるイベントはHTML通りにバブルしてくるから、見た目重なってもいない要素からもバブルしてくるようにも出来るんだが、
それだからこそ、同じプログラムで対応出来るんだよ。
違うのは人間からの見た目だけであって、プログラム上からの見た目は同じだから。

と、説明しても意味分からんと思うけど、多分やれば分かるよ。
「こんな手抜きの仕方があるのかよ！」みたいな事が結構出来たりするから。
典型的な例だと、HTML/CSSでは display:none （表示させないだけ、Formsで言う Control.Visible = false)を多用する。
勿論上記の通りFormsでも出来るけど、文化的にほぼ使われてないでしょ。（と俺は思っている）
ここら辺の手抜きの仕方がWeb系の方がこなれてる。
俺もそうだったが、,.NET界隈も真面目にプログラミングやりすぎてるんだよ。

「常に見えない設定の物を表示ルーチンに渡すのは無駄だ」というのは当たり前だけど、
それで別関数になるくらいなら、display:noneで同じ関数使おうぜ、ということ。
CSSの表現能力が高いからこれがかなり有効なんだよ。

488 ：
かまうほうも頭おかしいんだけど自覚ないの

489 ：
>>484
原理原則論としてはそうなのだろうけど、だから逆に使いにくくなってるんだよ。
多分これも、JavaScriptみたいに「自前でやらないと発火しない」フレームワークを使えば分かるよ。

君が既に両方使ったことがあって、
HTML/CSS/JavaScriptよりも.NETの方が使いやすいと判断しているのなら、それでいいが。

490 ：
なんでxamlとhtmlの比較の典型例にformsがでてくんの？
xamlでもコントロールの非表示なんて日常茶飯事だと思うが

491 ：
cssを採用したjava fxってどうなったんだろうね？

492 ：
>>486
ん？Pythonについてなら君の言うとおり、
> ゲーム開発においてスクリプト言語が来る時代は来るかもしれんがそれはunityにはこんだろう
これについては納得したぞ。俺の負けでいい。

あのブログはもう2-3年前になるが、まあ、少なくともunityにはスクリプトは来ないね。
あれはC#と心中する、という決断だ。（逆に言えばC#は死なないとunityは判断してる）

493 ：
差し支えなければどなたか>>470を…

494 ：
>>487
> XAMLを弄って変更した場合、文書階層が変わるから、バブルしてくるイベントも経路が変わってしまうだろ。
WPFではイベントは直接使わないよ（使うこともできるけどあまりよろしくない）
モデル側でコマンドを定義してコントロールにバインドする
って言っても君にはちんぷんかんぷんかもね
まあ理解する気なさそうだから君はそのままでいいと思うよw

495 ：
>>492
俺は複数の分野を横断的に知ってて各方面の弱いところをよく知ってる、だからマウントとれる、
と思ってるのかもしれないけど、職業プログラマだったらそんなの実務レベルで当たり前で、
むしろある分野を専門的にやってる人には勝てないなと思ってるからそんな大げさな物言いはしないんだけどね。
（〇〇の分野だと□□という概念があるんだけど、△△だとそういう概念はある？ぐらいに控えめに話題にする）

「C#信者」、「FORTRAN信者」だの、「Web系の馬鹿共」だの、「HTMLの良さがわからないのは君が知らないからだ」だの、
「説明しても意味わからんと思うけど」だの、よくもまあ自分以外を下に見る発言が沢山出てくるもんだ。
皆、あんたが偉そうに発言する割には、中身が誰でも思いつくことでしかも間違いが多いからツッコミを入れてるだけだぞ。それを「こいつはわからないから反論してきてるんだ」と思うようじゃ単なる天狗で自分の成長につながらないよ。
このスレでたった2日やりとりしたぐらいで、経験知識不足で頓珍漢な理屈を並べてると思われちゃってるんだから。

最終的に、実世界で相手されなくなって2chに書き込むしかなくなる悲しい人生になるぞ。

> 「今でもFORTRAN向けBLASの一つの実装がアップデートされている」
正直笑ってしまった。わかってないようだがOpenBLASはFORTRANのコードをコンパイルしてCから呼び出すんだよ。
FORTRAN専用のコードじゃない。CやFORTRANで呼び出せる共通バイナリをFORTRANで書いてるの。

496 ：
>>490
そうなら第一段階は出来ていることになる。
でも本当にそうなら、もっとStyle側に押し込めればコードを減らせる＝XAMLのスタイルなんて非力すぎる、
というのも実感出来てるはずだけど。


>>491
俺についてはCSSを採用してることすら知らなかったな。
ただJavaのGUIはどうやっても死んでるだろ。

色々原因は言えると思うが、既に言ったとおり、Javaの変数管理がGUIに向いてないんだよ。
これはC#も同じで、よく騙して来れてる方だよ。

497 ：
>>492
勝ちとか負けとかそんな話してないんですが…
俺が突っ込めるのは俺がわかる範囲だけだが、そういった浅い知識で何でも語る人間なら全ての話が適当なんだろうなとしか見えないね

498 ：
>>490
たぶんID:EA/Onx+o0はWPFのことをFormsをXMLで記述できるようにしたもの程度の認識なんだろうと思う

499 ：
>>494
> モデル側でコマンドを定義してコントロールにバインドする
そんなことになってんのかよ。
んー、まあ何か理由はあるんだろうけど、格好良すぎて余計に分かりにくくなってる気はするが。

まあいずれにしても俺の勉強不足はそのとおり。俺はWPFはやってないし、今すぐやれる準備もしてないからね。


>>495
だからそもそもマウント取りに来ていると考えているのが間違いなんだよ。
なんで一々そんなことしないといけないんだよ。

> FORTRAN専用のコードじゃない。CやFORTRANで呼び出せる共通バイナリをFORTRANで書いてるの。
おーマジか。知らんかったわ。というかFORTRANのバイナリなんて呼び出そうともしたこと無いし。
してOpenBLAS以外はFORTRANで書かれているのか？
Cじゃねえの？という気はするし、それ以前にアセンブラで書く気はするが。（勿論Cのインラインアセンブラな）

500 ：
>>497
> 勝ちとか負けとかそんな話してないんですが…
メンドクセエ奴だな、じゃあどう言って欲しかったんだよ？

俺のことをどう見るかは君が決めることであって、俺がどうこう言っても意味無いだろ。
好きにすればいい。

501 ：
>>500
適当な知識を撒き散らし嘘を広めるような言動をやめてほしかったんですよ

502 ：
>>499
初めの主張を否定されたら「知らんかったわ。だけどこれはどうなの？」とか言って話をずらすのは、
気付いてないのかもしれないが、マウントを取る行為そのもの。
会話をしている相手への礼儀に欠いている。
少なくともFORTRANが現状では死んだ言語だという主張は間違いなわけだ。あんたが呼び出そうとしたこともないかどうかで事実が変わる訳でもない。
やったことない領域は分からないんだと謙虚な態度で考えることがエンジニアリングにおいても人間関係においても大事。
伝聞からの外挿で精度の悪い話を吹聴しても勝てないんだよ。相手は大抵人間じゃないか自分より能力や経験値が高いから。
日常が精度の悪い話で勝てる状況なら、正直その環境を見直した方がいいと思うぞ。低レベルな環境で過ごしてて、知識や技術は身につかないのに歳だけ取るということになるからね。
エンジニアリングを生業にしてないのなら、まあ、趣味の範囲で好きに生きるといいと思うよ。

503 ：
>>502
マウント行為の重要なところが抜けてた。、他人を信者呼ばわりしたり、専門的にやってる人を「馬鹿共」と言ったり「分からないだろうけど」「知らないんだろうけれど」と決めつけたり、
なんの根拠もなしに他人を下に見て一方的な勝利宣言をするこれらの発言、マウント以外になんか理由があるのかい？

504 ：
>>501
嘘は広めてないだろ。
俺は俺の見解を述べてるだけで、間違いはその都度認めてるつもりだが。
俺は広報しているのではなく、会話をしているだけだ。

紛らわしいから白黒正せ、というのがあれば、一々挙げてくれたら回答するが。
既に言ったがunityにはPython(というかスクリプト)は来ないだろう、というのは君の見解の方が正しいだろう。

505 ：
>>504
広めるような、ね。
知識が無いのに明言してんじゃん
知識ある人がちょっと突っ込むだけで破綻するのになんで適当なこと言ったの？
知らないなら質問するだけにするか始めから触れなきゃ良いだけなのに

俺は突っ込めんがfortranもwpfも同じ流れじゃん
突っ込めない人間から見れば真実に見えかねない

506 ：
ここの書き込み毎日凄いね。
ついてけね～
C++のめんどくさいから来たから有用な書き込み求むわ。

507 ：
>>506
ここ質問スレのふらっとの隔離スレだから有用な書き込みなんか期待するのが間違い

508 ：
>>502
> 少なくともFORTRANが現状では死んだ言語だという主張は間違いなわけだ。
そんなことはない。というかマジでこれは止めろ。

現状のHPCはどう見てもAI/MLであって、そこが環境を用意していない以上、死んだも同然だ。
君はCOBOLを現役だ、と言っているに等しい。(いや、アセンブラが現役だ、の方が近いか？)
若い研究者が今からFORTRANに賭けたらいきなり死ぬんだから、こんな事を言ってはいけない。
君こそ、
> 手続き型言語だったら考え方は大して変わらないからね。
というのならさっさとCに乗り換えるべきで、今の若手にはCを強制すべきだ。
まあ君がFORTRAN使いでカチンと来ているのは分かったが、しかしさすがに今の若手に
> FORTRANが主役 (>>465)
はマジで止めろ。
というか君の発言は「FORTRAN信者」と言われても全く文句言えないレベルだと思うが。

>>503
して
> と、説明しても意味分からんと思うけど、多分やれば分かるよ。 (>>487)
は馬鹿にしてないだろ。こんな説明では説明がイマイチで分からないのは当然だけど、やれば分かる、と言っているだけだ。
まあそれ以外は馬鹿にしているのも多々あるが、それは本当に馬鹿にすべきだからだよ。
例えば、「Web系の馬鹿共」、実際に行ってCSSのページとか見てみればいい。
そこじゃねえんだよ、ってところで頑張ってて、肝心のそこだよ、ってところが抜けてるんだよ。
だから本当にWeb系は玉石混淆（といえばよく聞こえるが、ほぼゴミ）なんだよ。
これは事実だし、実際Web系は馬鹿にされまくってるだろ。PHPerとか特に。
それは馬鹿にされるだけの理由が確かにあるんだよ。(これも本当に、見れば分かるよ。
なお俺はPHPerは過小評価されすぎで、むしろJavaScripterの方が問題だと思っている）
ただし上手いところは本当に上手くCSSを使い、
え？この関数しかないの？こんなんで出来るの？スゲー、みたいな構造になってたりする。
そういうところは勿論馬鹿にしてないし、するはずもない。

要は、馬鹿だから馬鹿にする、というだけの話で、それ以上でもそれ以下でもないし、
それが俺は匿名掲示板のいいところだと思っている。

509 ：
>>505
> 突っ込めない人間から見れば真実に見えかねない
だから具体的にどれについてだ？
真実に見えかねないから全部訂正して回れ、というのなら、一々挙げろ。対応はする。

単に黙れ、というだけなら、お前が去れ。
ここは自由に意見を述べられる場所であって、それ以上でも以下でもない。
意見を自由に述べる以上、全部「正しい」なんて事にはならない。
というか、仮に全部「正しい」のであれば、そもそも議論が成立しない。

だから、俺の見解が間違っているというのなら、その意見を具体的に述べろと言っている。
そして必要なら俺は訂正する、とも言っている。
というのは>>504で述べたとおりの内容であって、お前が分からないようだから一端咀嚼したが、
無限ループするようならもう無視するから、その辺よろしく。

510 ：
>>509
突っ込めない人間が居ない話題についてはどう訂正なんかするんだよって話だよ
君の無知からくる発言全てにその分野の知識ある人間からツッコミ入れさせるの？
始めから知らん内容を推測で発言すべきじゃないと言ってんの

間違ってるなら訂正してやるから教えろ
じゃなくて間違ってる可能性の高い内容を流布すんなって話
無闇に手を広げずに自分が話せる内容に留めておけ
知見を広げたいための会話ならそうなるようなレスをしろ

511 ：
もー放っておけよ

こんだけデタラメ積み重ねてりゃ内容わからん人間でも
他人をディベートごっこに巻き込んでるだけで
なにひとつ言ってることが信用できないと既に印象付いてるから大丈夫だよ

1を聞いて-10を語るキチガイ相手じゃまともな方が何も得るもの無さすぎてかわいそうだわ

512 ：
これ数日前にusingウゼーとかゴネてた人？w
なんかすごい執念だね
でも結局何が言いたいんだろうw

513 ：
中身のない長文かけたら作文楽だったんだろうなあ

514 ：
>>513
わかるw
作文教育なんてやめた方がいいねw
あんなの思ってもいないことを平気で書ける不誠実な人間を育てるだけだ

515 ：
>>514
そうそう、書くんだったら普通に英文和訳の方が力が伸びますね、そもそも嘘は書けないし

516 ：
>>508
数値計算屋がFortranを捨てるべき３つの理由
(リンクがRock54で貼れないので、ググってくれ)

今でもこんな記事が書かれるほど、現場ではFORTRANが使われているということだろ。
自分はFORTRANはほとんど書いたことはないし、Cなんて当然のように使ってるし、人に教えるのならPythonだ。
(なぜ手続き型言語だとCなのかも謎だが)

FORTRAN使いとかいうのもお得意の決めつけなわけよ。

HPCはどう見てもAI/MLというのは、根拠がどこかにある話なのかな。よく知らないので否定しないので教えてくれ。HPCをどういう意味として使っているのかも教えてくれ。

517 ：
>>508
「説明しても意味分からんと思うけど」
は、通常「説明しても（お前が馬鹿だから）意味が分からないと思うけど」と解釈される。馬鹿にする意図がないなら「この説明では伝わらないかもしれないが」のように書くべきだろう。
また、Web系が馬鹿にされるべき理由があろうとも、その理由が会話の内容と関係のないものなら無文脈に馬鹿にすべきじゃないだろう。
レッテル貼りして否定して回るのは紛れもないマウンティングなんだよ。
マウンティングする気がないのなら、発言の仕方に気をつけよう。端的に言ってあんたの発言は精度も態度も雑すぎて、聞き手に対して無礼極まりない。いくら内容が正しくても相手の機嫌を損ねてまともに聞いてもらえないぞ。
そんな奴は知に対して素直じゃない、とか思うかもしれないが、知に対して素直になりたいのなら、知以外の部分で余計なマイナスの修飾をすべきじゃない。
504とは違う意味になるが、「知見を広げたいための会話ならそうなるようなレスをしろ」というのはそのとおりだ。
中学生とかじゃなくてもういい大人なんだろうから、態度についてちょっとでも意見されたときに、脊髄反射的に否定するんじゃなくて、
一旦自分にそういうところは本当にあっただろうか、メタな視点で振り返ることができるようになろうよ。
それをした上で自分の行為はマウンティングじゃない、と客観的な言葉で説明できるのならそれはそれで良いからさ。

518 ：
>>516
> HPCをどういう意味
HighPerformaceComputingだよ。普通に使われてる言葉だ。

> HPCはどう見てもAI/ML
むしろ今それ以外どこだと言うんだ？俺は君がここに疑問を持つことが疑問だが。

519 ：
>>517
どうでもいいわ。ここはお前の日本語力の養成所ではない。
その後に「多分やれば分かるよ」と続けているのだから、
普通に読めばある程度相手の技術力に信頼を置いていることは明白だし、
仮にそれが君みたいに誤読してかってに切れられたとしてもマジで割とどうでもいい。
ついでに言うと、誤読でなく、実際に俺の人格が糞で切れていたとしても、どうでもいい。
マウンティングだと取りたければ取ればいい。
ただ、俺は君自身が「本当の議論」をしたことがないだけだと思う。

君が議論に人格を持ち込む奴なのは>>495が端的だし、それ以前から色々におわしていた。
君はリアルでもそういう議論『ごっこ』をして、反対意見を『年長者』という勢いで潰してきているのだろう。
が、そもそも俺は話者の人格なんて見てないし、興味もない。
そしていくら人格について言われても、意見を引っ込める気はない。
それとこれとは全く別だからだ。

俺はこのスタンスでずっと続けているが、繰り返すがそもそも俺は相手の人格になんて興味なく、
相手が技術的に糞だった場合はズタボロに言うものの、こちらが間違いなら普通に負けを認めてるから、
そもそも相手の技術力が高い場合にはさほど衝突しない。
だから俺はこれで全く問題ないし、ここではこのスタンスが最適だと経験的に結論づけてる。

当初は確かに俺も丁寧にやってたが、結局それだと馬鹿が図に乗るだけで収拾がつかなくなるだけだった。
馬鹿に優しいと、馬鹿にとっての楽園になってしまって、余計に馬鹿が集まる循環にしかならなかった。
だから馬鹿は叩かれるべきだし、当然俺が馬鹿だと思えば叩いて来ればいい。
そうして馬鹿はたたき出される、ということにしないと、匿名掲示板の健全さは保てない、と知った。
そしてお前らが技術的に叩けなくなったら「人格ガー」と言い出すのも理解している。

520 ：
もう一度言う、「FORTRANが主流だ」(>>444)という嘘を平気でつくのは止めろ。
本当にそれは害悪だ。俺の人格云々ではなく、そっちの方が大問題だ。
これは見解の相違とかではなく、事実をねじ曲げてるレベルだからだ。


が、これ以上はどう見ても水掛け論だから、一応纏めておく。

君
・スーパーコンピュータで科学技術計算する分野では今でもFORTRANが主役(>>444)
理由はOpenBLASの実装がFORTRANで書かれているから(>>447)

俺
・FORTRANなんぞとっくに死んでる
理由は現在のHPCの主戦場であるAI/MLの中心に位置するCUDA/TensorFlow等に於いて
FORTRANはそもそもプロットフォームとして提供することすら議論されていない。
（ただしCUDAにはたまたま勝手ポートをした会社があり、それを買収して公式化されたので使えるが）

これをどちらが正しいと取るかは読者の判断だ。
技術的内容より人格だ、と思うのならそれでいいし、逆に、俺の人格は糞でも筋は通っている、と思うのも自由だ。

521 ：
>>510
そもそもそのスタンスが間違ってるんだよ。
発言の自由があるということは、結果的に間違っている発言もある程度存在することを許容しないといけないし、
そもそもここは学校のように「正しい知識を教えてくれる場所」ではない。
勝手に各自が発言した内容を、自身で精査して、どれが正しそうかを君自身が掴み取らなければならない。
それに君が人格フィルターを使うのも自由だし、それ以外を使うのも自由だけど、
いずれにしても君自身が「精査」出来ないのなら、ここを使って「正しい」知識を得るのは無理だ。

俺は意図的に間違いを言っているつもりはない。
だから間違っていると思うなら突っ込んでくれればいいし、勿論ブッ叩いてくるのもありだし、放置ならそれでもいい。
ただ、「正しい発言しかするな」は「発言の自由」とは原理的に両立しないし、そもそも俺は一応「正しい」と思って発言している。
だから君の態度がナンセンスなんだよ。

あと、ここはディベートが出来る場所ではない。>>511
あくまでもパネルディスカッションであり、「この問題については俺はこう思う」以上のことは出来ない。
それで複数人から意見を聞いて、どれが正しいかを判断するのは読者自身だ。それは読者の責任であり、俺の責任ではない。
繰り返すが、俺は一応正しいと思って言っているし、同様に、間違いだと思うことには噛みついている。
それが俺の責任範囲であり、それ以上のことは出来ない。
各意見を並べた上で、どれを採るかを決めるのは、読者の判断であり、俺はそれに関与出来ない。
俺は人格者だからーみたいなことを言う気も毛頭無い。俺の発言を全て読んだ上で、君がどう判断するかは、君の自由だ。
この態度に徹しきれないのは、君たちが議論慣れしてないからだ。それは自覚した方がいい。


>>470,493
巻き込んで申し訳なかった。
ただ申し訳ないが、俺にはそれに答えられる知識がない。
タイミングが悪かったのはそちらの責任ではあるが、流し去ってしまったことについては謝っておく。

522 ：
>>521
515の2行目を読んでから514の1行目読んでみなよｗ

常に正しい情報しか発信しないが理想論でしか無いのは当然
だからといって間違った情報を流布していい免罪符にはならない
間違ってないことが望ましいしそうなるように努めるべき

君のレスはどれも適当に言いくるめようと自身に都合の良いような情報を作っているように見える
事実unityで適当こいたしwpf周りも相当怪しい
fortranは俺にはさっぱりだがこの流れなら君の意見に対する信頼度は皆無

君は自分が正しいと思っていると言うがもう少し自身のハードルをあげたほうが良い
usingの頃からあらゆる方面についてさんざんツッコミを受けているんだから

523 ：
>>522
何度も言っているが、君がそう判断するならそれでいい。

ただ俺はusingについても特段間違ってないつもりだけどな。
君らが間違っていると思うのも自由だが。
一応纏めておくと、

1. usnig書け。usingを忘れるとリークする。最速。
2. usnig書け。ただし書き忘れてもFinalizerで救済する。
　でもその分GCが複雑化して多少遅くなるから、要らないときにはSuppressFinalize呼んでね←今の.NET
3. using不要。ただしローカルにしか確保出来ない。最速。←俺はこれがいいと思う
4. usnig不要。メソッド内でGDI+リソースを確保/解放することにより完全に隠蔽。
　確保/解放分各メソッドは遅くなるが、絶対安全ではあるのでFinalizer不要になりGCは高速化する。
　結果的に速くなるか遅くなるかは未知数←423のツッコミ

俺は今でも3がいいと思うよ。ただ当たり前だが俺には決定権なんて無いから関係ないけど。
安全側に倒すのなら4だし、これも理屈的にはありだけど。
2なんて完全に泥縄的仕様で、美しくはないだろ。ただMSはこういうのも許容するところはあるが。
3はC的寿命設計が必要にはなるが、別段難しくないし、GCに慣れきってる奴でもやらせれば出来る範囲。
DIコンテナの先は知るか、でも、おそらく問題はない。
GDI+リソース周りはそのDIコンテナの先に入り、ユーザーが管理することにはならないはずだから。
4でFinalizerを外すにはfileリソース等含めて全面的にusingを撤廃する必要があり、多分すぐには無理。
各メソッドでGDI+だけ隠蔽するのは出来るが、それだと単純に遅くなるので、やるなら上記の通り足並み揃えて全面改訂だとは思う。

これでどう間違っているか言ってみ。
というか俺はお前が「俺が間違っている」ということにしたがっている理由が分からん。
俺が「全面的に間違っている」か「全面的に正しい」かで、この『人』は信じられる、この『人』は信じられない、にしたい？
ならそれは諦めろ。ここはこの『意見』は正しそう、この『意見』は間違ってそう、にしかならない。

unityについては公式見解を読む限り俺の「スクリプトが来る」予想は撤回であり、それ以上にも以下にもならんよ。
ただそれは君も分かっているとおり、unityには、でしかないよ。

524 ：
>>522
> 515の2行目を読んでから514の1行目読んでみなよｗ
あ？ダブスタって話か？

なら俺は「分かり切っている嘘には噛みつく」という、君の言う
> 間違ってないことが望ましいしそうなるように努めるべき
をやってるだけだな。それでどっちが間違っているかを判断するのは君の責任だ。
さっぱりなら、「こういう事があった」ということだけ覚えていればいい。
そして後日、分かるようになったときに思い出したら、ああ、そういうことだったのか、でいい。

相手が言うことを止めることは無理だから、精々こちらは噛みつくことしか出来ない。
それで判断が保留されるのなら、それでも及第点ではある。
それが俺の精一杯だよ。

525 ：
>>523
割り込んで申し訳ないけどusingについては結構奇妙なこと言ってると思うよw
まず、コンピュータのリソースには希少どころか物理デバイスみたいに排他的にしか
利用できないものもあるので、解放されるタイミングをプログラマが制御できないのは困ると思うよ。
非同期メソッドがあるC#ならなおさら「メソッドのスコープを抜けたら解放」なんてそんないい加減な話困っちゃうでしょw
次に、希少なリソースを握ってるオブジェクトだからってそれを戻り値にできないような言語、
普通は使いたくないのでは？その制約はどういう利益のための代償ですか？w
こういうの「倒錯」って言うんだと思うよw
強迫神経症ともいうねw
そもそも大して冗長でもないusuingを目障りだ、という問題意識が恐らく盛大に間違っているんだと思うけどw

526 ：
Qiitaでやれ

527 ：
>>518
AI/MLはHPC分野で新たにシェアが伸びた分野ではあると思うが、
今までの数値シミュレーションだって当然需要がなくなるわけもなく、HPC分野の大きな一ジャンルだろう。
"High Performance Computing (HPC) on Azure"というページをググって見てくれ。AI/MLとは別に項目になっているのだから、
AI/MLに食われるような存在ではないということだろう。
そして、根拠を示してくれと言ったのだがそこはスルーなのな。

その根拠を示さない限りは、
>>520の言説の仮定の一つとなっている、「HPCは科学技術計算ではなくAI/MLである」の正しさが検証できず、
HPCでFORTRANなんか使われてない、は示せない。AI/MLではFORTRANなんか使われてない、としか言ってないだろう。
事実を捻じ曲げている、というのなら、明確な根拠をどうぞ。

>>519
あんたの大層な論の細部がめちゃくちゃだからツッコミを入れると、「信者」だの「知らないだけ」だの言って
ズレた反応を示しながら相手の発言と自分の知識の間違ったところのすり合わせをしないから「人格に問題がある」って言ってるんだよ。
端的に言うと、「馬鹿って言ってるけどお前のほうが〇〇の理由で馬鹿だぞ」と言われたときに、「〇〇は果たして間違っていただろうか？」と考えず、
「いや、やっぱりお前のほうが馬鹿」ってのを繰り返してるんだよ。思い込みを指摘されて、根拠はあるの？と言われてもまだ思い込みで返してくる。
少なくとも調べなおそうよ。
もう、技術的にあんたの経験不足、知識不足を指摘するのは諦めてるんだけど、あんたは人を馬鹿にできるほど経験も知識もない。
WindowsのGUIアプリはなんでもかんでもブラウザベースでOK、とか、インターネットにつながってない環境は考慮する必要ない、とか、
そりゃそういう世界もあって良いけど、そうじゃない世界もあって、そこでは通用しない考え方なんだよ。
自分の考えが通用しないからって、「そんな世界はない」と言ってるようだけれども、事実そんな世界はあるんだよ。
仕事でそんな世界にアプリを納品する必要があったら、ブラウザベースじゃないGUIアプリを作るとか、
インターネットに繋がってなくても当然のように使える開発プラットフォームを使うとか、別の方法をとるまでだ。
ちなみにSIerではないからね。設計から実装まで任されててもたまにそういうところはある。
そんなときにあんただったらどうするんだい？「こんな馬鹿な環境では仕事してらんないから辞めてやる！」のか？

528 ：
年末に何やってんだ君たち暇なの？
家族や友人とは交流しないの？

529 ：
中途半端な知識で何とか丸め込もう、話を付け替えて何とかしようとするから長文になる
わかってる人は、核心付くだけで済むから短文で済む

長くコンピュータに関わってたら、それぞれ皆わかってる程度の内容を書き連ねて暇だね～
えっ！？ 君園児？ それなら凄いわ

530 ：
何でもブラウザでできる時代になる論は20年前にも10年前にあったw

これ数年前にも書いたけど、そういうドリーマーにGMailやOutllook.comのUIが
どう見えているのか興味はあるねw

何年たってもどっか使いづらいままだよねw
UIの使い辛さ以上の利便性があるから使われているだけのことで

531 ：
outlookのWebUIは最近の365だと割とまともじゃないか？
使えない機能が多いのは確かに考えもんだけど。

532 ：
今のOutlookのUIってクライアント版もかなりWeb寄りになってるから、その気になればWebベースでも十分再現できそう
プログラマにとって最も馴染みの深いツールの一つであるテキストエディタがVSCodeでWebベースになった時点で、もう言い訳はきかんよ

533 ：
using はユージングって読む人が多いけど、ついウシングって読んでしまう。VBのときのストラコンブとかと同じような感覚で

534 ：
その読み方はした事ないけど自分の中で使っちゃうやつってのはあるね
charは脳内だといつもチャー読みだわ

535 ：
気絶するほど悩ましいな

536 ：
char は敢えてシャアと読むべきだね
https://marycore.jp/programmer/char-aznable-type/

537 ：
>>527
いやもうお前はいいよ。
前半はどういう論理でどう白黒つけたいのかさっぱり分からんし、後半は要するに俺への文句だろ。

君の中では俺は糞という結論が出ているのだし、それでいい。
それを周りの人がどう取るかも含めて読者の自由だ。
俺は技術論しかする気ないんだよ。

一応OpenBLAS見てみたんだが、やっぱFORTRANが生きているとは言い難いぞ。
アーキ毎に高速化されてる奴はkernelの中に入っているが、アセンブラとCしかない。
高速化されてない奴は確かにFORTRANの実装を呼んでるっぽいので、
実際に呼ばれるFORTRAN/C/アセンブラの割合がどれくらいかと、
最近他にFORTRANで改訂された物がどれくらいあるかだね。
つってもBLASの作りだと、単なる(FORTRANで書かれた）アセンブラライブラリでしかない。
現役だというのならまずその上位コードがFORTRANで書かれてないといけない。

538 ：
なお論調がまた勘違いして読み間違っているようだからもう一度はっきり言っておくと、
俺は君の意見なんて全く認めてないし、FORTRANは死んでると今も認識してる。
そしてお前は本当に議論が出来ないようだが、お前が今やるべきは、
A. 俺の『意見』を否定することにより、俺の『意見』を無効化する
B. 俺の『人格』を否定することにより、ここの人格重視の馬鹿C#er共と一緒に喚き立てて俺の発言全てを無効化したことにする
ではなくて、
C. 君の意見を補強する材料を提示して、俺の意見を木っ端微塵にする
なんだよ。お前みたいな議論が出来ない馬鹿はAやBにこだわるのが常だけど、
それだと、-1が0にしかならず、結果、その議論は何も得る物が無く、結論も出ない。
そうではなく、やるべきはCであって、+10とかぶっちぎってしまうことであり、
それが出来れば俺が-20とか出さないと勝てなくなるんだよ。
議論は足の引っ張り合いではなく、突っ張りあいをやるべきなんだよ。

お前は最新のプラットフォームで相手にもされてないのがどれだけのことなのか理解出来ないのか？
そしてこれを越える材料を持って来いと言ってるんだよ。

なおお前が実際にFORTRANでスパコン使いまくってる、というのなら俺にブチ切れるのも分かるが、
そうでないと言うのだから、ここにこだわる理由も分からんがな。
そして材料が無いなら、蒸し返そうが何しようがそれ以上話は進みようがないだろ。
「FORTRANが主役」「FORTRANはもう死んでる」で読者に判断を委ねるで済ませられない理由は？

> 別に項目になっているのだから、
> AI/MLに食われるような存在ではないということだろう。
お前はそもそも「スパコン」が何か理解出来てないようだが、何故ここまでこだわる？

539 ：
「FORTRAN」「求人」でたくさん引っかかるのですが
本当に FORTRAN は死んだのでしょうか？

540 ：
>>539
お前にレスするのは不本意だが、なかなか良いツッコミだ。
が、俺は
> あれはスパコンのCOBOL扱いになってるはずだが。
> （もしかしてベクトルはFORTRANしか受け付けないのかな？これはあり得るが） (>>445)
と既に言ってるだろ。

COBOLなら求人があるのは分かるよな？そういうことだ。
http://labs.timedia.co.jp/2017/06/gnufortran.html

541 ：
最新、トップシェア以外のものは死んでるという前提の理論はいらん

542 ：
いやスパコン言ってるなら既に出されてる京のpdfを否定する資料をまず出せば？
相手にされてないってものCUDA Fortranで自分で否定してるし

なんか対等にやりあってる風を装ってるけど
既に木っ端微塵されたところから全然建て直しできてねえぞ？

543 ：
>>533
ウンチングが正解
これ以外で読んだやつを信用してはならない

544 ：
まあFORTRANの話はいずれにしてもスレチだし、俺も終わりでいい。

ただお前らが思っている世界とスパコン界隈は全然状況が違うが、
それにしても興味もないだろうし、お前らに俺が間違っているとされても俺は問題ないので。
ただ、俺の話を少しでも信じる気があれば、
「FORTRANなんて既に死んでる」と言っていた奴が居たことを頭に留めておいて欲しい。
そしてもしなにか機会が発生したら、その時に俺が言っていたことを吟味してくれればいい。
それだけで、だいぶ違うはずだから。

545 ：
>>525
そう思うならそれでよし。
君は今の.NETの実装、つまり俺の纏めた 2 が妥当だと思ってるんだろ？
ならそう言えばいいだけ。
余分な人格評価とかすると（一般的には)君の評判自体も落ちると思うぜ。
そこも含めて自由にすればいいとも思うが。

> そもそも大して冗長でもないusuingを目障りだ、という問題意識が恐らく盛大に間違っている
これはちょっと違ってな、というか俺も以前は今の君のように何も考えずに「書くものだ」で書いてたんだけど、
それだと「書ける人」にしかならないんだよ。
ただの1行、ただの1ステートメントですら、
「本当にこれ必要なのか？無くすことは出来ないのか？」と考えないと、本当に余分のないコードにはならない。
ジョブスがやってた、「ボタンは一つにしろ」と同じだよ。
コードは、書くよりも、削る方が難しいし、削るときに腕前は上達する。
というのは以下のどこかにあったはずだが、出てこない。が、まあ、実感としてこれは当たってる。
https://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/

ググってたら出てきたからついでに
何事においても、完璧に到達するのは、 付け加えるものが何もなくなったときではなく、 削るものが何もなくなったときである。 （アントワーヌ・ド・サン＝テグジュペリ）

546 ：
>>530
どっちが優れていたとしても、優れていた方がパクられて、最終的に同じUIになるのは確実だろ。
区別する意味ないと思うが。

ただ俺が言っているのは、君が勝手に想像しているそれではない。
俺は単に、
・HTMLの方がUIが作りやすい
と言っている。

例えば00年代初頭にはJavaでクライアントアプリを作って配布することもあった(と聞く)勤怠アプリ、
今ではWebアプリ一択だろ。これには、君らは
1. デプロイの手間がない
2. 鯖にデータが勝手に溜まる
だけだと思っているのだろうけど、俺は、
3. GUIを作るのが楽
がでかいと思っている。
そしてそれがデスクトップに出てきたのがelectronだ。当然1,2の利点はなく、3だけで勝負してる。

ならなんでUIが糞なのさ、というのは言ってしまえばWeb系のデザイナのセンスが糞だからだろ。
フラットデザインが糞なのは、マルチデバイス優先で手抜きされてるからのようだが。
> しかし、もっとも大きな理由は「マルチデバイスへの対応に最適だから」と言えます。
https://webbu.jp/flatdesign-2762

547 ：
散々中立ぶっててこの未練がましさはさすがに草
無能さをさも自分がニュートラルであると振る舞って誤魔化す手合いだな
もうちっとまともな化けの皮を被れ

548 ：
コンピュータ関係者向けの漫談ぶっこんで、盛大に白けて終わったな

549 ：
>>547
メンドクセエ奴だな。
TensorFlowは既に言ったろ。>>451
ついでにTPUも確認してみた。>>462

TensorFlow: Python,/C/Java,/Go
TPU: Python/JavaScript/C++/Java/Go/Swift、これらは公式サポート
C#/Haskell/Julia/Ruby/Rust/Scala、これらはコミュニティサポート

喜べ、C#はTPUを使える。TensorFlowSharpとTensorFlow.NETだとさ。
https://www.tensorflow.org/versions/r1.14/api_docs/

550 ：
ヤーッホーフォートランランラン
ヤーッホーフォートランランラン
て歌ってたな。
30年前だけど。

551 ：
やっぱり終わらない笑
そしてまた持論の範囲を狭めて説得力ごと削ってゆくスタイルはもはや芸人である

552 ：
ガイジの群れ

553 ：
おまえらいい加減にしないとpythonいっちゃうぞ？

554 ：
>>540
褒めていただき光栄です！

＞お前にレスするのは不本意だが、
そういわずに、私もよいコメントを出そうと常に思っていますので今後ともよろしくお願いいたします

555 ：
>>530
補足。

WPFは糞だが、これは『現在の』HTMLと比べるからであって、
WPFが登場/仕様検討された頃のHTMLと比べればましだと思うよ。
だからMSが間違ったとか技術不足ではなくて、単に、進化の速度が遅いだけ。
それはMSも分かっていて.NETもアーリーリリースに切り替えたけど、それにはお前らは不満たらたらなんだろ？
なおWebの状況は「仕様に採用された！やったぜ！」とか騒いでいたから
（数ヶ月後に）使おうと思ったら未実装で使えないとか、
或いは新規機能もバグってて使い物にならないとか、普通にある。たぶん.NETの方がまだましなんじゃないかな。
ただ、何だかんだで仕様が決まってさえすれば次第に実装はされるから、結果的な進化速度は早くなる。
おかげでWeb系は「この機能は使っていい、これは駄目」みたいな全く無駄な努力を常に強いられる糞環境なものも事実だけど。

でもこの構造だと一度抜かされたら二度と追いつけないんだよ。で、今もうそうなってると思うよ。
そしてWeb系もそんなに勤勉なわけでもないから、WPFを勉強してまでデスクトップアプリを作ろうとはしない。
それは君らがHTMLを勉強してまでWebアプリを作ろうとはしないのと同じように。
だから結果的に分断されていたわけだが、垣根はなくなりつつあるし、そこまで余裕かませる理由が分からんけどね。
C#でちゃんと『プログラミングが出来る』のなら、JavaScriptの修得自体は容易なのは事実だけど、
『.NETを知っているだけ』ならほぼゼロからやり直しだよ。
とはいえ個人的には、既に言ったがPHPerは馬鹿にされすぎてるが実はそこそこ実力はあり、
調子に乗りすぎてるのはJavaScripterで「お前らがやってるのはプログラミングではなく塗り絵だ」のレベルが多いから、
C#erが大量流入して皆殺しにして欲しいのだけど。

556 ：
ただ逆に言えば、そんな馬鹿ばっかでも何とかなってしまうのがWeb系『フレームワーク』の実力で、
それは構造的に三層WebでMVC縛りだとか、
CSSの自由度が高くてVとCもほぼ分離出来るとか、
元々GUI向きなJavaScriptを使っているとか、そういうところなんだよ。(これらは既に言ったが)
最後のところはC#を使っている限り埋まらない。
今まで規模が3倍強のJavaに飲み込まれず、むしろ善戦してること自体が驚異的ではあるのだけど、
JavaScriptとは「異種格闘技」を強いられてしまうし、HTMLフレームワークは実はPHP+JavaScriptで4倍規模だから、
それも跳ね返していけるか、となると、正直きついだろうというのが俺の予想だね。

Web系なんてC#やJavaで「ちゃんと」設計出来てる人から見たら全てゴミだけど、
そのゴミでも何とかなっているというのがミソで、
MSはちょっと技術力が高すぎて、ユーザーに精度（技術力）を求めすぎているんだよ。
フレームワークを細かく整備していけば、勿論最終的な生産性は上がるのだけど、
当たり前だがそのフレームワークについて正確に知っていること,、正しく使うこと、という精度を要求してしまう。
結果、デタラメに仕様追加され、デタラメなコードになっていたときの劣化具合が余計に激しくなってしまう。
そこはMSが想定する「常識レベル」の技術者なら上手くリファクタ出来るレベルに留めているはずなのだけど、
それが(MS自体に馬鹿が少ないから）結果的に高めになってる。
ここら辺のズレが致命傷になると思う。(要は、.NETはニワカが使うには難しすぎる）

逆にWeb系は「生き残ってる物が正義」みたいな状況になってるから、結果的にずれることがない。
PHPなんて中級者に成りたて＝とりあえず一通りは出来るようになった！
みたいな馬鹿が書いたような仕様ばかりなので、いらつくしムカつくんだけど、
当然だが、そのレベルの人達にはそれが本当に心地よいんだよ。
だからそのレベルホイホイになっているところはあって、結果的に新規参入者が絶えない。
これも広い意味で言えばPHPの実力なんだよ。
ただし言語としてはかなり最悪の部類であるのも事実だが。

557 ：
>>554
君は多分狙いすぎてるんだよ。

投稿自体の切れ味は割といいと思うんだけど、『常に』ムカつくタイミングで出てくるから、
イラッとするし、そういうことを狙っている（そういうことしかしない）のだと取られてしまう。
また、大体は議論が紛糾している時であって、
レス付けたら余計に話がおかしくなるから無視するしかない、
みたいなタイミングで『しか』出て来ないのもどうにかしろとは思うよ。
話をしたいのなら、普通に話に混ざった方がいい。
いや俺はツッコミ専門だ、話なんてする気無い、というのならそれも自由だが、それだと今後とも嫌われると思うよ。

ただ俺は君の空気を読まないスタンスは素晴らしいと思う。
そもそもここではネットならではの議論をすべきであって、それは
「ここで突っ込んだら相手の面子丸つぶれだな…でも明らかに間違いだしな…」みたいなところで躊躇する必要がまるでないことであって、
馬鹿がよくやってる罵倒合戦ではないんだよ。
君はこれは完全に出来てて議論慣れしてるところはいいと思うよ。
ただ繰り返すが、話をする気があるのなら、出てくるタイミングが酷すぎる。

558 ：
長ったらしい説明は要点がボケる傾向にある。

559 ：
もうあんたら、学歴ジャンケンでどっちが頭がいいのか決着をつけたらどうだ？
それかQiitaに行けよ

560 ：
長文連投キチガイの法則はデスノートなみに正確だということ

561 ：
今年最後にあぼーんで埋まってゆく…

562 ：
そういえば、なぜJavaScriptに初心者が魅了されるのかというと、
コンパイラがなくてもすぐに始められるために、初めて触る言語が
それであることが多く、それに慣れてしまっているからではないかと思う。

しかし、Promise(とasync)の辺りとか、イベントのキャプチャーフレーズ、
ターゲットフレーズ、バブリングフェーズの違いや preventDefault や
stopPropagation を正しく理解するのはかなり難しい。

PromiseとResponceに、ServiceWorkerと responseWith、waitUntil
などの辺りなどは、ちゃんとした仕様が書いてあるサイトを見つけるのすら
難しい。

563 ：
>>555
なぜ、HTMLアプリが増大しているかの理由については以下も参考になる。
OSとみなした場合に、WindowsやAndoridに比べてシェアが圧倒的に大きいからと考えられるそうだ：

【Wasm】ブラウザをOSとみなすとシェアはTOP
https://medaka.2ch.sc/test/read.cgi/prog/1576520355/

564 ：
>>562
それもあるが、敷居が低いのは「インタプリタがある」からだよ。PHPもこれがデカい。
C#もあるにはあるようだけど、構造的に本物と全く同一動作というわけには行かないだろうから、ここも本質的に敷居が高くなってる。
https://ufcpp.net/study/csharp/cheatsheet/apscripting/
だたまあ、ある程度慣れれば「インタプリタでのデバッグなんて効率悪すぎ」で使わないのも事実だが。
この意味だとC#やJavaはプロ仕様で、いわゆるスクリプト言語は「アマ向け」なんだけど、
国民総プログラマ時代（俺はこれには大反対だけど）には敷居が低い言語の方が向いているんだよ。

JavaScriptは以前は環境が要らない、というのが大きかったけど、
スマホだと開発者ツールがついてないから以前のようにF12を押すだけ、とは行かない。
一応C#はコンパイラはWindows同梱だし(csc.exe)、ここについては形式的には完了してる。
ただ、HTMLは見た目のインパクトが大きい。例えば、
<img src="xxxx" style="position:fixed">
だけで画像がポップアップする。これは俺には「たったこれだけ？」と衝撃だった。
同様に、他言語/環境から入ったらその簡単さに衝撃を受ける。それくらい簡単さが違う。

565 ：
Promiseは俺に言わせれば完全な糞仕様で、あれは入れるべきではなかった。
C#でasync/awaitだけで問題ないのが分かっていたのに、止めることも出来ず、
今でも「あれがないとasyncが理解出来ない(ｷﾘｯ」と嘯いて正当化してるわけだが。
JavaScriptは本当に仕様委員会自体が糞で、仕様に政治を持ち込んだりもしてる。（httpSでしか使えない新仕様とかある）
完全に自殺中だ、というのが俺の見方だ。

ただそもそもPromise自体は「非同期を無理に同期的に組む」時に必要なものであって、組み方で回避出来る。
JavaScripterは非同期を極めているつもりの奴が多いが、
JSのは上手く色々省けるようにした「なんちゃって非同期」でしかなく、（これ自体は素晴らしいことだし、大成功だが）
連中はガチの非同期を知らないから、ここら辺を何度説明しても理解出来ない。
まあいずれにしても、ヘルズバーグも「でもPromiseはねーわ」だったし、俺はC#の判断の方が断然正しいと思う。

イベントバブルについては、理解すること自体は簡単だが、
それを上手く利用した構造を作ることは「ちゃんと設計する能力」が必要になる。（そんなに難しくもないと思うが、慣れは必要）
ただ、そこを何も考えない作りの時に威力を発揮するのがjQueryであり、
要はForms同様各GUIコンポーネントにイベントを一々付けていくわけであるが、
これをやってて、そしてまた、それでも問題ない事が多いのもまた事実だよ。
なおこれはWebページのみならず、一般のGUIもそう。
だから.NETはちょっと格好いいところを目指しすぎてて敷居が上がっている、とは思う。
といってもこれはWPFでも技術的には出来ることではあるから、コミュニティ的なもの、
つまりいまだにjQueryみたいな糞を使っていても大して文句を言われない、というところの違いかも。

JavaScriptは一部から生理的に拒絶されていたりするのでelectronも直接の驚異にはならないかもしれない。
パンドラの箱が開くのは、PythonがJS並の速度を持ったときだとは思う。

566 ：
>>470
コンバーターって、ValueConverterのことだよね？
StaticResourceとして定義すれば行けるはずだけど。
xamlを貼ってみると、回答しやすいんではないかな。みんな。

567 ：
>>565
無茶苦茶だな
C#のasync/awaitはTaskがベースでpromiseとほぼ同じだ
そしてJavaScriptにもMS主導でasync/awaitが導入済み

568 ：
>>567
そりゃTaskも最早ゴミだからだよ。
実際「asyncと書いておけば、後は小さいオッサンが何とかしてくれる」程度の理解で問題ないように出来てるだろ。
C#1.0からasyncだったら神だったろうよ。
そして俺はお前らの「今はもう要らない」仕様についても崇拝を続ける姿勢を信者だと揶揄してるんだよ。

ただJavaSriptのasync/awaitはMS主導なのか？だったらPromiseにこだわるのは政治か。
JavaScriptの仕様委員会は本当にどうしようもないな。

569 ：
>>568
アホか
C#のasync/awaitがTaskのシンタックスシュガーであるのと同様に、
JavaScriptのasync/awaitもPromiseのシンタックスシュガーに他ならない
そして、あなたが敵視している「JavaScriptの仕様委員会」において仕様策定をリードしているのは紛れもなくMSであり、
あなたの敬愛するヘルスバーグもいわばJavaScriptのパイロット版ともいえるTypeScriptの開発を通じて関わっている

570 ：
古い技術より新しい技術のほうが優れてるから最初からそっちだったらいいのに、なんて言うのは誰でもできるわな
それと非同期処理はasync/awaitが覇権を握ったけど並列処理でまだまだTaskが現役だぞ

571 ：
Taskイラネって、WaitAllみたいなユースケースは頭にないんだろうな
障害児はプログラミングなんかしなくていいんだぜ
迷惑だからな
新海面処分場に自主的に向かってくれや生ゴミ

572 ：
>>566
ありがとう。いま帰省してて手元にコード書ける環境がないので、戻ったら再度やってみるよ
流石にアイフォーンでxaml書くのはしんどいす

573 ：
プログラミングしてないから、Taskが必要なケースも知らないんじゃない？

574 ：
>>569
そりゃお前のスタンスがおかしい。敵視とかそういう問題ではない。
俺はゴミをゴミだと言ってるだけ。いい仕様を制定出来てれば褒めてるよ。

逆にお前らはポジショントークしかしてないだろ。
つまりC#を使ってるから（どんな糞仕様であっても）C#は素晴らしい、でしかない。それを信者だと言ってるんだよ。
比較的C#はマシなのは事実だが、全部素晴らしいわけもない。



>>571
それもPromise擁護のお約束だが、
asyncで済む場合にほぼ全員がasyncを選択する時点でPromiseはゴミでしかないよ。
だからPromiseにはそれ以外の機能もあるもん！というわけだが、
実際Promiseが無くても書けるし、難しくもないし、必要な時もそうないだろ。
○と○をくっつけたらチョー便利！なんてのはよく初心者がやってるが、それと同レベルだよ。

575 ：
>>570
その通りだ。だから俺の方がヘルスバーグより賢いなんて言う気もないし、実際言ってもないだろ。
ただ、だからといって、古い技術の方がよかった、なんて事にもならないんだよ。
ゴミはゴミだと正しく認識するべき。

> 並列処理
元々の問題はC#が即時関数（ラムダ）を軽視してたことだろう。
とはいえC#は対応も他言語(C++/Java)と比べて早かったのも事実だが。
確かに並列に関しては今後とも残るかもしれん。

ただC#がTaskを用意したのは「UIコンポーネントはUIスレッドで」という.NETフレームワークの思想の為であり、
俺はこれがそもそも疑問なんだがな。GUIはタスクランチャーだと割り切り、
・GUIからの呼び出しは「新規スレッド」か「UIスレッド」か選べるようにする。
・UIコンポーネントはどのスレッドからでもいじれるようにする。
・そこで競合するなら自前で同期化機構を書け
でよかったと思うし、実際これで当初「Task素晴らしい！」みたいなことを言われていたのは大体解決出来るだろ。
要は「重いジョブ」「そのGUI出力」を同じ関数内に記述したいけど、それは「.NETフレームワーク的には出来ない」だけであって、
自分でおかしな縛りを導入して、それに対する解を用意してって、マッチポンプでしかないだろ。

ただまあ、馬鹿が多いようなので無駄に噛みつかれないようにもう一度言っておくと、
確かに並列用途にはTaskは残るかもしれんね。
だからといってPromiseがいいって事にもならんが。

576 ：
高卒の天才みたいな人はいらないよ

577 ：
C＃ならではのアプリよろしく。

578 ：
もしかして「シンタックスシュガー」が理解できてないとか。

579 ：
> ・UIコンポーネントはどのスレッドからでもいじれるようにする。
この時点でマルチスレッドプログラミングまともにしたことない感が…

580 ：
>>575
＞・UIコンポーネントはどのスレッドからでもいじれるようにする。
それは土台無理というものですよ…

581 ：
別にUIコンポーネントのためにTaskを用意したわけではないが

582 ：
Task登場前に比べれば段違いで楽になったわけやしな

その後直ぐにasync出たのも時代的に仕方なかったわけで

583 ：
俺がasync/awaitを使うとだいたいハングアップするんだけど
みんなどういう場面で使ってるの？

584 ：
>>579,580
だからそれが俺には謎なんだよ。やれば出来る範囲としか思えない。
実際、お前らが今バインディングしている先も、一々排他チェックなんてしてないだろ。
そもそもGUIではレーシング時には「前の値」でも「後の値」でもどっちでもいいケースでほぼ全部で、
問題のあるところだけmutex等の遅い同期化機構でも全く問題ないんだよ。

MSはGUIがプチフリするのが許せなくて、30秒以上（だったかな？）のジョブをUIスレッドでやったら警告を出し、
他スレに強制移転させたわけだが、その時に仕様的にはそのままGUI出力出来なかったというのが元の問題だろ。
しかし button_onClickに最初から他スレで問題ないし、
そもそもお前らみたいに「DIコンテナが正義」ならどうせStringBuilder/TextBox等に直書きなんてあり得ないのだから、
必要ならDIコンテナ先で排他/同期で全く問題ないし、これの方が実際生産性も高いだろ。

ただこれは俺にとってはかねてからの疑問で、これを2chで言うのも初めてではない。
他言語、例えばJavaScriptも形式は違うが一応「UIはシングルスレッド」になっているので、何かあったのだとは思う。
色々聞いた限り、Javaで昔マルチスレッドなGUIがあって、盛大にそこでやらかしたから、
それ以降はシングルスレッドなのだ、との説を聞いたのだけど、これについて知っている奴はいるか？
ただそれにしても、その時はマルチスレッドにみんな慣れていなかったからであって、今なら普通にこなせるとも思うが。

>>581
ではなんだよ？
並列処理、というのは後付だと思うが。

585 ：
>>584
マルチスレッドとマルチスレッド以外のあらゆる非同期、並列処理を統一的に扱うための抽象化だよ
歴史的な経緯で非同期、並列処理のやり方がマチマチでわかりにくかったからTaskにまとめた
これにより雑魚プログラマでも簡単に安全にイイカンジに最適化された非同期、並列処理を実装できるようになった
さらに統一的な抽象を得たことによって言語レベルでasync awaitを導入する基礎ができた
UIスレッドなんてのはオマケもいいとこだ

586 ：
>>584
mutexを緻密にやればrace conditionが発生するし、
雑にやればパフォーマンスの低下を引き起こすと思うけど
UIの実装なんてあんまり真剣に考えたくないところなんだから、
別スレッドからUIスレッドへ実行すべきブロックをキューに追加するぐらいが丁度いいと思うが。
逆に、「やれば出来る範囲」と言うけど、実際にUIスレッドをスレッドセーフにしてまともなGUIフレームワークになっているものってあるの？

587 ：
すまん、race conditionではなくデッドロックだ

588 ：
マルチスレッドに分散処理させてた結果を最終的に本体スレッドで受け取る時に、queueで待機させて結局同期的にDBに書き込んでるんだけど、意味あるのかな？

589 ：
>>588
その分散処理とやらがボトルネックになっているなら意味があるかもしれない
多くの場合はDBの方がボトルネックになるから、DBへの書き込みをバッチ化するとかの方が遥かに効果がある

590 ：
>>585
俺はそうは思わんね。

> あらゆる非同期、並列処理を統一的に扱うための抽象化
これは単なる「関数」で超大昔に終わってる。
つまり、非同期でも、並列でも、エントリポイントは「関数」であり、つまり渡す物も「関数」であり、
その上の階層で非同期か並列かを選べるのだから、「関数」で抽象化は完成してる。
実際、ちゃんと組んであれば、内部の関数はマルチスレッド/シングルスレッド/同期/非同期のどれで用いるにしても、
一字も変更する必要がなく、変更されるのは最上位での呼び出し方だけだろ。
これが「抽象化」が「関数」で完全に済んでいる証拠。
（というよりは、こうなる為のお作法として「グローバル禁止」等があるわけだが）

async/Taskがいいのは「その場に書ける」「戻り値を取れる」からであり、
抽象化してるとするなら、「同期」と「非同期」を抽象化してる。
（ただしキーワードが必要なので厳密には抽象化出来ているわけではないが）
だから、簡単で直感的な「同期」記述とほぼ同じ記述で「非同期」が出来るから美味しいだけであって、
それ以上でもそれ以下でもない。
そしてC#に非同期が必須みたいになったのはフレームワークの仕様の問題であり、これは回避出来たと思ってる。

591 ：
>>590
GUIなんて「グローバル変数」の典型例だと思うけど、
設計モチベーションの一つとして、GUIを便利に書く言語となってほしいってのがおそらく合ったと思うけおd、
それでも「回避できた」可能性はあるの？

592 ：
>>586
> UIの実装なんてあんまり真剣に考えたくないところなんだから、
これはその通りだ。

> 別スレッドからUIスレッドへ実行すべきブロックをキューに追加するぐらいが丁度いいと思うが。
そしてこれがInvokeというわけか？
まあ.NET的にはそうなのかもしれん。

> 実際にUIスレッドをスレッドセーフにしてまともなGUIフレームワークになっているものってあるの？
知らん。だから聞いている。
無いのは、無い理由があるとは思うのだけど。(そしてそれが、昔Javaで…だと聞いているだけ)

593 ：
JavaScriptのPromiseが難しいのは、then のブロック内の最後の行で実行した関数の戻り値が勝手に次のプロミスにチェーンしていくみたいなところ。
ここが難しいのは、JavaScriptには明確な型が無いので公式サイトのサンプルを見ても、関数の戻り値がどんな内容（型）のデータを返しているのか分かりにくいところ。
それぞれの関数のドキュメントを調べてもそれが結局分からない。
同じ関数でも時と場合によって返すデータの型(?)が変わってしまうようなケースすらあるかも知れないし。
いまのところまだ理解できないのは、fetch でResponseオブジェクトを返すような処理。
ドキュメントの説明で、関数のプロトタイプ宣言の様な部分でも型がちゃんと書いてないので理解が難しい。

594 ：
>>593
みなさん、これをすらすらと理解できますでしょうか？
自分はなかなか理解できません。
https://developer.mozilla.org/ja/docs/Web/API/Fetch_API/Using_Fetch#Response_objects

595 ：
>>591
回避出来たも何も、それ以前にする必要がないんだよ、割と。

例えば>>255,261、画面のGUIコンポーネントを直接参照して動作時は画面ロックの方がよかった、というわけだが、
実際これでも「自家用アプリに簡単にGUIを付けたいだけ」なら全く問題ない。
そして、演算実行中は放置だから、他スレッドとも競合なんてしないんだよ。

格好良くいえば、「運用で回避する」ということになる。
勿論プログラムとしては色々ヤバイが、必要なら真面目に同期取ればいいだけ。
手抜きなら「動作中は触るな」で十分、というわけだ。
クラッシュするのは例えばログ出力用TextBoxに複数から同時に書き込まれた時だが、
そもそもそれは複数出力元がある=複数の計算ルーチンが同時に起動する事が必要で、
全くのGUI初心者が最初に組むアプリではないんだよ。

それを非同期で別スレ起動してInvokeしろとか、かなり敷居を上げてしまってるだろ。
（もっとも、警告を無視してUIスレッドで計算して、当然GUIはフリーズ、みたいなことも出来たが）

596 ：
>>590
超大昔に終わってないから出来損ないのインターフェイスや実装がポンポン出てきて混乱したんだよ
でマイクロソフトが主導してC#における標準的な抽象としてTaskを導入した
プログラマはみんなそれを受け入れてTaskを使うようになった

597 ：
>>594
追記：
thenブロック内部の関数の戻り値が Response「型」の場合でも、
直後のthenブロック内部の関数の引数が必ずしもResponse「型」ではないこともあるようで、その場合は、型の「自動変換」が行われているのではないかと思えるんです。
C++の場合だとプロトタイプ宣言などの関数宣言があるのでそれが分かり易いのですが、JavaScriptだと本当に型変換が行われているかどうかも不明確で理解が難しくなっています。
仮引数の型に可能性の幅が出てくる可能性があり、結局どのような「型」になっているか分からないので、どのクラス(?)のドキュメントを読んでいいのかも分からないので理解に時間が掛かります。
候補となりそうなクラスや関数の解説文を手当たり次第に読んでみて辻褄の合うようなものを自分なりに見つけてこないといけないようです。
C/C++ではなかった苦労がそこにあります。

598 ：
>>594
https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch#Return_value
↑fetchの仕様を見れば戻り値は
「A Promise that resolves to a Response object」と明記されてるよ
MDNも日本語訳は内容が古いからまずは英語で見たほうがいい

const response = await fetch(…);

599 ：
>>597
>直後のthenブロック内部の関数の引数が必ずしもResponse「型」ではないこともあるようで
んんん？？

thenは2つコールバック関数を引数にとって
一つはresolveした場合、もう一つはrejectされた場合。
fetchが返すpromiseがresolveした場合は必ずResponseオブジェクトじゃないの？

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/then

600 ：
>>584
＞Javaで昔マルチスレッドなGUIがあって、盛大にそこでやらかしたから、
Java ライブラリの GUI（基本は awt） ってそんなんだったかな…近々 awt を頭から見直そうと思っていますのでそのときに考えて見ます

601 ：
javaのフィールドに倣ってプロパティの接頭語にアンダースコアを付けるべきか悩んでいるのですがベテランの皆様はどう思われますか？

602 ：
好きにすればいいよ
どっちでも文法的に正しいし、どっちがより良いかは証明不可能

603 ：
>>601
それはハンガリアン（の一種）といって悪い作法だと思います

604 ：
>>598
A Promise that resolves to a Response object.
この言い回しが分かりにくて
「Responseオブジェクトを解決するところの1つのPromise」
とはコードで書くとどういうPromiseの事を言っているのか分かりません。

605 ：
>>604
リンク先にあった、以下のコードを見ればどういうことなのかは大体理解はできそうですが。
「Xを解決するところの1つのPromise」
というものの正確な定義はどこにあるのでしょうか。

let myRequest = new Request('flowers.jpg');
fetch(myRequest)
.then(function(response) {
if (!response.ok) {
throw new Error('HTTP error, status = ' + response.status);
}
return response.blob();
})

606 ：
>>596
FrameworkOnFrameworkが日常的になっている時点で、
機能的に足りない＝そのFrameworkが糞、なのは明らかだろ。


>>600
AWS等について確認したが、どうやら
> スレッドとAWT/Swing
> https://www.ibm.com/developerworks/jp/java/library/j-thread/index.html
> https://www.ibm.com/developerworks/jp/java/library/j-king/
・AWSは多分何のプロテクションもない
・SwingはinvokeLater()とinvokeAndWait()(多分BeginInvokeとInvoke相当）が用意されている
・これらで手こずったので、.NETは最初から「UIスレッド縛り」を付けた
ように見える。結果的には妥当な判断なのかもしれん。
(AWSやSwingは俺が569で言った構成に《.NETよりは》近い）

607 ：
これらやその他の記事を読む限り、
Javaはどうもマルチスレッド周りの問題をまともに解決しに行ったように見える。
時代的に「最先端言語」としての矜持があったのかもしれん。
結果、爆死して今に至るのかも。
例によってデッドロック周りがやたら記述されているが、これに関しては、
折角ポインタを廃止して消し去った、「悪いプログラム片が少し混入しただけでアプリ全体がアウト」
になるCの問題点がそのまま復活してしまうから、Javaとしては絶対に許せない。
かといって、上手い解決策も見つけられてない。

ただ、デッドロックは多分今の若者が教育されているほどには驚異にはならない。
あれはアホみたいに「一つ確保して、その場ですぐ返す」構造にすればそもそも回避出来る。
つまりロック周り自体ではなくて、その上位構造から単純化してしまって解決する方がいいのだけど、
それをしようとはしていない。
逆にそれをしたのが.NETで、言うなれば全部のUIコンポーネントで一つのmutex、
それをUIスレッドが握りつぶす（他に渡さない）から他が触れず、Invokeするしかなくなる。
OOP初心者が訳の分からないクラス構成にすることはよくあるが、同様に、
Javaでマルチスレッド初心者が訳の分からないロック機構（しかもバグってる）を作りまくったのかもしれん。
.NETはそれよりは、仕様的に回りくどい構造になるがアホでも組める方を選んだのだろう。
とはいえそれもFrameworkOnFrameworkしたくなってしまうほど糞で、実際それをやらかし、
Task/asyncで収まった、というのが現在か。(話を総合すると）

歴史の流れとしては極めて妥当なのかもしれん。

608 ：
>>606
君いわく超大昔にとっくに解決したはずのものが現実には多くの糞を生んだ
しかし新たに設けた抽象化であるTaskがそれれらの大部分を解決したということだな
君の言う関数という抽象化は非同期処理の現実には大して役に立たなかった
事実は事実として受け止めたほうがいいよ

609 ：
>>608
まあ俺のスタンスは変わらんけどな。一応纏めておくと、以下。
・Taskはゴミ。今となっては（非同期には）要らない。
・asyncは「抽象化」ではなく非同期の「記法」。
・asyncにより非同期の煩雑さは解決された。

簡単に記述出来る「記法」が足りなかったのに、非同期強制部分が.NETにあった為に多くの糞を生んだ。
元々はラムダや匿名関数周りが弱かったからであり、これらが最初からあればもうだいぶましだった。
実際、JavaScriptのイベントモデルだと、Taskなんて無くてもC#程酷いことにはならない。
そう出来なかったのはC#の問題であり、（といっても既に解決済みだが）
逆にWeb系は馬鹿でも出来るようになっているからこそ馬鹿が調子こいてる。（簡単なこと自体は素晴らしいことだが）

君がこれらを認めないのは君の自由。

610 ：
多くのケースでasyncawaitでコーディングしたほうが簡単だがTaskが要らないわけではない
並列処理では相変わらずTaskが活躍している
またasyncawaitを実装するためにはTaskという抽象が必要だった
関数で抽象は完結してるなどとトンチンカンなことを主張して思考停止していたらasyncawaitの発明には到達できなかった

611 ：
並列処理はうまく書けないからasync/awaitは中途半端な糞！にならないのが不思議だなあ
てかこのひと年末からずっと何かにつけて「ほにゃららは糞！おまえらは信者！」から入るのに
ひたすら教えられてるだけなのが面白いね

612 ：
>>604
スレチな気もするが一応回答しとく

Promiseってのは処理が終わってるかもしれないし
まだ終わってないかもしれないという文脈付きで値を運ぶ入れ物
処理が終わってる場合は、成功してるケースもあれば失敗してるケースもある

つまり下記3つのうちいずれか1つの状態にある
1. Pending:まだ終わってない/結果待ち
2. Fulfilled: 成功で処理完了済み(=Resolved)
3. Rejected: 失敗で処理完了済み

「戻り値が A Promise that resolves to a Response object」というのは
戻り値はPromise(=文脈付きで値を運ぶ入れ物)で
成功で処理が完了済みの状態になった場合
入れ物の中身は「a Response object」になるPromiseですよって意味

613 ：
>>605
>.then(function(response) {

.thenの第一引数はresolveした場合のコールバック関数で
そのコールバック関数に渡される引数が
Promiseが成功で処理完了済み状態になった場合に入れ物の中に格納してる値

fetchの場合はそれが「a Response object」
function(response){…}というコールバック関数の引数(response)に
Promiseという入れ物に格納されたa Response objectが入る

https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Promise/then

614 ：
>>611
そうとしか取れないのはお前が馬鹿な信者だからだ。
俺はそもそもasyncが悪いなんて言う気もない。いい物はいいと認めるだけ。
お前みたいな馬鹿信者は俺という『人』を全否定したいから、全部否定するとか、
お前みたいな馬鹿でも明らかに分かるほど間違った態度を取ってくれないと困るようだが。

> 並列処理
そりゃ重要度が違うからな。実際、お前ら並列処理なんて書いてないだろ。
スパコンのこと何にも知らないようだし。（これ自体はC#的には問題ないが）
C#/.NETが扱うのは、そもそも並列が効くような案件でもないし。
対して非同期は.NET的には日常的に必要な物になってしまってるだろ。

ただまあ、お前らがTaskにこだわるのなら、第一級関数ってのも意味があるのかもね。
Task自体はラムダをオブジェクト化したようなものであり、関数型で言う第一級関数的なものだ。
JavaScriptならFunctionにメソッド生やして全部Task的にすることも可能だ。（やったら別の意味で殺されるはずだが）
俺には第一級関数の有り難み自体はよく分からないのだけど。

615 ：
> C#/.NETが扱うのは、そもそも並列が効くような案件でもないし。

やっぱり使ったことない人だったか

616 ：
通信やファイル等々は並列化前提くらい当たり前に使う部分
そもそもまともに開発したことないんでしょ、彼は

617 ：
>>614
> 馬鹿でも明らかに分かるほど間違った態度を取ってくれないと困るようだが。
馬鹿がasyncマンセーTaskは糞なんて明らかに分かるほど間違った態度を取ってるから別に困って無いよ？

> そりゃ重要度が違うからな。実際、お前ら並列処理なんて書いてないだろ。
まあ日常的に並列処理を書いて無いならasync信者になるのも止む無しだね
粒度の粗いAPIを呼び出しているだけで済むプログラマ人生なのが良くわかる
まさに「馬鹿でも出来るようになっているからこそ馬鹿が調子こいてる。」

618 ：
並列実行をHPC系の計算でしか使わないと思ってるのかなあ
スマホゲームにだって使われている、カジュアルに使えなくちゃ今時大変な機能だと思うけど

619 ：
c#の並列処理ってコントロールが糞だから仕方なくって場面ばっかりだけどね

そもそも並列処理って実現方法に2つあって
並列で動く2つの処理を
処理Aと処理Bとしたときに

[方法1]
言語の並列機構に任せて
処理Aと処理Bをそれぞれ独立で実行する
もちろん処理過程や処理結果も表示通知する機能が存在する

[方法2]
処理Aと処理Bをブツ切りにした
処理A1~N、処理B1~Nをループで

処理A1
処理B1
表示
処理A2
処理B2
表示
・
・
・

という具合で実行

色々触ってきたけど[方法1]で
実行できた言語って一度もネーな（笑）

620 ：
そうだね、パソコンがなんでもやってくれると君みたいな頭でもプログラムが書けるね

621 ：
とりあえず並列処理と並行処理は区別しよう

622 ：
>>616
既に突っ込まれてはいるが、それは一応「並列(Parallelism)」ではなく、「平行(Concurrency)」という。
が、まあ、これはさておき、君の使い方はやはり平行でなく非同期(Asynchronous)だと思うよ。
実際、例えば、「asyncブロック」というのが次に来たとして、仕様は、
・これまでの記述の複数のasync文を　async { } で囲うことが出来ます。
・asyncブロック内のasync文は同時にディスパッチされます。
・全てのasync文が完了次第、asyncブロックを抜けます。
という、async { } で囲うだけ！簡単！楽チン！な物が提供されたら、
今お前らが使っているであろうTask<TResult>は不要になるだろ。

ディスパッチャを自前で書く気がなければTaskは基本的に要らないと思うけど。
本来「平行」の場合は表ジョブと裏ジョブの同期は割と厳密に取る。
手が空き次第捌け、順番はどうでもいい、は非同期の使い方で、大概はほぼこれだろ。

623 ：
×　平行
○　並行

624 ：
>>616
>>622
と思ったんだが訂正。
確かに今の仕様のasyncだとまだTaskは廃棄出来ないかも。
現在は明示的に発行と結果回収を別の行に書いてるんだな。それでawaitで引っかけてると。
俺はこれ、遅延評価で勝手に引っかかってるだけだと勘違いしてたわ。
すまんね。

625 ：
やっぱり使ったことない人だったか

626 ：
通信やファイル処理はCPUとは別のデバイスが同時に処理するから並列処理
ネットワークやディスクにアクセス中にスレッド消費されたら使い物にならん

627 ：
誤った指摘をしている人がいますが、>>616は、相当ミスらない限り並列処理かつ非同期処理です
並行処理である保証は全くありません

628 ：
並列は、CPU に使う用語

並行は、処理に使う用語

629 ：
こんだけ暴れておいてこの結末ｗ

630 ：
>>626,627
ファイルや通信のI/O処理中にCPUでは別の処理をするってのは
典型的な並行処理の例で一般的には並列処理とは呼ばないぞ

ファイルがパーティション分割されてて
100パーティション同時に書き込みを行うような処理なら並列処理

基礎的なことなのでもうちょい勉強してくれ

631 ：
>>630
>>627は冗談で言ってるんだとは思いますし、何が一般的かは知りませんが、私はこの並行処理の記述に従って理解しています
https://docs.microsoft.com/en-us/dotnet/standard/parallel-programming/
なお、私の知る限りでは他分野でも同じです

632 ：
>>630
並行処理ってのは、単一の主体が短いタイムスパンで複数の処理を切り替えて処理することによって、まるで並列処理をしているように見せかける技術のことな
言うまでもないが、並列処理は複数の主体が、見せかけじゃなく同時に別の処理をしてる場合な

例えばこうだ
var t1 = CalcSomething();
var t2 = DownloadFile();
var t3 = ReadFile();

1つの物理装置が、少しCPU処理→少しファイル処理→少しネットワーク処理、と繰り返して3つの処理を同時に処理してるように見せてるなら並行処理だ

でも実際には、別々の物理装置によって計算、ネットワークアクセス、ファイルアクセスを同時に処理するので、これは並行処理ではなく並列処理だ

基本的なことなので、勉強してくれまじで

633 ：
C#で並列処理を勉強しようとしたら大抵初めに出てくるParallel.Forすら知らないんでしょ
だから英単語出してきてまでそれは平行だ！とか指摘しちゃう
英単語わかってるなら並列だってわかるはずのにｗ

もう以前からびっくりするくらい知識が浅い

634 ：
あとマルチproccessとマルチthreadも同じやね
using System.Threadingも書いたことなんだろう

C#に無知でこれらを知らないは別に良いけど一般的なソフトウェア開発で並列処理なんて書かないとかいう指摘も的外れ
C#に関することに無知なのは触ってなけりゃ普通のことだろうけど今や当たり前に行われる並列処理をスパコンのものでお前らにはわからんだろうな、とか言っちゃうのは技術者としてどうかと思う

635 ：
プログラム内の厳密な並列ってなくね？
おそらく無理じゃね
同じメモリ空間をCPUが同時にアクセスできないよね？
paralle.forとか俺はこんないい加減な前準備でできると思ってないけどね
どういう仕組みか知らんけどｗ
多分なんちゃってだろ
やった感じ直列で処理したほうが早い感じになってうんこだったよ
ちなみにフルHDの画像処理を上から三等分にしてparalle.forでやってみたがクソ遅い上に並列にやってない気がしたけど
みんなはこんなもん使えてるの？

ところでスレッドってスレッドスイッチするし積まれたタスクを順番に処理してるだけだよな？
その切替タイミングはプログラム内のsleepやDoEventsだよね？

636 ：
変なの増えた

637 ：
>>635
> その切替タイミングはプログラム内のsleepやDoEventsだよね？
いつの時代の老害だよ…

638 ：
>>635
パイプラインとかキャッシュとかレジスタとかマルチスレッドとか、CPUの技術を少しは勉強したほうがいい

639 ：
>>637
え？じゃあどこ？

640 ：
>>638
それを実際に言語の機能に適用してるかどうかは別だよね？

なんか超遅かったよ
もし並列に動いてるなら画像処理は単純に三分の一で終わったはずだよね？
ところがむしろ3倍以上かかってるんだな
なんか前準備に色々条件があるのか？
こんなもん役に立たないのか？
該当する処理が本当に適用できるのかはチェックが必要だと思うな

641 ：
スレッド切り替えと言うが、今日日マルチコアだぞ。
Parallel.Forも一つだけど、PLINQなんかも実は色々効いてくる。
まあ、Taskは便利よ。
スレッドプールを有効利用するのは手でやると事故るので、Taskに任せるほうがよかろう。
その上でUIスレッドに返したければUIスレッドに返すコード書けば良いだけなんだし。
逆に言うと、UIスレッドからTaskをawaitしたときに元のスレッドに戻って来てる事自体が例外的な処理に近い。

642 ：
parallelにしてもちゃんと理解してないと遅くなることだってありうるよ
並列化できない処理をparallelしたって切り替え処理とかが無駄に働いて逆に遅くなることもある

コードでも上げてみりゃどこが間違ってるか指摘できる人もいるんじゃない？

643 ：
>>642
コードを見ないとわからない？
IDEが教えてくれる？
なんにせよ使えないよそんなの

644 ：
>>641
それ並列でやった処理結果まとめられないじゃん
やりにくいし

結局処理単位は自分でブツ切りにしないと途中経過出力できないし
実質この手の機能ってc++の頃から別に便利でもなんでもないゴミクズ機能で停滞してるよね？

645 ：
>>639
プリエンプティブ でググってこい

646 ：
>>643
いや、あんたが何かを勘違いしてるかもしれないことをコードレビューしてあげようかって言ってあげてんのｗ
詳細な実装は開示しないけど俺が試したら遅くなった！parallelなんかまともに使えない！って主張なの？
世界中のプログラマが有益に利用してるんだから間違って利用しちゃってるなら正せばいいだけじゃん
ググりゃ腐るほど日本語でも記事はヒットするんだし

647 ：
3分割したら3倍異常遅くなるって例えば各スレッドでファイルを読み込んでるだけじゃねーの？
そんなやり方したらそりゃ遅くなるよね

648 ：
>>646
フルHD画像処理を上から三等分でparalle.forって言ってんだからやって動くサンプル出してこいよ
おそらくdobon辺りに貼るだけでparalle.forかけて画像処理ループさせるだけだ
10分だぞ
やりたきゃ頑張れ

649 ：
GAIJI vs GAIJI

650 ：
ヤベエ逸材多過ぎだろこのスレｗ
今までどこに潜んでたんだコイツら

651 ：
>>644
纏められるよ。
PLINQ使ってみ。
途中経過が必要ってこと自体、多分並列化出来てないから考え方がおかしいよ。
並列にやってるんだから途中経過なんて足し込まないと出せない事はやるべきじゃないでしょ。
足しこみは並列にできないんだから、そこで足並み揃えちゃったらそりゃ並列に動かんよ。

652 ：
まあとりあえず、「並列」「並行」については最近は混同されてるし、実際混同しても問題ない領域が多いし、
文系馬鹿C#erが主流なこのスレでその厳密性を求める意味はない。
ただまあ、ファイルとCPUでは速度差がありすぎるから、
まともなスケジューラーなら並列に書いてても並行になってしまうとも思うが。
しかしMSはそこも含めて隠蔽しようって事なんだろ。これ自体はいい。

> Parallel.For
これはちょっと筋が悪い。現在の主流はMap/Reduceなんだから、そっちに合わせた方がよかった。
お前らが速くなるならないでグダグダ言っているのも、結局はこれで、Map/Reduceが効く場合は速くなり、
そうでない場合は速くならず、場合によっては遅くなる、というだけ。別に不思議なことではない。

ただまあ、君らも分かっているとおり、レンダリングの場合は分割は効果があるから、
・書き方が悪い
・今はそこまでParallel.Forの出来がよくない
のどちらかで、まあそれを揉めているわけだが、今の状況はさておき、
最終的にはこのコードで簡単楽チンに数倍速を得よう、ってのは間違ってはいない。

問題はやはりMap/Reduceでないことで、結局、「関数」で処理を抽象化出来ているから
関数を直接扱う「関数型」の方がI/Fは綺麗に並んでしまう。
そこをForにこだわったのは間違いだと思うよ。

653 ：
とりまコード見ないとなんとも
なんかで排他制御でも効いてるんだろうけど

654 ：
>>631
そのリンク先に並行処理についての記述は一切無いぞ

>>632
並行処理をせまく理解しすぎ
並行処理と並列処理は観点の違う概念であって相互排他的なわけではない

並行処理はある瞬間を切り取ると”必ずしも”同時に複数の処理が実行されているわけではないだけで同時に実行されてる場合もある

君の例は1つの物理装置で処理されてようが別々の物理装置によって同時に処理されてようが関係なく並行処理(Concurrent Processing)の例
それを並列処理とは呼ばない

655 ：
そもそもawait/asyncは、非同期処理を同期処理のようにかける仕組みであって
マルチタスクそのものじゃなくて周辺技術だよな

656 ：
>>654
いや、そっちが理解間違ってるよ

並列処理は複数の装置で複数の処理を同時に実行すること

並行処理は単一の装置に複数の処理をスケジューリングして、順番に実行することによって巨視的に並列処理のように見せかけること

複数の装置にスケジューリングすることを並行処理と呼んでる場合もあるが、それは正確には並列処理と並列処理のハイブリッドだな
君が言ってる同時に処理される場合もある、というのはこのことだろうな

657 ：
>>656
どっちが正しいと断言するつもりはないけど、この並列処理と並行処理の定義はどこから持ってきたものなの？

658 ：
>>652
自動的に適切な単位に分割されたMapとReduceがPLINQで実現できると思うんだが。

659 ：
>>657
放置しときなよ
用語知ってる俺スゲー君同士の戦いなんてどうでもいいし

660 ：
この年末からのつまんねえ言葉遊びの流れほんとクソ

661 ：
装置どうこうで並列や並行いってるやつらは
まずマルチコアなCPUを装置としてどう見てるのか書け
話はそれからだ

662 ：
>>658
実際効果が出ているのならそれでいいと思うよ。
MapかForについては、どっちから攻めるかの違いだけではあるから。

ただ、分割をC#側が担うのは明らかに間違ってるでしょ。
DBならSQL投げてその先はDB側で動的に何とかしろ、が正しく、
当たり前だがDBの構成なんてC#コーディング時に関知しようもないし。

といってもMSがこの辺を知らなかったはずもない。
何か作戦があるんだとは思うよ。

PLINQについては確かに「並列」だが、なかなかな事を書いている。
> 既定では、PLINQ はホスト コンピューター上のすべてのプロセッサを使用します。
> https://docs.microsoft.com/ja-jp/dotnet/standard/parallel-programming/introduction-to-plinq
> 結果の順序は毎回異なることがあります。
> この動作は、オペレーティング システムによるスレッドのスケジュール方法に依存するため、アプリケーションでは制御できません。
> https://docs.microsoft.com/ja-jp/dotnet/standard/parallel-programming/order-preservation-in-plinq
これはMSが悪いわけではなくて、当然そうにしかならないのだけど、
当たり前だがPLINQに丸投げすれば全てよし、みたいなものではない。（ただ、そこを目指してはいるのは正しい）
まずは書けないと話にならないので、MSとしてはプログラミングモデルを提供してきた、というところか。

663 ：
asyncも、ググれば分かると思うが、実はasync/awaitの片方はキーワードとしては要らない。
その場合には実行/フェンスについて、実行は今まで通り記述した時点で開始、
フェンスは結果を使うところで暗黙的に、ということになる。（つまり今ならawaitが要らない）
これはこの界隈ではすごく一般的な考え方で、
例えばアセンブラでDIVやSQRT命令みたいにレイテンシが長い命令を配置したとき、
結果レジスタを使わない場合はどんどん流し、結果レジスタを使う場合だけそこで一旦停止して結果待ち、という事を30年前からやっている。
だから「非同期」というよりは「並列化＋パイプライン(可変長レイテンシ）」として考える方がいいのかもしれないけど、
いずれにしても今は「明示的にawaitを書く」というある意味MSらしくない、
どちらかというとWeb系的ドベタ仕様で、だからこそ君らもTaskマンセーな訳だが、
こう説明されれば「あ、確かにawaitいらねえな」とはすぐに分かるだろ。
多分君らが非同期にだいぶ慣れた頃にawaitは廃止されると思うよ。
そして「非同期」と「同期」は一文字も変わらない同じ関数で実行可能となり、完全な抽象化が実現出来ることになる。

ただし、今の仕様が悪いか、と言われれば、必ずしもそうでもない。
俺がさんざん言っているとおり、MSは若干エレガントなところを狙いすぎていて、
ライト層がちょっと置いてきぼりになってる感がある。（Web系に比べて）
そしてさんざん君らがTaskマンセーしているとおり、ベタな仕様には分かりやすいという大きな利点がある。

ただそれにしても、繰り返すが、CPUのパイプライン構造を知っていれば、あ、確かに間抜けな仕様だな、とはすぐに分かるだろ。
俺が信者だと揶揄しているのはそこら辺であってさ。

664 ：
別スレ立てたら?

665 ：
もしかしたら伝わらないか？とも思うので一応。
俺はawaitを廃止して、以下の
> 次に、ベーコンと卵の await ステートメントを、メソッドの最後の朝食提供前に移動します。
> https://docs.microsoft.com/ja-jp/dotnet/csharp/programming-guide/concepts/async/index
の下のコードを以下に出来る、といっている。

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

Console.WriteLine("eggs are ready");
Console.WriteLine("bacon is ready");
Console.WriteLine("Breakfast is ready!");

まあみりゃ分かるとおり、await文部分を前に持っていっただけではあるが。
今の仕様だと、この書き方では肝心の非同期部分が1つずつステップ実行されてしまう、という事になっている。

666 ：
>>665
そのコードじゃ非同期処理が完了してなくても"～ are ready"って表示されるだろ。

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

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

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

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

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

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

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

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

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

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

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

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は非同期ではなく遅延評価)

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

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

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!");

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

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

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

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

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

679 ：
>>676
ああ、だから俺は、違いは

同期：
var eggs = FryEggsAsync(2);

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

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

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

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

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

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

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

684 ：
>>681
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 付ける、ってのは全くナンセンスだよ。
非同期は、今後は、今のお前らが思っているほどは特別なものではなくなるんだよ。これはもう確定してるだろ。

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

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

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

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

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

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

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

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

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

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

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

689 ：
awaitは必要だぞ

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

700 ：
>>699
guiのイベントでawaitじゃあかんの？

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

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

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

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

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

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

704 ：
>>701
なんだ… それなら

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

725 ：
>>721
TcpListener/TcpClientでSocketをそのまま使うかWCFかな

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

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

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

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

ruby -run -e httpd . -p 8080

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

http://localhost:8080

728 ：
IIS Expressは?

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

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

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

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

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

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

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

736 ：
そんな変わらんから

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

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

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

740 ：
市場も飽和しきってMSも他人にサードパティ製品で儲けさせず、自分んとこで出すために今後、ころころ変えていきそうだな。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

751 ：
>>750
ありがとうございます。

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

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

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

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

755 ：
なんだと…ｺﾞｺﾞｺﾞｺﾞ

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

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

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

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

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

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

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

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

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

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

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

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

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

768 ：
馬鹿の一つ覚え

769 ：
>>761
すまん、ジジイなんで勉強したいからソース教えてほしい

770 ：
>>764
linqとforeach、forだと処理効率かなり違う
だからといってlinqで書けるものをforで書く程ではないが

771 ：
可読性より性能重視でfor使いまくることあるです

772 ：
性能が必要なら言語かえますし

773 ：
アセンブラ最速（要最適化）

774 ：
レベル高いのはlinqやforをちゃんと使い分けれる人
レベルが低い人はどちらかしか使わない人

775 ：
Linqってnullがあった時面倒な印象がある
実装当時はselectみたいな予約語を中途半端に実装したってどっかで見た記憶があるけど増えたのかね？

776 ：
もちろんLINQでもforでも書けるけど、LINQで遅そうな処理で、それが作っている
ソフトの決定的なパフォーマンス問題につながりそうなら、forで書いてみて
ベンチマークしてどっちを採用するか決めるかな。
forの方がありとあらゆる言語で書ける書き方だから当然書けるけど、
LINQの方はPythonの内包表記やmap/filter/reduceの書き方に近くいから
こっちも当然書けるし、短いし一時変数用意しなくていいから基本LINQ使っちゃうよね。

777 ：
forでないと書けないってコードが汚いだけの場合が殆どだからまずそっちをリファクタリングする
すると自然とLINQで書けるようになる
LINQで遅いのは件数が多すぎるかキャッシュを使ってない場合なので実はforに変えただけじゃたかが知れてる

778 ：
あまり大したことに使ってなさそう

779 ：
＞　forでないと書けないってコードが汚いだけの場合が殆ど
そうは思わないけどｗ

780 ：
>>776
これも一見もっともそうなことを書いてるけどよく見ると変だよね
forでも書いてるならベンチ取る必要ない

781 ：
linqでしか書けない人は最下層
forでしか書けない人はそのやや上

782 ：
forでしか書かない人は使い物にならないおじいさん
無理してでもLINQでしか書かないのはまだまだ研鑽が足りない
意識しなくても自然とLINQになってるのが達人プログラマ

783 ：
POSTとかGETのレスポンス速度って、自分の回線速度と相手側のサーバー速度依存ですか？
プログラムの処理でコンマ数秒でも早くする方法ってあったりします？

784 ：
普通はないよ
アメリカとかにPOSTして帰って来てるんだとしたらそもそも物理的な距離も問題になる

785 ：
どうでもいいけど回線速度と言うのも変な表現だな
帯域依存だな
最初のレスポンス自体が帰ってくる速度は同じだけど取れる帯域が広いと早くダウンロードが終わる

786 ：
ダウンロードの時間じゃなくてレスポンスの話だろ
帯域よりレイテンシのほうが問題だと思うが

787 ：
相手側のサーバーまで全部依存ですよね
ちなみに、普通にwebとかで見えてるサーバーは、必ずping返してくれるの？

788 ：
ping返さないサーバはいくらでもある

789 ：
>>783
htmlに埋め込まれてるアンカーを
バックグラウンドで先読みするタイプのブラウザがあった
評判は悪いみたいだが

790 ：
フォームデータなのに？

791 ：
【与沢翼】労働収入を高くしても無駄！税金でほとんど持っていかれますよ。
金持ちになるにはたった２つしか方法がない
https://www.youtube.com/watch?v=A-5lQ2rDmc0
【与沢翼】サラリーマンとして生きるのはリスクでしかない。従業員は創業者に
利用されているだけだということに気づきなさい
https://www.youtube.com/watch?v=uPoTvbr5VDk&t=78s
【与沢翼】「世の中は罠だらけ。これに気づかない人はカモにされ続ける。」【思考の革命】
https://www.youtube.com/watch?v=qUk7HFabMeQ&t=70s
【与沢翼】現状に対する疑問を持てない人はずっと辛い労働をして生きてください。
今自分達が不自由であるということに気づかない人はどうぞご勝手に
https://www.youtube.com/watch?v=YGykF9IHv-w&t=41s
【与沢翼】時間を売るような働き方をしてはいけない。自分の24時間をどれだけ
増やせるかという発想で仕事しなさい。最終決定権がない仕事はビジネスとは呼べませんよ
https://www.youtube.com/watch?v=g0WXpcqg4oA&t=51s

792 ：
OS:Rasbian Stretch
ランタイム:Mono JIT compiler version 4.6.2 (Debian 4.6.2.7+dfsg-1)
ソース:https://i.imgur.com/cFLOcYN.png
パッケージ:https://i.imgur.com/bWRI0Zg.png
エラー:Method 'System.Net.ServicePointManager.CloseConnectionGroups' not found.
Windowsでは正常に動作します。
エラーの原因と解決策を教えてください。

793 ：
AngleSharpを入れるとこのエラーがでます。
AngleSharpを入れるとバイナリのフォルダにSystem.***という大量のDLLができます。

794 ：
ターゲットは.NET Framework4.6.1です

795 ：
>>794
Linux用には.Net Framework 4.6.1はないんじゃない？
.net coreと.net frameworkは別物

796 ：
>>795
回答ありがとうございます。
Mono4.6.2と.NET Framework4.6.1は互換性ありませんか

797 ：
AngleSharpを入れるとそれを使用しなくても関係ないところでエラーが出る理由がわかりませんね
　

798 ：
バージョンがあってないからだろ
初心者向けのふらっとスレに行け

まず
.Netにはいろいろ種類があると言うことをしり特性を知れ
次に.net standardが何か調べろ
そして使いたいフレームワークが.net standardで何に当たるか調べろ

次にServicePointManager クラスが自分の使いたいフレームワークで使えるかどうかMSのサイトをみて調べろ

799 ：
こちらの質問は却下します

800 ：
standardというパワー綴り

801 ：
startupでデフォルトのDB接続先でapp.CreatePerOwinContextを登録してるのだが
途中でDB接続先を変更出来たりしないですか？
コントローラーのOnActionExecutingでfilterContext.HttpContext.GetOwinContext().Set(wkUserManager);
で変更したんだが、他画面にいくとリセットされてるというか元が変わってないというか

802 ：
ライブラリの話が出ているので自分も質問させて頂きたいんですが、SevenZipSharp(by squid-box)使ってる方いないでしょうか？
分割されたRAR5.0を解凍する際にファイルが壊れてる的なエラーが出て解凍できないことがあるのはバグでしょうか？（純正7Zipアプリでなら正常に解凍できるため実際には壊れていない）
どうやら1GB程以上の大きい分割ファイルだとそうなることが多いようで、数百MB程度の分割ファイルなら問題なく解凍は出来ます
単体のRARであれば1GB以上の巨大圧縮も解凍できるためメモリ周りのエラーと言う事でもなさそうなのですが

803 ：
TabControl上の『選択されていないTabPage上の』ボタンをプログラムからクリックしたいんだが、どうすればいいのだ？
試したことは以下。
((Button^)ctrl)->PerformClick(); // ボタンが見えてないと（ボタンのあるTabPageが選択されていないと）ClickEventが発生しない（以下※１）
((Button^)ctrl)->OnClick(gcnew EventArgs()); // protected なメソッドなので呼べない
((Button^)ctrl)->Click->DynamicInvoke(gcnew array<Object^>(2){ctrl,gcnew EventArgs()}); // C3918、データメンバではないため、マルチキャストデリゲートに直接アクセス出来ない
((Button^)ctrl)->Click(ctrl, gcnew EventArgs()); // C3718, Clickにraiseメソッドがないから駄目
環境
.NET Framework3.5(Form), VC++/CLI, VS2008EE
目的
GUIの画面をバッチ処理しようとしていて、
ボタンの名前をスクリプトに書いておけば順にクリックしてくれる、みたいなものを作っている。
見えていればPerformClickは動作するので、今はその都度SelectedTabを切り替えて逃げているが、
バッチ中に一々画面が変わるので出来ればそのままで処理したい。

804 ：
※１
書いてあることとはこちらの状況と合致しているわけでもないが、とにかく見えてないとPerformClickは動作しない。
> TabControl.TabPages コレクションに少なくとも1つの TabPage が含まれている場合
> (Click、DoubleClick、MouseDown、MouseUp、MouseHover、MouseEnter、MouseLeave、MouseMove)、
> TabControl クラスでは、次のイベントは発生しません。 コレクションに少なくとも1つの TabPage が存在し、
> ユーザーがタブコントロールのヘッダー (TabPage 名が表示される) と対話する場合、
> TabControl は適切なイベントを発生させます。
> ただし、ユーザーの操作がタブページのクライアント領域内にある場合、TabPage は適切なイベントを発生させます。
> https://docs.microsoft.com/ja-jp/dotnet/api/system.windows.forms.control.click?view=netframework-4.8
自動翻訳がイマイチなので英語も。
> The following events are not raised for the TabControl class unless there is at least one TabPage in the TabControl.
> TabPages collection: Click, DoubleClick, MouseDown, MouseUp, MouseHover, MouseEnter, MouseLeave and MouseMove.
> If there is at least one TabPage in the collection, and the user interacts with the tab control's header (where the TabPage names appear), the TabControl raises the appropriate event.
> However, if the user interaction is within the client area of the tab page, the TabPage raises the appropriate event.
> https://docs.microsoft.com/en-us/dotnet/api/system.windows.forms.control.click?view=netframework-4.8

805 ：
>>803
表示されているかどうかの問題ではないと思う。

TabPageのコンテナ（およびその上のコントロール）はそのページが初めて
表示されるまで「作成」(CreateControl)されない仕様だった気が。

知らんけど

806 ：
>>805
過去一度でも表示されたことがあるか、なら、確実に一度は表示されている。（初期画面のタブなので)
そして一応、直前に表示した状況でも試してみたが、やはりPerformClickは反応しない。
(「スクリプト実行ボタン」と「スクリプトから押したいボタン」が同一TabControlの別ページにあるので、
タブを切り替えた直後に実行ボタンを押してみたが、駄目だった）

ただしその挙動は少し覚えがあるというか、
大量にコントロールを並べていて描画がもたつく場合、タブを切り替える毎に再描画している雰囲気はあるから、
それに近い可能性（見えてないタブのコントロールを剥がすとか）もありえるとは思う。

807 ：
リファレンスには書いてないっぽいけど
ControlのCanSelectがtrueじゃないとPerformClick()はイベントを発生させない
https://referencesource.microsoft.com/#system.windows.forms/winforms/managed/system/winforms/Button.cs,346

ボタン側を拡張したりボタンが呼び出してるメソッドを直接呼べない状況なら
素直にTabをSelectする以外にないんじゃないかな

808 ：
InvokeOnClick()呼べる？
こっちなら何もチェックしてないっぽいけど

809 ：
別にボタン押すとこまで律儀に再現しなくても良いよ
イベントハンドラかその中で呼んでるサービスを直接呼び出せばいい

810 ：
>>806
なるほど確かに初回表示済みかどうかにかかわらず表示されてない時はダネだねw
これなら問題なかった
static class Extensions
{
　　public static void RaiseClick(this Control control)
　　{
　　　　var t = control.GetType();
　　　　var m = t.GetMethod("OnClick", BindingFlags.NonPublic | BindingFlags.Instance);
　　　　m.Invoke(control, new[] { EventArgs.Empty });
　　}
}

811 ：
>>807
おお、ありがとう。
ググりまくりはしたが、ソースコードをチェックするという発想はなかった。

> このプロパティは、System.Windows.Forms.ControlStyles の Selectable 値が trueに設定されていて、
> 別のコントロールに含まれていて、コントロール自体が表示され、
> 有効になっていて、すべての親コントロールが表示され、有効になっている場合に true を返します。
> https://docs.microsoft.com/ja-jp/dotnet/api/system.windows.forms.control.canselect?view=netframework-4.8#System_Windows_Forms_Control_CanSelect
なんだかよく分からんが、かなり条件が深いのは分かった。
CanSelectはリードオンリーだから、素直に表示させるのが一番マシなようだ。

>>808
InvokeOnClickもprotectedなので駄目のようだ。(C3767)

ただ、なんでCanSelectなんだよ？とは思ったので、なるほどInvokeOnClickか!とも一瞬思ったが。
何がしたいんだよこの仕様(CanSelect必須）は。
GUIが有効か見ているわけだが、それをプログラムからの操作に噛ませる意味はないはず。

812 ：
>>810
ありがとう。
ただ、リフレクションは嵌る原因になるので出来る限り回避している。理由は以下。
・C#ならさておき、VC++だとググッてもヒットしない。
・ならば勿論C#を参考にするわけだが、本来同じCLRでMSILなので全く同一の筈なのだが、
　何故か一部異なっていたりして、そこで嵌る。（というか嵌ったことがある）
勿論使ってはいるが。
ただ、確かに今回はリフレクションでも対応出来る状況なので、最終的には使うかもしれないけど。

813 ：
バッチ処理なのになんでFormsなんだ？

814 ：
IEコンポーネントの代替品って何？　ChromiumベースEdge のものは既に用意されてるの？

815 ：
>>812
ならこれでも出来た。
何か気づいてない弊害があったらごめんね
public static void RaiseClick(this Button button)
{
　　var parent = button.Parent;
　　if(parent is TabPage)
　　{
　　　　button.Parent = null;
　　　　button.PerformClick();
　　　　button.Parent = parent;
　　}
}

個人的にはこういうバットノウハウ感全開のコードは嫌いw

816 ：
>>815
さすがに動的に剥がすのは色々副作用が発生しそうで怖い。
今のところ以下のコードでやっている。このままか、>>810にするかのどちらかだと思う。

if (ctrl->Parent->GetType()->Name=="TabPage") ((TabControl^)ctrl->Parent->Parent)->SelectedTab = (TabPage^)ctrl->Parent;
((Button^)ctrl)->PerformClick();

キャストが入ってうざくなっているが、要はボタンの親のタブページをその都度選択(表示)させている。
これで動いている。ただしタブが勝手に切り替わるので知らなければギョッとする。
直後に戻せばいいだけかもしれないが、それはそれで無駄にイベントが発生するし、とりあえず放置だ。
仕様だと分かったので諦めはつく。

しばらくこれで試して、問題がなければこのまま、といったところ。
現状TabControl内のTabControlなんて無いから、おそらくこの方法で問題ないと思っている。
(TabControlが入れ子になっている場合、おそらくリフレクションしかない）

817 ：
ボタンのコードを呼び出すのは駄目なの？

818 ：
>>816訂正
× TabControlが入れ子になっている場合
○ TabControl内にGroupBox等があり、そこにボタンがある場合

809のコードだと直接の親しか見てないので、
TabControl内のボタンは階層的に直接TabPageに貼られている必要がある。
そうでなければ親を再帰で辿るか、リフレクションするか、だろう。

819 ：
馬鹿がこんがらがってるイメージ
ボタンクリックのイベントハンドラを表示
private void button1_Click(object sender, EventArgs e)
{
//
}
始めの｛と終わりの｝の間をすべて選択する
右クリック　クイックアクションとリファクタリングを選択
メソッドの抽出を選択
適用をクリック

820 ：
>>819
だよなあ
おそらく「ボタンを押すこと」が目的化してしまってる
クライアントの要件は多分そういうことじゃない

821 ：
>>819
その程度の話なら既に指摘されてるよw

イベントハンドラは動的に変更されるかもしれないし、
ラムダ式や引数で与えられるデリゲートかもしれない。

だから普通質問者さんの問題意識は理解できると思うよw
イキってる君以外の人にはw

822 ：
>>821
その動的に変わるかもしれない処理とやらを抽出するだけだろ?

Form: btnFoo.Click += this.Model.Foo;

Model: void Foo() => _foo?.Invoke(); // _fooは動的に変化するかもしれない

スクリプト(オレオレマクロの文法がわからんから例としてpowershell)
$form = $AppHost.Container.Resolve("MyForm")
$form.Model.Foo()
画面を見なくていいならより直接的に
$model = $AppHost.Container.Resolve("MyFormModel")
$model.Foo()

823 ：
なんかもうバカの壁だねw
ボタンのクリックをシミュレートしたいというのは十分理解できる話だし、
それをなるべくそのまま表現できるようなコードを書きたい、という動機も
普通に理解できる話だと思うんだけど。
>>822的な発想の問題点は、
(1) プログラマの意図と実際のコードに乖離がある
(2) だから呼び出しているメソッドが今本当にButtonのイベントハンドラに登録されているものと
同一であるか、という検証の必要性が発生する。
(3) ButtonのPerformClickの「仕様バグ」を回避するため、
という非本質的な目的のためにコードの設計に手を入れるのは本末転倒
なにが「だろ？」なんだろうね
スギちゃんかよだっせーwww

824 ：
>>820の人も思いっきり倒錯してるねw

825 ：
>>823
それより前の問題としてプログラマの意図がまず間違ってんだよ
魚をさばくのにノコギリでやろうとしてる状態
そこを正してからじゃないと話にならない
正さずにむりやり進めようとしてるからボタンクリックエミュレートなどという頭の悪い発想に固執する
挙げ句の果に画面上で見えてないと処理が走らない（涙）なんてバカバカしい罠にどハマリしちゃってるわけだ
はっきり言ってリフレクションはハマりやすいからダメだなんて言ってる場合じゃないよ

826 ：
だいたいクライアントのやりたいことは自社アプケーションのオートメーションサポートだろうよ
それを素人の思いつきレベルの発想でUIのオートメーションに目的をすり替えたのが運の尽きだわな
レイヤの考え方が全くわかってないアマチュアの設計だからすんなりうまく行くはずがないんだ
見えてないと発火しないこと以外にいったいどんな罠が潜んでるかわかったもんじゃない
俺が提案した方法ならUIインフラに依存しなくなるから実行時の安定性と罠が少ないぶん高い生産性が期待できる

827 ：
アセンブリが自分や所属チーム/組織のコントロール下にないんじゃないのかな
違う理由かもしれないがそれと同じような制約下での話だと思われる

828 ：
>>803
>GUIの画面をバッチ処理しようとしていて
UiPathとかAutoIt使いな。

829 ：
>>827
そういうときはUIAutomationかWinAppDriverを使うといいよ
どうせこのあと要求がどんどん増えてボタンクリックだけじゃ済まなくなるんでしょ
あとで苦労するハックはやめてマイクロソフトが整備してる道具を使おう

830 ：
>>826
まあその「俺のプログラムが一番だ」という姿勢は俺は嫌いではないし、
むしろプログラマは全員持つべきだとも思うけども、
動的結合の価値（意味）が分からないのなら、まずはそこを理解した方がいい。

現在、Clickイベントをエミュレーション出来ないGUIフレームワークなんて、存在してない。
リフレクションも割と一般的になりつつある。(常用するのはどうかとも思うが)
だから、使いどころはあるんだよ。
静的結合だけでやれ、みたいなのは言ってしまえばC++がそうだが、それでもRTTIは検討されている。

動的結合の価値は>>823も書いてくれているが、同様に以下でも触れられている。(これらだけでもないが）
https://www.atmarkit.co.jp/fdotnet/dotnettips/270performclick/performclick.html
言ってしまえば「実行速度を捨てて保守性を採る」わけであり、これが適切かどうかは状況によるので、
PerformClickやリフレクション等を使うこと自体が間違いだ、というのはさすがに行きすぎてる。
(なお既に言ったが、速度至上主義のC++は割とそういう思想だし、これも間違いでもないが）


ただそれはさておき、PowerShellは使ったこと無いから調べてみたが、確かに面白いものではある。
ポイントは、.NETオブジェクトをインスタンス化出来ることと、それらをパイプで流せる点か。
>>822を見る限り、C#等CLRな物ならリフレクションで内部の関数をぶち抜いて、自在に呼べるのか！
(名前があやふやだが確か）COMでも似たようなことをしていたMSならあり得るか！とも思ったが、
そうではなくて、自分で.NETクラスをインスタンス化して呼べるだけか？
まあそれでもリフレクションを使えば何でもありにはなるし、
.NETを使うだけで本式のバッチスクリプト環境が自動的に提供されてしまう、というのは画期的ではある。
ここら辺はMSの上手いところだとは思う。

831 ：
>>823
俺も「仕様バグ」に近いものだとは思うが、おそらくMSはそう認識してないと思う。
理由は、.NETは比較的「仕様バグ」は少ない環境であり、これは、
・MSがガッツリ保守している
・バイナリ側がランタイムのバージョンを指定出来るので、改訂しやすい
為、「仕様バグ」を後方互換性の為に残す必然性がほぼ無いからだ。
少なくともobsolete(非推奨)にすることは簡単に出来るのだが、してない。
多分何か理由があるのだろうけど、俺には分からない。

なお後知恵だがDobonには書いてある。
> ただし、コントロールのCanSelectプロパティがfalseの時は、PerformClickメソッドは何もしません。
> 例えば、コントロールのVisibleプロパティがfalseの時、CanSelectプロパティはfalseとなります。
> https://dobon.net/vb/dotnet/control/performclick.html
Dobonは、というよりMSDN以外は基本的に見ないことにしていたのだが、妙な嵌り方をした場合は役に立つのかも。
なお他にも
> クリックの動作と同じ動きをするため、EnabledプロパティやVisubleプロパティが"False"の場合、
> PerformClickメソッドを呼び出しても何も実行されません。
> https://www.ipentec.com/document/csharp-simulate-click-event

832 ：
>>830
なにこの
メソッドにすりゃいーじゃん
以上の意味を見いだせない機能

833 ：
>>830
そのリンクの先はかなりクソコードだから鵜呑みにしないほうがいいぞ
まあ2005年の錆びついたものだしもともと低スキル向けの記事だからしょうがないけど
この記事の悪しき前提はViewに処理をベタ書きしちゃってることな
本来ならViewとModelを分離してView上のメニューとボタンからModelの同じメソッドをコールするのが正しい設計な

ViewとModelを分離してModelがViewに依存しなくなればModelをUIインフラから切り離して独立させることができる
そうすればオレオレスクリプトでオートメーションをサポートするといった要求にも容易に応えることができるようになる
UI操作をエミュレートするなどという泥臭いハックに頼らなくて済むのだ

834 ：
>>833
このページのコードと用例が糞なのは事実として、エミュレーションが適切な場合もあるってことだよ。
だから現在の全てのGUIフレームワークはエミュレーション出来るようになってるし、
リフレクションも装備しつつある。

MとVを厳密に分離してVはMのラッパ扱いに留めろ、というのは現在の思想としては正しいとして、
2005頃には今ほど言われていなかった、というより、そのころの失敗を経て現在の思想があるわけだから、
このページに対してそれを言ってもしょうがない。
ただそれにしても、現在もまだエミュレーションの価値はあると思うよ。

今回の点に関しての不満なら、俺は
MS:「OnClickがprotectedで呼べないからPerformClickを用意しました」
俺:「なら最初からOnClickをpublicにしとけよ」
であって、private至上主義という勘違いオブジェクト指向の面影を.NETもまた引きずっている点についてだね。

835 ：
>>834
ウンコをいじる正当性を探すな

836 ：
エミュレーションの有用性が分からないのは根本的に経験が足りない。
何故現在の全てのGUIフレームワークがその機能を持っているのか、その意味をよく考えた方がいい。
そしてそのレベルの奴がコードの善し悪しを議論するのは5年早い。
ただ、このレベルの初心者と話をしても意味がないから俺はやる気無い。
お前らが正しいのなら、MSは数年以内に.NETからエミュレーション機能、
つまりPerformClick/OnClick/リフレクション等を全削除することになるが、
俺はこれはあり得ないとしか思えない。
正否は結果で判断でいい。
ここで低レベルな水掛け論をやる意味はない。

837 ：
こんなクダンネーモン作ってる暇があるならメッセージボックスが後ろに回らないように修正しろ

838 ：
>>814
nugetにあるよ。

839 ：
>>834>>836
UI操作をエミュレートする需要があることは間違いではない
がしかしそれはUIコンポーネント実装のためだったりテストフレームワークのためだったりソースにアクセスできないGUIアプリケーションのオートメーションのためだったりであって
自社アプリにオートメーションサポートを実装するための基盤ではない
それをサポートを実現するまっとうな設計はUI層に依存しないAPIやCLIの提供であってUI操作とは全く逆の考え方だ

お前はノコギリにだって役目と需要があると言ってる
しかしノコギリは魚をさばくのには適さない
無論無理をすればノコギリで魚をさばくことはできるがそれはバカのやることだ

840 ：
年末年始年始に非同期処理で騒いでた人かな

841 ：
>>839
あんたも相当しつこいねw
俺は質問者さんと別人だけど、ボタンやメニューのクリックをシミュレートしたい
場面というのは実際問題しばしば存在するよ
例えばクリックすると何か処理が走るボタンが複数あるとする。
この時、これを全部クリックしたのと同じ機能を果たすボタンが欲しい、
なんていうのは割とありがちな話。
あと、クリックで同じ機能を果たすボタンとメニューが存在する、なんてしょっちゅうある。
この場合はメニューの方のクリックをシミュレートするのが普通だと思うから
件の話を正当化する材料にはならないけどね。

842 ：
>>841
えー、それにこれ使っちゃうのはキチガイだろ

チェック関連全部走ってから
本処理行くだろ

843 ：
>>839
「UIに依存する」のではなく、「UIの代替を提供する」のであって、
UIが変更された場合にはUIと同じく変更されるのが正しいんだよ。この点が違う。
そしてソース変更無しで自動追従させる手法がエミュレーションになる。
「UIに依存する」というのは、UIとは本来関係ない事をUIを通してやってしまっていることにより、
UIが変更された場合に動かなくなって困る（動作が変わってしまう）ことを言ってるだろ。
そうじゃない。今回はそこは動作が変わるのが正しいんだよ。


それはさておき、PowerShellって流行ってるのか？
思想が面白いのは認めるが、これはつまり「.NETアプリをライブラリとして公開する」訳であり、
ガチのプログラマに対してソース公開して、後はお前が頑張れ、と言っているに近い。
勿論これで行ける奴はいいが、実際のところ、使う側はアプリを使いたいのであって、
ソースを読みたいわけでもなく、プログラミングしたいわけでもない。
そしてアプリと完全に密結合してしまうから、そもそも同レベルのプログラマじゃないとソースは読めない。
だから現実的に、アプリ+PowerShellで何とかしろ、と言われても、プログラマでも困ると思うが。

ただし再三言っているが、思想が面白いのは認める。
これにより、全ての.NETアプリはPowerShellライブラリとして動作し、
また、ガチのスクリプト環境が手に入るわけだ。これ自体は（有用性はともかく）面白い。

844 ：
>>841
どちらもボタンクリックをエミュレートする必要はない
上の例はクリックで実行される処理を順に実行するだけ
下の例はメニューとボタンから同じ処理を呼ぶだけ

845 ：
>>843
つまりお前が言いたいのは
スクリプティング機能の定石に反する糞仕様こそを求めているので今回に限り馬鹿なことをするのが正しい
ということか

PowerShellは流行ってるというかWindowsのシステム管理ではほぼ必須
OSにプレインストールされてるから開発環境用意するまでもないちょっとしたツールを作るのにも便利
今まさに話してるDSLを手軽に実装するための基盤としてもしばしば使われる
LinuxやMacで仕事してるなら触る機会ないだろうけどWindowsで開発してるなら触る機会は無数にあるはず

846 ：
>>803
おいもうそろそろこの話題締めて他所にいってくれや。

847 ：
ふらっと荒らしてこっち荒らして、いつも同じメンバーだろこれ

848 ：
もともと完全にちゃんとＧＵＩ操作したいなんて書いてないだろさ
途中から見てる人が勝手に条件を足してるだけで本来あるべき姿とかい離してる
途中で無駄にリフレクションが出てくるあたり初心者の匂いが出てる
ボタン押すにはタブを切り替えなくてはならないのに
画面が変わらないままでボタン押したいって言ってるから別にＧＵＩ操作自体を再現したいわけじゃない

849 ：
>>845
違う。定石に反しているのは君の方で、つまりはカッコイイソリューションを目指しすぎている。
馬鹿みたいなソリューションの方が、現実的に使いやすいことは多々ある。
多分、ちょっと若すぎて元気がありすぎるのだと思う。
これ自体は悪いことではなく、むしろ上達には必須の性格で、良いことだとは思うが、
世の中のアプリがどうなっているか、もう少し周りを見た方がいい。
GUIの自動化で一番簡単なソリューションは、GUIを記録してしまうことだ。…(A)
俺が昔使ったアプリだと、「ログ画面」にGUI操作と等価のコマンドが一々流れる、というのがあった。
そして自動化したい場合は、このログ画面内の該当部分をコピペしたファイルを読ませるだけ、というものだ。
当然、見れば分かる程度であり、例えばファイルを読み込んだらそのファイルパスがまんま表示されている。
なら、そこを変更するだけで同じ処理を他ファイルに適用出来るよね、というわけだ。
冷静に考えれば分かるが、Unixのshもこれと同様だ。（というより上記方式がshのパクリだが）
shもhistoryで出てくる履歴をコピペすればバッチファイルになるようになっている。
そして必要なら該当部分を変数化してループを回せ、ということでしかない。
俺は使ったことないけど、Webブラウザの自動化ツールとして有名なSeleniumも以下見る限り似たようなもんだ。
https://www.valtes.co.jp/qbookplus/509
だから、初段階のスクリプト環境はこの程度でいいし、実際、この程度でも相当有益なんだよ。
そしてそれを手っ取り早く実装する方法がGUIのエミュレーション(PerformClick等）になる。
だから、
> 自社アプリにオートメーションサポートを実装するための基盤ではない
これはちょっと意識が高すぎる。（気持ちは分からなくもないが)
PowerShellでオートメーション、というのはその先の先の先位で、
初期段階に於いては超オーバースペックでしかない。
そして殆どのアプリでは最終的にも必要としない。

850 ：
例えば上記アプリ(A)方式だと、ループ機能すらないのだから、
アプリ(A)だけで100個のファイルに同じ処理を適用しようとすると困る。
そこでループ機能を、とか言い出すと色々他が必要になって結局PowerShell、という思想もありだが、
そうではなく、Perl等でファイル名だけ変更するスクリプトを作り、
それでループを回して作ったドベタに展開された糞長いバッチファイルをアプリ(A)に流し込む、
というのもありなんだよ。
全ての処理を自アプリでやろうとするから無理が発生する。
unixはこれと逆で、他コマンドで出来ることは自コマンドでするな、で上手く行ってるだろ。
ソースコードについてもそうだが、アプリについてもKISS原則は重要なんだよ。
そして話を戻すと、UIの自動化のド定番は「実際に行われたUIを記録してそのまま流すこと」であり、
「PowerShell等のガチスクリプト環境と連携すること」ではない。
だからクリックエミュレーション等も今のところは今後とも必要な機能でしかない。
が、まあ、PowerShellを推す気持ちも分からなくはない。
おそらくIEだとPowerShellで自動化出来ると推測されるので、
IEが天下取っていたときに自動化の流れが来てたら少しは違ったかもしれん。

851 ：
>>849
無知すぎて呆れる
世の中のサービスやアプリをちゃんと見てみろ
APIやCLIをサポートすることは多々あってもGUI操作をサポートしてるものなどごく少数派だ
UIとは読んで字のごとくユーザーのためのインターフェースであって自動化のためのインターフェースではない
APIとはアプリケーションプログラムのためのインターフェースであり自動化をサポートするならこちらを提供するのが当然の選択だ
APIやCLIのサポートが定石であってGUI操作は邪教徒の好む黒魔術でしかない
お前の常識は多分10年か20年前の辺境の集落での常識だ
現代のグローバルスタンダードに追いつく努力をしてくれ

852 ：
>GUIの自動化で一番簡単なソリューションは、GUIを記録してしまうことだ。…(A)
>俺が昔使ったアプリだと、「ログ画面」にGUI操作と等価のコマンドが一々流れる、というのがあった。
>そして自動化したい場合は、このログ画面内の該当部分をコピペしたファイルを読ませるだけ、というものだ。
>当然、見れば分かる程度であり、例えばファイルを読み込んだらそのファイルパスがまんま表示されている。
>なら、そこを変更するだけで同じ処理を他ファイルに適用出来るよね、というわけだ。
これ、昔作ったことが有るけど、最も上手くいった方法はMVCを徹底して、Cの入り口でコマンドオブジェクトをシリアライズして記録するパターンだったな
やってみればわかると思うけど、画面コントロールの操作ログを正確に記録するのも、再生するのも、一筋縄ではいかない

853 ：
COMで解決された問題を20年以上経って議論してる・・・

854 ：
この話題をすり替えつつ自分の正当性をゴリ押しするスタイル、最近見ましたよね
明後日くらいには全然違う話題になってるぞきっとｗ

855 ：
荒らしてるの毎回同じ人だよね
書き方に癖があるからすぐわかる

856 ：
>>844
繰り返しになるけどね、そういう「プログラマの意図と実際のコードに乖離がある」
ことをやると別の仕事が増えるでしょ。

ボタンABCDEが全部クリックされたのと確実に同じことが起るって誰が確認して保証するの？
ボタンABCDEのクリックイベントの処理を後で変更した時、またそれをやりなおすの？
その確認作業を忘れたらどうするの？

こういう後の保守のことを考えないプログラマは愚鈍で無能。

倒錯してるよ君。
「する必要はない」のは、「クリックで実行される処理を順に実行する」なんて保守性を下げる
アホな手段を採用すること。

なぜ素直にボタンクリックをシミュレートしようとしないの。

857 ：
>>856
プログラマの真の意図は
ボタンを押したら複数の一連の処理をまとめて実行したい
メニューとボタンで同じ処理を実行したい
だろ
君が好きなボタンをエミュレートする方法は上記のプログラマの意図を実現する遠回りなやり方の1つだ
誰が確認するの？確認忘れたらどうすんの？なんて質問は自分は仕事でコード書いたことありませんと言っているようなものだから控えたほうがいい
テストを自動化するか人がやるか誰がやるかはチーム次第だがいずれにせよテストをしないわけがないではないか
そしてテストをするのはボタンをエミュレートする方式だろうが他のどうな方法だろうが同じことだ
まるで暗にエミュレートならテストを省略していいような言い方をするとああこいつはアマチュアなんだなとバレてしまうぞ
ちなみにテストの心配をするならなおさらUIに依存しない方式で書いたほうがいい
そうすればテストの自動化が容易になるから君が気にしてるテスト工数の増加やリグレッションの発生確率も最小化することができる
UIのエミュレートが正しく行われたことをテストするのはUI非依存のテストと比べると面倒な作業だよ
まあこんへんはアマチュアにはわかりにくいメリットかもしれないね

858 ：
Seleniumデザインパターン&ベストプラクティス、2015、オライリー
この本は、Ruby, Selenium WebDriver でのテスト手法を書いた本
例えば、Ruby, Selenium WebDriverで、
Yahoo への自動ログインするスクリプトは、下を参照
【VBScript】WSHについて話し合うスレ【JScript】
https://mevius.2ch.sc/test/read.cgi/tech/1578522041/27

859 ：
そしてさも当然ように混じり込むいつものRubyキチ

860 ：
>>851
だから君は意識が高すぎるんだよ。
誰もAPIを欲してないし、スクリプトを書きたいとも思ってない。
GUIを自動化したいだけ。

そして君だって、1つや2つのファイル名の変更は、普通にエクスプローラで行うだろ。
勿論APIは整備されていて、コマンドプロンプトでren fileA fileB と打つだけなのに。
GUIの方が簡単だから、GUIで済む場合はGUIを選択する、これが普通だ。
勿論100個と言われたら考えるが、10個程度なら普通はそこでAPI調べてDSLとはならない。
理由は、10個程度なら我慢出来る範囲で、DSLを書く方が時間がかかるからだ。

そしてこの原因は、DSLの方言が酷く、オレオレアプリのDSLなんて書いてもすぐには動かないからだ。
だから「今やった操作をする為のスクリプト」が吐かれ、それをコピペすればすぐ動く、というのは優れたAPIではあるんだよ。
ただ、根本的な原因は既に言ったが『方言が酷すぎる』事だから、それをPowerShellで統一する、という野望は、
方向性として合ってるから悪くもない。
でもそれが達成出来てるとは全く思わないけど。
Unixの「テキストファイル/テキスト操作ツール群/ファイル操作」で統一しているシステムが出来が良すぎて、
結局WindowsもWSLやDockerを導入してる有り様だろ。

話を戻すと、PowerShell+APIでPerformClickが不要になる、なんて事にはなってないし、今後ともならないよ。
GUIの方が直感的で簡単だから世の中GUIな訳で、その操作を自動化するのならエミュレーションは一つの正しい解だ。
ただ、PowerShellの野望は面白いと思うし、なったらなったで俺は普通にそっちに乗っても問題ないけど。
そしてPowerShellが本当に面白いのは、.NETアプリならリフレクション使って何とでも出来ることだろ。
プロセスへのアタッチ機能も有るようだし、APIなんて無くてもやりたい放題だ。
これが、そそる、というのは分かる。

861 ：
>>852
それがすんなり行くかどうかはアプリの作りによる。
例えば、VSのコンパイル機能は csc.exe へのフロントエンドでしか無く、コマンドラインオプションを作るだけの物ではあるだろ。
こういう場合は至って簡単で、そのまま吐くだけで済む。

上手く行かなかったとしたら、前回の内部状態と混線したのだろうけど、ぱっとは思いつかないね。
普通にアプリを作ってしまえば当然再現性はあり、
どのボタンを押したかをそのまま記録/再生すれば当然同じ結果は生成される。
それらを「人間が見て分かるそれなりのコマンド名」に落とし込むのは大変だろうけど、ぶっちゃけ、

CONTROL Button インスタンス名 Click

程度のDSLならその心配もない。
これ以上に格好良くしようとすると、色々大変なのは分かるが、正直、この程度でもDSLとしては十分だから問題はない。
(ちなみに一応言っておくと、Buttonのみならず、他全て、例えばradioButtonやNumericUpDown、TextBox等、
内部状態を変更するGUIコンポーネントについては全てこの方式で記録/再生してる。
そりゃ再生出来るに決まってるだろ、というのは分かると思う）

862 ：
>>860
いやいや誰もUI操作を自動化したいとは思ってない
UI操作の背後で行われてる処理を使ってマクロを組みたいんだよ
ユーザーは無知だからUI操作をエミュレートする方法しか思いつかないんだろうけど開発者はそれじゃいけない

俺は名前変えるときでもコマンド打つけどねgit mv a bってさ
つうかそういう話じゃないよ
普段GUIで作業してようがなにしようがオートメーションしたいならGUI操作じゃなくAPIが整備されてたほうが嬉しい
それが当たり前の感覚であってAPIよりGUI操作のほうがいいなんてのは変人の考え方だ

UI操作するオレオレDSLなんてまあバグだらけだろうな
UI操作の不安定さなんてテスト自動化してる人なら誰でも身を持って経験してるからエンドユーザに提供するマクロ機能としてUI操作を強要するとかありえん
UI操作に加えてDSLまで独自開発なんてしてたらバグだらけのうえに開発機能までショボくて使い物にならんだろうな
PSみたいな既存言語に乗せればインタプリタの開発はマイクロソフトとコミュニティがやってくれる
デバッガなど含めた開発環境もノーコストで手にはいる
ユーザーは快適な環境でマクロを弄ることができるわけだ
オレオレマクロのユーザーは不憫だな

PerformClickはUIコンポーネントの開発者などが使うかもしれんから不要にはならないだろう
だがオートメーションサポートするのに依然としてPerformClickは必要ないな
UI非依存のAPIを提供するだけでいいのだからUIを操作する意味がない

人間が操作するときに直感的でわかりやすいといっても自動化に適するわけでもあるまい
自動化したいなら人間ではなくプログラムから見て呼び出しやすい構造を提供する必要がある
それはアプリケーションプログラミングインターフェースのことであってUI操作ではない

PSの面白いところはリフレクションとか意味わからんこと言うな
PS普通に使っててもリフレクション使ったコードなんて滅多に書かねえよ

863 ：
処理の冒頭だけで途中でメッセージボックスが表示されてさらにユーザの追加入力が必要な処理はこれ使えねぇだろ
まさにゴミだろキングオブゴミだろ

864 ：
ThreadPool を使って、非同期に処理を実行しています。
特定のタイミングで ThreadPool に溜まっている処理を全て削除したいのですが、どのようにすればよいでしょうか。

// Threadの登録
ThreadPool.QueueUserWorkItem(new WaitCallback(ThreadMethod));
// ThreadMethod の処理が終わる前に abort させたい

スレ違いなら、誘導してもらえると助かります。

865 ：
古すぎるコード

866 ：
>>864
CancellationToken(CancellationTokenSource.Token)

867 ：
>>857
なんか話が噛み合ってないね。

ボタンABCDEを全部クリックしたのと同じことが起るボタンが欲しい、という要件が発生した時、
その責務をモデルに持たせるべきか、むしろUIレベルでやってしまった方がよいかは微妙で
ケースバイケースだと思う。

俺は後者の場合の話をしています。
これまでの流れからそれは自明だと思うけど。

どうでもいいけどこういうのってemulat"なの？
simulateでしょ？俺の認識がおかしいのかな。

emulateって言葉はこの世界ではハードウェアの機能をソフトで代替するって
ニュアンスが強いと思うんだけどどうかな

868 ：
まああれだ、ボタンクリックをシミュレートするなんてなんかダサい、という
中二病的な発想は（同意はできないけど）理解はできないでもない

そういう人は「プログラマの意図と実際のコードに乖離がある」 ことの方には気持ち悪さを感じないんだねw
っていうか理解できないのか。>>857の人もそうだと思うけど。

だから、プログラマの意図というか要件は「ボタンABCDE全部が押されたのと同じことを起こすボタンが欲しい」
なんだけど。

869 ：
俺なら「ボタンが同時に押されないように作る若しくは押されても一つだけ有効にする」で組む方を優先するわ

870 ：
>>867
微妙、ではなくモデルに持たせるのが正解
>>868
中2とか意味わからん理由ではなく実益をとっただけ
理解しやすさ、テスタビリティ、変更への耐久性、等を考えればボタンクリックは、無い

プログラマ意図をコードに反映することは良い習慣だが
判断を誤ったプログラマの意図をコードに反映させることを正当化してはいけない
まずは判断を正してから意図をコードに落とし込もうね

871 ：
ﾜｯﾁｮｲ 477b-yNzz
ﾌﾞｰｲﾓ MM0e-BzDP
ｱｳｱｳｳｰ Sac3-+wK4
いつまで続ける気だよ役立たずどころかクソ迷惑

872 ：
>>871
C#のスレでFormsについて話し合うことの何が問題なんだ？
もともとはVC++だったけどこの話題はC#でも通じる話だからここで話してもなんの問題もないはずだ

873 ：
>>862
まあ君がどうしてもPowerShell推しなのはわかった。

> UI操作するオレオレDSLなんてまあバグだらけだろうな
それはオレオレDSLに無理に高度な機能を持たせすぎてるから。
つるんと書かれたDSLをただ上から順番に実行するだけ、しかもエミュレーションの時に、
何行のコードを追加し、何行の既存コードを変更する必要があると思ってるんだ？

面倒だから答えを言ってしまうが、追加が30-50行程度、既存変更は0行、つまり変更無しだ。
エミュレーションが開発的に強烈なのはこの、完全に外付け出来る点だ。
>>856,857の争点もここで、俺は849と思想が同じく、「そもそもテスト項目を増やすな」でしかない。
だからバグっててもDSLモジュール内で閉じてて精々DSL機能が使えなくなるだけで、
追加テストはエミュレーション部分のみ、というのは十分魅力的なんだよ。

そして君はAPIAPI言っているけど、PowerShellには特にAPIを用意する必要があるわけではないだろ。
publicにしてある関数を勝手に呼ぶだけ、精々ドキュメントを整備するくらいだ。
当然リフレクションを使えば内部関数等は全部抜けるので、呼ぶだけならいくらでも出来る。
リバースコンパイラを使えば分かるが、リフレクションでも割と読めるコードが得られる。
後は好きなだけハッキングしろ、でしかない。（これを、そそる、と言っている)

874 ：
あと、PowerShellにこだわりすぎて、強力なDSLなんてPowerShellでしか得られないと思ってないか？
気づいていないんだろうけど、「テキストファイルで操作する」というのはUnixのAPIであって、
そこに揃えるだけでUnix周りのツールが全て使えるようになるんだよ。
具体的に言うと、DSLソースをファイルではなく標準入力とすれば、
(一応言っておくがC#等GUIアプリもコマンドラインから起動すれば普通にパイプできる)
その前段のツールが標準出力に「CONTROL Button instancename Click」と吐きさえすれば自動化できるのだから、
PowerShellみたいな糞文法につき合う必要もなく、言語も選べる。当然、C#やPythonも使える。
これも一応具体的に言っておくと python myscript.py | my.NETapp.exe な。
だから高級なDSLが欲しいにしても、フルスペックのDSLを自前で持つ必要なんてまるでなくて、
自アプリ内はアホみたいに「食わされたコマンドを処理して終わり」なDSL実行部分だけで十分なんだよ。
それで後はAWK/Perl/Python/Ruby等、好きな言語使って勝手にやってくれ、になる。

つまり30-50行程度追加し、既存部分にバグが発生することもなく、
AWK/Perl/Python/Ruby等好きな言語を使って自動化出来るのがエミュレーションの利点であり、
Unixインタフェースに揃える美味さだ。だからみんなここから離れられない。

875 ：
>>867
一応調べてみたが、この場合は微妙だし、どっちでも良いと思う。
> https://hinative.com/ja/questions/11390949
> https://xcelgo.com/emulation-vs-simulation/
要は、中身まで模倣するのがemulationで、外面だけ合わせるのがsimulation。
よって実行速度は通常simulator>>>emulatorになる。


void Button_Clicked(Object^ sender, EventArgs^ e) {
some_func();
}

で some_func を直接呼ぶならsimulation、
Button_Clicked を呼んでもまあsimulation、
OnClick や PerformClick を呼ぶならemulation、というのが俺の見解。
emulation扱いの2つはClickイベントを発生させる＝UIスレッドのイベントキューに積むだけであり、
ハードウェアマウスのイベントと見分けが付かないから。
（内部的にハードウェアマウスのクリックを模倣している）
対して上記simulation扱いの２つは、
simulatorが「このボタンをクリックしたら結果的にこの関数を実行する」と知っていて、
外面動作を合わせる為にそこを呼んでいる。

当然emulationの実行速度はsimulationと比べて遅い。
だから、最初からsome_func()呼べよ、という若さは分かるが、そこをケチっても実質的意味はない。
ここら辺は年を取れば老獪になるというか、手の抜きどころが分かるようになる。
emulation方式だと当然、UIスレッドがハングアップしていたら永久に処理されないし、
未処理のイベントがあればその後に処理されることになる。
ここら辺は完全にハードウェアマウスの動作と同じになる。
simulation方式だと、すぐに呼ばれる為、
非UIスレッドでDSLを処理した場合、未処理のUIイベントがあると処理順序が逆転してしまう。
だから、DSL実行環境とGUIの実行環境が同一の場合はDSL処理はUIスレッドでやるしかない。
だったら最初からPerformClickでやればそういう心配すらないだろ、ということになる。

876 ：
余談だが>>857のUIテストが安定しないのはこの辺が大きい。
要は、GUIなんて所詮人間相手前提で組んであるのであって、
CPUの速度でイベントを積まれた場合にも正しく動くレベルまでのテストは為されていない事も多い。
技術的に見ればアプリが糞で組み方が悪いだけだが、そこまで保証する意味もないのも事実。
結果、「人間がやると動くが、CPUでやると動かない」なんてのは割とよく遭遇することになる。

だからまあ、「UIテストは安定しないから出来るだけ回避」も一つの戦術だが、
「UIテストも安定するようにちゃんと設計する」も一つの戦術なんだけどね。
「安定しない」のはあんまり正当化していい話でもないし、
ちゃんと設計されているアプリしか触ったことのない人にとってはポカーンな話でもあるとは思うよ。


ちなみに、文句を言っている連中に合わせるとしたら、以下のようなDSLにすればいい。

CONTROL Button instancename Click // PerformClickを呼ぶ
some_func() // some_func()を直接呼ぶ

これで、好きな方使えで済む話で、実際も、これに近い。
（当然だがDSL用のコマンドは別に持ってて、全部大文字なのはそれらと被らない為の方策）

877 ：
議論が発散しててよくわかんないな。
何が何なの？全員、アブストを書いたらどうだ？

878 ：
>>873
論点をずらそうとしてるね
クソみたいなUI操作オレオレマクロよりUI非依存のPSのが低コストで品質がいいねというだけの話だろ
例としてPSを出したが別になんだっていいよ
最も大きな問題はインタプリタの方ではなくUI操作でオートメーションサポートするというバカバカしい発想の方な
オートメーションをサポートするならUI非依存のAPIを整備しろ
それが正しい道だ

879 ：
話がまとまってないのに余談とか言っちゃって相手もそれに乗っかちゃって…
これを繰り返すからいつまで経っても収束しないし元の議題が何だったかわかりづらくなる

880 ：
>>867
>>875訂正、結果的に>>876は間違いなのでよろしく
俺の見解では全部simulationになる。


確認してみたら、PerformClickは同期イベントだった。
呼び出し履歴見る限り、Button.PerformClick->Button.Onclick->Control.OnClick->イベントハンドラ　なので、
OnClickもほぼ確実に同期だと思われる。
だから呼称は全て simulation の方が妥当となる。
イベントキューとかは全く関係なくなるので、該当部分の869の話は間違いということでよろしく。

同期イベントなのは.NETの癌だと思っていたが、
この点に関しては同期イベントの方がプログラミングしやすい、というのは事実だな。
(俺の想定の非同期イベントだと俺のコードは動かないはずなのに気づき、確認したところ、同期だったorz)

881 ：
>>878
> 論点をずらそうとしてるね
お前がだろ。
> UI操作でオートメーションサポートするというバカバカしい発想の方な
GUIの自動化ならGUIのエミュレーションが俺的に第一選択肢だ。
これについては既に>>849で言ったとおり、君が気に入らないのはどうぞご自由にだが、
最近話題のSeleniumでも同様なのだから、君が思うほど糞でもないんだよ。
もっとも汎用的で、もっともカッコ悪いが、どんな馬鹿でも使えるソリューションだ。
そして、やる気になればPerlやPythonと組み合わせて自由自在でもある。
ソースコード戦略にも、テストにも問題がない。ならこれで決まりでいい。

882 ：
>>881
Selenium系はAPIを提供してないサイトのオートメーションをユーザーが苦労して泣く泣く自動化したい場合やテスト自動化で使うツールな
俺らが今議論してるのはユーザー目線じゃなくて提供者側なんだよ
提供者側がAPI実装を放棄してGUI操作をサポートするなど馬鹿なことだ
ユーザーに苦労を押しつけてはいけない

883 ：
>>870
複数のボタンを全部クリックした時の動作、なんていう下らない機能を
モデルに持たせることが正当化されるケースってむしろあんまりないと思うよw

ぱっと思いつくのは、ボタンABCDEをクリックした時の処理に共通する部分
（例えばファイルのopen/closeのような前処理後処理）があって、まとめてやる場合には
大幅な最適化が可能な場合。

この人本当にプログラマかな。

884 ：
>>877
白鳥はすべて白い（PerformClickなんて100%ｲﾗﾈ）という人がいるので、
いやいや世界には黒い白鳥もいるんだよ、とまあそういう話

885 ：
>>883
その糞設計だと要件変化ですぐにコードが汚染されるだろうなぁ
処理は今までどおり実行したいが特定のボタンだけ画面から削除したくなったせいで謎のHiddenボタンを置いたり
処理の結果で後続の処理を分岐したくなったせいで不自然な制御フラグフィールドが乱立したり
画面のデザイン変えただけなのになぜか処理の実行順序が変わったり
少し想像しただけでトラブルの兆しがするするでてくる
こういう発想はアマチュアらしくて微笑ましいけど業務で見かけたら説教しなきゃいけないぐらいだ

886 ：
>>870
各ボタンに割り当ててるコマンドをcomposite Commandで繋いで終わりじゃない？

887 ：
>>885
よく分からない妄想ワロタw
意味が分からないよ

＞要件変化ですぐにコードが汚染される
まさにその通りw
君の設計方針だと必然的にそうなる。

888 ：
どーでもいい非必然的な機能をモデルに持たせることは、
UIにベタベタ処理を実装するのと同じ糞設計ですw

889 ：
一応言い訳しておくけど、>>883に書いたみたいに最適化の恩恵なんかなくても
複数の処理をまとめて一度にやるメソッドをモデルが持つことが自然なケースはもちろん存在すると思う。
っでも俺が言っているのは「黒い白鳥もいる」だからね。
「白鳥は全部白いは間違っている」と言ってるだけだから

890 ：
>>887
お前のやり方はではすぐにコードが汚くなるって言ってんの
俺のやり方はメンテナンスしやすいモデルを採用してるからコードの品質が維持される

891 ：
>>889
まとめて処理をする機能が要件にあるならそれをモデルに実装するのが王道で自然な方法
お前はそれをボタンクリックなどという大道芸的な方法で実装しようとしてる異端

892 ：
>>888
そうだ
だからまとめて処理をするという最小限の機能をモデルに実装せよと言ってる
ボタンクリックなどという余計なお遊びは入れなくていい

893 ：
こない未来を予測してる奴はバカ
絶対失敗する
しかも、最悪の形で

894 ：
>>893
来るかもしれない未来を考えないのも同じぐらい馬鹿だな
そして未来がわからんなら余計な拡張性を導入するのではなくコードを容易に改修できるようにシンプルに保つことが重要
つまりシンプルなモデルにやりたいことを素直に書けばそれでいい
それで済むものをわざわざボタンクリックなんていうやらなくていい遠回りな方法で実装するのは後で困る馬鹿の典型例

895 ：
>>882
だから君はちょっと意識が高すぎるんだよ。
自動化したいユーザーは、今やったのと同じ操作を100個のファイルに適用したいとかだ。
「ログに出てるコマンドをコピペすれば今やった操作を自動化出来ます」との情報を得て、ログを見たら、
CONTROL TextBox filename my000.jpg
CONTROL Button file_load Click
CONTROL Button filter_A Click
CONTROL Button file_save Click
となってたら、まともなプログラマなら適当にスクリプト書いて10分後には完了してる。
そこを「APIを調べてPowerShellでスクリプトを書いてください」だと困る奴の方が多いと思うが。
何でオレオレアプリのAPIをユーザーが一々調べないといけないんだよ？調べるだけで10分かかる。
方法は何でもよく、勿論APIでもいいんだけど、ユーザーは手っ取り早く今の処理を100個のファイルに展開したいだけ。
それには歴史的にも今も「テキストファイル内にコマンド羅列(＝つまりスクリプト)」という方法が用いられている。
これが一番分かりやすいからだよ。
PowerShellの「.NETアプリをインスタンス化して内部関数を直接呼ぶ」というのは発想としては面白いけど、
それが分かりやすいわけでもなく、汎用性があるわけでもなく、使いやすいわけでもない。
まあもうこれは堂々巡りだから終わりでいいが、
君の意見が正しければ、今後は全てのアプリでAPIが公開されていき、MS謹製のUIAutomationなんてゴミになることになる。
俺はそんなことにはならないと思うけど。

896 ：
>>895
だからよ
1処理用の処理を連続で100回動かしたら確認ダイアログが100回出るだろーが
バカかテメーは

897 ：
言い合いになるなら
構わなきゃいいのになあw

898 ：
>>895
意識は高くない普通の感覚だよ
当たり前のことを当たり前にやるだけだ
モデルに処理を書いてビューに紐付けるってごくごく自然なコードだろ

しかもそれすればほとんどタダでオートメーションサポート機能が手にはいるんだぞ
ボタンクリックとかわざわざ苦労してトラブルを持ち込んでくる意味わからねえわ
マゾなのか

899 ：
>>896
その程度の回避策が思いつかないようなバカがいるとは

900 ：
>>895
ちなみにこのマクロでわかりやすいと思うのはお前だけだぞ
普通の人だったら
オートメーションなのなんでコントロールを操らないといけないんだ意味わからん
ボタンとかテキストとか書かれても何やってるか意味わからん
各行の関連性が意味わからん
操作してるインスタンスはどのフォームだよ意味わからん
などなど大混乱してしまう

ユーザーが見てわかりやすいレコードログってのは↓こういうものな
$model = $MyAppHost.Resolve("MyModel")
$model.FileName = "..."
$model.LoadFile()
$model.FilterA()
$model.SaveFile()

この処理をたとえばカレントディレクトリ全体に適用したいなーってユーザーが思ったらls | foreachでパイプするだけ
お前の大好きなコード生成みたいなバカバカしい無駄な苦労をしなくて済む

901 ：
>>899
そこ工夫が必要ならこんなくだらんメソッド呼ばんわｗ

902 ：
>>895
例えばさぁ
お前のオレオレうんこマクロでファイルが存在しなかった場合のハンドリング処理はどうやって書くつもりなんだ？
ファイルの形式が間違ってた場合は？
セーブに失敗したときどうする？
指定したディレクトリツリーのファイルすべて処理したいときはどう書くんだ？

903 ：
直のWINAPI（というか多分アンマネージ）が混ざる動作だとDebugとReleaseで動き変わること割りとあってめんどくさいな

904 ：
>>903
単なるお前のバグだろ

905 ：
WINAPIのはDebugだと0埋めされるんだろ
そりゃ動作変わるって(バグがあればω)

906 ：
0じゃなく埋められる数値は何種類かある
デバッグリリースで挙動変わるのはほぼ確実にメモリ周りでなんかやらかしてるね

907 ：
>>900
俺はPowerShell知らんから推測文法で勝手に書くと
function apply_filterA(filename){ // (A)
echo CONTROL TextBox filename $finename
echo CONTROL Button file_load Click
echo CONTROL Button filter_A Click
echo CONTROL Button file_save Click
}
ls | foreach apply_filter
とかか？ まあ雰囲気は分かるだろ。どうしてもオブジェクト文法で書きたければ、property使える言語なら
ref class OreOreWrapper { // (B)
property String^ Filename {
void set(String^ filename){echo("CONTROL TextBox filename "+finename);}
}
} model;
とかかな。
俺が用意するのは公式UIAutomationでしか無い。
君は逆に何故UIAutomationがああなのか、また、
何故PowerShellなんて全く流行ってないのか、理解した方がいい。
既に言ったがコード戦略的には他にも色々理由はあるのだけど、それ以前に、
そもそも外面仕様的にも、.NET縛りになる糞APIを提供する意味なんて上記の通り、まるでないだろ。
Unixフォーマット(テキストと標準入出力)に揃えるのは、異様なほど自由度を提供する物なんだよ。
だからみんなそこから離れられない。

908 ：
君が間違えているのは、君が出来ているつもりになっている「レイヤー設計」だ。(>>826)
君の中ではPowerShell(中レベル)/アプリの2層しかないから
中レベルAPIをアプリ自体に求め、それで汎用性が全くなくなっている。
そうではなく、各言語向け中→低レベル変換ライブラリ（上記A,B等）を噛ませば、
各言語(中レベル)/各言語向けレベル変換ライブラリ/アプリ(低レベル）となり、
全ての言語で中レベルでも低レベルでも書ける状況になるだろ。
俺の好きなフォーマットで書かせろ、というのはいいが、それはAPIに直接求めるものではない。
どうせどんなAPI/フォーマットを提供したところで、全員が満足する事なんて無いんだ。
なら、上記のように、単純な関数化/ラップでそれぞれのオレオレ超最高フォーマットが手に入るのなら、
それは素晴らしいAPIってことになるんだよ。
そして本件なんて、文句を言った方が恥ずかしくなるレベルなのは君でも分かるだろ。

909 ：
>>907
まる一日以上かけてそれかよ
そんな汚いわかりにくいコードをありがたがるのはお前だけだぞ

さて>>902に答えるのに何日かかるかなｗ

910 ：
>>908
ホント残念なやつだな
アプリの中にさらに層が別れてるに決まってんだろ
それぞれの層をスクリプティング用に公開することもほぼノーコストでできる
薄汚いオレオレラッパーを大量生産する苦痛とは無縁だ
そんなこた言わなくてもわかることなんだがわからなかったか

911 ：
>>907
つうかな自由とハックを混同するな
そういうのは黒魔術的な方向に進化してあっという間にカオス化して行く
そんなものはだれもありがたがらない
製造元が頭の悪いマクロしか提供していないから泣く泣くラップ作業に着手するってんならまあ話はわかるが進んでやりたいことじゃねえわな

912 ：
>>909
まあもう一々答える気はないんだけどな。
本当に問題になることを突かれた場合は改善に繋がるから有用なのだけど、
君のレベルではそれは無理だし、実際に今回も恥ずかしいことになってるだろ。
多分君が根本的に間違っているのは、バグをバグと認識できてないことだ。
既に言ったがUIを噛ませて動作が不安定になるのは、明確にバグなんだよ。
それはCPUが余りまくっている暇人環境なら再現しにくいだけで、
他アプリでCPUを取られている場合においてはユーザー環境でも普通に再現する。
つまりCPUロードが高い状況では不安定になるわけで、これは普通にバグだよ。
だから君はまずそのバグを直さないといけない。
そうすると>>857の認識をだいぶ修正出来るだろうさ。

913 ：
>>912
答えられませんわかりませんって素直に言ったら？
潔さも時にはたいせつだよ

914 ：
>>912
つか不安定ってとこを拠り所にしてるようだが
仮に完全に安定しててもUI操作ベース貧弱文法のオレオレマクロなんて積極的に使う理由にならんからな
UI非依存のAPIを優先して他に何もなくてどうしてもUI操作せざるを得ないとなったらそこで初めて使うか別のツールに移行するか検討すんだよ
そこんとこはやく理解したほうがいいぞ
同僚や取引先にボタン押すオレオレマクロ機能をドヤ顔で提案して赤っ恥をかく前に気づいたほうがいい
これ本当に君が心配だから言ってる

915 ：
しかもな
もし仮に百万歩譲ってUI操作をサポートしなきゃならんとなったとしてもだ
そんなものはUIA、WinAppDriver、Seleniumに任せときゃいいんだよ
時間と金をかけて赤っ恥マクロを製造する必要はない
もうすでにゴミマクロの億万倍便利なライブラリがあるんだからそれつかいなよ
エンドユーザだってそっち使うよ当たり前だろ

916 ：
>>912
正常系だけ動けばいいマクロだったら人間用のUIを触るでもなんとかなるよ。
異常系もハンドリングしなければならないなら、何が出てくるかの一覧もないような、ダイアログに書かれてることを理解しなくちゃいけないんだから、網羅するのはめちゃくちゃ大変だと思わないかな。

人間用には問題を自然言語で全体的な説明する必要があって、
外部プログラム用には事前定義されたメッセージで問題を端的かつ詳細に伝える必要があって、
両者はプロトコルが大きく異なるんだから、人間用に外部プログラム用の伝え方をしたり、もしくはその逆ってのはどう考えても筋が悪い。

外部プログラムに人間シミュレーターをやらせたり、
人間に外部プログラムシミュレーターをやらせたら、
余計なレイヤーが必要になってバグの温床になるだろ。
「バグはバグだろ」とか言ってたって品質は改善しないので、そもそもバグが生まれにくい構造にしておくのが当たり前。
設計からやったことないのかな？

917 ：
>>916
ではまず、
・君的超最高な異常系ハンドリング方式、>>900と同様にコードで、と
・現状やたらあるタスクランナー等のどれ一つにもそれが採用されてない理由
を聞こうか。

918 ：
こういう返しをしてくるということは数日かけても本当に思いつかなかったんだなｗｗｗ

919 ：
>>917
あなたは話を逸らす傾向にあるから、その前に、まず、
「自分のオレオレマクロでは正常系での動作しか考えられていなくて、
正常系で動かないのであれば、バグはバグなんだから修正する必要があると言っていた。
だが、異常系への対応までは考慮することができていなかった」
ということを暗に表明していることを認めてもらえるかな？
異論があるならどこが違うのか指摘してくれ。

920 ：
ガイジの相手をしているところが間違っているね

921 ：
正常系と異常系がごちゃまぜで
どこが危なくてどこが危なくないのか全く区別がつかない

922 ：
毎度毎度スレ違いどころか明後日の方向レスの応酬やっている連中は病院行け

923 ：
漏れは、スクレイピングに、Ruby, Selenium WebDriver, Nokogiri を使う。
ブラウザの自動操作もできるし
ただ、各サイトの解析が大変。
特に、Ajax で動的に読み込むものは、読み込み前には存在しないから

924 ：
ところでこれ、既存の他アプリを操作するって話なの？
自分の既存アプリを多アプリが操作するって話なの？
多アプリで操作されるアプリを設計するって話なの？

925 ：
.NETってリバースされやすいけど、かといってそのためにC++で書くのも嫌（＋技術力が低いから出来ない）だから、

ゴマかすために部分的にC++で書いて、そのDLLを参照させてる・・・
って人いませんか。もちろん趣味の範囲の話です。

926 ：
部分的にってのは語弊がありました。ごまかすために無駄なコードをC＋＋で書いて、
それを参照するってことです。

927 ：
.NET 便利です。通信、非同期など、こんなのをネイティブ言語で自分で実装しようとしたら
難しいし、へたすれば逆に性能が悪いです。.NETを使ったほうが良いにきまっています。

一方で別に.NET言語でなくても書ける部分はC++で書いて参照するってことです。

928 ：
こんな感じで
TestDataGridView.Columns.Add("Number", "No.");
TestDataGridView.Columns.Add("Item", "項目");
for (int i = 0; i < Max; i++) {
TestDataGridView.Rows.Add(1);
TestDataGridView["Number", i].Value = (i + 1).ToString();
TestDataGridView["Item", i].Value = "";
}
初期化して、TestDataGridView["Item", i].Valueに何らかを代入して作業を終えて
中身を消そうと
for (int i = 0; i < Max; i++) {
TestDataGridView["Item", i].Value = "";
}
を実行するとGCがバカバカ発生して滅茶遅いのですが、なんでですか？

929 ：
GCがバカバカ発生したってのはどうやって確認したの？
遅い理由がGCにあるってどうやって確認したの？

930 ：
>>929
デバッグで起動して、右側の診断ツールのプロセスメモリのグラフに黄色のマークがどんどん現れたのです。

931 ：
WinformsならSuspendLayout & ResumeRayout(true)で囲ってみては？
DataGridViewってItemsSourceに代入するとき以外は代入するたびに表示の更新されるよね、確か

932 ：
>>931
やってみましたが変わらずです。
11列×256行で最初の2列はそのままで以降の列に計測値と計算値を代入して、次の測定でクリアするのですが、一回目は瞬時クリアで２回目以降は20秒くらい待たされます。
自動調節などは入れていません。

今まで同様なソフト作っていて初めての事です。

933 ：
プロファイラでどこが時間くってるか見てみれば？

934 ：
何らかの代入してる方に問題ありそう

935 ：
>>932
ミニマムコード作って動かしてみれば
それでそんな動作になるのなら諦めるか改めてそのコード示して質問するか
一回目と2回目の動きが変わるとかGCが頻繁に動くとかちょっとありえないし

936 ：
>>932
ちゃんと
TestDataGridView.SuspendLayout();
TestDataGridView.ResumeRayout(true);
って書いた？

これはコントロール毎にしか聞かないから、Form1のサスペンド呼び出しても子コントロールには効かない

937 ：
TestDataGridView.SuspendLayout();
//ここにTestDataGridViewの処理を書く
TestDataGridView.ResumeRayout(true);

いずれにしても20秒も掛かるとなると他に原因ありそうだな
一応自分はFlowLayoutPanelに自作コントロールをListViewのように並べるというソフト作ってた時、
1000個以上のアイテムを一気に追加すると数秒ラグってたのがこの手法によってほぼ一瞬で表示されるようにはなったが

938 ：
デバッガ表示見てるんだからプロファイラで問題箇所特定が一番早くて確実
その上で最小再現コード作ったり他の設定いじったり試行錯誤してみればいい

なんで便利な標準ツールを使わずに他の手法を進めるのか理解できない

939 ：
>>936
for文の前後に入れました。

940 ：
>>938
すまん、使いこなせないのだ。

941 ：
>>939
Resumeの()にはtrueじゃなくて空でした。
駄目？

942 ：
trueを渡せば停止中にキューに溜まってたものを一括でレイアウトするから低負荷にレイアウトが出来るって仕組みだったはず
なのでtrue引数入れないとパフォーマンス上の恩恵は得られない

943 ：
>>940
vs プロファイラでググればすぐ出てくる
どの関数がどれくらい処理時間くってるか全部出してくれる
何なら関数内のどの行がどれだけ処理時間かかってるかまでわかる
この点だけを調べるならマジで簡単だから一度試してみるといいよ

944 ：
true入れましたが駄目でした。
プロファイラ使ってみました。
１回目の状態です。
http://imgur.com/QRNwSP5.png
瞬時です。

２回目です。
http://imgur.com/cfzhpIi.png
時間かかってます。

セルに代入している時にGCが一杯発生してます。
http://imgur.com/IEzLFZa.png

使い方間違っているのかな？

945 ：
static な Main() の中で
await を使うと Main() に async が必要と言われ
Main() に async を付けると怒られました＞＜

946 ：
C#7.1(だっけ？)以降なら書けるから更新する
もしくはstatic async Task AsyncMain()みたいなのを挟む

947 ：
>>944
直接dataGridView触るとやたら遅くなるケースがあるから
データの追加削除等全部mainlistの方でやって、
こんな感じで更新する形に落ち着いたような　全然覚えてないような・・・

SortableBindingList<Model.hoge> sortableList = new SortableBindingList<Model.hoge>(Model.mainlist);
dataGridView1.DataSource = sortableList

C#も話題もよく分かってないから 見当違いだったらすまんね！

948 ：
>>947
ありがとう。
直接アクセスすると良くなさそうなんでlistでバインディング出来るか試そうとしてました。
明日、トライします。
MFCで少し書いていましたがC#だとめちゃくちゃ短いソースになるんで勉強します！
ハード周りはC++のDLLでやれそうで明るい未来になりそうです。

949 ：
DataGridViwのなんかのイベントで重い処理やってんじゃないのか

950 ：
>>948
SortableBindingListに関しては下記のページより、
https://docs.microsoft.com/ja-jp/previous-versions/dotnet/articles/ms993236(v=msdn.10)?redirectedfrom=MSDN
ぐぐって何番目かに出てくる、動物病院のページが参考になったよ 先生凄い
dataGridViewって利用者多いと思うんだけど、どれがスマートな利用方法かは調べにくいよね　頑張って！
>>949
詳しい解説や dataGridViewこう使うのが一番賢いぜ！って内容凄く聞いてみたい

951 ：
https://dobon.net/vb/dotnet/datagridview/

952 ：
がんばって

953 ：
autoScrollをtrueにしたPanel内で例えばcomboboxにフォーカスすると、スクロールバーが自動で上まで移動してしまいます。
それを解決するにはScrollToControlメソッドをoverrideしたPanelを作成すれば良いというところまではわかったのですが、
SplitContainer内のPanelの場合はどのようにすれば良いのかがわかりません。あまり頭が良くないので具体的なコードで教えていただけると助かります。

954 ：
>>953
SplitContainerのSplitterPanelはsealed classになっているからそっちで何とかしようとするとめんどくさそう
SplitterPanelの上にSizeとAnchor合わせた「ScrollToControlメソッドをoverrideしたPanel」を重ねるのが楽じゃない？

955 ：
>>953
正攻法でやるの面倒そうだから、その魔改造したPanelをSplitterPanelに入れて
Dock = Fillにしたら？
それにしても糞UIだねそれw
見えないComboBoxにフォーカスが当たっててマウスホイールに触っちゃったりしたら
いろいろイライラが募りそうw

956 ：
>>955-955
ありがとうございます。無事に実装できました。

957 ：
これ同一人物で精神分裂病だろ

958 ：
怖いことを言わないで

959 ：
実行モジュールをWindowsサーバーに常駐させてクライアントPCからのリクエストでサーバー上でコマンドを実行する
という仕組みに最適な.NETプロジェクトって何だと思いますか？
IIS建ててWebサービスかなと思うのですが1つのサービスのためにIIS建てるのは何か大袈裟だなと思いまして
よりモダンでイケてる仕組みがあったらお聞かせ頂きたいと

960 ：
常駐のための設定とか信頼性とか監視とか考えたら結局IISの方が手っ取り早くて楽
モダンでイケてるとか言い出したら今時WinサーバーかよとかオンプレかよとかAWSやGCPでKubernetes使えとかそういうそもそも論にしかならないのでナンセンス

961 ：
検索してやったぞ
https://qiita.com/0829/items/5518256b348521ac358c

自分なら環境が許せはコンソールアプリ常駐で（リクエスト）ファイル監視で作るかな

962 ：
名前付きパイプとかは？

963 ：
Windows限定で良いなら MSMQ とかは？

964 ：
>>959
embedIOで雑なHTTPサーバ作る。超楽。

965 ：
>>959
windows 用の sshd をサービスに登録して起動
リモート側から putty とか plink とかで操作

966 ：
windows 限定でセキュリティ気にしないなら psexec

967 ：
インターネットに公開するのかイントラネット内だけの話なのかで大分変わりそうだが

968 ：
Ruby なら、コマンドプロンプト・PowerShell から、1-liner で、
Rubyで作られた遅いウェブサーバー、WEBrick が起動する

ruby -run -e httpd . -p 8080

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

http://localhost:8080

969 ：
知らない技術が出てきて勉強になります
C#でさささと書ければ良いので色々試させて頂きます

970 ：
要件まとめずに実装方法から入ってあとで後悔するパターンだね
個人用途ならいいんだけど

971 ：
>>967
イントラのお気楽サーバーです
AD立ててるので操作ログにログインIDを記録することでセキュリティに替えたいと思います
中国軍のハッキング等は想定しておりません

972 ：
>>970
一部のチーム員が使うサーバ管理ツールです
すでにある実行ファイルを任意のタイミングで実行するのみのもの
DB使ったフラグのやり取りしてもと思ったのですが、実行ファイルをポーリングさせてリクエスト監視するのは効率悪いなと断念しました

973 ：
利用者がWindowsのサーバー管理をしてるんなら
Powershellが第一候補なんじゃないかな

認証やロギングの要件わからないけど
Invoke-Commandだけでも結構なことができるよ

974 ：
>>959
そんな時こそD-COMだよ！

975 ：
staticな拡張メソッドが作れれば割と便利な気がしないこともない

976 ：
>>959
普通に考えてまずWindowsサービスだろ
プロトコル等に規制がないならIISでもいいけど

977 ：
>>976
それは回答になってないだろ
winサービスを自前で作るんならクライアントから要求を受ける仕組みもセットで示さないと
まあその場合大抵はTCP系だろうが、だったら素直に最初からIISの方が手っ取り早い

978 ：
何言ってんだこの馬鹿

979 ：
誰に言ってんだｗ

980 ：
>>976
windowsサービスも考えたのですがクライアントとのやり取りをどうしようと
データベースでやり取りすればと思いましたがサービス側が周期的にデータベースへアクセスは辛いかなと

981 ：
>>959
.NETでないとダメなの？
> 実行モジュールをWindowsサーバーに常駐させてクライアントPCからのリクエストでサーバー上でコマンドを実行する
要件がこれだけならサーバーにOpenSSH入れてクライアントからログインしてコマンド投げるコード書けばいいだけかと

982 ：
>>981
それ実行モジュールが常駐してないじゃん

>>980
クライアントとのやり取りで悩むレベルならIIS一択

983 ：
>>982
> それ実行モジュールが常駐してないじゃん
サービスも知らんのか？

984 ：
C#はどうなるの？

985 ：
https://docs.microsoft.com/ja-jp/dotnet/framework/windows-services/walkthrough-creating-a-windows-service-application-in-the-component-designer
http://kenzauros.com/blog/add-own-installer-and-auto-start-to-windows-service-with-csharp/
https://symfoware.blog.えふしー2.com/blog-えんとり-1133.html
https://symfoware.blog.えふしー2.com/blog-えんとり-1132.html

986 ：
>>984
なくなるよ

987 ：
次世代言語C7に駆逐されることになってる

988 ：
エイプリルフールとかつまらん

989 ：
どんな言語も永遠ではない

990 ：
>>987
CR7な

991 ：
次スレは新しく立てずにこっちで
C#, C♯, C＃相談室 Part94
https://mevius.2ch.sc/test/read.cgi/tech/1553075856/
即死判定無いし削除依頼は機能してないからゴミスレがどんどん増える

992 ：2020/04/18
スーパーマン・・・(´･ω･｀)

プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
Rust Part6
D言語 Part34
☆★ Java の宿題ここで答えます Part 74 ★★
Pythonについて（アンチ専用）
Boost C++ Libraries Sandbox
WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part19
Excel VBA 質問スレ Part66
Java入門・初心者質問スレ Part.10
プログラミングのお題スレ Part11
--------------------
【実は】モデルの生活【極貧】
京王線の複々線・高架線化の是非 4
【バトル】嘘つき爺さんVS愉快な仲間たち
たとえばVIPファンスレ
【総合】長野県のバレーボールを語る【Vリーグ/大学/高校　等々】partⅠ
　　D　　A　　O　　v　s　　A　　D　　O　　
【糞運営】ポケコロ～かわいい育成SNS～97ドナ【テーブル疑惑】
ゆとり世代は犯罪者予備軍
大罪やスラムに逃げるくらいならプリコネやれ
音楽を楽しむのに音質の瑣末な差異は関係ないと思う
ニードフォースピードアンダーグラウンド２車道
(∵)どぼぢでぞんなごどずるのおおおおおお！？！？！！？
オマエらバイクに名前付けてる？
【コロナ速報】米国で1日に100人以上の死者　23日
【バーチャルYouTuber】.LIVEアイドル部アンチスレ#7641【アップランド】
【ブラック】マクロミル回答者ユニオン 123円目【正直者はバカをミル】
40過ぎて分かった事 Part.14
しってる？千葉市川署長杉田義弘★長崎ストーカー
関西ローカル番組感想スレ　98
【SAGI】【豚叩き専用】ぷよぷよ!!クエスト 1143【ぷよクエ】
TOP カテ一覧 スレ一覧 100～終まで 2ch元 削除依頼