■Visual Studio 2017 Community(無償の統合開発環境)等はこちら
http://www.visualstudio.com/downloads/
■コードを貼る場合はこちら
http://ideone.com/
■前スレ
C#, C♯, C#相談室 Part94
http://mevius.2ch.net/test/read.cgi/tech/1492843013/
■次スレは>>970が建てる事。
建てられない場合は他を指定する事。
VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured
C#, C♯, C#相談室 Part95
レス数が1000を超えています。これ以上書き込みはできません。
1デフォルトの名無しさん (ワッチョイ 7b7f-3FY0)
2017/10/17(火) 00:41:22.60ID:JxIRdCj702デフォルトの名無しさん (ワッチョイ 017f-3FY0)
2017/10/17(火) 00:42:40.72ID:JxIRdCj70 ■過去スレ
C#, C♯, C#相談室 Part90
http://echo.2ch.net/test/read.cgi/tech/1455160063/
C#, C♯, C#相談室 Part91
http://echo.2ch.net/test/read.cgi/tech/1467142749/
C#, C♯, C#相談室 Part91 (実質Part92)
http://echo.2ch.net/test/read.cgi/tech/1467211515/
C#, C♯, C#相談室 Part92 (実質Part93)
http://echo.2ch.net/test/read.cgi/tech/1485589613/
C#, C♯, C#相談室 Part94
http://mevius.2ch.net/test/read.cgi/tech/1492843013/
C#, C♯, C#相談室 Part90
http://echo.2ch.net/test/read.cgi/tech/1455160063/
C#, C♯, C#相談室 Part91
http://echo.2ch.net/test/read.cgi/tech/1467142749/
C#, C♯, C#相談室 Part91 (実質Part92)
http://echo.2ch.net/test/read.cgi/tech/1467211515/
C#, C♯, C#相談室 Part92 (実質Part93)
http://echo.2ch.net/test/read.cgi/tech/1485589613/
C#, C♯, C#相談室 Part94
http://mevius.2ch.net/test/read.cgi/tech/1492843013/
3デフォルトの名無しさん (ワッチョイ 017f-3FY0)
2017/10/17(火) 00:44:21.39ID:JxIRdCj704デフォルトの名無しさん (ワッチョイ 1181-xxCr)
2017/10/17(火) 01:01:00.68ID:opt3bdnY0 Dictionary.TryGetValueってどんなシーンで使う?
5デフォルトの名無しさん (スプッッ Sd73-0jJv)
2017/10/17(火) 04:05:33.86ID:64Shj4sfd ワッチョイスレは既に立っていますので重複です
C#, C♯, C#相談室 Part93
http://mevius.2ch.net/test/read.cgi/tech/1492818720/
本スレ誘導
C#, C♯, C#相談室 Part95
http://mevius.2ch.net/test/read.cgi/tech/1508180530/
C#, C♯, C#相談室 Part93
http://mevius.2ch.net/test/read.cgi/tech/1492818720/
本スレ誘導
C#, C♯, C#相談室 Part95
http://mevius.2ch.net/test/read.cgi/tech/1508180530/
6デフォルトの名無しさん (ササクッテロレ Sp87-6js8)
2017/12/22(金) 08:39:00.94ID:7XdQkYV8p7デフォルトの名無しさん (ワッチョイ ffb3-6aYH)
2017/12/22(金) 08:53:14.96ID:sp7ymsVp08デフォルトの名無しさん (ワッチョイ 89fa-9WOx)
2018/05/23(水) 21:01:17.50ID:Au5e7VGg0 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
3RP0W
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
3RP0W
9デフォルトの名無しさん (ワッチョイ a7fa-i/RF)
2018/07/05(木) 00:53:50.67ID:RfoszcD20 QBP
10デフォルトの名無しさん (オッペケ Sr03-zBb6)
2018/08/15(水) 22:24:37.15ID:xMngeBxOr PictureBox に次々と画像を表示すると、使用メモリがどんどん増えます。
PictureBox.Image.Dispose() を呼んでも変わらず、強制GCも利かず。
皆さんは、どの様に対処されてます?
PictureBox.Image.Dispose() を呼んでも変わらず、強制GCも利かず。
皆さんは、どの様に対処されてます?
11デフォルトの名無しさん (アウアウカー Sa0f-Nhff)
2018/08/17(金) 00:31:15.00ID:L6iTgn30a 日本語入力中の文字列や変換途中の文字列を取得してリアルタイムに出力したいんだが
どうやったらいい?
どうやったらいい?
12デフォルトの名無しさん (ワッチョイ 3703-Q0Kr)
2018/09/15(土) 00:15:15.09ID:8rxpHkWL0 壊れてなければリアルタイムに表示されとるやろ普通
何をいっとんのやコイツ?
何をいっとんのやコイツ?
13デフォルトの名無しさん (アウアウイー Sae3-+zFU)
2018/12/17(月) 19:01:40.46ID:UYXOgZv/a C#でJavadocのようなドキュメントを生成するツールを探していますが何かないのでしょうか?
14デフォルトの名無しさん (ワッチョイ ffd3-2dqZ)
2018/12/17(月) 19:09:18.60ID:72hjMHy3015デフォルトの名無しさん (アウアウイー Sae3-+zFU)
2018/12/18(火) 09:21:18.76ID:SVAz0FaDa16デフォルトの名無しさん (ワッチョイ ffba-vS77)
2019/02/01(金) 12:10:55.48ID:a5sB8C060 独習C# 新版買った人いますか?
async/await周りの記述は詳しいでしょうか?
async/await以降のマルチスレッド本が欲しい(async/await前のは持ってます)んですが、
おすすめを教えてください
async/await周りの記述は詳しいでしょうか?
async/await以降のマルチスレッド本が欲しい(async/await前のは持ってます)んですが、
おすすめを教えてください
17デフォルトの名無しさん (ワッチョイ 5fae-kMzi)
2019/02/01(金) 15:12:22.79ID:hduBTqlQ0 リアクティブプログラミングの本とか?
18デフォルトの名無しさん (ブーイモ MM03-i9IT)
2019/02/01(金) 17:14:51.42ID:j4fLIOVKM イディオムかな
19デフォルトの名無しさん (ワッチョイ a701-rbBm)
2019/03/09(土) 01:17:01.33ID:zk58FQoZ0 >>10
Pic.Imageに設定したやつをディスポしてないんじゃね?
Pic.Imageに設定したやつをディスポしてないんじゃね?
20デフォルトの名無しさん (ワッチョイ efa9-FfYY)
2019/03/10(日) 14:58:42.56ID:ENU6jwJt021デフォルトの名無しさん (ワッチョイ 1f7b-qion)
2019/03/10(日) 15:58:02.62ID:lXJk3Jp70 ある程度は増えるがフィールドなどで抱え込んでいない限りGCがそのうち片付けてくれる
片付けるタイミングは環境によっても変わるのでどうしようもない
if (Image!=null) Image.Dispose;
Image=null;
GC.Collect();
と並べておくと何とかなるかもしれないが、これで駄目だったこともあるw
片付けるタイミングは環境によっても変わるのでどうしようもない
if (Image!=null) Image.Dispose;
Image=null;
GC.Collect();
と並べておくと何とかなるかもしれないが、これで駄目だったこともあるw
22デフォルトの名無しさん (ワッチョイ 1e1c-87UU)
2019/03/11(月) 23:50:39.49ID:Aga3WO5M0 using(Image){/*NO OP*/}が一番楽じゃねえの?開放。
23デフォルトの名無しさん (ワッチョイ 932c-McIj)
2019/03/12(火) 06:57:58.76ID:u7hxzk6s0 >>22
あたりまえだけどusing抜けたら画像が表示されなくなるからPictureBoxの画像を次々と差し替えるのには適さない
あたりまえだけどusing抜けたら画像が表示されなくなるからPictureBoxの画像を次々と差し替えるのには適さない
24デフォルトの名無しさん (ワッチョイ 73ef-lxI/)
2019/03/18(月) 17:47:01.83ID:IuFF1Fl80 Windows8のコマンドプロンプトでcsファイル実行しても操作可能なプログラムとして認識されていませんとか出るんだけどどうしたらいいかな
VSみたいなアカウント登録が必要なのは論外だからアカウント不要な開発環境で
VSみたいなアカウント登録が必要なのは論外だからアカウント不要な開発環境で
25デフォルトの名無しさん (ワッチョイ cf63-oGl6)
2019/03/18(月) 17:58:27.59ID:Tplellnd0 >>24
VSはアカウント登録しなくても使えるよ
VSはアカウント登録しなくても使えるよ
26デフォルトの名無しさん (ワッチョイ 9361-h1+v)
2019/03/18(月) 18:14:49.07ID:lC4FotEs0 直接csc叩け
27デフォルトの名無しさん (ワッチョイ ff01-jA9u)
2019/03/18(月) 18:31:06.06ID:4bO+uLM30 >>24
notepad.exe + csc.exe
notepad.exe + csc.exe
28デフォルトの名無しさん (ワッチョイ 6388-E+DK)
2019/03/18(月) 18:31:22.52ID:dVHfVzUE0 何で論外になるのか知らんけどVS嫌ならVS codeにでもすれば?
つうかcsファイルが開けないってだけならサクラエディタでも入れれば?
つうかcsファイルが開けないってだけならサクラエディタでも入れれば?
29デフォルトの名無しさん (アウアウエー Sadf-FtxA)
2019/03/18(月) 20:02:22.69ID:GzoPXNc2a30デフォルトの名無しさん (ワッチョイ ffad-OnF4)
2019/03/18(月) 23:42:29.99ID:n7FtwzLH0 csファイル実行って書いてるから
csファイルが実行可能形式かスクリプト言語だと思っている???
csファイルが実行可能形式かスクリプト言語だと思っている???
31デフォルトの名無しさん (ワッチョイ cf2c-Of+3)
2019/03/18(月) 23:52:43.64ID:e1XJ4IHa0 notepad.exe は、メモ帳だろ。
notepad は、メモ帳を使うコマンドだろ
エディタは関係ないだろw
notepad は、メモ帳を使うコマンドだろ
エディタは関係ないだろw
32デフォルトの名無しさん (ワッチョイ ff7d-qSNg)
2019/03/19(火) 01:59:31.74ID:L0g4cJmZ0 コンパイルしないと実行ファイルにならないで
33デフォルトの名無しさん (スッップ Sd1f-E+DK)
2019/03/19(火) 08:16:05.74ID:4uo186SGd コマンド?
exeがなかったらexeつけたファイルがあるか探索するだけだよ
csファイルを実行したんだろ
登録された拡張子じゃないからどうすりゃいいのって質問でしょ
どんだけ読解力無いの
exeがなかったらexeつけたファイルがあるか探索するだけだよ
csファイルを実行したんだろ
登録された拡張子じゃないからどうすりゃいいのって質問でしょ
どんだけ読解力無いの
34デフォルトの名無しさん (ワッチョイ cf63-/SkX)
2019/03/19(火) 08:29:12.81ID:G0T8TIFf0 まあ24への回答だったら
馬鹿には無理
で十分よ
馬鹿には無理
で十分よ
35デフォルトの名無しさん (ワッチョイ 7370-B7Il)
2019/03/19(火) 08:39:01.56ID:m7J+vmgi0 ■「C#」「Visual studio」「Windows EXE実行ファイル」のリリースについての質問です
Visual studio(C#)でコンパイルした、
Windows EXE実行ファイルのリリースについて質問です。
バッチシステムとしてタスクスケジューラーで起動させますが、
頻繁にシステム改修があり、都度リリースが必要です。
しかし、システム実行中にリリース(EXEファイルの上書き)を行うと、
起動中のため上書きエラーとなります。
実行中のEXEに対して、
次回の実行分から最新のシステム改修を反映させるには、
どのようにしたら良いでしょうか?
以下私の案がございますが、スマートではありませんし、
実行開始に時間がかかるデメリットがございます。
他にスマートな案はございますでしょうか?
起動に関するフレームワークなどあるのでしょうか。
<案>
1.処理開始時に本体EXEファイルをコピーして実行版EXEファイルを作成する(同一のEXEファイル)
2.実行版EXEファイルを起動する
3.実行中でも本体EXEファイルは上書き可能なため、本体EXEファイルに対してリリース(EXEファイルの上書き)を行う
Visual studio(C#)でコンパイルした、
Windows EXE実行ファイルのリリースについて質問です。
バッチシステムとしてタスクスケジューラーで起動させますが、
頻繁にシステム改修があり、都度リリースが必要です。
しかし、システム実行中にリリース(EXEファイルの上書き)を行うと、
起動中のため上書きエラーとなります。
実行中のEXEに対して、
次回の実行分から最新のシステム改修を反映させるには、
どのようにしたら良いでしょうか?
以下私の案がございますが、スマートではありませんし、
実行開始に時間がかかるデメリットがございます。
他にスマートな案はございますでしょうか?
起動に関するフレームワークなどあるのでしょうか。
<案>
1.処理開始時に本体EXEファイルをコピーして実行版EXEファイルを作成する(同一のEXEファイル)
2.実行版EXEファイルを起動する
3.実行中でも本体EXEファイルは上書き可能なため、本体EXEファイルに対してリリース(EXEファイルの上書き)を行う
36デフォルトの名無しさん (ワッチョイ 6388-E+DK)
2019/03/19(火) 09:07:23.60ID:CPLZKK98037デフォルトの名無しさん (ワッチョイ ff4b-NxE7)
2019/03/19(火) 09:14:33.95ID:3S//TzO00 >>35
一般的には起動時に更新が存在するかをチェック。
あれば更新してから実行。
この時、自分自身は更新できないから回避方法は大きく2つ。
・更新時に別プロセスを起動して更新させる。
・起動用プロセスがチェック、更新、実行プロセスの起動を行う。
自分なら後者を使う。
一般的には起動時に更新が存在するかをチェック。
あれば更新してから実行。
この時、自分自身は更新できないから回避方法は大きく2つ。
・更新時に別プロセスを起動して更新させる。
・起動用プロセスがチェック、更新、実行プロセスの起動を行う。
自分なら後者を使う。
38デフォルトの名無しさん (ワッチョイ ff61-kdx8)
2019/03/19(火) 12:10:38.03ID:LicdY6jn0 この人あらゆるサイトにマルチポストしてますね
39デフォルトの名無しさん (ワッチョイ 937b-iGub)
2019/03/19(火) 18:42:15.21ID:YCqruXzc0 ちょっとググっただけで5ch以外で五ヶ所くらい見つかるな
本人か別の人が貼りまくってんのか。どっちにしても春爛漫な人のようだ
マジレスした人お疲れ
本人か別の人が貼りまくってんのか。どっちにしても春爛漫な人のようだ
マジレスした人お疲れ
40デフォルトの名無しさん (ワッチョイ 237d-KxX0)
2019/04/25(木) 12:02:44.25ID:4R4XZvlv0 C#でセレニウムにチャレンジしています。
Chromeを起動すると「Chromeは自動テスト ソフトウェアによって制御されています」と
メッセージが表示されてうざいです。
これを非表示にする方法はないでしょうか?
Chromeを起動すると「Chromeは自動テスト ソフトウェアによって制御されています」と
メッセージが表示されてうざいです。
これを非表示にする方法はないでしょうか?
41デフォルトの名無しさん (ワッチョイ 3512-peSw)
2019/04/25(木) 12:14:25.25ID:Pe+Vku0k0 マルチンポ
42デフォルトの名無しさん (ワッチョイ 6563-Tko9)
2019/04/25(木) 17:44:55.50ID:LsEtYAXi0 >>40
君には無理
君には無理
43デフォルトの名無しさん (ワッチョイ 237d-KxX0)
2019/04/25(木) 19:24:14.09ID:4R4XZvlv0 C#でセレニウムにチャレンジしています。
Chromeを起動すると「Chromeは自動テスト ソフトウェアによって制御されています」と
メッセージが表示されてうざいです。
これを非表示にする方法はないでしょうか?
Chromeを起動すると「Chromeは自動テスト ソフトウェアによって制御されています」と
メッセージが表示されてうざいです。
これを非表示にする方法はないでしょうか?
44デフォルトの名無しさん (ラクペッ MM91-peSw)
2019/04/25(木) 21:07:39.01ID:KcxI9mhOM 無理よー無理無理
45デフォルトの名無しさん (スプッッ Sd03-Neyz)
2019/04/25(木) 21:22:54.09ID:Y4s3yTN3d うざいメッセージはNGに突っ込むと非表示になるよ
46デフォルトの名無しさん (ワッチョイ 237d-KxX0)
2019/04/26(金) 02:48:58.81ID:P0GkOuW/0 C#でセレニウムにチャレンジしています。
Chromeを起動すると「Chromeは自動テスト ソフトウェアによって制御されています」と
メッセージが表示されてうざいです。
これを非表示にする方法はないでしょうか?
Chromeを起動すると「Chromeは自動テスト ソフトウェアによって制御されています」と
メッセージが表示されてうざいです。
これを非表示にする方法はないでしょうか?
47デフォルトの名無しさん (ワッチョイ 237d-KxX0)
2019/04/30(火) 10:29:54.76ID:aEHW+H2s0 C#でセレニウムにチャレンジしています。
Chromeを起動すると「Chromeは自動テスト ソフトウェアによって制御されています」と
メッセージが表示されてうざいです。
これを非表示にする方法はないでしょうか?
Chromeを起動すると「Chromeは自動テスト ソフトウェアによって制御されています」と
メッセージが表示されてうざいです。
これを非表示にする方法はないでしょうか?
48デフォルトの名無しさん (ラクッペ MMe1-peSw)
2019/04/30(火) 11:25:48.00ID:2EfrguiEM まだやってたの(苦笑)
49デフォルトの名無しさん (ワッチョイ 234b-Dy63)
2019/04/30(火) 11:29:08.25ID:FOFXj9fL0 BOTでしょ。気になるならNGにしとき。
50デフォルトの名無しさん (ワッチョイ 6563-Tko9)
2019/04/30(火) 12:53:10.84ID:U6s2JtRt0 varでも使っとけや
51デフォルトの名無しさん (ワッチョイ 237d-KxX0)
2019/04/30(火) 13:51:49.79ID:aEHW+H2s0 C#でセレニウムにチャレンジしています。
Chromeを起動すると「Chromeは自動テスト ソフトウェアによって制御されています」と
メッセージが表示されてうざいです。
これを非表示にする方法はないでしょうか?
Chromeを起動すると「Chromeは自動テスト ソフトウェアによって制御されています」と
メッセージが表示されてうざいです。
これを非表示にする方法はないでしょうか?
52デフォルトの名無しさん (アウアウエー Sa13-PPr9)
2019/04/30(火) 14:54:31.08ID:9iFOigCpa そろそろ通報しとくか
53デフォルトの名無しさん (ワッチョイ 237d-KxX0)
2019/04/30(火) 15:12:51.52ID:aEHW+H2s0 C#でセレニウムにチャレンジしています。
Chromeを起動すると「Chromeは自動テスト ソフトウェアによって制御されています」と
メッセージが表示されてうざいです。
これを非表示にする方法はないでしょうか?
Chromeを起動すると「Chromeは自動テスト ソフトウェアによって制御されています」と
メッセージが表示されてうざいです。
これを非表示にする方法はないでしょうか?
54デフォルトの名無しさん (ワッチョイ 067b-15o0)
2019/05/08(水) 23:34:40.33ID:JTdgk5iA0 docsに.NET Framework 4.8対応の表記並んでいたからリリースされたのかと思ったら18日からか
55デフォルトの名無しさん (ワッチョイ c461-NNKj)
2019/05/22(水) 17:15:08.68ID:jBS0JRHS0 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よりそんなに優れている」ということに私は賛同しかねます。
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よりそんなに優れている」ということに私は賛同しかねます。
56デフォルトの名無しさん (ワッチョイ c461-NNKj)
2019/05/22(水) 17:18:44.42ID:jBS0JRHS0 この文章で一番重要なのは、2018/08/24 の時点で、「C#はまだ人気が無い」
と書かれていること。
本場アメリカでは、C#は人気がないらしい。実際、C++のスレッドは、C#の
スレッドの3倍弱程度存在している。そして、Javaは、C++の数割り増し程度。
つまり、C++ を 1.0 とすると、
Java : C++ : C# = 1.3 : 1.0 : 0.36
程度の人気。
と書かれていること。
本場アメリカでは、C#は人気がないらしい。実際、C++のスレッドは、C#の
スレッドの3倍弱程度存在している。そして、Javaは、C++の数割り増し程度。
つまり、C++ を 1.0 とすると、
Java : C++ : C# = 1.3 : 1.0 : 0.36
程度の人気。
57デフォルトの名無しさん (ワッチョイ c461-NNKj)
2019/05/22(水) 17:21:17.26ID:jBS0JRHS0 ジェネリック、ネイティブコード、そしてC#がJavaよりも優れていることに
ついての他の多くのことについて、デリゲートなど、あなたがコメントで
述べたものはすべて無意味です。これらの機能は、どちらかの言語を使用する
プログラマの95%には使用されていないか、または必要とされていません
(私はその割合を引き下げただけです。まったく意味がありません)。
C#がJavaでできないことはありません。それに加えて、Javaは本当に、
絶対にそして明白にクロスプラットフォームです。私は毎日クロスプラット
フォームのソフトウェアを書くためにそれを使います。一方、C#はMicrosoft
のファン用です。私のすべてのプロジェクトでMicrosoftスタックを使うよう
に制限されたくはありません。私はVisual Studioが神の地球上で最高のIDE
であると認めますが、それはそれについてのみのことです。
ついての他の多くのことについて、デリゲートなど、あなたがコメントで
述べたものはすべて無意味です。これらの機能は、どちらかの言語を使用する
プログラマの95%には使用されていないか、または必要とされていません
(私はその割合を引き下げただけです。まったく意味がありません)。
C#がJavaでできないことはありません。それに加えて、Javaは本当に、
絶対にそして明白にクロスプラットフォームです。私は毎日クロスプラット
フォームのソフトウェアを書くためにそれを使います。一方、C#はMicrosoft
のファン用です。私のすべてのプロジェクトでMicrosoftスタックを使うよう
に制限されたくはありません。私はVisual Studioが神の地球上で最高のIDE
であると認めますが、それはそれについてのみのことです。
58デフォルトの名無しさん (ワッチョイ c461-NNKj)
2019/05/22(水) 17:28:47.03ID:jBS0JRHS0 「C#開発者よりもはるかに多くのJava / Python /他の言語の開発者がいる」
と書かれている。
と書かれている。
59デフォルトの名無しさん (ワッチョイ c461-NNKj)
2019/05/22(水) 17:41:08.19ID:jBS0JRHS0 KotlinはSwiftに似ていて、JVM上で動くSwift、という感覚なんだそうだ。
60デフォルトの名無しさん (ワッチョイ c461-NNKj)
2019/05/22(水) 17:42:35.27ID:jBS0JRHS0 「その名前にもかかわらず、C#はC ++よりもJavaに近いです。」
61デフォルトの名無しさん (ワッチョイ c461-NNKj)
2019/05/22(水) 18:00:54.62ID:jBS0JRHS0 アメリカでは、MS以外の大手IT企業で、C#を使用しているところはほぼないらしい。
逆にJavaはほぼ全ての大手IT企業が使用していると書かれている。
驚き・・・。
逆にJavaはほぼ全ての大手IT企業が使用していると書かれている。
驚き・・・。
62デフォルトの名無しさん (スフッ Sd94-cyZN)
2019/05/22(水) 18:13:05.15ID:xw9W3h2yd Java guyだからわかんないんじゃないの?
カツ丼食ったことない人に、カツは不要、必要とされてないと言われてもなんの説得力も無い。
単にJavaで開発してる人の周りにはJavaで開発してる人だらけなだけっしょ。
カツ丼食ったことない人に、カツは不要、必要とされてないと言われてもなんの説得力も無い。
単にJavaで開発してる人の周りにはJavaで開発してる人だらけなだけっしょ。
63デフォルトの名無しさん (ドコグロ MM2e-A+mh)
2019/05/22(水) 19:10:57.52ID:iIF1m3tOM 別に他の人がC#使ってるかどうかなんてどうでもいいし
自分が書き易けりゃいいよ
自分が書き易けりゃいいよ
64デフォルトの名無しさん (ワッチョイ 1c79-N32O)
2019/05/22(水) 19:18:04.88ID:MzmNNcgl0 C++は置いておくとしてJavaがC#に勝る点なんて
ジェネリックもデリゲートも使えないようなエンジニアものどきの数くらいだろ
ジェネリックもデリゲートも使えないようなエンジニアものどきの数くらいだろ
65デフォルトの名無しさん (アウアウカー Sa0a-qY1O)
2019/05/22(水) 19:52:44.58ID:2lRo2w4aa .NET5が出たら本気出すってことか?
66デフォルトの名無しさん (アウアウウー Saab-r78r)
2019/05/24(金) 08:09:17.65ID:igiSdUACa 確かにCOBOLからJavaに置き換える案件は多い
67デフォルトの名無しさん (ワッチョイ 8761-/n6F)
2019/05/24(金) 08:51:40.63ID:05/tcy9p0 >>64
Quora英語版によれば、
・言語の使い勝手は言語そのもの良し悪しだけでなく、トータルで決まる。
(ただし、言語そのものもC#がJavaよりそんなに優れているわけではないとのこと。)
・Javaは今までに形成されたエコシステムがかなり大きい。
・JavaはかなりMultiplatformだが、C#はそこまでには至っておらず、
ほぼWindows限定になる、とされている。
・C#がJavaよりも優れた点は、Javaそれほど使用頻度の高いものではない。
・Javaの開発環境は無料だが、C#の開発環境はかなり高価。
・C#はMSの独占的なもの。
・今までJavaを使ってきて、C#に乗り換えるのは大変。
・C#が数としては使われているとしても、愛されているわけではないが、
Javaは愛されている。
Quora英語版によれば、
・言語の使い勝手は言語そのもの良し悪しだけでなく、トータルで決まる。
(ただし、言語そのものもC#がJavaよりそんなに優れているわけではないとのこと。)
・Javaは今までに形成されたエコシステムがかなり大きい。
・JavaはかなりMultiplatformだが、C#はそこまでには至っておらず、
ほぼWindows限定になる、とされている。
・C#がJavaよりも優れた点は、Javaそれほど使用頻度の高いものではない。
・Javaの開発環境は無料だが、C#の開発環境はかなり高価。
・C#はMSの独占的なもの。
・今までJavaを使ってきて、C#に乗り換えるのは大変。
・C#が数としては使われているとしても、愛されているわけではないが、
Javaは愛されている。
68デフォルトの名無しさん (ワッチョイ df4b-pwRx)
2019/05/24(金) 09:02:59.96ID:lAxT3vyt069デフォルトの名無しさん (ワッチョイ 6788-/+qw)
2019/05/24(金) 09:16:04.73ID:kloIg+HC0 私見というか私怨すら感じるw
javaの魅力が伝わってこない
javaの魅力が伝わってこない
70デフォルトの名無しさん (ワッチョイ 6788-/+qw)
2019/05/24(金) 09:19:51.94ID:kloIg+HC0 C#がMS独占っていうけどjavaはoracle独占じゃないの?
71デフォルトの名無しさん (ラクッペ MM2b-6Xxa)
2019/05/24(金) 09:40:39.23ID:P3eS9itCM 正しくはJCP独占
なぜならTCKに合格しなければJavaであることは認められず、TCKを管理してるのがJCPだから
JCPはOracleの傀儡だろという意見は受け付けます
なぜならTCKに合格しなければJavaであることは認められず、TCKを管理してるのがJCPだから
JCPはOracleの傀儡だろという意見は受け付けます
72デフォルトの名無しさん (ワッチョイ df4b-pwRx)
2019/05/24(金) 09:48:45.17ID:lAxT3vyt0 JCPで検索かけたら・・・w
73デフォルトの名無しさん (ワッチョイ 8761-/n6F)
2019/05/24(金) 11:12:31.29ID:05/tcy9p0 >>69
本場アメリカと5chとの違いかも知れん。
本場アメリカと5chとの違いかも知れん。
74デフォルトの名無しさん (ワッチョイ 07e4-GYMe)
2019/05/24(金) 11:13:51.92ID:6vtlfMC30 Java EEは今後JCPを使わず
https://www.infoq.com/jp/news/2018/01/no-jcp-for-javaee/
>オラクルは今後のJava EEの拡張に対してJCP (Java Community Process)を使うことを支持、推奨していない。
https://www.infoq.com/jp/news/2018/01/no-jcp-for-javaee/
>オラクルは今後のJava EEの拡張に対してJCP (Java Community Process)を使うことを支持、推奨していない。
75デフォルトの名無しさん (スプッッ Sd7f-/+qw)
2019/05/24(金) 11:17:28.35ID:Y8PgvzDud そんなに本場アメリカを啓蒙するなら本場アメリカに行けばいいにでは?
76デフォルトの名無しさん (スフッ Sdff-x288)
2019/05/24(金) 12:39:15.94ID:iXpyShWxd >>67
主観というかJavaを愛しすぎて履かせた下駄すら見えなくなってるな。
主観というかJavaを愛しすぎて履かせた下駄すら見えなくなってるな。
77デフォルトの名無しさん (ドコグロ MM9f-LXA5)
2019/05/24(金) 12:44:10.24ID:8pSuDyEhM >>67
10年前ならまあどういしただろうけど、おじいちゃんの意見は今更どうでもいい
10年前ならまあどういしただろうけど、おじいちゃんの意見は今更どうでもいい
78デフォルトの名無しさん (ワッチョイ dff9-nozY)
2019/05/24(金) 13:00:38.95ID:y+lys2lm0 unityもあるしな
79デフォルトの名無しさん (アウアウエー Sa9f-n8n+)
2019/05/24(金) 20:36:14.08ID:ABZKxWnCa Coreもどーせ頓挫すると思ってたが存外ガチにやってきてるな
>>67何時の記事か知らんけど全く現状に即していない
>>67何時の記事か知らんけど全く現状に即していない
80デフォルトの名無しさん (ワッチョイ 2701-2jib)
2019/05/29(水) 18:21:13.04ID:mJlxjjN/0 javaと聞くとCOBOLと同じ感情を抱くようになった
特にラムダ機能以降
特にラムダ機能以降
81デフォルトの名無しさん (ワッチョイ df79-buEI)
2019/05/29(水) 19:55:22.71ID:qkuyzewN0 実際今のJava使いなんてコボラー2世みたいなもんだろ
82デフォルトの名無しさん (ブーイモ MM8a-r9gy)
2019/05/31(金) 14:06:42.31ID:MtNeYm5bM 元からじゃね?
83デフォルトの名無しさん (ワッチョイ eada-IoUc)
2019/06/01(土) 13:07:38.67ID:tnqKk6pO084デフォルトの名無しさん (ワッチョイ ea2c-2omG)
2019/06/01(土) 15:15:29.99ID:EpzVxqsJ0 AKlass.Foo()って呼ばれたらどうするんだよ
どう書こうがAKlass.Foo()の呼び出しにコンパイルされるからそのままじゃ無理
InheritedKlassとAnotherInheritedKlassそれぞれにFooを定義して
protectedなAKlass.FooCoreを呼び出すとかすれば?
どう書こうがAKlass.Foo()の呼び出しにコンパイルされるからそのままじゃ無理
InheritedKlassとAnotherInheritedKlassそれぞれにFooを定義して
protectedなAKlass.FooCoreを呼び出すとかすれば?
85デフォルトの名無しさん (ワッチョイ eada-IoUc)
2019/06/01(土) 15:55:32.30ID:tnqKk6pO0 やっぱりそうするしかないか
適当に自動生成させる方法考えよう
適当に自動生成させる方法考えよう
86デフォルトの名無しさん (アウウィフ FFb3-hHHL)
2019/06/09(日) 14:15:26.18ID:02v9wbJMF WPFでの開発をやりたいのですが
prismを使った開発手法が一般的なんでしょうか
prismを使った開発手法が一般的なんでしょうか
87デフォルトの名無しさん (スフッ Sdd7-Q7h/)
2019/06/09(日) 14:47:24.44ID:FIpX7RO5d >>86
一般的だったんだけど、MSの手を離れてからどうにも信憑性が薄くなったような…
機能自体は便利になってるんだけど、ベースクラスの削除とか平気でやるからバージョンによってテンプレートが使えなくなる印象
それでも使わないと面倒が臭すぎるから使うけど
一般的だったんだけど、MSの手を離れてからどうにも信憑性が薄くなったような…
機能自体は便利になってるんだけど、ベースクラスの削除とか平気でやるからバージョンによってテンプレートが使えなくなる印象
それでも使わないと面倒が臭すぎるから使うけど
88デフォルトの名無しさん (アウアウカー Sad3-hHHL)
2019/06/09(日) 15:18:30.20ID:P7OmBcI8a >>87
ありがとうございます
そうなんですね。。でもまぁ初心者が自前で全部シコシコするよりは全然ですよね
ちょっと頑張って勉強してみます
ちなみに、 Prirm.Coreと Prism.Wpfの両方を入れればいいのですか?
ありがとうございます
そうなんですね。。でもまぁ初心者が自前で全部シコシコするよりは全然ですよね
ちょっと頑張って勉強してみます
ちなみに、 Prirm.Coreと Prism.Wpfの両方を入れればいいのですか?
89デフォルトの名無しさん (ワッチョイ bf63-KqSM)
2019/06/09(日) 15:46:48.83ID:2sqBIYy90 答えはyesです
90デフォルトの名無しさん (ワッチョイ 8763-yXBe)
2019/06/09(日) 16:26:35.71ID:fG0JnxBE0 >>88
WPF初心者ならまずはPrism使わずにコードビハインドにイベントベタ書きするのをおすすめする
WPF初心者ならまずはPrism使わずにコードビハインドにイベントベタ書きするのをおすすめする
91デフォルトの名無しさん (アウアウカー Sad3-hHHL)
2019/06/09(日) 20:44:11.71ID:zPw/481Xa >>90
ありがとうございます
・コードビハインドでの実装
・prismを使わない場合のMVVMの実装
・prismを使った場合の実装
をそれぞれ一通り確認して、仕組みの勉強は軽くだけですがしてみました
今後開発するにあたって仕組みの理解を深めつつ、どの手法で行うのがいいのか聞いてみました
formの経験はそこそこあるのですが、WPFは初めてなのでアドバイス助かります
ありがとうございます
・コードビハインドでの実装
・prismを使わない場合のMVVMの実装
・prismを使った場合の実装
をそれぞれ一通り確認して、仕組みの勉強は軽くだけですがしてみました
今後開発するにあたって仕組みの理解を深めつつ、どの手法で行うのがいいのか聞いてみました
formの経験はそこそこあるのですが、WPFは初めてなのでアドバイス助かります
92デフォルトの名無しさん (ワッチョイ f101-4gXx)
2019/06/23(日) 15:07:10.60ID:4oGZ8zjy0 DDDを体現するためビジネスロジックは全て日本語で表現しようと思うのですがC#の仕様的に発生する不都合って何か考えられますか?
93デフォルトの名無しさん (ワッチョイ a163-ufzS)
2019/06/23(日) 15:12:31.08ID:q/+ohx0h0 全て日本語で表現したらキーワードが構文エラーになるのでは
例えば制御文がビジネスロジックではないとは言いますまい
例えば制御文がビジネスロジックではないとは言いますまい
94デフォルトの名無しさん (ブーイモ MMab-mCyV)
2019/06/23(日) 15:41:55.57ID:4589uE1UM C#は日本語問題ないでしょ
95デフォルトの名無しさん (ワッチョイ 3917-Im5L)
2019/06/23(日) 19:49:13.23ID:XYuZEt+Z0 日本語にすることで理解しやすくなるんならOK
96デフォルトの名無しさん (ワッチョイ d91b-6Wjr)
2019/06/23(日) 23:01:38.80ID:939gOEnE0 変数やデービーのカラムを日本語にすると、たしかにシステム的にわかりやすい気はするんだけど、コーディングの時に変換しなきゃいけないめんどうくささがあるのよ。コーディングするときって、せいぜいコメンティングぐらいしか変換しないので書きづらい
97デフォルトの名無しさん (ワッチョイ 51a7-8n2t)
2019/06/23(日) 23:05:28.73ID:d7dmSNhX0 ぴゅう太の日本語ベーシック思い出してしまった
98デフォルトの名無しさん (ワッチョイ 9379-eGkX)
2019/06/24(月) 00:11:23.94ID:BrGul7Md0 日本語使うと入力補完は効きにくくなるだろうな
99デフォルトの名無しさん (ワッチョイ f101-4gXx)
2019/06/24(月) 07:43:23.14ID:INU2Nep40100デフォルトの名無しさん (ワッチョイ f101-4gXx)
2019/06/24(月) 07:44:36.74ID:INU2Nep40 要件洗い出しは関係ないですね
要件とコードの対応と言うべきですか
要件とコードの対応と言うべきですか
101デフォルトの名無しさん (ワッチョイ 9379-eGkX)
2019/06/24(月) 13:24:04.39ID:BrGul7Md0 ハンガリアン記法+日本語名というのを考えたことはある
これならVSの入力補完が多少は効くはず
実践したことはない
これならVSの入力補完が多少は効くはず
実践したことはない
102デフォルトの名無しさん (ワッチョイ 4b7c-hqo7)
2019/06/24(月) 15:17:24.99ID:8JMYiMGy0 class FileInfoファイル情報 {
public string FilePathファイルパス { get; }
}
こんなんでよくね(適当
public string FilePathファイルパス { get; }
}
こんなんでよくね(適当
103デフォルトの名無しさん (ドコグロ MM2d-w2KU)
2019/06/24(月) 20:48:54.28ID:zxVE+D4VM104デフォルトの名無しさん (ワッチョイ f92c-6Wjr)
2019/06/24(月) 22:34:42.57ID:C8NcvPkq0 変換もあれだけど、そもそもガリガリコード書くときにime使わんめえ
105デフォルトの名無しさん (ワッチョイ 93ad-XQnl)
2019/06/25(火) 00:19:38.21ID:fdS9q1aa0 法律とか簿記の用語とかバンバン出てくるようなやつは全面漢字の方が仕様ととのチェックが楽だった
〜に係る〜、とかそんなの
〜に係る〜、とかそんなの
106デフォルトの名無しさん (ワッチョイ 13c7-eGkX)
2019/06/25(火) 01:16:15.18ID:mH+I2Nvc0 グローバリゼーションが絶対ありえないなら有効かもなー
今までコード補完使いまくるから強引に英語化していたけど、
法律関連とか無理に英語化しても結局コード補完で悩みそうだし、
日本語のままがいいなんてケースもあるんだな
適切な英語に訳すことができたとしても
大きいプロジェクトなら大量の用語の日本語と英語間の対応を全員が把握するなんて困難だもんな
今までコード補完使いまくるから強引に英語化していたけど、
法律関連とか無理に英語化しても結局コード補完で悩みそうだし、
日本語のままがいいなんてケースもあるんだな
適切な英語に訳すことができたとしても
大きいプロジェクトなら大量の用語の日本語と英語間の対応を全員が把握するなんて困難だもんな
107デフォルトの名無しさん (ワッチョイ f101-4gXx)
2019/06/25(火) 07:33:14.34ID:RLkxwly20 やはり日本語は有効ですね
クライアントが日本人なら属性とクラスとメソッドは日本語で書きます
クライアントが日本人なら属性とクラスとメソッドは日本語で書きます
108デフォルトの名無しさん (ワッチョイ f101-4gXx)
2019/06/25(火) 07:37:02.66ID:RLkxwly20 バリバリのjava使いはクラスに日本語使うなんてファックすんぞと怒りますがC#erは意外と受け入れてくれそうで良かったです
流石に先進的です
流石に先進的です
109デフォルトの名無しさん (ワッチョイ 9961-MRln)
2019/06/26(水) 19:29:12.31ID:bHDlLtN30 買収劇を繰り返して競争相手をなくして言っているような企業には、
著作権法で守る必要はない。独占禁止法や不正競争防止法に条項を
追加して、著作憲法によう保護が適用されないようにし、
ライセンスを無視してコピーして使って良いことにしなければならない。
そういう法律を作ろう。MSのやり方は我慢の限度を超えている。
著作権法で守る必要はない。独占禁止法や不正競争防止法に条項を
追加して、著作憲法によう保護が適用されないようにし、
ライセンスを無視してコピーして使って良いことにしなければならない。
そういう法律を作ろう。MSのやり方は我慢の限度を超えている。
110デフォルトの名無しさん (ワッチョイ 9961-MRln)
2019/06/26(水) 19:30:07.76ID:bHDlLtN30 買収劇を繰り返して競争相手をなくして行っているような企業には、
著作権法で守る必要はない。独占禁止法や不正競争防止法に条項を
追加して、著作憲法による不正コピーの禁止が適用されないようにし、
ライセンスを無視してコピーして使って良いことにしなければならない。
そういう法律を作ろう。MSのやり方は我慢の限度を超えている。
著作権法で守る必要はない。独占禁止法や不正競争防止法に条項を
追加して、著作憲法による不正コピーの禁止が適用されないようにし、
ライセンスを無視してコピーして使って良いことにしなければならない。
そういう法律を作ろう。MSのやり方は我慢の限度を超えている。
111デフォルトの名無しさん (ワッチョイ 3917-Im5L)
2019/06/26(水) 19:33:56.13ID:y6o5vel10 ハナちゃんのパパ?
112デフォルトの名無しさん (ワッチョイ a990-HEuD)
2019/06/29(土) 19:59:50.56ID:YcHWvjCx0 FuncかActionで表現した方が定義やIntelliSenseを見たときに分かりやすいから
デリゲートを自分で定義して使うのではなくFunc、Actionを使え、という主張を以前見たことがあるのですが、どう思いますか?
デリゲートを自分で定義して使うのではなくFunc、Actionを使え、という主張を以前見たことがあるのですが、どう思いますか?
113デフォルトの名無しさん (アウアウウー Sa11-PkEo)
2019/06/29(土) 20:18:03.17ID:PRWAmALBa どう思いますかって言われても困ると思うよw
114デフォルトの名無しさん (ワッチョイ 4a2f-fjwL)
2019/06/30(日) 20:22:22.67ID:KUa1H9ms0 インテリセンスのない環境でコードを見たときにって話なら分からんでもないけど
インテリセンス前提で自作クラスが分かりにくいとか、どういう主張なんだか理解できん
インテリセンス前提で自作クラスが分かりにくいとか、どういう主張なんだか理解できん
115デフォルトの名無しさん (アウアウウー Sa11-9zjL)
2019/06/30(日) 22:36:06.16ID:E9GgFL0oa インテリセス云々以前の問題でFunc Action の方が見易い
ってか、いい加減 return void を認めて、その二つを統一してくれ!
ってか、いい加減 return void を認めて、その二つを統一してくれ!
116デフォルトの名無しさん (アウアウウー Sa11-PkEo)
2019/06/30(日) 22:53:18.91ID:UMa0Fer9a Predicateみたいに可読性への寄与度から専用の方が好ましい場合もあるし、
EventHandlerみたいにジェネリックの型パラメータを制約したい場合もあるよ
何でも汎用のFuncやActionがあれば用が足りると思うのはあまりに単細胞
EventHandlerみたいにジェネリックの型パラメータを制約したい場合もあるよ
何でも汎用のFuncやActionがあれば用が足りると思うのはあまりに単細胞
117デフォルトの名無しさん (アウアウウー Sa67-rgZK)
2019/07/09(火) 12:56:17.51ID:8vBp03U7a List<XXXX> abc;
このXXXXを変数で指定するのはどうしたらいいのでしょう?
class XXXX {}というクラス定義をSystem.Reflection.Emitをつかって動的に生成しているのですが、
List<>のような使い方はどうしたらいいのかで詰まっています
このXXXXを変数で指定するのはどうしたらいいのでしょう?
class XXXX {}というクラス定義をSystem.Reflection.Emitをつかって動的に生成しているのですが、
List<>のような使い方はどうしたらいいのかで詰まっています
118デフォルトの名無しさん (ワッチョイ cf63-7viB)
2019/07/09(火) 13:43:55.71ID:yquUIfg/0119デフォルトの名無しさん (アウアウウー Sa67-rgZK)
2019/07/09(火) 14:21:23.40ID:8vBp03U7a なんとかなりそう。ありがとう
120デフォルトの名無しさん (ワッチョイ 3302-mE9d)
2019/07/10(水) 13:09:36.44ID:0hCGlEp90 >119
後学のために教えてほしい
なんでList<Object>ではだめなの?
後学のために教えてほしい
なんでList<Object>ではだめなの?
121デフォルトの名無しさん (アウアウウー Sa67-rgZK)
2019/07/10(水) 14:01:08.12ID:mry5rpAoa listは例で出しただけで実際は別の扱ってる
クラスの中でtypeに応じて処理してるから、objectだと処理をしてくれない
クラスの中でtypeに応じて処理してるから、objectだと処理をしてくれない
122デフォルトの名無しさん (スフッ Sd1f-/tA/)
2019/07/10(水) 15:37:43.85ID:ousD8GLzd それはインターフェース作るべきでは…?
123デフォルトの名無しさん (アウアウウー Sa67-rgZK)
2019/07/10(水) 15:48:11.66ID:mry5rpAoa そういうクラス作っててインターフェース用意してないのはMSだから、こっちとしてはどうしようもない
オープンソースライブラリだから作り直すって手もあるにはあるけどw
オープンソースライブラリだから作り直すって手もあるにはあるけどw
124デフォルトの名無しさん (ワッチョイ 3317-mE9d)
2019/07/10(水) 18:54:55.06ID:Pc5iw8Z80 自分の設計力不足をMSのせいにするなよ
125デフォルトの名無しさん (ワッチョイ cf63-7viB)
2019/07/10(水) 19:00:13.51ID:BgjseyMO0126デフォルトの名無しさん (ワッチョイ b32c-/tA/)
2019/07/10(水) 22:41:42.75ID:r/PFuwdP0 typeに応じてやる処理を抽象化すればinterfaceのリストで事足りるってことじゃないんか
127デフォルトの名無しさん (ワッチョイ 7f7b-eBwx)
2019/07/21(日) 23:27:31.90ID:lGaupOsP0 >>10
結局これは
https://mevius.5ch.net/test/read.cgi/tech/1563258983/31
こういうことだったんだな
ファイナライザは確認してないがDisposeした後に2回動かすと確かにちゃんと片づけられる
GC.Collect使わなくてもある程度まで積みあがったら片付けられたけど自分の環境で試したら1GBまでそのままだったw
結局これは
https://mevius.5ch.net/test/read.cgi/tech/1563258983/31
こういうことだったんだな
ファイナライザは確認してないがDisposeした後に2回動かすと確かにちゃんと片づけられる
GC.Collect使わなくてもある程度まで積みあがったら片付けられたけど自分の環境で試したら1GBまでそのままだったw
128デフォルトの名無しさん (ワッチョイ 4f0c-0ngu)
2019/07/22(月) 07:36:47.16ID:1xNSkDCq0 ファイナライザが実装されているオブジェクトは
自分でDisposeを呼ばないまま参照されなくなった場合
GC二回後にメモリが回収される(ファイナライザ待ちは世代昇格されるのであくまでGC.Collectでフル実行した場合の回数)
という仕組みなのでそれで問題が解決するなら結局どっかでDispose忘れてるんじゃねという話に戻るだけだょ
まあそもそもDisposeでファイナライザ抑制してなかったり
フレームワーク側で無駄に参照掴んでたりってパターンもあるから誰が戦犯かはそれだけじゃわからんけど
自分でDisposeを呼ばないまま参照されなくなった場合
GC二回後にメモリが回収される(ファイナライザ待ちは世代昇格されるのであくまでGC.Collectでフル実行した場合の回数)
という仕組みなのでそれで問題が解決するなら結局どっかでDispose忘れてるんじゃねという話に戻るだけだょ
まあそもそもDisposeでファイナライザ抑制してなかったり
フレームワーク側で無駄に参照掴んでたりってパターンもあるから誰が戦犯かはそれだけじゃわからんけど
129デフォルトの名無しさん (ワッチョイ 7d00-brtY)
2019/08/12(月) 14:38:09.12ID:kdU0FwTT0 C#の国際規格についてちょっと聞きたい。そんな高級な質問じゃないんだけど……。
https://www.ecma-international.org/publications/standards/Ecma-334.htm
C# 5.0相当のISO/IEC 23270が2018年に公開されたけど、これに対応する日本産業規格って発行されるのだろうか?
そして発行されるとしていつごろになるんだろう。
この辺りの動向についてご存知のかたいます?
https://www.ecma-international.org/publications/standards/Ecma-334.htm
C# 5.0相当のISO/IEC 23270が2018年に公開されたけど、これに対応する日本産業規格って発行されるのだろうか?
そして発行されるとしていつごろになるんだろう。
この辺りの動向についてご存知のかたいます?
130デフォルトの名無しさん (ワッチョイ 5a2c-QI54)
2019/08/13(火) 08:39:07.10ID:OBL8K+z10 知らんけど
ISOの2003版がJISの2005版、2006版が2008版になってるから
今回も2020版ぐらいになるんじゃね
ISOの2003版がJISの2005版、2006版が2008版になってるから
今回も2020版ぐらいになるんじゃね
131デフォルトの名無しさん (ワッチョイ 2b28-6eyv)
2019/08/15(木) 06:29:42.47ID:KFntKln70 東京五輪の影響で規格化が遅れそう…
132デフォルトの名無しさん (ワッチョイ f15f-iJJm)
2019/08/26(月) 22:54:59.78ID:llFp3/Xa0 スレッド数が64を超えるcpuアフィニティの設定てどうするの?
133デフォルトの名無しさん (ワッチョイ 0d90-gQHD)
2019/08/28(水) 07:10:45.65ID:Zi6oAw3b0 VScodeで脳死プログラミングができると聞いたのですが本当ですか?
134デフォルトの名無しさん (ワッチョイ 8902-cRT5)
2019/09/04(水) 00:05:09.92ID:bsu7VNi60 昔のWin32アプリは、WinMain関数のnCmdShow引数で表示方法を得られましたが
int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow);
WinFormアプリはどうやって得ればよいのでしょうか?
int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow);
WinFormアプリはどうやって得ればよいのでしょうか?
135デフォルトの名無しさん (ワッチョイ 0b7c-+0qt)
2019/09/04(水) 09:33:16.14ID:E2wRgXH30 GetStartupInfoを使う
MINIMIZE/MAXIMIZEだけならFormのWndProcをオーバーライドしてbase.WndProc後のm_Msg==1の時のthis.WindowState見るというのも
MINIMIZE/MAXIMIZEだけならFormのWndProcをオーバーライドしてbase.WndProc後のm_Msg==1の時のthis.WindowState見るというのも
136デフォルトの名無しさん (ワッチョイ dd02-kyym)
2019/09/05(木) 18:54:53.82ID:HPpIgnWU0 >134
ありがとうございます
諸事情によりEXEとフォーム持つDLLが分離しているため
APIで取得することにしました
ありがとうございます
諸事情によりEXEとフォーム持つDLLが分離しているため
APIで取得することにしました
137デフォルトの名無しさん (アウアウウー Sa85-TrZH)
2019/09/25(水) 07:50:08.17ID:yu694yUKa 今までほぼformアプリの開発しかしてきてないんですが、ASP.NETの開発やらないといけなくなりました
習得は結構大変ですか?おすすめの書籍などあれば教えていただきたいです
習得は結構大変ですか?おすすめの書籍などあれば教えていただきたいです
138デフォルトの名無しさん (ブーイモ MM65-Kp5G)
2019/09/25(水) 20:17:31.78ID:EcWtzQyLM わいも知りたい
139デフォルトの名無しさん (ワッチョイ 216e-iM7L)
2019/09/25(水) 22:10:57.54ID:9Q76ghao0 FindIndex使えばループ書かなくても一行で済むじゃん綺麗じゃんと思ったんですけど、時間測ったらループ回すのより10倍くらい遅いんですよ
でも10倍って言っても0.00001と0.0001のオーダーでの差でぶっちゃけ体感時間には全く差が無し
そんな高速化が求められるようなプログラムでも無いんですが、こうなったら速度と可読性のうちこっちを優先させるみたいな基準って無いですかねぇ
でも10倍って言っても0.00001と0.0001のオーダーでの差でぶっちゃけ体感時間には全く差が無し
そんな高速化が求められるようなプログラムでも無いんですが、こうなったら速度と可読性のうちこっちを優先させるみたいな基準って無いですかねぇ
140デフォルトの名無しさん (ワッチョイ 45da-sg2W)
2019/09/25(水) 22:20:32.97ID:VqafUfZJ0 まず可読性を優先、体感でわかるレベルで問題になるところ「だけ」速度を考えろ
141デフォルトの名無しさん (ワッチョイ c7da-srNF)
2019/09/26(木) 02:48:32.55ID:en+kNYvx0 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
142デフォルトの名無しさん (ワッチョイ e36e-cmPQ)
2019/10/30(水) 18:23:48.89ID:NKPTY8aU0 ・変数名は意味の読み取れない1文字2文字ばかり
・関数名は中身と一致してない上に連番
・意地でも動的配列を使わずに宣言の際に要素数100とか宣言する
・複数のオブジェクトを使いたいときはわざわざ
public class Persons
{
public n = 0; // 要素数
person[] arr = null;
]
みたいなクラスを作る
そんなC#を書く隣の上司をなんとかする方法を相談したい……(スレ違い)
・関数名は中身と一致してない上に連番
・意地でも動的配列を使わずに宣言の際に要素数100とか宣言する
・複数のオブジェクトを使いたいときはわざわざ
public class Persons
{
public n = 0; // 要素数
person[] arr = null;
]
みたいなクラスを作る
そんなC#を書く隣の上司をなんとかする方法を相談したい……(スレ違い)
143デフォルトの名無しさん (オッペケ Sr47-D75Y)
2019/10/30(水) 19:38:29.73ID:2ARpxczkr サルでも解るシリーズの書籍を誕生日に贈る。
144デフォルトの名無しさん (ワッチョイ ff6a-mjLV)
2019/10/30(水) 21:14:47.10ID:hAwpvm3E0 プルリクで却下できないん?
145デフォルトの名無しさん (ワッチョイ cf2d-KmKR)
2019/10/30(水) 21:50:28.28ID:doIb6RUv0 メソッドの戻り値がどのようなものなのか、コード上で分かりやすく修飾する方法ってないのでしょうか?
雰囲気としてはこんな感じに書きたいのですが、こういう需要ってないんでしょうか・・・・
(FirstName : string, FamilyName : string) Name(){return ("aiueo", "700");}
雰囲気としてはこんな感じに書きたいのですが、こういう需要ってないんでしょうか・・・・
(FirstName : string, FamilyName : string) Name(){return ("aiueo", "700");}
146デフォルトの名無しさん (ワッチョイ ff63-/RqP)
2019/10/30(水) 21:53:35.09ID:zxDW+B/R0 >>145
そういうのはタプルよりもFirstNameとFamilyNameプロパティ持ったPersonクラス作るほうがわかりやすくない?
そういうのはタプルよりもFirstNameとFamilyNameプロパティ持ったPersonクラス作るほうがわかりやすくない?
147デフォルトの名無しさん (アウアウウー Sa27-0Ghx)
2019/10/30(水) 22:54:56.03ID:Gqhw4MMca ドキュメンテーションコメントでも書けばいいんじゃ
148デフォルトの名無しさん (ワッチョイ d363-daWW)
2019/10/30(水) 23:06:52.77ID:Ve/HJIbT0 tupleを返す
class/struct作ってその型で返す
out引数使う
お好きなのをどうぞ
個人的には場合によりけりでどのパターンも使う
class/struct作ってその型で返す
out引数使う
お好きなのをどうぞ
個人的には場合によりけりでどのパターンも使う
149デフォルトの名無しさん (ワッチョイ d363-daWW)
2019/10/30(水) 23:08:32.80ID:Ve/HJIbT0 コード見て思ったけどもしかしてtupleに名前つけられるのを知らないだけだったりする?
150デフォルトの名無しさん (ワッチョイ b37c-HiRB)
2019/10/30(水) 23:58:19.82ID:3bs3H/Xu0 え、tupleに名前付けられるの?
Item1とか分かりにくすぎて嫌だからクラス作ってたけど名前つけられるならtupleでいいな
Item1とか分かりにくすぎて嫌だからクラス作ってたけど名前つけられるならtupleでいいな
151デフォルトの名無しさん (ワッチョイ 8a01-ODnH)
2019/10/31(木) 00:18:43.85ID:JXLI+jKB0 (string FirstName, string FamilyName) Name(){return ("aiueo", "700");}
って書けるよってことでしょ
using Name = System.Tuple<string, string>;
usingでaliasは設定できるけどこっちは使いみち少ない
って書けるよってことでしょ
using Name = System.Tuple<string, string>;
usingでaliasは設定できるけどこっちは使いみち少ない
152デフォルトの名無しさん (ワッチョイ 6763-ORrh)
2019/10/31(木) 00:50:52.29ID:MkAQwKar0 tupleのitem1とかにはプログラマが自由に命名できるしVSの補完候補にもちゃんと出てきてくれるよ
その1箇所でしか使わないような内容ならtupleで十分
その1箇所でしか使わないような内容ならtupleで十分
153デフォルトの名無しさん (ワッチョイ 9e2d-46hx)
2019/10/31(木) 01:30:49.91ID:7TTG6xuA0 まじか、全然知らなかったよ
ありがとう
ありがとう
154デフォルトの名無しさん (ワッチョイ 4aad-bcUy)
2019/11/01(金) 06:58:19.64ID:POn0QVxB0 >>142
その上司も含めてコーディング規約を作ればええやん
その上司も含めてコーディング規約を作ればええやん
155デフォルトの名無しさん (ワッチョイ dee3-qV4/)
2019/11/01(金) 08:13:50.59ID:bPRiWep60156デフォルトの名無しさん (アウアウウー Sa2f-bcUy)
2019/11/01(金) 08:44:40.64ID:oh61GAM5a >>155
それで皆が納得してるなら従うしかないな
それで皆が納得してるなら従うしかないな
157デフォルトの名無しさん (ワッチョイ ca01-+xQI)
2019/11/01(金) 09:22:46.81ID:luUnrp0t0 「互換性を保つため」とかならまだしも「今までこれでやって来たからこのままで問題ないだろ」って言ってそう
158デフォルトの名無しさん (ワッチョイ ca6a-qV4/)
2019/11/01(金) 19:09:11.77ID:EqckBJhH0 LINQ分からん奴が言いそうね
159デフォルトの名無しさん (ワッチョイ 6f02-qV4/)
2019/11/01(金) 22:43:07.33ID:MCB8CVSf0 ワイの上司は使わなくてもいい新しい機能容赦なく使ってくるので困る…
160デフォルトの名無しさん (ワッチョイ ca01-+xQI)
2019/11/01(金) 22:53:20.80ID:luUnrp0t0 たしかにそれはそれでうざいかも…
でも今使わない機能でも知っておくのはいいことだよ
でも今使わない機能でも知っておくのはいいことだよ
161デフォルトの名無しさん (ワッチョイ 0b6e-ANgw)
2019/11/02(土) 00:21:45.36ID:Hd3sBx8l0 えーそんな上司羨ましいけど
こんな書き方あるんですね!みたいに話せそうで楽しそうじゃん
こんな書き方あるんですね!みたいに話せそうで楽しそうじゃん
162デフォルトの名無しさん (ワッチョイ 6763-ORrh)
2019/11/02(土) 01:35:16.42ID:gWk8WKKS0 使わなくていい、のレベルによるかな
使うべきではないところで無理に新機能入れるのはやだな
慣れてないがために可読性が…くらいなら入れてほしい
var初期の頃とか後者な感じ
使うべきではないところで無理に新機能入れるのはやだな
慣れてないがために可読性が…くらいなら入れてほしい
var初期の頃とか後者な感じ
163デフォルトの名無しさん (ワッチョイ ca01-+xQI)
2019/11/02(土) 09:30:28.25ID:esIitHWU0164デフォルトの名無しさん (ワッチョイ 6763-ORrh)
2019/11/02(土) 09:45:46.24ID:gWk8WKKS0165デフォルトの名無しさん (ワッチョイ ca01-+xQI)
2019/11/02(土) 10:17:49.05ID:esIitHWU0166デフォルトの名無しさん (スップ Sd8a-ORrh)
2019/11/02(土) 10:43:02.41ID:pWYzNK5/d167デフォルトの名無しさん (ドコグロ MMea-+xQI)
2019/11/02(土) 11:39:00.90ID:vl/bFsjFM168デフォルトの名無しさん (スップ Sd8a-ORrh)
2019/11/02(土) 11:47:25.61ID:pWYzNK5/d169デフォルトの名無しさん (ワッチョイ 0b6e-ANgw)
2019/11/02(土) 11:56:17.08ID:Hd3sBx8l0 vs2019なんだけどvar書いたら明示的な書き方に変更しねぇ?ってメッセージ出してくるのではーんそういう方針になったんかと思ってたんだけどあれぇ?
170デフォルトの名無しさん (ワッチョイ ca01-+xQI)
2019/11/02(土) 12:46:00.84ID:esIitHWU0 >>168
そりゃお前みたいな頭の硬い爺とキャッチボールなんて成り立たんしw
そりゃお前みたいな頭の硬い爺とキャッチボールなんて成り立たんしw
171デフォルトの名無しさん (ワッチョイ ca6a-qV4/)
2019/11/02(土) 16:58:33.03ID:km6s5e3E0 >>169
デフォルトがそっちなだけで逆にも設定できるけどね
デフォルトがそっちなだけで逆にも設定できるけどね
172デフォルトの名無しさん (ワッチョイ 635f-1FRn)
2019/11/02(土) 23:56:05.01ID:kSdsB0kB0 大量にキューに入れておいた情報を順次取り出して
10程度の芸列でどんどん処理していくのは
どういう感じで書けばいいですか。
とりあえず直近では処理の結果は個別にファイルにサクセイ・書き込みです。
10程度の芸列でどんどん処理していくのは
どういう感じで書けばいいですか。
とりあえず直近では処理の結果は個別にファイルにサクセイ・書き込みです。
173デフォルトの名無しさん (ワッチョイ ff61-R6C/)
2019/11/02(土) 23:58:30.80ID:dJ3V2vrm0 >>172
>10程度の芸列でどんどん処理していくのは
芸列とはなんですか?
>とりあえず直近では処理の結果は個別にファイルにサクセイ・書き込みです。
「個別にファイル作成・書き込み」の意味をもっと詳しく。
>10程度の芸列でどんどん処理していくのは
芸列とはなんですか?
>とりあえず直近では処理の結果は個別にファイルにサクセイ・書き込みです。
「個別にファイル作成・書き込み」の意味をもっと詳しく。
174デフォルトの名無しさん (ワッチョイ 8a01-ODnH)
2019/11/03(日) 00:17:01.38ID:1Yjm47HG0175デフォルトの名無しさん (ワッチョイ 635f-1FRn)
2019/11/03(日) 00:38:06.74ID:y3onw07e0176デフォルトの名無しさん (ワッチョイ cbda-JGSe)
2019/11/04(月) 09:42:36.30ID:2+WwS96M0 FormのMainMenu内のMenuItemとしてPanelやUserControlを表示するにはどうすればよいでしょうか?
177デフォルトの名無しさん (ワッチョイ cbda-JGSe)
2019/11/04(月) 10:13:49.85ID:2+WwS96M0 すみません打開しました。
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);
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);
178デフォルトの名無しさん (ワッチョイ 7b61-tp7K)
2019/11/13(水) 09:04:11.57ID:1AwZzcZD0 メニュー項目をグレイ表示にしたりチェック記号など付けたいような場合、
MFCではOnUpdateXxxx()ハンドラでCCmdUIを使ったり、メニュー項目に
IDM_XXXXの様なID番号を付けておいて、そのID番号で操作することが
出来たのですが、C#で同様の事をしようとすると項目の表示順がそのまま
反映された0から割り振られた番号を使う必要があるようです。でもそれだと、
新しい項目を途中に追加した場合に番号がずれてしまいます。MFCと同様に
IDM_XXXX のようなID番号を付けたり、Updateハンドラで処理するような
方法はないのでしょうか?
MFCではOnUpdateXxxx()ハンドラでCCmdUIを使ったり、メニュー項目に
IDM_XXXXの様なID番号を付けておいて、そのID番号で操作することが
出来たのですが、C#で同様の事をしようとすると項目の表示順がそのまま
反映された0から割り振られた番号を使う必要があるようです。でもそれだと、
新しい項目を途中に追加した場合に番号がずれてしまいます。MFCと同様に
IDM_XXXX のようなID番号を付けたり、Updateハンドラで処理するような
方法はないのでしょうか?
179デフォルトの名無しさん (ワッチョイ 4f7c-3bRk)
2019/11/13(水) 12:10:20.10ID:dfp87pvz0 MenuItemなりToolStripMenuItemなりのインスタンスを使えばいい
デザイナで配置してるならフィールドに置かれてる
変数名はデザイナでNameプロパティを変えれば追従する
デザイナで配置してるならフィールドに置かれてる
変数名はデザイナでNameプロパティを変えれば追従する
180デフォルトの名無しさん (ワッチョイ 0f7b-ggIY)
2019/11/13(水) 23:53:39.67ID:tSkG/O4T0181デフォルトの名無しさん (ワッチョイ 0261-bNU/)
2019/11/14(木) 10:48:50.19ID:23v5U+5B0182デフォルトの名無しさん (ワッチョイ 6d61-bNU/)
2019/11/16(土) 00:42:57.25ID:AbQTX8d40 Formアプリケーションを作っているとき、
例えば、Form1.cs, Form1.Designer.cs
Form1.resx(Form1.ja.resxなどになる場合も有りますが)
が組みになって作成されます。
Form1.csは人間がコードを書くためのもの、
Form1.Designer.csはIDEのデザイナが作成するもの
のように役割が決まっているそうですが、これらを互いに
関連付けているのはファイル名や拡張子なのでしょうか。
それとも、どこかに関連付いていることが記述されている
ファイルがあるのでしょうか???
例えば、Form1.cs, Form1.Designer.cs
Form1.resx(Form1.ja.resxなどになる場合も有りますが)
が組みになって作成されます。
Form1.csは人間がコードを書くためのもの、
Form1.Designer.csはIDEのデザイナが作成するもの
のように役割が決まっているそうですが、これらを互いに
関連付けているのはファイル名や拡張子なのでしょうか。
それとも、どこかに関連付いていることが記述されている
ファイルがあるのでしょうか???
183デフォルトの名無しさん (ワッチョイ 826a-jvSr)
2019/11/16(土) 00:44:19.89ID:HfmqkgpW0 csprojファイルに書いてある
184デフォルトの名無しさん (ワッチョイ 6d61-bNU/)
2019/11/16(土) 00:46:32.43ID:AbQTX8d40 >>182
お聞きしたいのは、
xxx.cs と xxx.Designer.cs のようなファイル名の「パターン」によって関連付けられて
いるのか、それとも、どこかのファイルに、書き方はわかりませんが、例えば、
Relation{ "xxx.cs", "xxx.Designer.cs" };
や
Form "xxx.cs" {
Designer : "xxx.Designer.cs"
};
のような感じで関連付けを書いてあるファイルがあるのか、ということです。
お聞きしたいのは、
xxx.cs と xxx.Designer.cs のようなファイル名の「パターン」によって関連付けられて
いるのか、それとも、どこかのファイルに、書き方はわかりませんが、例えば、
Relation{ "xxx.cs", "xxx.Designer.cs" };
や
Form "xxx.cs" {
Designer : "xxx.Designer.cs"
};
のような感じで関連付けを書いてあるファイルがあるのか、ということです。
185デフォルトの名無しさん (ワッチョイ 1d2c-zeRf)
2019/11/16(土) 01:19:44.10ID:YMoVrrFx0 >>184
だからcsprojファイルに書いてある
だからcsprojファイルに書いてある
186デフォルトの名無しさん (スフッ Sda2-CthP)
2019/11/16(土) 01:20:36.88ID:Jhdu8Hovd >>184
クラスがpartial。
VSから見たときの関連性と言う意味では多分ファイル名だけど、コンパイルする時としてはpartialで同じ名前のクラスは纏められる。
というか昔はファイルわかれてなくて、regionの中に居た気がする。
partialが使えるようになった時にファイル分かれた。
クラスがpartial。
VSから見たときの関連性と言う意味では多分ファイル名だけど、コンパイルする時としてはpartialで同じ名前のクラスは纏められる。
というか昔はファイルわかれてなくて、regionの中に居た気がする。
partialが使えるようになった時にファイル分かれた。
187デフォルトの名無しさん (スフッ Sda2-CthP)
2019/11/16(土) 01:24:27.50ID:Jhdu8Hovd csprojで、DependentUponになってるけど、ファイル名変えたら変な事になった気がする。
変えても良いんだっけ?
変えても良いんだっけ?
188デフォルトの名無しさん (ワッチョイ 1d2c-zeRf)
2019/11/16(土) 01:26:29.09ID:YMoVrrFx0 >>182
はたぶん自動的にサブタイプになる設定がどこかに定義されてるかを聞きたいんだろうな…
はたぶん自動的にサブタイプになる設定がどこかに定義されてるかを聞きたいんだろうな…
189デフォルトの名無しさん (ワッチョイ 6d61-bNU/)
2019/11/16(土) 09:28:48.15ID:+CnVgCxY0 >>185
こんな風になっています。例えば、クラス名が 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
{
・・・
}
}
こんな風になっています。例えば、クラス名が 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
{
・・・
}
}
190デフォルトの名無しさん (ワッチョイ 6d61-bNU/)
2019/11/16(土) 09:29:13.19ID:+CnVgCxY0 >>189
【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>
【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>
191デフォルトの名無しさん (ワッチョイ ee7b-MAFP)
2019/11/16(土) 09:45:51.65ID:ILBbGfsX0 >>182
Visual Studioの設定や機能の話は該当するVSのバージョンのスレでやってくれ
Visual Studioの設定や機能の話は該当するVSのバージョンのスレでやってくれ
192デフォルトの名無しさん (ワッチョイ 022c-+JiD)
2019/11/16(土) 11:16:34.71ID:MdmPeVmZ0 >>189
試してみれば?
試してみれば?
193デフォルトの名無しさん (ワッチョイ 022f-Lnqu)
2019/11/16(土) 14:34:42.64ID:H9Ba0iJt0 VSが入れ子表示してるファイル名と、コンパイラがコンパイルするクラス名は別の話だからな
VSが入れ子表示する話やデザイナファイル作る話ならVSスレ行ってやってくれ
VSが入れ子表示する話やデザイナファイル作る話ならVSスレ行ってやってくれ
194デフォルトの名無しさん (ワッチョイ fe05-Ks/Y)
2019/11/16(土) 15:38:12.07ID:Sm3PGb9V0 緊急で質問です。
Windowsフォームのコンボボックスにて、フォーカスされた時の背景色を青ではなく薄水色にしたいのですが、やり方がわかりません。
ネットで調べてもほとんど引っかかりません。簡単なソースコードサンプル付きで教えてくださる優しい方がいらっしゃいましたら、よろしくお願い申し上げます。
Windowsフォームのコンボボックスにて、フォーカスされた時の背景色を青ではなく薄水色にしたいのですが、やり方がわかりません。
ネットで調べてもほとんど引っかかりません。簡単なソースコードサンプル付きで教えてくださる優しい方がいらっしゃいましたら、よろしくお願い申し上げます。
195デフォルトの名無しさん (ワッチョイ c201-Iq/z)
2019/11/16(土) 16:48:11.20ID:gzUz93yQ0196デフォルトの名無しさん (アウアウウー Sa45-CsEk)
2019/11/16(土) 17:41:51.10ID:aUb/5lHla >>194
緊急とか書くと自分の都合しか考えない身勝手な奴だと思われるよ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;
}
緊急とか書くと自分の都合しか考えない身勝手な奴だと思われるよ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;
}
197デフォルトの名無しさん (ワッチョイ 822c-Lnqu)
2019/11/16(土) 18:34:21.65ID:dnB+BkZr0198デフォルトの名無しさん (ワッチョイ 6d61-bNU/)
2019/11/16(土) 19:58:19.51ID:+CnVgCxY0 >>197
ソリューションエクスプローラー上の、Form1.cs上で、右クリックして、
出てくるメニューから「名前を変更」を選んでファイル名を変更したところ、
Form1.Designer.csのファイル名も連動して変更される現象を発見しました。
ソリューションエクスプローラー上の、Form1.cs上で、右クリックして、
出てくるメニューから「名前を変更」を選んでファイル名を変更したところ、
Form1.Designer.csのファイル名も連動して変更される現象を発見しました。
199デフォルトの名無しさん (ワッチョイ 6d61-bNU/)
2019/11/16(土) 21:35:50.24ID:+CnVgCxY0200デフォルトの名無しさん (ワッチョイ 21da-Mufb)
2019/11/17(日) 07:31:12.67ID:2EA7witB0 これからGUIデスクトップアプリ作り始めるなら、.net framework 4.8と.net core 3.0 どっちがいいの?
.net core のほうはGUIデザイナがないのがなんか気になる。
今書いたGUIデザインソースが.net 5 でGUIデザイナが出てきた時にうまく認識されずに全部書き直しになるんじゃないか不安になる。
.net core のほうはGUIデザイナがないのがなんか気になる。
今書いたGUIデザインソースが.net 5 でGUIデザイナが出てきた時にうまく認識されずに全部書き直しになるんじゃないか不安になる。
201デフォルトの名無しさん (ブーイモ MMa2-l7ob)
2019/11/17(日) 07:37:16.91ID:LRl+Pbw6M Blazorがいいよ
202デフォルトの名無しさん (ワッチョイ 214f-iGNt)
2019/11/17(日) 07:58:55.17ID:ADq5wcSz0 Client-side Blazorすら正式版が出てないのに。
203デフォルトの名無しさん (ワッチョイ 22cf-jvSr)
2019/11/17(日) 08:27:12.76ID:lClw7DuB0 Unoがいいよ
204デフォルトの名無しさん (ワッチョイ 0263-7IF2)
2019/11/17(日) 12:01:58.08ID:romeOKJN0205デフォルトの名無しさん (ワッチョイ 122d-61jP)
2019/11/18(月) 14:21:42.81ID:cok7taLx0 .NetCoreでMingw64のBashで表示できるプログラムって作れないのですか?
206デフォルトの名無しさん (ワッチョイ 0261-bNU/)
2019/11/18(月) 20:06:09.61ID:Vzii0sJA0 >>205
そもそも、Windows上のbashはWinアプリなら全て実行できます。
そもそも、Windows上のbashはWinアプリなら全て実行できます。
207デフォルトの名無しさん (ワッチョイ 0210-iGNt)
2019/11/20(水) 12:30:53.34ID:HwawHrED0 CefSharp使うと一瞬画面が消えるんですけどなんとかなりませんかね?
208デフォルトの名無しさん (ワッチョイ 99f0-NYkR)
2019/11/23(土) 09:13:16.39ID:g35NHCcr0 C#で作ったコマンドラインアプリで例外が原因でアプリが終了した場合の
終了コード(バッチだとERRORLEVEL%で見れる値)が仕様でどうなってるか教えて。
単純にMainでSystem.Exception投げるだけのプログラム組んだら-532462766だったけど、
typeof(System.Exception).GetHashCode()あたりかなと思ったけど違ったし……
終了コード(バッチだとERRORLEVEL%で見れる値)が仕様でどうなってるか教えて。
単純にMainでSystem.Exception投げるだけのプログラム組んだら-532462766だったけど、
typeof(System.Exception).GetHashCode()あたりかなと思ったけど違ったし……
209デフォルトの名無しさん (ワッチョイ 7117-/L9V)
2019/11/23(土) 09:21:08.42ID:Q44dea670 returnで終了コード返すのはダメなの?
210デフォルトの名無しさん (ワッチョイ 99f0-NYkR)
2019/11/23(土) 09:29:14.61ID:g35NHCcr0 実用上はtrycatchしてreturnすりゃ問題ないけど、これ何の値なのかなーと。
211デフォルトの名無しさん (ワイーワ2 FF63-cdi2)
2019/11/23(土) 11:13:28.16ID:2xdzU1XAF 16進数に変換してググると何か分かるかもね
212デフォルトの名無しさん (ワッチョイ 5142-/L9V)
2019/11/23(土) 11:38:50.28ID:0TwI+VPl0 /h -h 等でヘルプを出力がよくあるパターンだな
213デフォルトの名無しさん (ワッチョイ 5161-CJzu)
2019/11/24(日) 00:34:51.49ID:HUSWRqmS0 >>208
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
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
214デフォルトの名無しさん (ワッチョイ 5161-CJzu)
2019/11/24(日) 00:48:09.56ID:HUSWRqmS0 >>223
"CCR" は、「時間の霧で意味が失われる」という意味ではなく、
昔は何らかの英語の言葉の略語だったが、今となっては何の意味だったか
誰も思い出せなくなってしまったよく分からない略語、という意味らしい。
"CCR" は、「時間の霧で意味が失われる」という意味ではなく、
昔は何らかの英語の言葉の略語だったが、今となっては何の意味だったか
誰も思い出せなくなってしまったよく分からない略語、という意味らしい。
215デフォルトの名無しさん (ワッチョイ 99f0-NYkR)
2019/11/24(日) 19:54:50.84ID:qE01BsLZ0216デフォルトの名無しさん (ワッチョイ 696e-d0qP)
2019/12/03(火) 18:29:27.61ID:rt0m4L9f0 XML処理しなきゃいけなくなってコード組んだんだけどXDocument×LINQの組み合わせが楽すぎた
XML扱う上でC#は最強の言語なのではなかろうか。併用するライブラリの都合上C++/Pythonも考えたけど勝負にならんかったわ
他にXML使うのに便利な言語ってなんかある?
XML扱う上でC#は最強の言語なのではなかろうか。併用するライブラリの都合上C++/Pythonも考えたけど勝負にならんかったわ
他にXML使うのに便利な言語ってなんかある?
217デフォルトの名無しさん (ブーイモ MMa6-WxKp)
2019/12/03(火) 19:11:05.07ID:aZbE0bc+M powershell
218デフォルトの名無しさん (ブーイモ MMb2-aYeG)
2019/12/03(火) 21:27:27.34ID:nqX73ViMM xslt
219デフォルトの名無しさん (JP 0H79-e23S)
2019/12/05(木) 14:46:16.32ID:JfDO/4XBH 以前に、const での定義名は、defineで定義したものに上書きされることがあるので
全部大文字で名前を付けないでPascal形式で付けるのが正しいらしいって質問をしたものだけど
そもそもC#ってdefineで定数作れないな
それでもPascal形式で名前つけたほうが良い?
全部大文字で名前を付けないでPascal形式で付けるのが正しいらしいって質問をしたものだけど
そもそもC#ってdefineで定数作れないな
それでもPascal形式で名前つけたほうが良い?
220デフォルトの名無しさん (ワッチョイ 0588-FbR7)
2019/12/05(木) 15:24:41.41ID:S5Q8fHSu0 MS推奨はPascal
221デフォルトの名無しさん (ドコグロ MM49-5nhq)
2019/12/05(木) 15:28:13.82ID:dtUadt8oM222デフォルトの名無しさん (ワッチョイ ed02-Fgt1)
2019/12/05(木) 16:33:23.52ID:Y6gi0TAn0 昔はXML最強だと思ってたけど
jsonやyamlの天才的な手抜きにに触れて考えが変わった
jsonやyamlの天才的な手抜きにに触れて考えが変わった
223デフォルトの名無しさん (アウアウウー Saa9-FVm2)
2019/12/05(木) 17:22:34.08ID:izIiWsXta224デフォルトの名無しさん (ワッチョイ cd0c-Fgt1)
2019/12/05(木) 18:16:38.66ID:iMFkaL+I0 ぶっちゃけMS自身もconstが全部大文字だったりPascalだったりしてる
細けェことは気にすんな
命名なんて気分だ気分
細けェことは気にすんな
命名なんて気分だ気分
225デフォルトの名無しさん (ワッチョイ 256e-j5Jm)
2019/12/05(木) 19:17:29.95ID:5HmbMnOR0 C++→C#と来て久しぶりにC#に戻ったらC++の面倒くささに驚いた
226デフォルトの名無しさん (ワッチョイ 256e-j5Jm)
2019/12/05(木) 19:18:00.89ID:5HmbMnOR0 C++に戻ったらの間違い
227デフォルトの名無しさん (ドコグロ MM31-cb5P)
2019/12/05(木) 22:20:07.57ID:P/hgT5Y1M >>222
JSONはいいかげんコメント書けるようにしろよ
JSONはいいかげんコメント書けるようにしろよ
228デフォルトの名無しさん (ワッチョイ cd4b-fARI)
2019/12/05(木) 22:28:30.57ID:lfPZrKZb0 >>227
コメントというデータを仕込めばいいんじゃね?
コメントというデータを仕込めばいいんじゃね?
229デフォルトの名無しさん (ワッチョイ dd7b-R0T4)
2019/12/05(木) 22:56:27.93ID:Ne31Bdzq0 ラベルダブルクリックでテキストがコピーされるのに初めて気づいた
何でこんな余計な機能つけるんだよ。せめてプロパティでオンオフできるようにしとけよ
何でこんな余計な機能つけるんだよ。せめてプロパティでオンオフできるようにしとけよ
230デフォルトの名無しさん (ワッチョイ 2301-cb5P)
2019/12/05(木) 23:33:27.61ID:LiE2fHBS0 >>228
そういうバッドノウハウに頼りたくない
そういうバッドノウハウに頼りたくない
231デフォルトの名無しさん (ラクッペ MMa1-nv6m)
2019/12/06(金) 12:42:16.61ID:OcIGrh02M JSONの"再発見"者ニキ「JSONにコメントを書けないようにしておいてよかった」
232デフォルトの名無しさん (ワッチョイ cd4b-fARI)
2019/12/06(金) 12:55:10.38ID:q3Vb2TIN0 >>230
じゃあ、RFC4627 に口出しできる立場になって、自分で提唱すれば?
じゃあ、RFC4627 に口出しできる立場になって、自分で提唱すれば?
233デフォルトの名無しさん (アウアウウー Saa9-FVm2)
2019/12/06(金) 12:56:20.84ID:PT33Vgnva 何がじゃあだよガキかw
234デフォルトの名無しさん (ワッチョイ 2363-Uyjt)
2019/12/06(金) 13:58:14.26ID:5jTZz7uG0 どこがガキなのかわからん
235デフォルトの名無しさん (ドコグロ MM43-cb5P)
2019/12/06(金) 21:08:55.37ID:G0zfLpZEM えっ?
いきなりRfCとか言い出す>>232なんてガキの思考そのままだろw
いきなりRfCとか言い出す>>232なんてガキの思考そのままだろw
236デフォルトの名無しさん (ワッチョイ 4563-nv6m)
2019/12/06(金) 22:18:00.52ID:ttYkMtMH0 なるほどガキらしい考えだ
ママに聞かせて褒めてもらいな
ママに聞かせて褒めてもらいな
237デフォルトの名無しさん (ワッチョイ cd4b-fARI)
2019/12/07(土) 14:40:03.37ID:9Gp2j7L60 規格が気に入らないなら、それを変更するように影響を与えないといつまでも変わらない。
規格が気に入らない。可能な代替案も気に入らない。って喚いてるだけじゃん。
どっちがガキだよlol
規格が気に入らない。可能な代替案も気に入らない。って喚いてるだけじゃん。
どっちがガキだよlol
238デフォルトの名無しさん (ワッチョイ 2361-GJme)
2019/12/07(土) 15:36:41.80ID:4jkkIRaG0239デフォルトの名無しさん (アウアウウー Saa9-FVm2)
2019/12/07(土) 17:37:24.28ID:Ga9vuWSha240デフォルトの名無しさん (ワッチョイ 6d17-Fgt1)
2019/12/07(土) 17:47:06.56ID:uIc1VvAO0 ふらっとだけじゃなくここでも人格批判かよ
板違いだから余所でやってくれ
板違いだから余所でやってくれ
241デフォルトの名無しさん (ワッチョイ 7501-GGZf)
2019/12/07(土) 17:50:57.13ID:MHWzy9730242デフォルトの名無しさん (ワッチョイ 2301-cb5P)
2019/12/07(土) 18:02:30.43ID:f2i8nuZX0243デフォルトの名無しさん (ワッチョイ 2361-GJme)
2019/12/07(土) 18:02:39.31ID:4jkkIRaG0244デフォルトの名無しさん (ワッチョイ 2361-GJme)
2019/12/07(土) 18:07:14.42ID:4jkkIRaG0 >>243
あれ、JSONの話だった。
あれ、JSONの話だった。
245デフォルトの名無しさん (ワッチョイ 2363-Uyjt)
2019/12/07(土) 18:12:42.05ID:L+Kcsfik0 >>238
よくわからないんだけどC#と敵対してる言語ってなに?
よくわからないんだけどC#と敵対してる言語ってなに?
246デフォルトの名無しさん (ドコグロ MM93-5nhq)
2019/12/07(土) 18:21:09.76ID:erYV0nIUM 大多数のC#erが敵と感じることが多いのはVBじゃないかな
MS的には敵はGoやJavaと言いたいだろうけど、まだまだC#は(Unityを除けば)Windowsでしか使われておらず、プラットフォームの制約で仕方なく選ばれる言語の域を出ない
その上でVBを選ぶかC#を選ぶかは完全に好みの問題なわけで、
そこで好みを優先できる組織ならそもそもサーバーにWindowsなんか採用しないよね
MS的には敵はGoやJavaと言いたいだろうけど、まだまだC#は(Unityを除けば)Windowsでしか使われておらず、プラットフォームの制約で仕方なく選ばれる言語の域を出ない
その上でVBを選ぶかC#を選ぶかは完全に好みの問題なわけで、
そこで好みを優先できる組織ならそもそもサーバーにWindowsなんか採用しないよね
247デフォルトの名無しさん (ワッチョイ 2361-GJme)
2019/12/07(土) 18:28:17.16ID:4jkkIRaG0 >>245
自分の好きな言語を広めたいと思っている人も居るわけですよ。
自分の好きな言語を広めたいと思っている人も居るわけですよ。
248デフォルトの名無しさん (ワッチョイ 2363-Uyjt)
2019/12/07(土) 18:37:40.00ID:L+Kcsfik0249デフォルトの名無しさん (ワッチョイ 2361-GJme)
2019/12/07(土) 18:50:47.69ID:4jkkIRaG0 >>248
黙秘権を使います。
黙秘権を使います。
250デフォルトの名無しさん (ワッチョイ 236a-Fgt1)
2019/12/07(土) 20:35:07.03ID:VnqK0uSL0251デフォルトの名無しさん (ワッチョイ a501-gDf/)
2019/12/07(土) 20:48:48.93ID:KZIoY4Tw0 さすがに今どきVB.NETは有り得ないんじゃね?
252デフォルトの名無しさん (ワッチョイ 4be3-V35x)
2019/12/07(土) 20:53:05.32ID:7QN5mOIt0 ここ数年VBなんて見てないわ
他の選択肢が多すぎて選ぶ人なんて居ないだろう
他の選択肢が多すぎて選ぶ人なんて居ないだろう
253デフォルトの名無しさん (ワッチョイ 152f-V35x)
2019/12/07(土) 22:43:02.88ID:quRr2R9X0 1. 設定値を入力する画面がある
2. 設定値を入力して登録ボタンを押すと、設定値保管用クラスの変数に値を渡す
3. 他クラスは画面の値でなく、設定用保管クラスの変数の値を参照する
みたいなクソ仕様のアプリを書いてしまいました。
なんで直接、設定値入力画面の入力値を参照しないのか・・・。
仕様を直したいんだけど、もうクソ長いコード書いてしまっていまさら直すのも数日かかりになりそう。。。
2. 設定値を入力して登録ボタンを押すと、設定値保管用クラスの変数に値を渡す
3. 他クラスは画面の値でなく、設定用保管クラスの変数の値を参照する
みたいなクソ仕様のアプリを書いてしまいました。
なんで直接、設定値入力画面の入力値を参照しないのか・・・。
仕様を直したいんだけど、もうクソ長いコード書いてしまっていまさら直すのも数日かかりになりそう。。。
254デフォルトの名無しさん (ワッチョイ 152f-V35x)
2019/12/07(土) 22:44:22.12ID:quRr2R9X0255デフォルトの名無しさん (アウアウウー Saa9-GapK)
2019/12/07(土) 22:46:49.22ID:1bDOsUysa 普通じゃね?シリアライズするなら当然そうしねーか?
256デフォルトの名無しさん (ワッチョイ 4b7b-iKQf)
2019/12/07(土) 23:08:25.55ID:zukzhMoh0 C#関係ないようなw
設定値の復帰させるとかでも一括で管理する部分あった方が取り回し楽になるし何がクソなのかもわからない
>>254
むしろ該当部分組みなおすのに数日かかってしまう形になっているのが問題では
設定値の復帰させるとかでも一括で管理する部分あった方が取り回し楽になるし何がクソなのかもわからない
>>254
むしろ該当部分組みなおすのに数日かかってしまう形になっているのが問題では
257デフォルトの名無しさん (アウアウウー Saa9-FVm2)
2019/12/07(土) 23:09:21.20ID:Ga9vuWSha >>253
言ってること誤解してるかもしれないけど、
UIの入力をダイレクトに設定に反映しないのはMSのお作法的には
むしろ正しいんじゃないの?
適用かOKをクリックするまで入力が設定に反映されず、キャンセルボタンを
クリックすると何もなかったことになる仕様なんだよねたぶん?
まあ、仕様が適切かどうかは要件次第だと思うんで、あんまり教条主義的に考えない方が...
要は使いやすければそれでいいんで
言ってること誤解してるかもしれないけど、
UIの入力をダイレクトに設定に反映しないのはMSのお作法的には
むしろ正しいんじゃないの?
適用かOKをクリックするまで入力が設定に反映されず、キャンセルボタンを
クリックすると何もなかったことになる仕様なんだよねたぶん?
まあ、仕様が適切かどうかは要件次第だと思うんで、あんまり教条主義的に考えない方が...
要は使いやすければそれでいいんで
258デフォルトの名無しさん (ワッチョイ 032d-Do/g)
2019/12/08(日) 00:00:10.40ID:Oblj5J3Y0 大まかな設計は悪くないと思うけど、
2. 設定値を入力して登録ボタンを押すと、設定値保管用クラスの 「変数に値を渡す」
3. 他クラスは画面の値でなく、設定用保管クラスの「変数の値を参照する」 (画面の値でも同様によくない)
って仕組みは直した方がいいんじゃないかな
一箇所仕様を変えたら全部が狂うとか、変なことが起きてくるんじゃないの
2. 設定値を入力して登録ボタンを押すと、設定値保管用クラスの 「変数に値を渡す」
3. 他クラスは画面の値でなく、設定用保管クラスの「変数の値を参照する」 (画面の値でも同様によくない)
って仕組みは直した方がいいんじゃないかな
一箇所仕様を変えたら全部が狂うとか、変なことが起きてくるんじゃないの
259デフォルトの名無しさん (ワッチョイ 152f-V35x)
2019/12/08(日) 00:29:06.09ID:pSs03yKS0 >>258
まさにそこなんですよね。。。
他クラスで使用しているときに値を変更されないように2、3を実装したんですけど、単に画面を入力できないようにロックすればよかった。
2の変数の名前とか少し替えるとどこで参照先を全て直さなければいけない。
この仕様直したいんですけど、時間がかかるのと単純作業を繰り返すので、
考えただけで目眩がします。
まさにそこなんですよね。。。
他クラスで使用しているときに値を変更されないように2、3を実装したんですけど、単に画面を入力できないようにロックすればよかった。
2の変数の名前とか少し替えるとどこで参照先を全て直さなければいけない。
この仕様直したいんですけど、時間がかかるのと単純作業を繰り返すので、
考えただけで目眩がします。
260デフォルトの名無しさん (ワッチョイ 15a7-aps1)
2019/12/08(日) 00:38:02.22ID:3vBWNciC0 え?何が悪いのかさっぱりわからん
〜すればってのも俺には的外れに見える
〜すればってのも俺には的外れに見える
261デフォルトの名無しさん (ワッチョイ 2363-Uyjt)
2019/12/08(日) 00:50:00.57ID:tOnI98EO0 >>259
変数の名前ならVisual Studioの機能で簡単に一括変更できるぞ
https://docs.microsoft.com/ja-jp/visualstudio/ide/reference/rename?view=vs-2019
変数の名前ならVisual Studioの機能で簡単に一括変更できるぞ
https://docs.microsoft.com/ja-jp/visualstudio/ide/reference/rename?view=vs-2019
262デフォルトの名無しさん (ワッチョイ 1563-FbR7)
2019/12/08(日) 01:02:05.03ID:7KQ7NXxs0 変数名の変更はVSの機能で一発で済む
vsじゃなくても最近のIDEなら標準的な機能じゃないかな?
書いてある設計自体は普通でクソだとは思わん
設定値が1万個くらいあってそれを1個のclassに全部ぶち込んでるとかだと整理したほうがいいんじゃね?って思うけどそういうわけでもないんでしょ?
画面ロックすればよかったって言ってるってことはあとから値変えられて困ってるってこと?
登録ボタンなんて作らずに画面上の設定値が変更されたら即座に設定値管理用classに反映させればいいのでは?
vsじゃなくても最近のIDEなら標準的な機能じゃないかな?
書いてある設計自体は普通でクソだとは思わん
設定値が1万個くらいあってそれを1個のclassに全部ぶち込んでるとかだと整理したほうがいいんじゃね?って思うけどそういうわけでもないんでしょ?
画面ロックすればよかったって言ってるってことはあとから値変えられて困ってるってこと?
登録ボタンなんて作らずに画面上の設定値が変更されたら即座に設定値管理用classに反映させればいいのでは?
263デフォルトの名無しさん (ワッチョイ cdde-aps1)
2019/12/08(日) 01:04:08.10ID:PIvqmbCd0264デフォルトの名無しさん (ワッチョイ ed5f-QX1D)
2019/12/08(日) 01:06:23.59ID:KIb7eBZ10265デフォルトの名無しさん (ワッチョイ cdde-aps1)
2019/12/08(日) 01:06:29.61ID:PIvqmbCd0 開始日、終了日の入力で
開始日から終了日の期間に制限がある場合とかバインドに弱い
開始値、終了値も同様
開始日から終了日の期間に制限がある場合とかバインドに弱い
開始値、終了値も同様
266デフォルトの名無しさん (ワッチョイ 1563-FbR7)
2019/12/08(日) 01:13:11.42ID:7KQ7NXxs0 >>263
いや、何も詰まないけど?
反映するときにチェックして異常値であることがわかればいいじゃん
登録ボタンで登録時にチェックしてエラーとするのと何らかわらん
設定値保持classは常に正常な値のみを保持する
って要件ならそら無理よ
いや、何も詰まないけど?
反映するときにチェックして異常値であることがわかればいいじゃん
登録ボタンで登録時にチェックしてエラーとするのと何らかわらん
設定値保持classは常に正常な値のみを保持する
って要件ならそら無理よ
267デフォルトの名無しさん (ワッチョイ 032d-Do/g)
2019/12/08(日) 04:54:32.09ID:Oblj5J3Y0268デフォルトの名無しさん (ワッチョイ 2301-cb5P)
2019/12/08(日) 06:45:15.65ID:h14g0YSH0 WPFとかだとそういう風に組むのが推奨されてるし
269デフォルトの名無しさん (ワッチョイ a54f-Fgt1)
2019/12/08(日) 08:21:03.71ID:rNTMaYhL0 >って要件ならそら無理よ
このことを「詰む」って言ってたんではないかと
このことを「詰む」って言ってたんではないかと
270デフォルトの名無しさん (ワッチョイ a501-gDf/)
2019/12/08(日) 08:33:51.79ID:YBiAuaAw0 DocumetViewとかMVVMパターンでは普通の実装だね。
271デフォルトの名無しさん (ワッチョイ 9bde-aps1)
2019/12/08(日) 10:03:29.48ID:K3lJ24NK0272デフォルトの名無しさん (ワッチョイ 152f-V35x)
2019/12/08(日) 10:24:22.87ID:pSs03yKS0273デフォルトの名無しさん (ワッチョイ 152f-V35x)
2019/12/08(日) 10:25:27.96ID:pSs03yKS0 自分で途中からクソ仕様と思い始めてしまったんですが、これが標準なんですかね。
だとしたら安心して引き継げるのですが。
正直面倒くさくて直したくないorz
だとしたら安心して引き継げるのですが。
正直面倒くさくて直したくないorz
274デフォルトの名無しさん (ワッチョイ 9bde-aps1)
2019/12/08(日) 10:29:01.88ID:1rCojsjZ0275デフォルトの名無しさん (ワッチョイ 7501-V35x)
2019/12/08(日) 10:34:32.17ID:JIo60cn60276デフォルトの名無しさん (アウアウエー Sa13-zX1Z)
2019/12/08(日) 10:48:39.51ID:sqNFXMf8a277デフォルトの名無しさん (アウアウウー Saa9-GapK)
2019/12/08(日) 10:56:36.45ID:z9x/0bTQa >>272
ちょっとした吐き捨ての設定ならそれで問題ないかもしれないけど、入力の項目が多くなってアプリを開いてあの設定を保存して呼び出したいってなった時とかどうすんの?とか結局仕様と設計の問題じゃないか?
ちょっとした吐き捨ての設定ならそれで問題ないかもしれないけど、入力の項目が多くなってアプリを開いてあの設定を保存して呼び出したいってなった時とかどうすんの?とか結局仕様と設計の問題じゃないか?
278デフォルトの名無しさん (ドコグロ MM93-cb5P)
2019/12/08(日) 10:57:28.44ID:8fOog+TqM279デフォルトの名無しさん (ワッチョイ 9bde-aps1)
2019/12/08(日) 11:04:44.31ID:C3XpVZQF0 画面遷移されたら消えるの?
たまたま今回画面遷移せんの?
問題が起こりまくるから止めろと言っておく
コントロールの不正な入力を完璧にガードするのはよく知ってる奴でも結構難しいときあるし
たまたま今回画面遷移せんの?
問題が起こりまくるから止めろと言っておく
コントロールの不正な入力を完璧にガードするのはよく知ってる奴でも結構難しいときあるし
280デフォルトの名無しさん (ワッチョイ 1563-FbR7)
2019/12/08(日) 12:32:23.17ID:7KQ7NXxs0 >>271
ユーザーが設定値を変更したとき
そうやって突っ込むってことは
>設定値保持classは常に正常な値のみを保持する
って要件はないんだよね?
開始終了とか関係なくユーザーが設定した値保持するだけじゃん
mvvmとか見たこと無いの?
ユーザーが設定値を変更したとき
そうやって突っ込むってことは
>設定値保持classは常に正常な値のみを保持する
って要件はないんだよね?
開始終了とか関係なくユーザーが設定した値保持するだけじゃん
mvvmとか見たこと無いの?
281デフォルトの名無しさん (ワッチョイ 9bde-aps1)
2019/12/08(日) 12:50:54.37ID:MsET5CX00 >>280
開始に1980/01/01
終了に1980/02/01
が設定されてたとき
期間に3ヶ月って制限がかかってたときに
開始と終了に2019/09/01-2019/10/01を設定したいとするわな?
よし、じゃ、開始に2019の・・・エラー!(終了に1980/02/01が入ってるので)
じゃ、終了に2019の・・・エラー!(開始に1980/01/01が入ってるので)
詰んだじゃん
開始に1980/01/01
終了に1980/02/01
が設定されてたとき
期間に3ヶ月って制限がかかってたときに
開始と終了に2019/09/01-2019/10/01を設定したいとするわな?
よし、じゃ、開始に2019の・・・エラー!(終了に1980/02/01が入ってるので)
じゃ、終了に2019の・・・エラー!(開始に1980/01/01が入ってるので)
詰んだじゃん
282デフォルトの名無しさん (ワッチョイ 152f-V35x)
2019/12/08(日) 12:55:17.97ID:pSs03yKS0283デフォルトの名無しさん (ワッチョイ 152f-V35x)
2019/12/08(日) 12:56:57.51ID:pSs03yKS0 >>279
開始ボタンをおしても、設定入力画面は開いたままで画面遷移させてないんですよね。
開始ボタンをおしても、設定入力画面は開いたままで画面遷移させてないんですよね。
284デフォルトの名無しさん (ワッチョイ 152f-V35x)
2019/12/08(日) 12:59:14.97ID:pSs03yKS0 みなさんのお話を聞いていると、
登録ボタンを押して、変数記録クラスに画面の値を記録させるというのはクソ仕様ではなかったんですね。
ホッとしました。
登録ボタンを押して、変数記録クラスに画面の値を記録させるというのはクソ仕様ではなかったんですね。
ホッとしました。
285デフォルトの名無しさん (ワッチョイ 1563-FbR7)
2019/12/08(日) 13:00:29.22ID:7KQ7NXxs0 >>281
エラーになる設定に値を設定への操作を許可してりゃ詰んでないじゃんw
そもそもそういう操作を禁止するなんて話どこにあった?
ユーザーの操作は何も制限なんてする必要は無い
設定保持classが現在入力されている設定値が正常か否かだけを分かってればいい
エラーになる設定に値を設定への操作を許可してりゃ詰んでないじゃんw
そもそもそういう操作を禁止するなんて話どこにあった?
ユーザーの操作は何も制限なんてする必要は無い
設定保持classが現在入力されている設定値が正常か否かだけを分かってればいい
286デフォルトの名無しさん (ワッチョイ 152f-V35x)
2019/12/08(日) 13:00:57.18ID:pSs03yKS0 画面に入力された文字は変数記録クラスに記録させて、
変数記録クラスを参照していると、
「あれ、この変数って画面ではどこのことだっけ?」
とかなるのは自分の頭がクソ仕様ということか・・・。
変数記録クラスを参照していると、
「あれ、この変数って画面ではどこのことだっけ?」
とかなるのは自分の頭がクソ仕様ということか・・・。
287デフォルトの名無しさん (ワッチョイ 1563-FbR7)
2019/12/08(日) 13:04:18.68ID:7KQ7NXxs0 この理論、パスワードは8文字以上でって制限だと
1文字目を打ったタイミングでエラー出して入力ボックス消すってことか?
そんでコピペ以外で8文字以上打つことができずに詰んだってか?
そんなびっくり仕様どこにあるの?
1文字目を打ったタイミングでエラー出して入力ボックス消すってことか?
そんでコピペ以外で8文字以上打つことができずに詰んだってか?
そんなびっくり仕様どこにあるの?
288デフォルトの名無しさん (ワッチョイ 95ad-dl55)
2019/12/08(日) 13:04:22.11ID:oZbmRsqQ0 >>286
そこは間違いないな
そこは間違いないな
289デフォルトの名無しさん (ワッチョイ 9bde-aps1)
2019/12/08(日) 13:06:20.25ID:BE6HVZz80 だからワンクッション置かないと駄目だよねって話
290デフォルトの名無しさん (ワッチョイ ed5f-QX1D)
2019/12/08(日) 13:08:13.78ID:KIb7eBZ10 >>286
変数記録クラスで変数を入れておくのをプロパティにしておけば、VSの機能で参照先をすぐに探せる
変数記録クラスで変数を入れておくのをプロパティにしておけば、VSの機能で参照先をすぐに探せる
291デフォルトの名無しさん (ワッチョイ 9bde-aps1)
2019/12/08(日) 13:17:20.81ID:WI1y2v9y0292デフォルトの名無しさん (ワッチョイ 1563-FbR7)
2019/12/08(日) 13:26:39.13ID:7KQ7NXxs0 >>291
だからダメだったら何なの?
不正な値が入力されたらそうであることが参照するclassがわかればいいだけ
登録ボタン形式であっても登録時にチェックして正常異常を判定するのだから異常入力をユーザーに通知できるタイミングの違いでしか無い
何も詰まないのに詰むでしょ?考えて?組んだこと無いの?
って勝手に操作入力制限の要件足して突っかかってくるのやめてね
だからダメだったら何なの?
不正な値が入力されたらそうであることが参照するclassがわかればいいだけ
登録ボタン形式であっても登録時にチェックして正常異常を判定するのだから異常入力をユーザーに通知できるタイミングの違いでしか無い
何も詰まないのに詰むでしょ?考えて?組んだこと無いの?
って勝手に操作入力制限の要件足して突っかかってくるのやめてね
293デフォルトの名無しさん (ワッチョイ 9bde-aps1)
2019/12/08(日) 13:42:37.78ID:z1c2Df2S0294デフォルトの名無しさん (ワッチョイ a301-8opd)
2019/12/08(日) 13:49:38.20ID:B7mwO2xN0295デフォルトの名無しさん (ワッチョイ 1563-FbR7)
2019/12/08(日) 13:50:09.94ID:7KQ7NXxs0296デフォルトの名無しさん (ワッチョイ a54f-Fgt1)
2019/12/08(日) 13:53:27.09ID:rNTMaYhL0 >設定値が変更されたら即座に
>設定値管理用classに反映させればいいのでは?
これ、バリデーションとか無い場合の方がやっかいだよね。
ユーザーは10を入力したかったのに1で処理されちゃうとか。
>設定値管理用classに反映させればいいのでは?
これ、バリデーションとか無い場合の方がやっかいだよね。
ユーザーは10を入力したかったのに1で処理されちゃうとか。
297デフォルトの名無しさん (ワッチョイ 1563-FbR7)
2019/12/08(日) 13:58:30.12ID:7KQ7NXxs0 個人的に割とよくある設計だと思ってる
入力したタイミングからエラーチェックして早めにユーザーに通知できるメリットがでかい
webなんかではよく見る形式
で、そんなよくある設計を詰むよ、なんて言って初学者(かどうかわからんが)に対して無意味に敬遠させるべきでは無いと思う
入力したタイミングからエラーチェックして早めにユーザーに通知できるメリットがでかい
webなんかではよく見る形式
で、そんなよくある設計を詰むよ、なんて言って初学者(かどうかわからんが)に対して無意味に敬遠させるべきでは無いと思う
298デフォルトの名無しさん (ワッチョイ 9bde-aps1)
2019/12/08(日) 14:06:24.08ID:90QfBCQ40299デフォルトの名無しさん (ワッチョイ 9bde-aps1)
2019/12/08(日) 14:08:43.35ID:90QfBCQ40300デフォルトの名無しさん (ワッチョイ 25e7-xqEQ)
2019/12/08(日) 14:18:51.74ID:WpCL9e8A0 MVVMを持ち出してる割にVMとMがごっちゃになってるように見える
301デフォルトの名無しさん (ワッチョイ 1563-FbR7)
2019/12/08(日) 14:19:22.37ID:7KQ7NXxs0 >>299
何を無理だと感じているのかさっぱりわからん
from/toが範囲外になったってユーザーがそう入力してるならその値を保持するだけ
で処理に進む段階で異常値があるなら進ませない
登録ボタン形式なら異常値があるなら受け付けない
処理に進むのを実行ボタンとすれば
前者なら異常値があれば実行ボタンを無効化しておき、設定値が全て正常になったタイミングで有効化する
みたいな要件が実現しやすい
何を無理だと感じているのかさっぱりわからん
from/toが範囲外になったってユーザーがそう入力してるならその値を保持するだけ
で処理に進む段階で異常値があるなら進ませない
登録ボタン形式なら異常値があるなら受け付けない
処理に進むのを実行ボタンとすれば
前者なら異常値があれば実行ボタンを無効化しておき、設定値が全て正常になったタイミングで有効化する
みたいな要件が実現しやすい
302デフォルトの名無しさん (ワッチョイ 9bde-aps1)
2019/12/08(日) 14:25:09.69ID:90QfBCQ40 >>301
即時反映の話はどこいったん?
即時反映の話はどこいったん?
303デフォルトの名無しさん (ワッチョイ 9bde-aps1)
2019/12/08(日) 14:26:41.39ID:90QfBCQ40 さらに設定値を参照してる奴全員に異常値の対応をさせるってありえなくね?
304デフォルトの名無しさん (ワッチョイ 1563-FbR7)
2019/12/08(日) 14:27:36.72ID:7KQ7NXxs0305デフォルトの名無しさん (ワッチョイ 1563-FbR7)
2019/12/08(日) 14:28:42.21ID:7KQ7NXxs0 >>303
そんな仕様どこに書いてあった?
そんな仕様どこに書いてあった?
306デフォルトの名無しさん (ワッチョイ 9bde-aps1)
2019/12/08(日) 14:32:02.79ID:90QfBCQ40 なんかすでに議論に勝つためだけに頑張っちゃってる感じ?
307デフォルトの名無しさん (ワッチョイ a54f-Fgt1)
2019/12/08(日) 14:34:19.70ID:rNTMaYhL0 登録ボタンと実行ボタンがある前提で登録ボタンの方は無くせる、と言っているのかな?
308デフォルトの名無しさん (ブーイモ MM6b-zX1Z)
2019/12/08(日) 14:41:07.50ID:eGeBS+CxM >>299
入力中はアンダーラインを引いたりメッセージを出して通知はするが間違ってても即保存する
入力された不正な設定値を読み取る時に無視するあるいは警告を出して無視するはたまたエラーを出して失敗させる
後々設定をアプリ外から弄ることも視野に入れると読み取り時にデータの正確性を保証したほうがいい
入力中はアンダーラインを引いたりメッセージを出して通知はするが間違ってても即保存する
入力された不正な設定値を読み取る時に無視するあるいは警告を出して無視するはたまたエラーを出して失敗させる
後々設定をアプリ外から弄ることも視野に入れると読み取り時にデータの正確性を保証したほうがいい
309デフォルトの名無しさん (ワッチョイ 1563-FbR7)
2019/12/08(日) 14:50:30.86ID:7KQ7NXxs0 UI→登録ボタンによるチェック処理→設定値保持class
UI→チェック機能を有した設定値保持class
こんだけ
前者はチェック処理で弾けば設定値保持classには異常値が入っていないことが担保できる
後者は設定値保持class自身が正常と判断してるかどうかで異常値があるかどうかを判断する
別に前者の設計が一概にダメとは思わないしこういうこともよくするが後者が詰むという理論は理解できん
UI→チェック機能を有した設定値保持class
こんだけ
前者はチェック処理で弾けば設定値保持classには異常値が入っていないことが担保できる
後者は設定値保持class自身が正常と判断してるかどうかで異常値があるかどうかを判断する
別に前者の設計が一概にダメとは思わないしこういうこともよくするが後者が詰むという理論は理解できん
310デフォルトの名無しさん (ワッチョイ a301-8opd)
2019/12/08(日) 14:51:48.07ID:B7mwO2xN0 >>272
一般的には読みやすくメンテしやすくするため
画面からの入力を処理する役割と設定値を管理する役割は別のクラスに持たせる
ただ簡単なプログラムなら画面クラスに設定値管理の役割を持たせるのでも別に構わない
他クラスから不用意に値を書き換えられないようにするのはそいうふうに設定管理クラスを作ればいいだけ
レス見る限り他のクラスの変数を
プロパティやメソッド経由せずに直接設定したり直接参照してる風に読めるんだが
もしそうなら役割ごとにクラスを分離したのに密結合してるのが一番の問題
でもブチ切れるレベルの人ならササッと書き換えるから心配する必要ないと思う
一般的には読みやすくメンテしやすくするため
画面からの入力を処理する役割と設定値を管理する役割は別のクラスに持たせる
ただ簡単なプログラムなら画面クラスに設定値管理の役割を持たせるのでも別に構わない
他クラスから不用意に値を書き換えられないようにするのはそいうふうに設定管理クラスを作ればいいだけ
レス見る限り他のクラスの変数を
プロパティやメソッド経由せずに直接設定したり直接参照してる風に読めるんだが
もしそうなら役割ごとにクラスを分離したのに密結合してるのが一番の問題
でもブチ切れるレベルの人ならササッと書き換えるから心配する必要ないと思う
311デフォルトの名無しさん (ワッチョイ 032d-Do/g)
2019/12/08(日) 15:03:31.77ID:Oblj5J3Y0 >>272
いやいや、2みたいなものは要るし、3は一番ダメだよ
問題なのはフィールドを他クラスのオブジェクトから読み書きする点で、ここをプロパティーやフレームワークの内部コマンドに置き換えたりしないと徐々にコードが酷くなっていくよ
いやいや、2みたいなものは要るし、3は一番ダメだよ
問題なのはフィールドを他クラスのオブジェクトから読み書きする点で、ここをプロパティーやフレームワークの内部コマンドに置き換えたりしないと徐々にコードが酷くなっていくよ
312デフォルトの名無しさん (ワッチョイ 45a9-hz4T)
2019/12/08(日) 17:55:31.29ID:zhe6A2K90 この一連の流れは相談か?
313デフォルトの名無しさん (ワッチョイ 95ad-dl55)
2019/12/08(日) 18:19:08.18ID:54HI4DkC0 そうだんですよ川崎さん
314デフォルトの名無しさん (アウアウウー Saa9-FVm2)
2019/12/08(日) 18:25:13.90ID:q5OZjWUaa 正直最初の質問が結局何を質問してるんだか俺にはいまいちよく分からないんだけど、
こんな雲をつかむような話でよくレスが50も進むよねw
まず質問者が何を聞きたいと思ってるのかを明確にするのが先だと思うんだけど
こんな雲をつかむような話でよくレスが50も進むよねw
まず質問者が何を聞きたいと思ってるのかを明確にするのが先だと思うんだけど
315デフォルトの名無しさん (ワッチョイ 2301-cb5P)
2019/12/08(日) 19:25:44.35ID:h14g0YSH0316デフォルトの名無しさん (アウアウウー Saa9-FVm2)
2019/12/08(日) 19:40:58.07ID:q5OZjWUaa317デフォルトの名無しさん (ワッチョイ 2301-cb5P)
2019/12/08(日) 20:06:20.23ID:h14g0YSH0 いや、わからないならスルーしとけよ
別にお前がわかる必要はないんだしw
別にお前がわかる必要はないんだしw
318デフォルトの名無しさん (ワッチョイ 6d17-Fgt1)
2019/12/08(日) 20:19:46.26ID:vQtEDwKW0 また昨日の続きかよ
319デフォルトの名無しさん (ワッチョイ 2301-cb5P)
2019/12/08(日) 20:37:00.33ID:h14g0YSH0 自分がわからないのは質問者のせいだ
って思い込んでる人は一定数いるからw
って思い込んでる人は一定数いるからw
320デフォルトの名無しさん (ブーイモ MM39-bVmn)
2019/12/11(水) 18:58:15.46ID:neU6iLAlM 該当クラスがどこのネイムスペースから
なのかすぐわかる方法ってない?
なのかすぐわかる方法ってない?
321デフォルトの名無しさん (アウアウウー Saa9-FVm2)
2019/12/11(水) 19:12:17.36ID:A2ve7TTYa322デフォルトの名無しさん (ブーイモ MM39-bVmn)
2019/12/11(水) 19:16:20.62ID:neU6iLAlM323デフォルトの名無しさん (ワッチョイ 6d17-Fgt1)
2019/12/11(水) 19:22:09.23ID:3diBwqZu0 名前空間を省略せずに書けばいいだろ
324デフォルトの名無しさん (ワッチョイ 95ad-dl55)
2019/12/11(水) 19:27:51.94ID:2za+15ZK0 javaだってするだろ
325デフォルトの名無しさん (ワッチョイ 2363-Uyjt)
2019/12/11(水) 19:31:24.40ID:tBBOlHQ00 >>322
C#に限らず最近の言語はほぼIDEや高機能エディタ前提だと思うが
C#に限らず最近の言語はほぼIDEや高機能エディタ前提だと思うが
326デフォルトの名無しさん (アウアウウー Saa9-FVm2)
2019/12/11(水) 20:19:46.44ID:A2ve7TTYa >>322
ライブラリの型ならC#と一緒にググればすぐ出てくるでしょ
ライブラリの型ならC#と一緒にググればすぐ出てくるでしょ
327デフォルトの名無しさん (ワッチョイ 1563-FbR7)
2019/12/11(水) 20:25:15.92ID:EPJ4Sm/w0 vscodeすら入れられないの?
メモ帳縛りとかコンパイルもめんどいやん
てかコンパイラ単体で持ってきたの?
メモ帳縛りとかコンパイルもめんどいやん
てかコンパイラ単体で持ってきたの?
328デフォルトの名無しさん (ワッチョイ 23ad-XnaB)
2019/12/11(水) 23:25:24.84ID:fjLZq11N0 昔はviとかで普通にコーディングしてたが
今更メモ帳でコーディングする気にはなれんな
今のIDEとかもう便利すぎる
今更メモ帳でコーディングする気にはなれんな
今のIDEとかもう便利すぎる
329デフォルトの名無しさん (ワッチョイ a201-VrMI)
2019/12/12(木) 00:08:12.86ID:n05Ewb3K0 dotnet buildでいいからコンパイルは楽でしょ
330デフォルトの名無しさん (ワッチョイ e26a-xO71)
2019/12/12(木) 00:22:15.51ID:AJjh9lU00 今時viだってコーディング支援あるしね
331デフォルトの名無しさん (オッペケ Srcb-elTq)
2019/12/21(土) 08:44:14.52ID:mOkYxWI2r インデントもわざわざ打たなきゃならんでしょメモ帳・・・
332デフォルトの名無しさん (スップ Sd3f-JseX)
2019/12/21(土) 09:28:59.77ID:RVospelqd333デフォルトの名無しさん (ブーイモ MMbf-70ba)
2019/12/21(土) 09:53:05.63ID:elCUYmNmM クラウドIDE良いよ
インストール不自由でも使える
インストール不自由でも使える
334デフォルトの名無しさん (ワッチョイ 9f01-pdcM)
2019/12/21(土) 11:11:56.97ID:tKqa0Mcd0335デフォルトの名無しさん (ワッチョイ 7717-prDO)
2019/12/21(土) 12:14:55.25ID:wj7YAMPY0 メモ帳しか使えない環境だからいくら紹介しても無駄だぞ
336デフォルトの名無しさん (ササクッテロ Spcb-JQOI)
2019/12/22(日) 01:12:40.65ID:BLYFt7Uup 最初にメモ帳でC#に特化したエディタ作る
以降はそれで開発
以降はそれで開発
337デフォルトの名無しさん (ワッチョイ 5701-EwPn)
2019/12/22(日) 02:09:51.62ID:thbQEK090 C言語はC言語で書かれてると聞いたことがあるような…
最初にどう始めたかは知らない
アセンブラか他言語で始めてCに移行だとは思うが
最初にどう始めたかは知らない
アセンブラか他言語で始めてCに移行だとは思うが
338デフォルトの名無しさん (ワッチョイ b754-+Tiu)
2019/12/22(日) 05:49:50.97ID:By9IH60L0 セルフホスティングやな
339デフォルトの名無しさん (ブーイモ MMdb-gy34)
2019/12/22(日) 12:27:43.38ID:BM7u1zydM そんなことも知らないのかよ
cの場合は最初にクロスコンパイラを作るから、新しいプラットフォームでもアセンブラは不要。
て、さっきwikiで読んだ
cの場合は最初にクロスコンパイラを作るから、新しいプラットフォームでもアセンブラは不要。
て、さっきwikiで読んだ
340デフォルトの名無しさん (ワッチョイ 9f6a-prDO)
2019/12/22(日) 13:11:54.70ID:0l5I7UXk0 原初の環境では機械語直入力だ
341デフォルトの名無しさん (ワッチョイ 9f01-fd2f)
2019/12/22(日) 14:27:23.59ID:4GpMlcpo0 >>339
そのクロスコンパイラとやらはなんの言語で書かれてるんだ?
そのクロスコンパイラとやらはなんの言語で書かれてるんだ?
342デフォルトの名無しさん (ワッチョイ ff12-gy34)
2019/12/22(日) 15:28:16.06ID:la1jzM750 もちろんCだよ。
gccに関して言えば、まず、Cで書かれた自分自身のサブセットを別のCコンパイラでコンパイルしてから、自分自身のサブセットで自分自身をコンパイルする。
だから今後Cコンパイラがアセンブラで書かれる必要はまったくない。書きたければ書くのは自由だが。
なお、最初のCコンパイラはBで書かれたものとDECマシン向けのアセンブラで書かれたものがあり、Bコンパイラはすべてアセンブラで書かれていた。
僕くらい博識になるとこんなの常識だね。明日には忘れるけど
gccに関して言えば、まず、Cで書かれた自分自身のサブセットを別のCコンパイラでコンパイルしてから、自分自身のサブセットで自分自身をコンパイルする。
だから今後Cコンパイラがアセンブラで書かれる必要はまったくない。書きたければ書くのは自由だが。
なお、最初のCコンパイラはBで書かれたものとDECマシン向けのアセンブラで書かれたものがあり、Bコンパイラはすべてアセンブラで書かれていた。
僕くらい博識になるとこんなの常識だね。明日には忘れるけど
343デフォルトの名無しさん (ブーイモ MMbf-70ba)
2019/12/22(日) 15:36:37.89ID:ngCRczT7M まるでC博士だな
大したやつだ
大したやつだ
344デフォルトの名無しさん (アウアウウー Sa5b-1WEo)
2019/12/22(日) 15:38:35.28ID:sqLa+RyJa いきなりネイティブのコンパイラは無理っぽいわ。
>>342
gcc は確か C++ で記述されていたはず、C++ のサブセットなんてどんなものなんですかね?
gcc は確か C++ で記述されていたはず、C++ のサブセットなんてどんなものなんですかね?
346デフォルトの名無しさん (ワッチョイ d7ad-6AKx)
2019/12/22(日) 16:11:14.32ID:5lkZulIS0 元々はただのCだぞ
>>346
ずいぶん昔に gcc は c++ になってしまいましたよ…
ずいぶん昔に gcc は c++ になってしまいましたよ…
348デフォルトの名無しさん (アウアウカー Sa2b-6AKx)
2019/12/22(日) 16:45:16.31ID:lRvby7lea 元々はって日本語わからんのかな
349デフォルトの名無しさん (ワッチョイ 17da-UiIE)
2019/12/22(日) 16:46:38.86ID:uiOI59Hv0 昔のc++はcのコードを一旦出力してcコンパイラでバイナリを作っていたな
350デフォルトの名無しさん (ワッチョイ 9f01-fd2f)
2019/12/22(日) 17:21:58.53ID:4GpMlcpo0352デフォルトの名無しさん (ワッチョイ d7ad-6AKx)
2019/12/22(日) 18:56:50.05ID:5lkZulIS0 かわいそうに、馬鹿なのだな
353デフォルトの名無しさん (ワッチョイ 7717-prDO)
2019/12/22(日) 19:39:34.09ID:tqOBQt+/0 >>352
コテでググったら各所で問題児扱いされている奴だったわ
コテでググったら各所で問題児扱いされている奴だったわ
354デフォルトの名無しさん (ワッチョイ 9f6a-prDO)
2019/12/22(日) 21:03:00.98ID:0l5I7UXk0 >>350
よーく読んでみ
よーく読んでみ
355デフォルトの名無しさん (ワッチョイ ff12-gy34)
2019/12/22(日) 21:43:42.23ID:la1jzM750356デフォルトの名無しさん (ワッチョイ 9f01-fd2f)
2019/12/22(日) 21:55:06.63ID:4GpMlcpo0357デフォルトの名無しさん (ワッチョイ 9f6a-prDO)
2019/12/23(月) 00:11:53.87ID:GXjcw1770 だめだこいつ…w
358デフォルトの名無しさん (ドコグロ MMdf-fd2f)
2019/12/23(月) 06:44:48.06ID:AlxEeRKZM >>357
自己紹介乙ww
自己紹介乙ww
359デフォルトの名無しさん (ワッチョイ 978e-Imov)
2019/12/25(水) 16:59:22.64ID:Zg8ebJFL0 今日もつまらないことで5chは盛り上がっております
360デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/26(木) 11:49:58.62ID:2UlJm9YS0 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)
あれって厳密には「リークする」ではなくて、
「解放のタイミングが不明で、場合によっては問題が発生することもあり得る」なだけだよな?
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)
361デフォルトの名無しさん (ワッチョイ dc2c-++NQ)
2019/12/26(木) 12:35:29.16ID:WMR2NHe80 サンプルプログラムに厳密性を求めるな ってだけ
362デフォルトの名無しさん (ドコグロ MM46-Nxir)
2019/12/26(木) 12:37:11.96ID:Fsuom43iM サンプルだから本質には関係ないところをバッサリ省略してるだけでしょ
ガチな例外処理とか入れられても見辛いだけだし
それと同じ話
ガチな例外処理とか入れられても見辛いだけだし
それと同じ話
363デフォルトの名無しさん (ドコグロ MM40-NvuD)
2019/12/26(木) 13:02:58.04ID:Wx+k6OqqM まあサンプルをコピペしちゃうレベルなら他にもっとまずいところはいくらでもあるだろうから、
少々Disposeが先延ばしになるくらいは無視しても問題ないかと
少々Disposeが先延ばしになるくらいは無視しても問題ないかと
364デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/26(木) 13:36:36.96ID:2UlJm9YS0 >>253
周回遅れだが一応参戦。当該院生が冬休みでもう一度読んでいることを期待する。
他の人も言っているとおり、設計としては253で正しい。直す必要はない。
なおその点はForms->WPFで思想が修正された点であり、(つまりFormsが駄目だった点)
これも他の人が既に言っているとおり、「最新のフレームワークの流儀」で設計するのが妥当。
判断する能力がないなら、とにかく「最新の流儀」に乗っかるのが
無駄に嵌るのを未然に防ぐ適切な方策となるのでそうすべき。
構成としては、おそらく、
「設定値変更画面(V)」「設定値保管用クラス(M)」「他クラス(多分演算ルーチン)(EXE)」で、
これはMVCの通りであり、V-M, M-EXE 間は結合しているがV-EXEは結合していない。
これに対して、誰か(≒老害)に指摘されたのだと思うが、君が253の時点でいいと思っている構成は、
「設定値変更画面(V+M)」「他クラス(多分演算ルーチン)(EXE)」となっており、Mが分離していない。
(=EXE側がVを知っている必要がある)
この構成の利点は、
・コードが多少少なく済む
点であるが、結局使い勝手が悪いので、ずっと改善していくと最終的に253みたくMVCに分離することになる。
周回遅れだが一応参戦。当該院生が冬休みでもう一度読んでいることを期待する。
他の人も言っているとおり、設計としては253で正しい。直す必要はない。
なおその点はForms->WPFで思想が修正された点であり、(つまりFormsが駄目だった点)
これも他の人が既に言っているとおり、「最新のフレームワークの流儀」で設計するのが妥当。
判断する能力がないなら、とにかく「最新の流儀」に乗っかるのが
無駄に嵌るのを未然に防ぐ適切な方策となるのでそうすべき。
構成としては、おそらく、
「設定値変更画面(V)」「設定値保管用クラス(M)」「他クラス(多分演算ルーチン)(EXE)」で、
これはMVCの通りであり、V-M, M-EXE 間は結合しているがV-EXEは結合していない。
これに対して、誰か(≒老害)に指摘されたのだと思うが、君が253の時点でいいと思っている構成は、
「設定値変更画面(V+M)」「他クラス(多分演算ルーチン)(EXE)」となっており、Mが分離していない。
(=EXE側がVを知っている必要がある)
この構成の利点は、
・コードが多少少なく済む
点であるが、結局使い勝手が悪いので、ずっと改善していくと最終的に253みたくMVCに分離することになる。
365デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/26(木) 13:37:07.04ID:2UlJm9YS0 >>259
といっても分かりにくいだろうから具体的に指摘すると、
君の問題は、間違った方策で解決しようとして、余計におかしくなっていることだ。
> 他クラスで使用しているときに値を変更されないように2、3を実装したんですけど、単に画面を入力できないようにロックすればよかった。
これは「画面をロック」ではなく、演算開始時に「設定値保管クラスのコピーを演算ルーチンに渡す」とすべき。
これにより、一つの実行画面から多数の演算ルーチンを並列に起動したり、
或いはGUI無しでコマンドラインから起動することも普通に可能となる。
(つまりプログラムとしての汎用性/柔軟性が上がっている)
「クラスのコピー」ってのはディープコピーだが、単純に値が入っているクラスなら、
Cなら構造体の代入、つまり
SomeClass myCopy = reference;
の1行で事足りる。或いは通常、関数呼び出しには構造体への「ポインタ」を用いているはずだが、そこを構造体の「値」に変えればいいだけ。
C#だとstructは値型だったと思うので、設定値保管用『struct』なら自動的に上記が常に行われる構造になるが、
余程小さくない限りそれでは使いにくい筈なので、設定値保管用『クラス』で正しく、何らかの方策でディープコピーをした方がいい。
インミュータブルに組んでいればシャローコピーでも行けるようには出来るはずだが。
といっても分かりにくいだろうから具体的に指摘すると、
君の問題は、間違った方策で解決しようとして、余計におかしくなっていることだ。
> 他クラスで使用しているときに値を変更されないように2、3を実装したんですけど、単に画面を入力できないようにロックすればよかった。
これは「画面をロック」ではなく、演算開始時に「設定値保管クラスのコピーを演算ルーチンに渡す」とすべき。
これにより、一つの実行画面から多数の演算ルーチンを並列に起動したり、
或いはGUI無しでコマンドラインから起動することも普通に可能となる。
(つまりプログラムとしての汎用性/柔軟性が上がっている)
「クラスのコピー」ってのはディープコピーだが、単純に値が入っているクラスなら、
Cなら構造体の代入、つまり
SomeClass myCopy = reference;
の1行で事足りる。或いは通常、関数呼び出しには構造体への「ポインタ」を用いているはずだが、そこを構造体の「値」に変えればいいだけ。
C#だとstructは値型だったと思うので、設定値保管用『struct』なら自動的に上記が常に行われる構造になるが、
余程小さくない限りそれでは使いにくい筈なので、設定値保管用『クラス』で正しく、何らかの方策でディープコピーをした方がいい。
インミュータブルに組んでいればシャローコピーでも行けるようには出来るはずだが。
366デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/26(木) 14:38:18.82ID:2UlJm9YS0 >>361-363
つかこれ、どれくらい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周りがだいぶ違うって事か?
つかこれ、どれくらい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周りがだいぶ違うって事か?
367デフォルトの名無しさん (アウアウウー Sab5-655U)
2019/12/26(木) 14:50:50.75ID:+pzqFzNua >>366
DC(Graphics)は不要になった時点でDisposeした方がいいと思うけど、
PebとかBrushとかFontとか、このあたりがIDisposable実装してるのは
たぶんWin9xを想定してるんだろうねw
.NET 1.1とかの時代に、Win2kやXPではそこまで神経質にならなくていいよ、
って記事を結構読んだ記憶がある
DC(Graphics)は不要になった時点でDisposeした方がいいと思うけど、
PebとかBrushとかFontとか、このあたりがIDisposable実装してるのは
たぶんWin9xを想定してるんだろうねw
.NET 1.1とかの時代に、Win2kやXPではそこまで神経質にならなくていいよ、
って記事を結構読んだ記憶がある
368デフォルトの名無しさん (ワッチョイ ef4f-K0SF)
2019/12/26(木) 14:53:40.92ID:g3TV29VW0 多いから糞って単純な話でもないだろ。表示しているオブジェクトが多いなら仕方がない。
explorerもウィンドウを大量に開くとモリモリ消費する。
explorerもウィンドウを大量に開くとモリモリ消費する。
369デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/26(木) 15:25:02.44ID:2UlJm9YS0 >>368
いやJaneはガチでリークしてると思うぜ。
俺のPC内での今の順位
1. Jane2ch 8,677 ←増えてやがるし
2. explorer 1,340
3. chrome 826
以下chromeが20個ほど続く。
字しか表示しねえJaneでどうやって8,677個になるんだよ?
フォントや色でも精々100だろ。
そもそも複数ページ表示してるchrome越えてる時点でだいぶおかしい。
いやJaneはガチでリークしてると思うぜ。
俺のPC内での今の順位
1. Jane2ch 8,677 ←増えてやがるし
2. explorer 1,340
3. chrome 826
以下chromeが20個ほど続く。
字しか表示しねえJaneでどうやって8,677個になるんだよ?
フォントや色でも精々100だろ。
そもそも複数ページ表示してるchrome越えてる時点でだいぶおかしい。
370デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/26(木) 15:25:33.99ID:2UlJm9YS0 >>367
そのわりにusingガーというのが多いのはなんでだ?
若干Java的オブジェクト指向(オブジェクト指向が唯一絶対神であり、それ以外は認めない)に近い偏見を感じる。
GCなんて手抜きの為の機構であり、逆に言えば、GC使っている以上、書かなくて済む事は書かない、というのが正しいだろ。
全部書け、ならC++を使って全部書き、GCなんて使っている軟派野郎は死ね、とあるべき。
C#でusingって、なんか違うくね?
まあ現実的にヒットするなら致し方ないとして、俺が試した限りでは、どうにもヒットしないように見える。
それとも
> DC(Graphics)は
これはdevice context だけは即時解放した方がいい、ということか?
具体的にはGetHdcメソッドを有する連中だが、見た目Graphicsだけかな。
だとすると俺がやってるBrushでは再現しないのも納得だが、
かといってGraphicsを10,000取得とかいう使い方もないとも思うが。
そのわりにusingガーというのが多いのはなんでだ?
若干Java的オブジェクト指向(オブジェクト指向が唯一絶対神であり、それ以外は認めない)に近い偏見を感じる。
GCなんて手抜きの為の機構であり、逆に言えば、GC使っている以上、書かなくて済む事は書かない、というのが正しいだろ。
全部書け、ならC++を使って全部書き、GCなんて使っている軟派野郎は死ね、とあるべき。
C#でusingって、なんか違うくね?
まあ現実的にヒットするなら致し方ないとして、俺が試した限りでは、どうにもヒットしないように見える。
それとも
> DC(Graphics)は
これはdevice context だけは即時解放した方がいい、ということか?
具体的にはGetHdcメソッドを有する連中だが、見た目Graphicsだけかな。
だとすると俺がやってるBrushでは再現しないのも納得だが、
かといってGraphicsを10,000取得とかいう使い方もないとも思うが。
371デフォルトの名無しさん (ササクッテロル Sp88-9la5)
2019/12/26(木) 15:49:32.19ID:8rtfbEtYp 何をグダグタと気にしてるのかよーわからんな
どうせそのうち回収されるんだから無駄に残ってるのが気にならねえならどうでもいいだろ
精々Janeみたいに過剰に確保されてるのを観測されてクソクソ言われるのが自分のアプリになるだけだ
どうせそのうち回収されるんだから無駄に残ってるのが気にならねえならどうでもいいだろ
精々Janeみたいに過剰に確保されてるのを観測されてクソクソ言われるのが自分のアプリになるだけだ
372デフォルトの名無しさん (ドコグロ MM40-NvuD)
2019/12/26(木) 16:01:00.94ID:Wx+k6OqqM つか本来は実際に画面に表示されてる間だけアンマネージリソースを確保すればいいわけで、設計が手抜きなんだよ
まあ、そういう思想でスマートなリソース管理をしてるWPFはゴミのように遅いわけだがw
まあ、そういう思想でスマートなリソース管理をしてるWPFはゴミのように遅いわけだがw
373デフォルトの名無しさん (アウアウウー Sab5-655U)
2019/12/26(木) 16:08:06.67ID:+pzqFzNua >>370
なんかちょっと被害妄想激しいよw
IDisposableを実装してたら絶対Disposeすべき、という教条主義を展開してる記事って
あんまり読んだ記憶ないけど、まあusingブロックは十分コンパクトに書けてかつ便利なので、
Disposeしなくてもいい、という確信が持てないなら素直にDisposeするのが普通に安全牌だよね。
※ 個別にDisposeを呼ぶんじゃなくてusingを使え、という趣旨の記事ならいくつか読んだことある
なんかちょっと被害妄想激しいよw
IDisposableを実装してたら絶対Disposeすべき、という教条主義を展開してる記事って
あんまり読んだ記憶ないけど、まあusingブロックは十分コンパクトに書けてかつ便利なので、
Disposeしなくてもいい、という確信が持てないなら素直にDisposeするのが普通に安全牌だよね。
※ 個別にDisposeを呼ぶんじゃなくてusingを使え、という趣旨の記事ならいくつか読んだことある
374デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/26(木) 16:15:52.27ID:2UlJm9YS0 >>371
俺自身は「usingを使うべき」とされる解説ページでお約束的に出される
・そこで例外が発生してdisposeされずに抜けてしまった場合、リークする
が間違い(というか誇大)だと見ているのだが、これが間違ってるかどうかをここで尋ねている。
俺の認識に間違いがないとすると、
俺が試した限りではヒットすることが難しいのに、何故ここまでusingにこだわるのか?というのが疑問になる。
勿論こだわるのもありだが、C#ってそういう言語でもないし。
なお俺のはdisposeしてなくて50-70だぞ。
そこで上記の通り、Brushを40k個作ってもだ。
(もっとも、多すぎてGCが常に速攻行われているだけかもしれないが)
JaneStyleは調べたところOpenJaneからの派生で、OpenJaneはDelphiで、これはGC無しらしい。
つまりモロにリークしてるだけだよ。
俺自身は「usingを使うべき」とされる解説ページでお約束的に出される
・そこで例外が発生してdisposeされずに抜けてしまった場合、リークする
が間違い(というか誇大)だと見ているのだが、これが間違ってるかどうかをここで尋ねている。
俺の認識に間違いがないとすると、
俺が試した限りではヒットすることが難しいのに、何故ここまでusingにこだわるのか?というのが疑問になる。
勿論こだわるのもありだが、C#ってそういう言語でもないし。
なお俺のはdisposeしてなくて50-70だぞ。
そこで上記の通り、Brushを40k個作ってもだ。
(もっとも、多すぎてGCが常に速攻行われているだけかもしれないが)
JaneStyleは調べたところOpenJaneからの派生で、OpenJaneはDelphiで、これはGC無しらしい。
つまりモロにリークしてるだけだよ。
375デフォルトの名無しさん (ワッチョイ f12d-vQnI)
2019/12/26(木) 16:30:20.52ID:bzjIw0U90 尋ねてるって言うけど、君の求めてる通りの回答以外は認めないんでしょ
聞くだけ無駄じゃん
聞くだけ無駄じゃん
376デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/26(木) 16:40:38.25ID:2UlJm9YS0 >>373
> Disposeしなくてもいい、という確信が持てないなら素直にDisposeするのが普通に安全牌だよね。
つまりこれ。
実はDisposeしなくていいんじゃねえの?というのが俺の疑問。
ヒットしている人がいるから何か要件はあるのだろうけど、俺が試してる限りではヒットさせようがないように見える。
とはいえ、ヒットする可能性がある限り、解説ページ等では「Disposeしなくていい」とは書けない。
だけどほぼ必要がないことはMSも認めてるからサンプルページではusingなんて使っておらず、
usingについてのリンクすらない、というように見える。
(つまりサンプルページを確認しているレベルの奴がヒットさせようがなく、
余計な混乱を防ぐ為にも書かない方がいい、とMSが判断してる。
まあ>>361-363はモロにそう言ってるわけだが)
ただこの状況でも、自分だけが使うならともかく、他人も使うとなると、
using使わないわけには行かない、というのは認める。
だからなんだかなあ、みたいな感じになってる。
結局のところ、これは俺の環境のみならず、
.NETが動くありとあらゆる環境に於いて問題なく動くプログラムを作る為の作法であって、
MSがusing使えと言う以上、書くしかない、ということか。
それが俺のPCでは再現不能だとしても、それはたまたまでしかない、ということであって。
> Disposeしなくてもいい、という確信が持てないなら素直にDisposeするのが普通に安全牌だよね。
つまりこれ。
実はDisposeしなくていいんじゃねえの?というのが俺の疑問。
ヒットしている人がいるから何か要件はあるのだろうけど、俺が試してる限りではヒットさせようがないように見える。
とはいえ、ヒットする可能性がある限り、解説ページ等では「Disposeしなくていい」とは書けない。
だけどほぼ必要がないことはMSも認めてるからサンプルページではusingなんて使っておらず、
usingについてのリンクすらない、というように見える。
(つまりサンプルページを確認しているレベルの奴がヒットさせようがなく、
余計な混乱を防ぐ為にも書かない方がいい、とMSが判断してる。
まあ>>361-363はモロにそう言ってるわけだが)
ただこの状況でも、自分だけが使うならともかく、他人も使うとなると、
using使わないわけには行かない、というのは認める。
だからなんだかなあ、みたいな感じになってる。
結局のところ、これは俺の環境のみならず、
.NETが動くありとあらゆる環境に於いて問題なく動くプログラムを作る為の作法であって、
MSがusing使えと言う以上、書くしかない、ということか。
それが俺のPCでは再現不能だとしても、それはたまたまでしかない、ということであって。
377デフォルトの名無しさん (ガックシ 0634-K0SF)
2019/12/26(木) 16:47:16.53ID:BHrZHcGr6 c#のListをイテレーションするサンプルをウェブで探していたんだけど、インデックスでアクセスして回しているコードがよく見つかるんだけど、
Listのデータ構造はリストではないの?
Listのデータ構造はリストではないの?
378デフォルトの名無しさん (アウアウウー Sab5-655U)
2019/12/26(木) 16:48:04.03ID:+pzqFzNua >>376
上に書いたWin9x環境を特に想定した実装、というようなケースを除けば
そのクラスを作ったプログラマは「不要になったらDisposeを呼んで欲しい」と思っているから
IDisposableを実装している。
だからDisposeしなくてもいい、という確信が持てないなら(以下略
上に書いたWin9x環境を特に想定した実装、というようなケースを除けば
そのクラスを作ったプログラマは「不要になったらDisposeを呼んで欲しい」と思っているから
IDisposableを実装している。
だからDisposeしなくてもいい、という確信が持てないなら(以下略
379デフォルトの名無しさん (ワッチョイ dc2c-++NQ)
2019/12/26(木) 16:55:18.99ID:WMR2NHe80380デフォルトの名無しさん (ワッチョイ 6c88-hRE6)
2019/12/26(木) 16:59:42.72ID:F8ujXl8x0 GC任せではなく明示的にメモリを開放していかきゃ動作に支障をきたすような少メモリな環境だって世の中にはある
381デフォルトの名無しさん (ドコグロ MM40-NvuD)
2019/12/26(木) 17:03:28.05ID:Wx+k6OqqM382デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/26(木) 17:07:04.85ID:2UlJm9YS0 >>378
なるほど確かにその通りだ。
設計者が想定したとおりに使うのが安牌であり、
書いておけば済む物を、特段メリットもないのに書かずに済ませて後で嵌るのは生産性が悪い、というのはC#的には当たりだ。
呼ぶか呼ばないかは使用者が判断するものではなく、設計者がIDisposableを実装するかどうかで示し、それに従え、ということか。
まあ長期的に見てその思想が正しいんだろう。
なるほど納得した。
なるほど確かにその通りだ。
設計者が想定したとおりに使うのが安牌であり、
書いておけば済む物を、特段メリットもないのに書かずに済ませて後で嵌るのは生産性が悪い、というのはC#的には当たりだ。
呼ぶか呼ばないかは使用者が判断するものではなく、設計者がIDisposableを実装するかどうかで示し、それに従え、ということか。
まあ長期的に見てその思想が正しいんだろう。
なるほど納得した。
383デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/26(木) 17:10:19.42ID:2UlJm9YS0384デフォルトの名無しさん (ワッチョイ 1e6f-RbSw)
2019/12/26(木) 18:35:58.39ID:EoULV8Z50 disposeされなくてもデストラクタで解放されるが、
かなり高コストな処理が発生するそうな
https://ufcpp.net/study/csharp/rm_disposable.html#idisposable
かなり高コストな処理が発生するそうな
https://ufcpp.net/study/csharp/rm_disposable.html#idisposable
385デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/26(木) 19:21:56.18ID:2UlJm9YS0 >>384
それは嘘。というか誇大広告。
オブジェクトの寿命が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+オブジェクトに関してはこの方向でもコーディングは可能のように思える。
それは嘘。というか誇大広告。
オブジェクトの寿命が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+オブジェクトに関してはこの方向でもコーディングは可能のように思える。
386デフォルトの名無しさん (ワッチョイ 6e0c-K0SF)
2019/12/26(木) 21:56:25.88ID:Ag2MBuDI0 >>385
> オブジェクトの寿命が1GC分伸びるだけ。それが深刻になる状況
じゅうぶん現実的な状況でなり得るよ。Gen1以上のGCを舐めてる
それが許容できるかは要件次第
ゲームプログラミングでなくとも極力排除すべき要素
そういえば「ガクガクするから結局Dispose呼び出した」とか自分で言ってたね
なんでガクガクしたの?
> 型によっては using var でしか宣言出来ない(=静的に確保出来ない=ローカルでしか持てない)ようにすれば、
論外。ネイティブリソースを持った時点でスタックにしか確保できない型しか作れない言語の出来上がり
ファイナライザを作らずDisposeを強制するというのはそういこと
大した問題じゃないから、ではなく潜在的に負荷を抱える可能性の排除とリソースリークへのセイフティを天秤にかけた結果だよ
> VC++/CLIのpin_ptr
それC#で言うunsafeなfixed相当。関係無い
> オブジェクトの寿命が1GC分伸びるだけ。それが深刻になる状況
じゅうぶん現実的な状況でなり得るよ。Gen1以上のGCを舐めてる
それが許容できるかは要件次第
ゲームプログラミングでなくとも極力排除すべき要素
そういえば「ガクガクするから結局Dispose呼び出した」とか自分で言ってたね
なんでガクガクしたの?
> 型によっては using var でしか宣言出来ない(=静的に確保出来ない=ローカルでしか持てない)ようにすれば、
論外。ネイティブリソースを持った時点でスタックにしか確保できない型しか作れない言語の出来上がり
ファイナライザを作らずDisposeを強制するというのはそういこと
大した問題じゃないから、ではなく潜在的に負荷を抱える可能性の排除とリソースリークへのセイフティを天秤にかけた結果だよ
> VC++/CLIのpin_ptr
それC#で言うunsafeなfixed相当。関係無い
387デフォルトの名無しさん (ワッチョイ 8b63-b920)
2019/12/26(木) 22:28:04.26ID:9AkEaWNs0 Disposeしないで挙動を調べた結果、問題ないんだったらそのリソースに関してはDisposeしなくていいってことがわかるだけじゃない?
それを一般化してusingなんか使う必要がないのだ/Disposeはファイナライズのときにされるので十分なのだってのはおかしいような。
一々いろんなIDisposableのオブジェクトの挙動を調べてたら検証時間がかかってしょうがないし、
今調べた挙動が将来的にずっと同じである保証もないから、Disposeしてね、と言われているものに関しては、
Disposeされるものだと思って設計変更される可能性がある、と考えて、
問題のないタイミングで行儀よくDisposeしてトラブルの種を潰すってだけの話だと思うんだけど
逆に、使い尽くしてDisposeしなくていいってわかってるんだったら
(例えば自作クラスで、なんかのハンドルを握ったままになったりしないという保証があるなら)
どうぞご自由に、って思うけどね
「自転車ってうちの近くの舗装の綺麗で平坦な道路では手放し運転できるのに、なんでハンドルなんかついてるんだ?いらなくね?」って言ってるようなものだと思うけどね。
それを一般化してusingなんか使う必要がないのだ/Disposeはファイナライズのときにされるので十分なのだってのはおかしいような。
一々いろんなIDisposableのオブジェクトの挙動を調べてたら検証時間がかかってしょうがないし、
今調べた挙動が将来的にずっと同じである保証もないから、Disposeしてね、と言われているものに関しては、
Disposeされるものだと思って設計変更される可能性がある、と考えて、
問題のないタイミングで行儀よくDisposeしてトラブルの種を潰すってだけの話だと思うんだけど
逆に、使い尽くしてDisposeしなくていいってわかってるんだったら
(例えば自作クラスで、なんかのハンドルを握ったままになったりしないという保証があるなら)
どうぞご自由に、って思うけどね
「自転車ってうちの近くの舗装の綺麗で平坦な道路では手放し運転できるのに、なんでハンドルなんかついてるんだ?いらなくね?」って言ってるようなものだと思うけどね。
388デフォルトの名無しさん (ワッチョイ 8401-K0SF)
2019/12/26(木) 23:04:21.26ID:qz8G02Zg0 なるほど!と読んでたら最後の例えでよくわからんようになった…
389デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/26(木) 23:08:24.18ID:2UlJm9YS0 >>386
いや多分、みんな求め過ぎなんだよ。
C++erが特にそうだが、C++を何でも出来る言語にしようとしてる。
それと同じく、君もまた、C#を万能言語にしようとしてないか?
つまり、簡単に書け、かつ、最速な言語に、ということだ。
> それが許容できるかは要件次第
俺に言わせれば、ゲームプログラミング等のパフォーマンスクリティカルな状況でC#を使う選択自体が間違ってる。
実際、ゲームは今でもC++が主流で、それはパフォーマンスの問題からだろ。
そういえばUnityはC#だが、(俺はゲーマーでないから詳しくないが)
あれは紙芝居ゲーとかそういう全くパフォーマンスとかどうでもいい系向けではないのか?
グラゴリゴリのゲームをC#で書いて、C++に勝てるとでも思っているのか?
> なんでガクガクしたの?
知らん。ただ、Disposeしてなかったから試しにしてみたらとりあえず直った。
だからGCなのだろうとは思うが、それ以上は確認してない。
ただ、2-3画面毎だったから、Brushで言うと100k毎くらいだ。
いや多分、みんな求め過ぎなんだよ。
C++erが特にそうだが、C++を何でも出来る言語にしようとしてる。
それと同じく、君もまた、C#を万能言語にしようとしてないか?
つまり、簡単に書け、かつ、最速な言語に、ということだ。
> それが許容できるかは要件次第
俺に言わせれば、ゲームプログラミング等のパフォーマンスクリティカルな状況でC#を使う選択自体が間違ってる。
実際、ゲームは今でもC++が主流で、それはパフォーマンスの問題からだろ。
そういえばUnityはC#だが、(俺はゲーマーでないから詳しくないが)
あれは紙芝居ゲーとかそういう全くパフォーマンスとかどうでもいい系向けではないのか?
グラゴリゴリのゲームをC#で書いて、C++に勝てるとでも思っているのか?
> なんでガクガクしたの?
知らん。ただ、Disposeしてなかったから試しにしてみたらとりあえず直った。
だからGCなのだろうとは思うが、それ以上は確認してない。
ただ、2-3画面毎だったから、Brushで言うと100k毎くらいだ。
390デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/26(木) 23:09:24.48ID:2UlJm9YS0 > 論外
いやお前の不勉強具合が論外だよ。少なくとも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の取っつきにくさはここにあって、
要するに既存言語のノリでやったら全然コンパイルが通らないらしい。(俺はやってなから知らんが)
ただし、スタックアロケーションの方が効率も管理も楽なので、スタックアロケーション出来るものはスタックに、という理屈は合ってる。
問題はそれだと柔軟性、つまりデタラメなコーディングが出来なくなる点で、
いやお前の不勉強具合が論外だよ。少なくとも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の取っつきにくさはここにあって、
要するに既存言語のノリでやったら全然コンパイルが通らないらしい。(俺はやってなから知らんが)
ただし、スタックアロケーションの方が効率も管理も楽なので、スタックアロケーション出来るものはスタックに、という理屈は合ってる。
問題はそれだと柔軟性、つまりデタラメなコーディングが出来なくなる点で、
391デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/26(木) 23:10:55.58ID:2UlJm9YS0 > 天秤にかけた結果だよ
というのはその通りで、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出してくる、というのが理想だと思うが。
というのはその通りで、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出してくる、というのが理想だと思うが。
392デフォルトの名無しさん (ワッチョイ 4d63-hRE6)
2019/12/26(木) 23:23:27.97ID:aYxazJyl0 unityでも3Dゴリゴリのゲームは作るよ
というかスマホで3Dゲームの高クオリティ開発ならunity
1択なくらい。unrealはまだスマホ市場少ない
unityはスマホが多いがコンシューマもPCもそれなりにある
ゲーム以外のARVR分野もかなりunityは多い
言語パフォーマンスより開発パフォーマンスが優先された結果だと思う
だからといって処理速度をないがしろにできるわけじゃない
というかスマホで3Dゲームの高クオリティ開発ならunity
1択なくらい。unrealはまだスマホ市場少ない
unityはスマホが多いがコンシューマもPCもそれなりにある
ゲーム以外のARVR分野もかなりunityは多い
言語パフォーマンスより開発パフォーマンスが優先された結果だと思う
だからといって処理速度をないがしろにできるわけじゃない
393デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/26(木) 23:25:15.01ID:2UlJm9YS0 >>387
いや長期的に見た生産性の為にusingを書いてトラブルの種を潰しておく、というのは納得した。
俺がいくら試しても、俺環境で俺の使い方での結果でしかないから、公式に従った方が得策だ。
ただし言語としてそれが最高か、と言われれば、俺はusingなんて書かなくてもなんとかしとけ、という思想。
つまり、
C#: using書け、ただし、書き忘れても大体何とかなるようには作ってある
Rust: そもそも変数はスタック上にしかアロケートしないので、usingとか原理的に不要
俺: 勝手にコンパイラが色々チェックして、可能なところは自動的にやって、駄目なところだけwarning出してこい
ということ。ただしこれは理想論であって、現実はそうではないのはもう認めてる。
ただそれにしても、「GDI+オブジェクトがスタック上にしか確保出来ない」がそんなに糞だとは思わない。
実際、俺はこれでほぼ組んでいるはずだし。
いや長期的に見た生産性の為にusingを書いてトラブルの種を潰しておく、というのは納得した。
俺がいくら試しても、俺環境で俺の使い方での結果でしかないから、公式に従った方が得策だ。
ただし言語としてそれが最高か、と言われれば、俺はusingなんて書かなくてもなんとかしとけ、という思想。
つまり、
C#: using書け、ただし、書き忘れても大体何とかなるようには作ってある
Rust: そもそも変数はスタック上にしかアロケートしないので、usingとか原理的に不要
俺: 勝手にコンパイラが色々チェックして、可能なところは自動的にやって、駄目なところだけwarning出してこい
ということ。ただしこれは理想論であって、現実はそうではないのはもう認めてる。
ただそれにしても、「GDI+オブジェクトがスタック上にしか確保出来ない」がそんなに糞だとは思わない。
実際、俺はこれでほぼ組んでいるはずだし。
394デフォルトの名無しさん (アウアウウー Sa83-NvuD)
2019/12/26(木) 23:41:44.91ID:V9vPePAWa Rustは普通にヒープ使うぞ?
なんか勘違いしてるようだが、そもそもスタックだけで用が足りるんなら所有権だの何だのとRustの高度なリソース管理は要らん
C++のRAIIや、それこそC#で変数をデフォルトでusingにした程度で十分だ
なんか勘違いしてるようだが、そもそもスタックだけで用が足りるんなら所有権だの何だのとRustの高度なリソース管理は要らん
C++のRAIIや、それこそC#で変数をデフォルトでusingにした程度で十分だ
395デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/26(木) 23:42:14.94ID:2UlJm9YS0 >>392
> 言語パフォーマンスより開発パフォーマンスが優先された結果だと思う
> だからといって処理速度をないがしろにできるわけじゃない
C#の開発パフォーマンスがいいのは認める。
とはいえ、原理的な速度というのはあって、
正直、C++erの「GC使わないけどスマポ使え」ってのはロジック的に間抜け(矛盾してる)と思うが、
Rustの「全部スタック動作と連動」というのは原理的に正しく、逆に言えば、この方法でないとCを越えられない。
だから、根幹の思想は何だかんだで重要で、GDI+に関してはusngではなく「スタック縛り」の方が妥当だったように思う。
ファイルリソースは永続化出来ないとイテレータが使えないのでusingじゃないと無理っぽいが、
GDI+リソースは特に永続化する必然性が無く、大量に生成し、破棄するものだからだ。
パフォーマンス上は断然「スタック縛り」が有利で、
それでコードが書けなくなる/書きづらくなる、ってこともないと思うのだが。
と言ってもMSも気づいているだろうし、当然考えてもいるだろうし、
Rustにも手を出してはいるから必要なら出してくるんだろうけど。
> 言語パフォーマンスより開発パフォーマンスが優先された結果だと思う
> だからといって処理速度をないがしろにできるわけじゃない
C#の開発パフォーマンスがいいのは認める。
とはいえ、原理的な速度というのはあって、
正直、C++erの「GC使わないけどスマポ使え」ってのはロジック的に間抜け(矛盾してる)と思うが、
Rustの「全部スタック動作と連動」というのは原理的に正しく、逆に言えば、この方法でないとCを越えられない。
だから、根幹の思想は何だかんだで重要で、GDI+に関してはusngではなく「スタック縛り」の方が妥当だったように思う。
ファイルリソースは永続化出来ないとイテレータが使えないのでusingじゃないと無理っぽいが、
GDI+リソースは特に永続化する必然性が無く、大量に生成し、破棄するものだからだ。
パフォーマンス上は断然「スタック縛り」が有利で、
それでコードが書けなくなる/書きづらくなる、ってこともないと思うのだが。
と言ってもMSも気づいているだろうし、当然考えてもいるだろうし、
Rustにも手を出してはいるから必要なら出してくるんだろうけど。
396デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/26(木) 23:44:51.57ID:2UlJm9YS0 >>394
他言語の「ヒープ」と同等の動作では全くない、ということ。
他言語の「ヒープ」と同等の動作では全くない、ということ。
397デフォルトの名無しさん (アウアウウー Sa83-BCWm)
2019/12/27(金) 01:44:02.82ID:FV6GRoMta398デフォルトの名無しさん (ワッチョイ 4697-Wq+o)
2019/12/27(金) 09:28:31.67ID:9LlS+1cS0 >>393
呼び出しの静的解析だけで、コンパイラ側が自動でusing付けるとか、現状の言語仕様でいけるもんなのかなあ。
行けそうなケースがあるのはわかるけど、すべてのケースで問題なく動作するというエビデンスはなんかある?
あと、俺に言わせりゃ静的解析で出来るだろとのことだけど、設計実装難易度も十分に低いと見積もってて、なんでやらないんだ、と言いたい、ってことなの?個人的には難易度は未知数だと思うんだけどなあ。
呼び出しの静的解析だけで、コンパイラ側が自動でusing付けるとか、現状の言語仕様でいけるもんなのかなあ。
行けそうなケースがあるのはわかるけど、すべてのケースで問題なく動作するというエビデンスはなんかある?
あと、俺に言わせりゃ静的解析で出来るだろとのことだけど、設計実装難易度も十分に低いと見積もってて、なんでやらないんだ、と言いたい、ってことなの?個人的には難易度は未知数だと思うんだけどなあ。
399デフォルトの名無しさん (ワッチョイ ef4f-K0SF)
2019/12/27(金) 10:30:46.74ID:jG1yqawr0 >>398
参照がスコープ外に持ち出されていないかどうかを判断する必要があるだろうけど、それには
rustのように関数呼び出しに情報を受け渡す拡張が必要になるだろうね。
どうせ文法を拡張するなら、C++/CLIのようにusingより簡単な記述でDispose()の必要性を
判断できるようにする方が現実的かも。
参照がスコープ外に持ち出されていないかどうかを判断する必要があるだろうけど、それには
rustのように関数呼び出しに情報を受け渡す拡張が必要になるだろうね。
どうせ文法を拡張するなら、C++/CLIのようにusingより簡単な記述でDispose()の必要性を
判断できるようにする方が現実的かも。
400デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/27(金) 11:10:40.91ID:AkdF/Ds50 >>398
> 設計実装難易度も十分に低いと見積もってて、なんでやらないんだ、と言いたい、ってことなの?
いや違う。ぶっちゃけ、信者的態度で言われたから言い返してるだけだな。
現実問題として、Rust公式でも述べているとおり、ヒープ+GCの使い勝手は素晴らしく良く、
「コードの書きやすさ」という意味においては現状最高だろう。
だからC#がこれを採用しているのも理に適ってる。
ただし問題は、それを信者的に素晴らしいと君らが捕らえている点で、
これはC#が魔法を使ったわけでもなんでもなく、
単純に、速度を捨てて書きやすさを取っているだけだと正しく認識しろと言っている。
だからパフォーマンスクリティカルだと分かっている状況でC#を使うのが間違いだし、
それはファイナライザが実装されているからGCが1世代分伸びるのも問題だ、というときも該当する。
そこまでのパフォーマンスを求めるときに使う言語ではないし、出来る言語でもない。これは今後共だ。
解決策は既に述べたとおりだが、ここに関してはMSが「間違えた」というのは厳しいが、でも、間違いだとは思う。
usingは「書く」前提ではC#8.0で完成しているが、
問題は、「それが書かなければならない型だ」とユーザーが認識しなければならない点で、
そもそも知らなければ抜けるし、そのためのファイナライザでシステム的に遅いGCになる事を許容しなければならない。
(というほど俺は遅くはならないと思うが、お前らはファイナライザが問題だと言うので)
なら、最初から「スタック縛り」にしてしまえば、SyntaxErrorで落とせるし、GC機構そのものが不要になる。
このときの問題点は多少コーディングの自由が奪われることだが、現実として、
PenやBrushをクラスメンバとして永続させる必要なんて無いし、
GraphicsやFontも生成元『マネージド』情報(既に述べたがControl等)を代わりに持つことによって回避出来る。
結果、馬鹿みたいに「GDI+オブジェクトはその都度生成して、その都度廃棄」なコードになってしまうが、
SyntaxErrorにならなければリソースリークは原理的になくなり、
GCも簡素化/高速化し、using周りの仕様も覚える必要がない、ということになる。
> 設計実装難易度も十分に低いと見積もってて、なんでやらないんだ、と言いたい、ってことなの?
いや違う。ぶっちゃけ、信者的態度で言われたから言い返してるだけだな。
現実問題として、Rust公式でも述べているとおり、ヒープ+GCの使い勝手は素晴らしく良く、
「コードの書きやすさ」という意味においては現状最高だろう。
だからC#がこれを採用しているのも理に適ってる。
ただし問題は、それを信者的に素晴らしいと君らが捕らえている点で、
これはC#が魔法を使ったわけでもなんでもなく、
単純に、速度を捨てて書きやすさを取っているだけだと正しく認識しろと言っている。
だからパフォーマンスクリティカルだと分かっている状況でC#を使うのが間違いだし、
それはファイナライザが実装されているからGCが1世代分伸びるのも問題だ、というときも該当する。
そこまでのパフォーマンスを求めるときに使う言語ではないし、出来る言語でもない。これは今後共だ。
解決策は既に述べたとおりだが、ここに関してはMSが「間違えた」というのは厳しいが、でも、間違いだとは思う。
usingは「書く」前提ではC#8.0で完成しているが、
問題は、「それが書かなければならない型だ」とユーザーが認識しなければならない点で、
そもそも知らなければ抜けるし、そのためのファイナライザでシステム的に遅いGCになる事を許容しなければならない。
(というほど俺は遅くはならないと思うが、お前らはファイナライザが問題だと言うので)
なら、最初から「スタック縛り」にしてしまえば、SyntaxErrorで落とせるし、GC機構そのものが不要になる。
このときの問題点は多少コーディングの自由が奪われることだが、現実として、
PenやBrushをクラスメンバとして永続させる必要なんて無いし、
GraphicsやFontも生成元『マネージド』情報(既に述べたがControl等)を代わりに持つことによって回避出来る。
結果、馬鹿みたいに「GDI+オブジェクトはその都度生成して、その都度廃棄」なコードになってしまうが、
SyntaxErrorにならなければリソースリークは原理的になくなり、
GCも簡素化/高速化し、using周りの仕様も覚える必要がない、ということになる。
401デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/27(金) 11:11:26.51ID:AkdF/Ds50 俺が思うC#の利点は、「無駄に覚えなければならない仕様」がほぼ無いことであり、
これは、C++が何でも出来る言語にしようとしている反面、
ほぼ使いもしない仕様を覚える必要がありすぎる状況になっているのと対極的ではある。
ただ、俺に言わせれば、usingも覚えるべき仕様ではない。
「GDI+リソースを持つクラスはスタック上にしか置けません」の仕様だと、何も覚えなくて済み、リーク周りの問題もない。
ただこれは完全に後出しで、MSが間違いを犯したわけではない。
彼等は単純に現状の仕様に乗るようにしてきただけであり、
未来の改訂で「スタック縛り&using廃止」になるのも十分ありうるし、俺はそれを望む。
ただMSはおそらくパフォーマンスよりも書きやすさに振ると思うので、微妙だとは思うが。
> 呼び出しの静的解析だけで、コンパイラ側が自動でusing付けるとか、現状の言語仕様でいけるもんなのかなあ。
要は
Brush xxxxx;
{
// ここで永続化されなければよい
}
なので、中身を辿りきれるかどうかに尽きる。
具体的には、ヒープ上のオブジェクトに保持されているとかが無ければいい。(といってもC#は全部ヒープだが)
解析に問題になるのは関数ポインタを動的に使われるケース(テーブルジャンプ等)だが、
そういうのはほぼやらないから現実的には大半の場合は解析可能だと思う。
> 行けそうなケースがあるのはわかるけど、すべてのケースで問題なく動作するというエビデンスはなんかある?
こんな物はそもそも必要ない。
解析可能なら自動でusing付けろ、解析無理(かつユーザーがusing付けてない)ならwarning出せ、のベストエフォートでいい。
現実的にこれで問題ない。
というかJavaScriptのJITが既にこれに近いことをやっていたはずで、
要は「この関数を抜けたら破棄されると静的に解析済みの変数は最初からスタックに配置する」で、
解析無理なら従来通りヒープに置いてGC、可能な物は纏めてスタックに置いてGC回避で高速化、みたいなことになってたはず。
だから.NETもそれをやればいいだけ。
これは、C++が何でも出来る言語にしようとしている反面、
ほぼ使いもしない仕様を覚える必要がありすぎる状況になっているのと対極的ではある。
ただ、俺に言わせれば、usingも覚えるべき仕様ではない。
「GDI+リソースを持つクラスはスタック上にしか置けません」の仕様だと、何も覚えなくて済み、リーク周りの問題もない。
ただこれは完全に後出しで、MSが間違いを犯したわけではない。
彼等は単純に現状の仕様に乗るようにしてきただけであり、
未来の改訂で「スタック縛り&using廃止」になるのも十分ありうるし、俺はそれを望む。
ただMSはおそらくパフォーマンスよりも書きやすさに振ると思うので、微妙だとは思うが。
> 呼び出しの静的解析だけで、コンパイラ側が自動でusing付けるとか、現状の言語仕様でいけるもんなのかなあ。
要は
Brush xxxxx;
{
// ここで永続化されなければよい
}
なので、中身を辿りきれるかどうかに尽きる。
具体的には、ヒープ上のオブジェクトに保持されているとかが無ければいい。(といってもC#は全部ヒープだが)
解析に問題になるのは関数ポインタを動的に使われるケース(テーブルジャンプ等)だが、
そういうのはほぼやらないから現実的には大半の場合は解析可能だと思う。
> 行けそうなケースがあるのはわかるけど、すべてのケースで問題なく動作するというエビデンスはなんかある?
こんな物はそもそも必要ない。
解析可能なら自動でusing付けろ、解析無理(かつユーザーがusing付けてない)ならwarning出せ、のベストエフォートでいい。
現実的にこれで問題ない。
というかJavaScriptのJITが既にこれに近いことをやっていたはずで、
要は「この関数を抜けたら破棄されると静的に解析済みの変数は最初からスタックに配置する」で、
解析無理なら従来通りヒープに置いてGC、可能な物は纏めてスタックに置いてGC回避で高速化、みたいなことになってたはず。
だから.NETもそれをやればいいだけ。
402デフォルトの名無しさん (ドコグロ MM40-BCWm)
2019/12/27(金) 11:48:38.34ID:hRCuq6kQM 君が冒している最大の勘違いは、「C#開発者の皆が自分と同じくusingの不便を感じている」という前提を置いていることだ。
実際にはもうFormsの開発なんてC#ではマイナーな部類になりつつあり、
現在の主流であるWeb開発ではDisposeなんか滅多に使わない。
Webのパフォーマンス改善の観点で言えば、(君の愛する)スタックにしか置けない特殊な構造体の導入等により、
C#のGCに極力頼らない高度なメモリ管理は実は一部では既に実現されている。
usingはもはや滅多に使わない機能であり、それほど力を入れて改善されるべき対象ではないんだよ。
実際にはもうFormsの開発なんてC#ではマイナーな部類になりつつあり、
現在の主流であるWeb開発ではDisposeなんか滅多に使わない。
Webのパフォーマンス改善の観点で言えば、(君の愛する)スタックにしか置けない特殊な構造体の導入等により、
C#のGCに極力頼らない高度なメモリ管理は実は一部では既に実現されている。
usingはもはや滅多に使わない機能であり、それほど力を入れて改善されるべき対象ではないんだよ。
403デフォルトの名無しさん (ササクッテロル Sp88-9la5)
2019/12/27(金) 11:56:34.65ID:JsENnlV9p 信者的信者的ってなんのこと言ってんだコイツ?
ファイナライザ持ちがDispose呼ばないと昇格オブジェクトが増えてやばいって警告に
誇大広告だのほざいてるのは自分じゃねえか
自分のコードでDispose呼ばずにフルコレクトかましてガクガクさせながら「自分はそれほどでもないと思う」とかなんのギャグだよ
ファイナライザ持ちがDispose呼ばないと昇格オブジェクトが増えてやばいって警告に
誇大広告だのほざいてるのは自分じゃねえか
自分のコードでDispose呼ばずにフルコレクトかましてガクガクさせながら「自分はそれほどでもないと思う」とかなんのギャグだよ
404デフォルトの名無しさん (ワッチョイ 4697-Wq+o)
2019/12/27(金) 11:59:55.99ID:9LlS+1cS0 >>401
JITだからできることでコンパイラじゃできなくない?
何が気になるかって言うと、コールスタックの解析とかをコンパイル時点でやり始めるってのは停止性問題を取り扱うみたいなむりがあるんじゃないのかってこと。
ごく簡単な例だったら問題ないだろうけど、そのごく簡単な例ってわずかじゃないのかな。
JITだからできることでコンパイラじゃできなくない?
何が気になるかって言うと、コールスタックの解析とかをコンパイル時点でやり始めるってのは停止性問題を取り扱うみたいなむりがあるんじゃないのかってこと。
ごく簡単な例だったら問題ないだろうけど、そのごく簡単な例ってわずかじゃないのかな。
405デフォルトの名無しさん (ドコグロ MM40-BCWm)
2019/12/27(金) 12:08:44.93ID:hRCuq6kQM それをコンパイラ(というか型システム)でやろうとした結果がRustだね。
ちなみに彼は知らないようだが、Rustのメモリ管理がスマートであると言われる所以は、
エスケープしていないオブジェクトの生存管理などではなく(そんなものはC++でとっくの昔に実現されている)、
エスケープした「ヒープ上の」オブジェクトも正しく追跡して破棄できること。
それがプログラマにどれだけの負担を強いているかは>>390の通り。
ちなみに彼は知らないようだが、Rustのメモリ管理がスマートであると言われる所以は、
エスケープしていないオブジェクトの生存管理などではなく(そんなものはC++でとっくの昔に実現されている)、
エスケープした「ヒープ上の」オブジェクトも正しく追跡して破棄できること。
それがプログラマにどれだけの負担を強いているかは>>390の通り。
406デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/27(金) 12:34:15.59ID:AkdF/Ds50 >>402
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#はスクリプト言語レベルの手抜きを目指しているわけでもないから、割と妥当なラインなのかもしれんが。
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#はスクリプト言語レベルの手抜きを目指しているわけでもないから、割と妥当なラインなのかもしれんが。
407デフォルトの名無しさん (スププ Sd94-CmeR)
2019/12/27(金) 12:41:35.60ID:Xz3K8ooNd えらい散らかった論調だな。もう少し端的に話せんか?
408デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/27(金) 13:00:43.57ID:AkdF/Ds50 >>404
JITで出来ることとコンパイラで出来ることは違うが、今回に関しては同じだよ。
(関数単位でJITしてる限り同じ)
普通に考えれば分かると思うが、関数内の変数なんてその関数出たら破棄される物が大半で、
仮に内部でさらなる関数呼び出しに関連している物が全部追跡不可能だったとしても、十分効くんだよ。
完全にやり切ろうとするのはそりゃかなり無理だよ。でもそれは必要ないんだ。
JITで出来ることとコンパイラで出来ることは違うが、今回に関しては同じだよ。
(関数単位でJITしてる限り同じ)
普通に考えれば分かると思うが、関数内の変数なんてその関数出たら破棄される物が大半で、
仮に内部でさらなる関数呼び出しに関連している物が全部追跡不可能だったとしても、十分効くんだよ。
完全にやり切ろうとするのはそりゃかなり無理だよ。でもそれは必要ないんだ。
409デフォルトの名無しさん (アウアウウー Sab5-655U)
2019/12/27(金) 13:13:01.35ID:ra/PE2rBa 極論 vs. 極論でなんともw
410デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/27(金) 13:18:13.87ID:AkdF/Ds50 >>405
> ちなみに彼は知らないようだが
実際知らんからRustの話は君に任せる。
俺はRustはどういうコンセプトでどういう状況かを遠くから眺めているだけで、
「このコードが動かないんです!」みたいな悲鳴をチラ見してるだけだからな。
ただ、その中に「ヒープ上のオブジェクトすらも勝手に解放されるのかー!!!」みたいな話もあった気がするが。
スマポ限定なだけだというのなら、あれは関数呼び出しによる所有権移転で解放されただけの話か。
まあそうかもしれん。
いずれにしても俺はRustのコードは書いてないし、直近で書く予定もないので、Rustについては君に任せる。
> ちなみに彼は知らないようだが
実際知らんからRustの話は君に任せる。
俺はRustはどういうコンセプトでどういう状況かを遠くから眺めているだけで、
「このコードが動かないんです!」みたいな悲鳴をチラ見してるだけだからな。
ただ、その中に「ヒープ上のオブジェクトすらも勝手に解放されるのかー!!!」みたいな話もあった気がするが。
スマポ限定なだけだというのなら、あれは関数呼び出しによる所有権移転で解放されただけの話か。
まあそうかもしれん。
いずれにしても俺はRustのコードは書いてないし、直近で書く予定もないので、Rustについては君に任せる。
411デフォルトの名無しさん (アウアウウー Sab5-655U)
2019/12/27(金) 13:29:20.92ID:ra/PE2rBa どうせ過疎スレだし、BGMこれでガンガンやって欲しいw
https://youtu.be/BvmqYM1xpZA?t=28
https://youtu.be/BvmqYM1xpZA?t=28
412デフォルトの名無しさん (ワッチョイ f12d-vQnI)
2019/12/27(金) 16:53:56.60ID:SNZP60vo0 トヨタの車をブレーキを踏まずに運転できる人なら、usingはいらないよ
413デフォルトの名無しさん (ワッチョイ 3263-mlB/)
2019/12/27(金) 20:05:38.60ID:vYkXGtn00 うぜーから個人ブログでやれよ
414デフォルトの名無しさん (ワッチョイ 082c-avnG)
2019/12/27(金) 21:26:25.65ID:rZaePzzs0 正直半分ぐらいしかわからないけど、たまには盛り上がるのもいいよ
415デフォルトの名無しさん (ワッチョイ f12d-vQnI)
2019/12/27(金) 23:28:54.87ID:SNZP60vo0 2週間に1度ぐらいのペースで、わけのわからん話題で盛り上がってる気はする
416デフォルトの名無しさん (ワッチョイ 4c7b-Zxhf)
2019/12/27(金) 23:31:26.75ID:jbwOykBS0 ふらっとじゃなくこっちで暴れる分には好きにしたらいい
こっちでNGしとけばふらっとで見なくて済むし
こっちでNGしとけばふらっとで見なくて済むし
417デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/27(金) 23:40:23.09ID:AkdF/Ds50 >>414
半分しか分からないのは、オブジェクトの寿命を考えずにコーディングしているからだ。
ただしこれがGC言語の魅力でもあり、一々グダグダ考えていると魅力半減ではあるが、
そうは言っても、上達したいのなら、考える癖は付けた方がいい。
これについては、禿(ストロウストラップ=C++創始者)の
「ドキュメントを作成すべきコードのサイズには下限があるが、
コーディングする前に考えるべきコードのサイズには下限がない」
が当たってる。なまじ出来るようになるとどうとでも組めるようになるが、それがいけない。
本来このコードはここにあるべきか?というのを考えながらコーディングした方がいい。
usingに関しては、そもそもGDI+オブジェクトが永続化されるのが間違いで、
それはVに状態を持つということだから、MVCから見てもアウトだとすぐ分かるだろ。
本来は、GDI+オブジェクトに関しては、
・usingの中でしか使えない
・スタック上にしか置けない
(まあこの2つは等価だが)みたいな制限を課されたとしても、まともな設計なら制限にすらならないんだよ。
で、戻るが、これが分からないのなら、それはオブジェクトの寿命を考えてないからだ、となる。
といっても分からないだろうから、具体的に説明すると、
例えばドベタな将棋ソフトを作るとしよう。
CPUと対戦するだけの将棋ソフトで、ドベタに、
ユーザーが入力(指す)→画面の更新→CPUは考える→指す(画面の更新)→アイドル(ユーザー入力待ち)、の無限ループだとしよう。
これでMVCなら、
M: 盤面と持ち駒情報
V: 画面表示
C: それらのグルー
であって、画面はその都度最新状態に更新されているのだから、
アイドル状態で残っているオブジェクトはどう考えてもMの「盤面と持ち駒情報」だけでいいだろ。
だからアイドル状態にてV用のGDI+オブジェクトが捕まれたままになっている時点で設計がおかしいんだよ。
この点、Janeは再起動してみたが相変わらずGDI+は8,657なので、明らかに糞設計だと断言出来る。
半分しか分からないのは、オブジェクトの寿命を考えずにコーディングしているからだ。
ただしこれがGC言語の魅力でもあり、一々グダグダ考えていると魅力半減ではあるが、
そうは言っても、上達したいのなら、考える癖は付けた方がいい。
これについては、禿(ストロウストラップ=C++創始者)の
「ドキュメントを作成すべきコードのサイズには下限があるが、
コーディングする前に考えるべきコードのサイズには下限がない」
が当たってる。なまじ出来るようになるとどうとでも組めるようになるが、それがいけない。
本来このコードはここにあるべきか?というのを考えながらコーディングした方がいい。
usingに関しては、そもそもGDI+オブジェクトが永続化されるのが間違いで、
それはVに状態を持つということだから、MVCから見てもアウトだとすぐ分かるだろ。
本来は、GDI+オブジェクトに関しては、
・usingの中でしか使えない
・スタック上にしか置けない
(まあこの2つは等価だが)みたいな制限を課されたとしても、まともな設計なら制限にすらならないんだよ。
で、戻るが、これが分からないのなら、それはオブジェクトの寿命を考えてないからだ、となる。
といっても分からないだろうから、具体的に説明すると、
例えばドベタな将棋ソフトを作るとしよう。
CPUと対戦するだけの将棋ソフトで、ドベタに、
ユーザーが入力(指す)→画面の更新→CPUは考える→指す(画面の更新)→アイドル(ユーザー入力待ち)、の無限ループだとしよう。
これでMVCなら、
M: 盤面と持ち駒情報
V: 画面表示
C: それらのグルー
であって、画面はその都度最新状態に更新されているのだから、
アイドル状態で残っているオブジェクトはどう考えてもMの「盤面と持ち駒情報」だけでいいだろ。
だからアイドル状態にてV用のGDI+オブジェクトが捕まれたままになっている時点で設計がおかしいんだよ。
この点、Janeは再起動してみたが相変わらずGDI+は8,657なので、明らかに糞設計だと断言出来る。
418デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/27(金) 23:41:02.61ID:AkdF/Ds50 画面の更新は、当然関数であり、
画面の更新はこの中でしか行われないのだから、当然、この関数を出れば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用オブジェクト掴みっぱなしなんてあり得ないし。
画面の更新はこの中でしか行われないのだから、当然、この関数を出れば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用オブジェクト掴みっぱなしなんてあり得ないし。
419デフォルトの名無しさん (ワッチョイ 412f-fJ/L)
2019/12/28(土) 04:09:04.41ID:Cmc+tz5h0 GDI+だけがアンマネージドリソースではないんだが
そんな狭い前提で話されてもなぁ
そんな狭い前提で話されてもなぁ
420デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/28(土) 09:58:00.22ID:6W1egYcc0 ちょっと言い方が本質的でなかったから言い直すと、
ある関数内で必要とされるリソースに対して、
・その関数突入時には掴んでおらず、
・その関数脱出時にはリリースしててよい(=その関数の中でしか使わない)
場合は、必ずブロックスコープの入れ子で対応出来る。(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#は整合性より実質的利益を選択するはず。
ある関数内で必要とされるリソースに対して、
・その関数突入時には掴んでおらず、
・その関数脱出時にはリリースしててよい(=その関数の中でしか使わない)
場合は、必ずブロックスコープの入れ子で対応出来る。(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#は整合性より実質的利益を選択するはず。
421デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/28(土) 09:59:17.52ID:6W1egYcc0 お前らは多分気づいていないんだろうけど、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対応を捨てて速度を取っている。
動作効率はいいが、関数を頻繁に抜ける=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対応を捨てて速度を取っている。
422デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/28(土) 09:59:55.78ID:6W1egYcc0 なお余談だが、そのGUIをグダグダにならないように設計として対処しよう、というのがMVCであり、
これはやった方がいいのは事実だが、酷い話、
JavaScriptほどGUIと相性がいいとMとVが混ざっていようがなんとでもなってしまうのも事実で、
これの最たる物がjQueryであり、jQuery自体ではなく使う奴の使い方の問題なのだが、レッテル貼られて丸ごと廃棄されようとしている。
ただここら辺も、やれば、C#なんてGUIにはまるで向いて無く、
だからMVCだバインディングだと手の込んだ仕掛けを作って誤魔化さないと駄目なのだ、というのが分かるようになる。
だからまあ、設計の善し悪しが分かるようになってきたら、他言語を触ってみればいい。
(分からないうちに触っても文法コレクターにしかなれず、意味無いから止めとけ)
これはやった方がいいのは事実だが、酷い話、
JavaScriptほどGUIと相性がいいとMとVが混ざっていようがなんとでもなってしまうのも事実で、
これの最たる物がjQueryであり、jQuery自体ではなく使う奴の使い方の問題なのだが、レッテル貼られて丸ごと廃棄されようとしている。
ただここら辺も、やれば、C#なんてGUIにはまるで向いて無く、
だからMVCだバインディングだと手の込んだ仕掛けを作って誤魔化さないと駄目なのだ、というのが分かるようになる。
だからまあ、設計の善し悪しが分かるようになってきたら、他言語を触ってみればいい。
(分からないうちに触っても文法コレクターにしかなれず、意味無いから止めとけ)
423デフォルトの名無しさん (アウアウウー Sa83-BCWm)
2019/12/28(土) 10:32:20.67ID:Jn8dNYLra FormがBackgroundプロパティを持たないでどうやって背景色を指定するのかな?
再描画の際にしかBrushのGDI+オブジェクトは使用されないのだから常にBrushがGDI+リソースを持ち続ける必要がないという主張であるなら、パフォーマンスを度外視すればその通りかもしれん。
しかしBrushがGDI+リソースと一対一対応するのではなく必要なときにだけ内部的にGDI+リソースを作るような設計思想なら、
そもそもBrushのusingが一切必要ないようなアーキテクチャが十分に実現可能なんだよ。
言語をいじるまでもない簡単な話。
再描画の際にしかBrushのGDI+オブジェクトは使用されないのだから常にBrushがGDI+リソースを持ち続ける必要がないという主張であるなら、パフォーマンスを度外視すればその通りかもしれん。
しかしBrushがGDI+リソースと一対一対応するのではなく必要なときにだけ内部的にGDI+リソースを作るような設計思想なら、
そもそもBrushのusingが一切必要ないようなアーキテクチャが十分に実現可能なんだよ。
言語をいじるまでもない簡単な話。
424デフォルトの名無しさん (ワッチョイ 0c01-PaHz)
2019/12/28(土) 11:00:39.51ID:b3ohKRMf0 今日も知ったか君が暴れてるw
425デフォルトの名無しさん (ワッチョイ 4dda-K0SF)
2019/12/28(土) 11:09:23.84ID:mOzjhcRm0 予防線張ることに必死過ぎて何言ってんのかわからなくなってる典型だなこりゃ
自分の発言を自分で否定しながらお花畑垂れ流してる底抜けのアホ
自分の発言を自分で否定しながらお花畑垂れ流してる底抜けのアホ
426デフォルトの名無しさん (ブーイモ MM5e-7Yd4)
2019/12/28(土) 11:11:57.13ID:e/19aGJmM オブジェクト指向ではリソースは依存性として分離して注入するのが良い習慣とされる
なのでローカルスコープでいきなりリソース確保みたいなコードを書くことは稀だ
C#やJavaの世界ではリソースのライフタイムはDIコンテナが管理するものであってスタックに同期させるものではない
なのでローカルスコープでいきなりリソース確保みたいなコードを書くことは稀だ
C#やJavaの世界ではリソースのライフタイムはDIコンテナが管理するものであってスタックに同期させるものではない
427デフォルトの名無しさん (アウアウウー Sa83-BCWm)
2019/12/28(土) 11:16:46.70ID:Jn8dNYLra >>426
彼の主張は置いといて、生成タイミングの制御のためにDIでファクトリーオブジェクトを注入するのはよくあるパターンだぞ
彼の主張は置いといて、生成タイミングの制御のためにDIでファクトリーオブジェクトを注入するのはよくあるパターンだぞ
428デフォルトの名無しさん (ワッチョイ e25e-CmeR)
2019/12/28(土) 11:45:36.16ID:yuB2IAbM0 cでもmallocしてりゃどこかで開放は要るだろ。
理屈すり替えて楽しいか?
理屈すり替えて楽しいか?
429デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/28(土) 13:24:27.10ID:6W1egYcc0 >>423
> パフォーマンスを度外視すれば
GDI+オブジェクトの生成ってそんなに重いのか?
> そもそもBrushのusingが一切必要ないようなアーキテクチャが十分に実現可能なんだよ。
その通りだ。だから.NET自体がボロいんだよ。
元々はGDI+オブジェクトのリソースが限られていたから、win98までは文句を言わず俺が言っている
「使うときだけ生成、使い終わったらすぐ解放」
しかなかった。これを「面倒」と思ったのか単にボケているだけなのか、
リソースが大幅に増えたこともあって問題にもならなくなった為、掴みっぱなしも出来るようになった。
.NET自体はWin32APIを隠蔽する為の物で、これ自体は良く出来ている。
ただ、俺は、君の言うとおり、もう一枚多く隠蔽して、usingが一切不要のフレームワークにした方がいいと思うけど。
もしGDI+オブジェクト生成が問題になるほど重く、キャッシュしたいというのなら、直接自前でGDI+オブジェクトを掴む必要がある。
だから.NETは今のアーキテクチャなのだ、と捕らえることも出来るが、
実際はそうではなく、単に皮を被せただけで、その皮の厚さが不適当だっただけだと思うよ。
まあこれはすぐに修正出来る話でもあるけど。
> パフォーマンスを度外視すれば
GDI+オブジェクトの生成ってそんなに重いのか?
> そもそもBrushのusingが一切必要ないようなアーキテクチャが十分に実現可能なんだよ。
その通りだ。だから.NET自体がボロいんだよ。
元々はGDI+オブジェクトのリソースが限られていたから、win98までは文句を言わず俺が言っている
「使うときだけ生成、使い終わったらすぐ解放」
しかなかった。これを「面倒」と思ったのか単にボケているだけなのか、
リソースが大幅に増えたこともあって問題にもならなくなった為、掴みっぱなしも出来るようになった。
.NET自体はWin32APIを隠蔽する為の物で、これ自体は良く出来ている。
ただ、俺は、君の言うとおり、もう一枚多く隠蔽して、usingが一切不要のフレームワークにした方がいいと思うけど。
もしGDI+オブジェクト生成が問題になるほど重く、キャッシュしたいというのなら、直接自前でGDI+オブジェクトを掴む必要がある。
だから.NETは今のアーキテクチャなのだ、と捕らえることも出来るが、
実際はそうではなく、単に皮を被せただけで、その皮の厚さが不適当だっただけだと思うよ。
まあこれはすぐに修正出来る話でもあるけど。
430デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/28(土) 13:31:51.66ID:6W1egYcc0 >>426
> オブジェクト指向ではリソースは依存性として分離して注入するのが良い習慣とされる
そうだ。ただ、これがGUIとは絶望的に相性が悪いんだよ。
実際、Formsはこれで、各コントロールが値を保持してそれを参照する、というアーキテクチャだが、
事実としてこれは使いにくくて、WPFでばっさり修正されてるだろ。
(例としてはまんま>>253で、彼が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は二重に間違いを犯してる。
> オブジェクト指向ではリソースは依存性として分離して注入するのが良い習慣とされる
そうだ。ただ、これがGUIとは絶望的に相性が悪いんだよ。
実際、Formsはこれで、各コントロールが値を保持してそれを参照する、というアーキテクチャだが、
事実としてこれは使いにくくて、WPFでばっさり修正されてるだろ。
(例としてはまんま>>253で、彼が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は二重に間違いを犯してる。
431デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/28(土) 13:34:55.12ID:6W1egYcc0432デフォルトの名無しさん (アウアウウー Sab5-655U)
2019/12/28(土) 14:09:15.47ID:06FVqHz0a うーん、なんかさすがに「アインシュタインは間違っている!」と主張するトンデモ本作者的な主張は草不可避w
433デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/28(土) 14:31:37.94ID:6W1egYcc0 >>432
それが信者的態度だよ。
お前はC#以外の言語をいくつも知っていて、C#/.NETの良さ/悪さをちゃんと識別出来るのか?
ただしこれはC#だけではなく、どの言語スレも割とこの傾向の奴が多いのも事実だが。
ただその態度は目を曇らせるから止めた方がいい。
C#が覇権を取れておらず、今後とも取れそうにもないのにも理由があるし、
JavaScriptが糞糞言われてもやたら蔓延っているのにも理由がある。
お前が何を好きかはお前の自由だが、何故そうなっているのかが分からないようなら単なる馬鹿でしかない。
勿論馬鹿であり続けるのも君の自由だが。
> https://www.youtube.com/watch?v=Og847HVwRSI
> https://mevius.5ch.net/test/read.cgi/tech/1571315884/69
それが信者的態度だよ。
お前はC#以外の言語をいくつも知っていて、C#/.NETの良さ/悪さをちゃんと識別出来るのか?
ただしこれはC#だけではなく、どの言語スレも割とこの傾向の奴が多いのも事実だが。
ただその態度は目を曇らせるから止めた方がいい。
C#が覇権を取れておらず、今後とも取れそうにもないのにも理由があるし、
JavaScriptが糞糞言われてもやたら蔓延っているのにも理由がある。
お前が何を好きかはお前の自由だが、何故そうなっているのかが分からないようなら単なる馬鹿でしかない。
勿論馬鹿であり続けるのも君の自由だが。
> https://www.youtube.com/watch?v=Og847HVwRSI
> https://mevius.5ch.net/test/read.cgi/tech/1571315884/69
434デフォルトの名無しさん (ブーイモ MM5a-7Yd4)
2019/12/28(土) 14:54:05.52ID:yrEHcKMIM そんなに良いものなら実装してC#チームにマージリクエスト出したら?
ここで演説しても全く時間の無駄だよ?
実装するのにスキル不足なら機能リクエストでもいい
C#はオープンソースなんだからさ
ここで演説しても全く時間の無駄だよ?
実装するのにスキル不足なら機能リクエストでもいい
C#はオープンソースなんだからさ
435デフォルトの名無しさん (ワッチョイ 4697-b920)
2019/12/28(土) 15:20:44.51ID:WD8h4qtV0 今でもJavaでもクライアントコードを書けることになっている、とか、どの世界の話だろう?
あと、自分は432じゃないけど、
> それが信者的態度だよ。
> お前はC#以外の言語をいくつも知っていて、C#/.NETの良さ/悪さをちゃんと識別出来るのか?
というぐらいなら、C#以外の言語使えばいいんじゃない?って思ってしまう。
実際自分はプラットフォームに合わせて、アプリケーションの使いかたに合わせて8言語ぐらいから選んで使ってるけど。
あと、C#が覇権を取れていないとは全く思わないけどな。Windowsで適当なアプリ作るなら普通みんなC#で書くんじゃないの?
UnityだってC#だし。
あと、自分は432じゃないけど、
> それが信者的態度だよ。
> お前はC#以外の言語をいくつも知っていて、C#/.NETの良さ/悪さをちゃんと識別出来るのか?
というぐらいなら、C#以外の言語使えばいいんじゃない?って思ってしまう。
実際自分はプラットフォームに合わせて、アプリケーションの使いかたに合わせて8言語ぐらいから選んで使ってるけど。
あと、C#が覇権を取れていないとは全く思わないけどな。Windowsで適当なアプリ作るなら普通みんなC#で書くんじゃないの?
UnityだってC#だし。
436デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/28(土) 16:14:20.14ID:6W1egYcc0 >>434
俺は.NETを使っているのであって、C#は使ってない。
ただ、usingをどうするかは思想の問題であって、技術的に不足しているわけではないので、提案しても通らないとは思う。
(作ってる側も知っててそうしているはず)
>>435
そう思うならそれでよし。
C#は良い言語だし健闘している方だが、Javaと食い合うなら死ぬのはC#だ。(俺はJavaが死んで欲しいのだが)
OracleはJavaを技術的に成長させることは出来なかったが、ある意味余計なこともしなかった為、
プラットフォームとしては既に膨れあがってしまった。
後はC#で成果が出た仕様を順に取り入れていけば、「C#には負けない」言語にはなる。(勝てもしないが)
同じような仕様で並立すると、死ぬのは小さい側のC#なので、当然C#は新規機能を追加して逃げ続けるしかない。
これはこれで恩恵はあり、そうこうしているうちに勢力逆転出来ればいいが、今のところその芽もないだろ。
(Unityがそうだというのならそれでいいが)
> Windowsで適当なアプリ作るなら普通みんなC#で書くんじゃないの?
俺は知らんが多分Python。大体ネット上ではブッ叩かれているが。
その動画見ても一応トップだし。
俺は.NETを使っているのであって、C#は使ってない。
ただ、usingをどうするかは思想の問題であって、技術的に不足しているわけではないので、提案しても通らないとは思う。
(作ってる側も知っててそうしているはず)
>>435
そう思うならそれでよし。
C#は良い言語だし健闘している方だが、Javaと食い合うなら死ぬのはC#だ。(俺はJavaが死んで欲しいのだが)
OracleはJavaを技術的に成長させることは出来なかったが、ある意味余計なこともしなかった為、
プラットフォームとしては既に膨れあがってしまった。
後はC#で成果が出た仕様を順に取り入れていけば、「C#には負けない」言語にはなる。(勝てもしないが)
同じような仕様で並立すると、死ぬのは小さい側のC#なので、当然C#は新規機能を追加して逃げ続けるしかない。
これはこれで恩恵はあり、そうこうしているうちに勢力逆転出来ればいいが、今のところその芽もないだろ。
(Unityがそうだというのならそれでいいが)
> Windowsで適当なアプリ作るなら普通みんなC#で書くんじゃないの?
俺は知らんが多分Python。大体ネット上ではブッ叩かれているが。
その動画見ても一応トップだし。
437デフォルトの名無しさん (ワッチョイ 9701-K0SF)
2019/12/28(土) 16:38:51.11ID:WVh0vSeH0 ずーっと勝ちだの負けだのふわっふわなことこだわってるのなこのド近眼馬鹿
手前で他の言語持ち出してきて突っ込まれたら知らんから解説譲るとか逃げてるし
まさに無意味な頭でっかち文法コレクター(笑)を自ら体現してる
クスリでもキめてんのか?
手前で他の言語持ち出してきて突っ込まれたら知らんから解説譲るとか逃げてるし
まさに無意味な頭でっかち文法コレクター(笑)を自ら体現してる
クスリでもキめてんのか?
438デフォルトの名無しさん (ワッチョイ 4697-b920)
2019/12/28(土) 22:03:53.41ID:WD8h4qtV0 >>436
> 俺は知らんが多分Python。大体ネット上ではブッ叩かれているが。
いやいや…
実情を知らなすぎだろう?C#なら実行ファイルの入ったフォルダごと渡したら実行できるようになるけど、
Pythonだと環境を作ったりとか結構めんどくさいぞ。大体GUIを考えたらPythonとか最悪でしょ。
「お前はC#以外の言語をいくつも知っていて、C#/.NETの良さ/悪さをちゃんと識別出来るのか? 」とか言ってる割にはトンチンカンすぎる。
一応言っとくと、C#しか書けないからこう言ってるわけじゃなくて、Pythonもガンガン使って仕事してるからね。
あと、JavaはもうほとんどSIer専用言語みたいになってるから、C#と直接比較するのもナンセンスでしょ。
スーパーコンピュータで科学技術計算する分野では今でもFORTRANが主役だけど、そこ以外で使わないだろ。それと一緒。
最強言語なんてのはない。色々なニーズに合わせて言語(プラットフォーム)を選んで何でも書けばいいんだよ。
手続き型言語だったら考え方は大して変わらないからね。
> 俺は知らんが多分Python。大体ネット上ではブッ叩かれているが。
いやいや…
実情を知らなすぎだろう?C#なら実行ファイルの入ったフォルダごと渡したら実行できるようになるけど、
Pythonだと環境を作ったりとか結構めんどくさいぞ。大体GUIを考えたらPythonとか最悪でしょ。
「お前はC#以外の言語をいくつも知っていて、C#/.NETの良さ/悪さをちゃんと識別出来るのか? 」とか言ってる割にはトンチンカンすぎる。
一応言っとくと、C#しか書けないからこう言ってるわけじゃなくて、Pythonもガンガン使って仕事してるからね。
あと、JavaはもうほとんどSIer専用言語みたいになってるから、C#と直接比較するのもナンセンスでしょ。
スーパーコンピュータで科学技術計算する分野では今でもFORTRANが主役だけど、そこ以外で使わないだろ。それと一緒。
最強言語なんてのはない。色々なニーズに合わせて言語(プラットフォーム)を選んで何でも書けばいいんだよ。
手続き型言語だったら考え方は大して変わらないからね。
439デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/28(土) 22:29:59.46ID:6W1egYcc0 >>438
そりゃお前の現状認識がおかしいと思うぞ。
インストールすら大変なら、Pythonがここまで蔓延ることはない。
何故かよく出てくるFORTRANガーってのも、FORTRANなんて実際もう誰も使ってない(と聞いている)し、
今のFORTRANは昔のFORTRANとは別物(と聞いている)ので、FORTRANを持ち出すのもおかしい。
それはVBを持ち出してBASICがまだ使われている、と言っているに近い。(はず)
多分お前もFORTRAN信者に嘘を吹き込まれているだけだと思うが、
冷静に考えれば見抜けるはずだが、FOTRAN全盛時代の連中はもうリタイヤかその辺であって、コードなんて書いてない。
あれはスパコンのCOBOL扱いになってるはずだが。
(もしかしてベクトルはFORTRANしか受け付けないのかな?これはあり得るが)
まあいいが。
いずれにしてもお前らが何故そんなに信者化するのかはいつも疑問だ。
そりゃお前の現状認識がおかしいと思うぞ。
インストールすら大変なら、Pythonがここまで蔓延ることはない。
何故かよく出てくるFORTRANガーってのも、FORTRANなんて実際もう誰も使ってない(と聞いている)し、
今のFORTRANは昔のFORTRANとは別物(と聞いている)ので、FORTRANを持ち出すのもおかしい。
それはVBを持ち出してBASICがまだ使われている、と言っているに近い。(はず)
多分お前もFORTRAN信者に嘘を吹き込まれているだけだと思うが、
冷静に考えれば見抜けるはずだが、FOTRAN全盛時代の連中はもうリタイヤかその辺であって、コードなんて書いてない。
あれはスパコンのCOBOL扱いになってるはずだが。
(もしかしてベクトルはFORTRANしか受け付けないのかな?これはあり得るが)
まあいいが。
いずれにしてもお前らが何故そんなに信者化するのかはいつも疑問だ。
440デフォルトの名無しさん (ワッチョイ e25e-CmeR)
2019/12/28(土) 22:34:45.14ID:yuB2IAbM0 自分が作ったものだけ動かすなら楽だもの。Python。
envで環境作らないといかんくなったらめんどくさい。
お前あんまり知らねえだろ。
envで環境作らないといかんくなったらめんどくさい。
お前あんまり知らねえだろ。
441デフォルトの名無しさん (ワッチョイ 4697-b920)
2019/12/28(土) 23:12:31.42ID:WD8h4qtV0 >>439
開発用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
どうしてろくに自分で調べもせずに聞きかじったそれっぽい言葉を信じちゃうのか。
「いずれにしてもお前が何故そんなに知ったかするのかはいつも疑問だ。」
開発用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
どうしてろくに自分で調べもせずに聞きかじったそれっぽい言葉を信じちゃうのか。
「いずれにしてもお前が何故そんなに知ったかするのかはいつも疑問だ。」
442デフォルトの名無しさん (ワッチョイ 9b5f-/WEI)
2019/12/28(土) 23:13:03.41ID:H+9YQLdE0 自分とは違う意見=信者、と言うレッテル張り
443デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/29(日) 00:26:30.89ID:EA/Onx+o0 >>441
もう意味がないから終わりでいいが。
> インターネット接続不可の環境
今更ねえし。それが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使いが多いだけであって、
やっぱり君の現状認識は間違ってると思うぜ。
もう意味がないから終わりでいいが。
> インターネット接続不可の環境
今更ねえし。それが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使いが多いだけであって、
やっぱり君の現状認識は間違ってると思うぜ。
444デフォルトの名無しさん (ワッチョイ dc2c-++NQ)
2019/12/29(日) 00:34:45.31ID:jh70IlFa0 結局このスレで長文垂れ流して何がしたかったのかは永遠の謎だった
445デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/29(日) 00:36:25.95ID:EA/Onx+o0 >>441
すまん、名前(TensorFlow)が出てこなかったので分かれてしまったがついでに。
GoogleのTensorFlowもPython,/C/Java,/Goであって、FORTRANは動かない。
CUDAは既に書いたようにFortranも出ているようだが、
元々はそもそも出す気もなく、ユーザーも「C++のサポートを」とは言っていたけどFORTRANについては言ってなかったと思うけど。
BLASのFORTRANをUpdateしている連中は、どこで何向けを流しているんだ?
現在のHPCはFORTRANなんて見てないと思うのだが。(上記CUDAやTensorFlowしかり)
すまん、名前(TensorFlow)が出てこなかったので分かれてしまったがついでに。
GoogleのTensorFlowもPython,/C/Java,/Goであって、FORTRANは動かない。
CUDAは既に書いたようにFortranも出ているようだが、
元々はそもそも出す気もなく、ユーザーも「C++のサポートを」とは言っていたけどFORTRANについては言ってなかったと思うけど。
BLASのFORTRANをUpdateしている連中は、どこで何向けを流しているんだ?
現在のHPCはFORTRANなんて見てないと思うのだが。(上記CUDAやTensorFlowしかり)
446デフォルトの名無しさん (ワッチョイ 3263-mlB/)
2019/12/29(日) 00:40:06.58ID:9rgAI5qX0 GUI Programming in Python
https://wiki.python.org/moin/GuiProgramming
https://wiki.python.org/moin/GuiProgramming
447デフォルトの名無しさん (ワッチョイ 4d63-hRE6)
2019/12/29(日) 00:58:10.27ID:s3t0CIvz0 python製のwindowsアプリって何かある?
448デフォルトの名無しさん (ワッチョイ 7001-VnBs)
2019/12/29(日) 01:04:54.28ID:34CXn0hn0 凄えなGitHubの見方もまともにわからねえのかコイツ…
ここまで全方位に雑な上から目線キャラ初めて見たw
ここまで全方位に雑な上から目線キャラ初めて見たw
449デフォルトの名無しさん (ワッチョイ 4d63-hRE6)
2019/12/29(日) 01:13:01.51ID:s3t0CIvz0 現時点でwinアプリ開発で採用される言語のトップにpythonなんか入るわけ無いと思うけど
普通にC++/C#/VB辺りじゃない?
VBは国内だけかな?
この次あたりはどれも似たようなもんでそこにpythonが入るとかならまぁわかる。
javaはwinアプリなんかで使われてるのかはわからんけど
普通にC++/C#/VB辺りじゃない?
VBは国内だけかな?
この次あたりはどれも似たようなもんでそこにpythonが入るとかならまぁわかる。
javaはwinアプリなんかで使われてるのかはわからんけど
450デフォルトの名無しさん (ワッチョイ 4d63-hRE6)
2019/12/29(日) 01:17:48.90ID:s3t0CIvz0 ある程度の知識が広く浅くあるタイプの人間で技術屋以外に対して上手く話をして言いくるめるのが得意そうな感じ
あんま知らんけどSIerってこんな感じの人間なのかな?って見える
あんま知らんけどSIerってこんな感じの人間なのかな?って見える
451デフォルトの名無しさん (ワッチョイ 0101-Mkmj)
2019/12/29(日) 01:55:47.41ID:Jtzyjysr0 言い訳と反論が得意なイメージ有るけど。
452デフォルトの名無しさん (ブーイモ MM5a-LPJF)
2019/12/29(日) 11:03:14.73ID:HK/YahvcM >>443
> 今更ねえし。それがC#なら楽チン!(とも思えないが、仮にそうでも)それが売りになるとでも?
いくらでもある。当然売りになる。というかセキュリティ要件で満たさなきゃいけない。
> 当たり前だがGUI用のツールキットも死ぬほどあったはずだよ。ググればいくらでも出てくるでしょ。
で、使おうとしてみたことあるの?Pythonしか書けないってんじゃなければWinFormsの方がましとすぐに気がつく。
あとgithubのグラフの読み方は間違ってる。コミット数じゃなくて、コードの総量。
> 京がCとFORTRANのユーザー割合を公開していた気がしたが、出てこないんだな。
さっきのPDFに書いてあるとおり、FORTRANが1位だよ。
> 今更ねえし。それがC#なら楽チン!(とも思えないが、仮にそうでも)それが売りになるとでも?
いくらでもある。当然売りになる。というかセキュリティ要件で満たさなきゃいけない。
> 当たり前だがGUI用のツールキットも死ぬほどあったはずだよ。ググればいくらでも出てくるでしょ。
で、使おうとしてみたことあるの?Pythonしか書けないってんじゃなければWinFormsの方がましとすぐに気がつく。
あとgithubのグラフの読み方は間違ってる。コミット数じゃなくて、コードの総量。
> 京がCとFORTRANのユーザー割合を公開していた気がしたが、出てこないんだな。
さっきのPDFに書いてあるとおり、FORTRANが1位だよ。
453デフォルトの名無しさん (ブーイモ MM5a-LPJF)
2019/12/29(日) 11:04:58.14ID:HK/YahvcM >>443
> 今時はPythonで書かせろゴラアで、NumPyだCythonだが出てきてるわけだろ。
その辺は科学数値計算よりデータサイエンス系で盛り上がってるだけで、
色々余計なレイヤーがかぶさってるPythonが数値計算でnumpy、Cythonがあったとしても採用されにくいと
思うけどな。それこそメモリまわりの挙動とかで。
あと、tensorflowを例に挙げてHPCがどうこうと言ってたけど、ディープラーニングとかHPCの1ジャンルでしかないし、
ディープラーニングの分野ではFORTRANが使われてない、以上のことを示してないよ。
で、なんでそんなに他人の違う意見に対して「自分は正しい。お前の現状認識は間違ってる」と自信満々に言えるの?根拠は?
聞いてる限り聞きかじりの知識ばかりで実際に作らずに良し悪しを決めつけてるようにしか思えないんだが。
> 今時はPythonで書かせろゴラアで、NumPyだCythonだが出てきてるわけだろ。
その辺は科学数値計算よりデータサイエンス系で盛り上がってるだけで、
色々余計なレイヤーがかぶさってるPythonが数値計算でnumpy、Cythonがあったとしても採用されにくいと
思うけどな。それこそメモリまわりの挙動とかで。
あと、tensorflowを例に挙げてHPCがどうこうと言ってたけど、ディープラーニングとかHPCの1ジャンルでしかないし、
ディープラーニングの分野ではFORTRANが使われてない、以上のことを示してないよ。
で、なんでそんなに他人の違う意見に対して「自分は正しい。お前の現状認識は間違ってる」と自信満々に言えるの?根拠は?
聞いてる限り聞きかじりの知識ばかりで実際に作らずに良し悪しを決めつけてるようにしか思えないんだが。
454デフォルトの名無しさん (ワッチョイ 9317-K0SF)
2019/12/29(日) 11:46:41.74ID:vuWWhjO70 ここはC#スレだぞ
455デフォルトの名無しさん (ワッチョイ 9763-K0SF)
2019/12/29(日) 13:00:01.09ID:99B+H0jR0 ワッチョイスレなんだから各自NGすればよろし
456デフォルトの名無しさん (ワッチョイ ae2c-fJ/L)
2019/12/29(日) 13:26:29.34ID:KIjz0jVz0 日経Linux 2020/1月号に、
米田聡の記事「AI で鳩を自動認識、ラズパイ4 で3倍速」が載っている
TensorFlow Lite を使う、Google のEdge TPU の2製品、
Coral USB Accelerator, Coral Dev Board
CUDA なら、CPU の1/50 ぐらいの時間になる
ここは、C# のスレなので、以降は他のスレで議論してください!
米田聡の記事「AI で鳩を自動認識、ラズパイ4 で3倍速」が載っている
TensorFlow Lite を使う、Google のEdge TPU の2製品、
Coral USB Accelerator, Coral Dev Board
CUDA なら、CPU の1/50 ぐらいの時間になる
ここは、C# のスレなので、以降は他のスレで議論してください!
457デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/29(日) 14:36:52.40ID:EA/Onx+o0 >>452
概ね全面的に水掛け論だからまあもういいが、一応反論だけはしておく。
> いくらでもある。当然売りになる。というかセキュリティ要件で満たさなきゃいけない。
いや逆じゃね?ローカルにUSBメモリ刺してexe/dllを直インストールなんてセキュリティが厳しい要件で許可されるのか?
まあいいが。
> Pythonしか書けないってんじゃなければWinFormsの方がましとすぐに気がつく。
だから言ったとおり俺はPythonを使ってない。
> WinFormsの方がまし
ただ、これはない。Formsは壮絶にゴミだ。それはHTML/CSS/JavaScriptを使えばすぐ分かる。
同様にWPFもゴミだが、Formsよりは数倍ましだ。
そしてWPFがHTMLに寄せたのはMSもそっちの方が断然いいと判断したからだ。
ただ、まだCSSが当てられないのが相当痛い。だから次は丸々HTML/CSSに寄せるはず。
(というかWeb開発では事実上そうでしかないが)
そもそもPythonもそっちに動いているっぽいだろ。>>446の頭の2つ、
> Cross-Browser Frameworks
は多分それだよ。Pythonでローカルに鯖を立てて、それをブラウザで見るんだよ。(かそれに近い形式)
というか俺なら最初からそうする。
つまり計算用PythonはJSONインタフェースだけ付けて終わりで、後は全面的にHTMLの恩恵を受けられる。
HTMLの良さが分からないのは、君が知らないからでしかない。といっても別に難しいものではないから、やってみればいいんだよ。
やれば、悲しいくらいに簡単にGUIを作れて、Formsとか本当にゴミだと実感出来るようになる。
概ね全面的に水掛け論だからまあもういいが、一応反論だけはしておく。
> いくらでもある。当然売りになる。というかセキュリティ要件で満たさなきゃいけない。
いや逆じゃね?ローカルにUSBメモリ刺してexe/dllを直インストールなんてセキュリティが厳しい要件で許可されるのか?
まあいいが。
> Pythonしか書けないってんじゃなければWinFormsの方がましとすぐに気がつく。
だから言ったとおり俺はPythonを使ってない。
> WinFormsの方がまし
ただ、これはない。Formsは壮絶にゴミだ。それはHTML/CSS/JavaScriptを使えばすぐ分かる。
同様にWPFもゴミだが、Formsよりは数倍ましだ。
そしてWPFがHTMLに寄せたのはMSもそっちの方が断然いいと判断したからだ。
ただ、まだCSSが当てられないのが相当痛い。だから次は丸々HTML/CSSに寄せるはず。
(というかWeb開発では事実上そうでしかないが)
そもそもPythonもそっちに動いているっぽいだろ。>>446の頭の2つ、
> Cross-Browser Frameworks
は多分それだよ。Pythonでローカルに鯖を立てて、それをブラウザで見るんだよ。(かそれに近い形式)
というか俺なら最初からそうする。
つまり計算用PythonはJSONインタフェースだけ付けて終わりで、後は全面的にHTMLの恩恵を受けられる。
HTMLの良さが分からないのは、君が知らないからでしかない。といっても別に難しいものではないから、やってみればいいんだよ。
やれば、悲しいくらいに簡単にGUIを作れて、Formsとか本当にゴミだと実感出来るようになる。
458デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/29(日) 14:37:27.40ID:EA/Onx+o0 > あと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)
> その他、スーパーコンピュータセンターからのコメントから、FORTRAN77からFortran90への移行、
> あるいはC++
への移行等、より記述性や生産性の高い言語への移行が進んできている印象を受けた。
君は移行すらしてない、という見解なんだろ。なんだかなあ。
> それこそメモリまわりの挙動とかで。
何が言いたいのか分からん。
Cのdllを呼んでるだけだぞ。C#でならunsafeでCのdllを呼んでるのと同じ。
全く問題ないし、関係ないよ。だからこれについてはC#でも何でもいいわけだが。
間違いは認めるとして、いずれにしてもナンセンスだからこれは止めよう。
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)
> その他、スーパーコンピュータセンターからのコメントから、FORTRAN77からFortran90への移行、
> あるいはC++
への移行等、より記述性や生産性の高い言語への移行が進んできている印象を受けた。
君は移行すらしてない、という見解なんだろ。なんだかなあ。
> それこそメモリまわりの挙動とかで。
何が言いたいのか分からん。
Cのdllを呼んでるだけだぞ。C#でならunsafeでCのdllを呼んでるのと同じ。
全く問題ないし、関係ないよ。だからこれについてはC#でも何でもいいわけだが。
459デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/29(日) 14:38:02.85ID:EA/Onx+o0 > ディープラーニングとかHPCの1ジャンルでしかないし、
> ディープラーニングの分野ではFORTRANが使われてない、以上のことを示してないよ。
今寄ってたかってホットなのは明らかにここだし、これを外して何を言うんだ?
問題は、こういった新しい環境ではFORTRAN向けの環境整備なんてされてない、ってことなんだよ。
だから正確には、「新しいHPC環境ではFORTRANは使えない」だよ。
俺は君が
> スーパーコンピュータで科学技術計算する分野では今でもFORTRANが主役だけど(>>438)
という明らかな嘘を言ったことを咎めている。
「環境自体がない」んだからそんなわけがないだろ。
何も知らない若い奴らが信じてしまう可能性もあるのだから、明らかな嘘をついてミスリードするようなことはするな。
色々見解が違うのはいいとしても、これはねえよマジで。
> ディープラーニングの分野ではFORTRANが使われてない、以上のことを示してないよ。
今寄ってたかってホットなのは明らかにここだし、これを外して何を言うんだ?
問題は、こういった新しい環境ではFORTRAN向けの環境整備なんてされてない、ってことなんだよ。
だから正確には、「新しいHPC環境ではFORTRANは使えない」だよ。
俺は君が
> スーパーコンピュータで科学技術計算する分野では今でもFORTRANが主役だけど(>>438)
という明らかな嘘を言ったことを咎めている。
「環境自体がない」んだからそんなわけがないだろ。
何も知らない若い奴らが信じてしまう可能性もあるのだから、明らかな嘘をついてミスリードするようなことはするな。
色々見解が違うのはいいとしても、これはねえよマジで。
460デフォルトの名無しさん (ワッチョイ e25e-CmeR)
2019/12/29(日) 14:51:21.50ID:mqdEA2UD0 WPFはHTMLに寄せたんじゃねえよ。
XMLとしてvalidだろ。
XMLとしてvalidだろ。
461デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/29(日) 15:06:33.85ID:EA/Onx+o0 >>460
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から移行した奴らは活用してないかもしれんが。
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から移行した奴らは活用してないかもしれんが。
462456 (ワッチョイ ae2c-fJ/L)
2019/12/29(日) 15:10:58.86ID:KIjz0jVz0 VSCode で良い。
markdown も表示できるし
Python は、Jupyter Notebook でも良い。
Julia, Ruby でも使えるし
VSCodeは、Electron だから、Node.js + Chromium だろ。
Ruby の標準サーバーを立ててもよいし
markdown も表示できるし
Python は、Jupyter Notebook でも良い。
Julia, Ruby でも使えるし
VSCodeは、Electron だから、Node.js + Chromium だろ。
Ruby の標準サーバーを立ててもよいし
463デフォルトの名無しさん (ドコグロ MM36-BCWm)
2019/12/29(日) 15:26:07.21ID:J2Lmqp1KM >>462
ルビ糞は教祖様推奨のEmacsを使えカス
ルビ糞は教祖様推奨のEmacsを使えカス
464デフォルトの名無しさん (スフッ Sd94-hoej)
2019/12/29(日) 15:26:34.81ID:fYAoNqJEd コントロールに適用したいStyleがあるので、Generic.xaml を作成して、
App.xaml で ResourceDictionary.Merge Dictionaryしました。その中で自作のコンバータークラスを使いたくて定義したのですが、どうしても認識してくれません。ビルドは通るのですが、実行時に見つからないエラーがでます(xaml parse exeption)
同じ定義を App.xaml の中で、Generic.xamlをマージする前に書くと、何故か実行時にエラーも出ませんし、ちゃんと動きます。
Generic.xaml の中でコンバーターを定義することは出来ないのでしょうか
App.xaml で ResourceDictionary.Merge Dictionaryしました。その中で自作のコンバータークラスを使いたくて定義したのですが、どうしても認識してくれません。ビルドは通るのですが、実行時に見つからないエラーがでます(xaml parse exeption)
同じ定義を App.xaml の中で、Generic.xamlをマージする前に書くと、何故か実行時にエラーも出ませんし、ちゃんと動きます。
Generic.xaml の中でコンバーターを定義することは出来ないのでしょうか
465デフォルトの名無しさん (ワッチョイ 412f-Bp86)
2019/12/29(日) 15:30:19.53ID:Lr7vQfGy0 テキスト送信して相手にレンダリングさせるものと自身のウインドウ環境に直接レンダリングするものを本気で横ならびで比較する時代になったのね
466デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/29(日) 15:59:41.03ID:EA/Onx+o0 >>465
なったというか、いわゆる(短期的な)「生産性」ってのは、どうでもいいところで如何に手を抜くか、でもあるからね。
グラが勝負なら自前でレンダリングしかないが、
>>253とか俺とか、>>452もほぼ確実にそうだと思うが、
計算ソフトの初期値設定をするだけ、みたいなGUIに時間かけて凝っても意味無いんだよ。
そこは「計算」に凝るべきであって、とりあえず多少遅かろうが表示出来れば何でもいいんだよ。
というか、こういうのを分かっててお前らはC#を選んでいるんじゃないのか?
ならまあ、お前らが奇妙なほどに信者化するのも分からなくもないが。
ちなみにUnity、内部エンジンはC++で上位スクリプトだけC#か?なら確かに芽があるかもしれん。
しかしこの構成なら、じきに上位スクリプトもPythonで書かせろ、になるとも思うが。
なったというか、いわゆる(短期的な)「生産性」ってのは、どうでもいいところで如何に手を抜くか、でもあるからね。
グラが勝負なら自前でレンダリングしかないが、
>>253とか俺とか、>>452もほぼ確実にそうだと思うが、
計算ソフトの初期値設定をするだけ、みたいなGUIに時間かけて凝っても意味無いんだよ。
そこは「計算」に凝るべきであって、とりあえず多少遅かろうが表示出来れば何でもいいんだよ。
というか、こういうのを分かっててお前らはC#を選んでいるんじゃないのか?
ならまあ、お前らが奇妙なほどに信者化するのも分からなくもないが。
ちなみにUnity、内部エンジンはC++で上位スクリプトだけC#か?なら確かに芽があるかもしれん。
しかしこの構成なら、じきに上位スクリプトもPythonで書かせろ、になるとも思うが。
467デフォルトの名無しさん (ワッチョイ e25e-CmeR)
2019/12/29(日) 16:06:57.90ID:mqdEA2UD0 >>461
機構のどこが丸パクリなんだよ。
Cだけじゃねえか。
Formsでもイベントのさばき方次第だろ。全然Forms触ってねえだけじゃねえか。
で、イベントも普通はそう捌くんじゃなくて、バインディングするもんだよ。
何意味不明な事言ってんだよ。
機構のどこが丸パクリなんだよ。
Cだけじゃねえか。
Formsでもイベントのさばき方次第だろ。全然Forms触ってねえだけじゃねえか。
で、イベントも普通はそう捌くんじゃなくて、バインディングするもんだよ。
何意味不明な事言ってんだよ。
468デフォルトの名無しさん (ワッチョイ 6e0c-K0SF)
2019/12/29(日) 16:08:17.70ID:ot6kdVlr0 語れば語るほど行毎に突っ込みどころ量産してるのが凄い…
釣りでガイジのフリやってるなら大したもんだわ
釣りでガイジのフリやってるなら大したもんだわ
469デフォルトの名無しさん (ワッチョイ 6c88-hRE6)
2019/12/29(日) 16:11:04.28ID:RdqvkJW90 > ちなみにUnity、内部エンジンはC++で上位スクリプトだけC#か?なら確かに芽があるかもしれん。
> しかしこの構成なら、じきに上位スクリプトもPythonで書かせろ、になるとも思うが。
なんでこんな予測になるのか意味不明
unityから使用できるjavascriptが廃れた経緯があるのにまた変更なんかこないよ
ゲーム開発においてスクリプト言語が来る時代は来るかもしれんがそれはunityにはこんだろう
新しいエンジンが来たときにその時代に沿った新しい言語が採用される可能性はある
> しかしこの構成なら、じきに上位スクリプトもPythonで書かせろ、になるとも思うが。
なんでこんな予測になるのか意味不明
unityから使用できるjavascriptが廃れた経緯があるのにまた変更なんかこないよ
ゲーム開発においてスクリプト言語が来る時代は来るかもしれんがそれはunityにはこんだろう
新しいエンジンが来たときにその時代に沿った新しい言語が採用される可能性はある
470デフォルトの名無しさん (ワッチョイ ee89-VnBs)
2019/12/29(日) 16:14:19.03ID:8r12tXQy0 実際にUnityで選択肢として使えたjsとpythonがC#に駆逐された経緯とか知ったらこのキチガイ脱糞しそう
471デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/29(日) 16:27:43.79ID:EA/Onx+o0 >>467
逆だろ。Bはこれからパクる、Cはパクリ、D/Eは直っていればパクリ、直ってなければ糞だ。
あとFormsはバインディングできない。(から自前でやるにはReflectionすることになり、これが糞)
ただバインディングについては、
バブルされたイベント拾ってそこでバリデーションして問題なければ反映、アウトなら戻す、
みたいな方が格好悪いが結果的に楽な気はする。
(既に言ったとおり俺自身がWPF使ってないから全てに於いてバインディングだけで上手く行くのかは分からない。
勿論全く問題ないならバインディングした方がいいけども)
>>469
>>470
おお、その釣り針は喜んで食いつくから、駆逐された経緯とか書いたページがあれば紹介してくれ。
つってもちょっと(席を)外すが。
逆だろ。Bはこれからパクる、Cはパクリ、D/Eは直っていればパクリ、直ってなければ糞だ。
あとFormsはバインディングできない。(から自前でやるにはReflectionすることになり、これが糞)
ただバインディングについては、
バブルされたイベント拾ってそこでバリデーションして問題なければ反映、アウトなら戻す、
みたいな方が格好悪いが結果的に楽な気はする。
(既に言ったとおり俺自身がWPF使ってないから全てに於いてバインディングだけで上手く行くのかは分からない。
勿論全く問題ないならバインディングした方がいいけども)
>>469
>>470
おお、その釣り針は喜んで食いつくから、駆逐された経緯とか書いたページがあれば紹介してくれ。
つってもちょっと(席を)外すが。
472デフォルトの名無しさん (ワッチョイ 6c88-hRE6)
2019/12/29(日) 16:36:33.93ID:RdqvkJW90 食いつかんで良いから自分の浅はかな知識で事を語っていることを認識し悔い改めていただきたい
知りたきゃご自身でお調べ下さい
知りたきゃご自身でお調べ下さい
473デフォルトの名無しさん (ワッチョイ e25e-CmeR)
2019/12/29(日) 17:14:51.69ID:mqdEA2UD0474デフォルトの名無しさん (ワッチョイ aa01-Nxir)
2019/12/29(日) 18:30:55.82ID:2GmPR76J0475デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/29(日) 19:00:10.06ID:EA/Onx+o0 >>473
> DataSource
ああそれは確かに俺は触ってないわ。何かあったけど放置してた。
一応軽く見てみたが、ちょっと使ってみないと分からんね。
.NETは若干かっこよさを追求しすぎていて、既に言った
「フォームの値をプログラムから変更してもイベントが『同期』で発生する」
もそうだけど、格好良く自動連動を目指したのだろうけど、余計に使いにくくなってる。
同様に、余計なイベント接続が行われている可能性もあるから、実際に使えるかどうかは試してみないと分からん。
JavaScriptの場合はもっとドベタに
「プログラムから変更したらイベントは発生しないから、必要なら自分で呼べ」
でしかないから、本当にドベタにユーザーが挙動を定義出来る。
言ってしまえば、JavaScriptはライト層向けにできていて、
.NETはプロ向け(.NETのことを隅々までよく知っている前提)だと言えなくもないが、
ちょっとチューニングを失敗しているように思う。
結果、JavaScriptの方が取っつきやすいから、最近はどうでもいいUIはだいたいWebアプリになってるだろ。
>>474
これか?
https://www.atmarkit.co.jp/ait/articles/1009/07/news096_2.html
これは確かにCSSの一部だが、これでは全然足りない。
スタイルを適用したいのはコントロールそのものに、ではない。
CSSが美味しいのは、左右はもちろん上下ですら表示位置を簡単に入れ替えられること。
だから見た目全く違う物も同じHTML構造を取れ、結果、
同じ関数からお約束のHTMLを吐き出して後はCSSでも当てて、みたいな手抜きがあっさり出来る。
(見た目毎に出力関数を用意する必要がない)
CSSの表現能力についてはWeb系の馬鹿共がよく「CSSでここまで出来る!」みたいなページを作っているから見てみればいい。
> DataSource
ああそれは確かに俺は触ってないわ。何かあったけど放置してた。
一応軽く見てみたが、ちょっと使ってみないと分からんね。
.NETは若干かっこよさを追求しすぎていて、既に言った
「フォームの値をプログラムから変更してもイベントが『同期』で発生する」
もそうだけど、格好良く自動連動を目指したのだろうけど、余計に使いにくくなってる。
同様に、余計なイベント接続が行われている可能性もあるから、実際に使えるかどうかは試してみないと分からん。
JavaScriptの場合はもっとドベタに
「プログラムから変更したらイベントは発生しないから、必要なら自分で呼べ」
でしかないから、本当にドベタにユーザーが挙動を定義出来る。
言ってしまえば、JavaScriptはライト層向けにできていて、
.NETはプロ向け(.NETのことを隅々までよく知っている前提)だと言えなくもないが、
ちょっとチューニングを失敗しているように思う。
結果、JavaScriptの方が取っつきやすいから、最近はどうでもいいUIはだいたいWebアプリになってるだろ。
>>474
これか?
https://www.atmarkit.co.jp/ait/articles/1009/07/news096_2.html
これは確かにCSSの一部だが、これでは全然足りない。
スタイルを適用したいのはコントロールそのものに、ではない。
CSSが美味しいのは、左右はもちろん上下ですら表示位置を簡単に入れ替えられること。
だから見た目全く違う物も同じHTML構造を取れ、結果、
同じ関数からお約束のHTMLを吐き出して後はCSSでも当てて、みたいな手抜きがあっさり出来る。
(見た目毎に出力関数を用意する必要がない)
CSSの表現能力についてはWeb系の馬鹿共がよく「CSSでここまで出来る!」みたいなページを作っているから見てみればいい。
476デフォルトの名無しさん (ワッチョイ 6c88-hRE6)
2019/12/29(日) 19:12:12.77ID:RdqvkJW90 詳細を突っ込まれると
そうだね、けどこの面では…的な論理展開ばっかだけど自分で気にならないの?
これを繰り返してるうちに自身の主張が何かよくわからなくなって無意味に多方向にdisを撒き散らしてるだけになってる
そうだね、けどこの面では…的な論理展開ばっかだけど自分で気にならないの?
これを繰り返してるうちに自身の主張が何かよくわからなくなって無意味に多方向にdisを撒き散らしてるだけになってる
477デフォルトの名無しさん (ワッチョイ aa01-Nxir)
2019/12/29(日) 19:21:15.54ID:2GmPR76J0 >>475
> CSSが美味しいのは、左右はもちろん上下ですら表示位置を簡単に入れ替えられること。
それはコンセプトの違い
WPFはXAMLでコントロールの位置を変えればいいだけ
データとはバインディングで繋がってるから位置を変えてもDataSourceはいじる必要はない
> CSSが美味しいのは、左右はもちろん上下ですら表示位置を簡単に入れ替えられること。
それはコンセプトの違い
WPFはXAMLでコントロールの位置を変えればいいだけ
データとはバインディングで繋がってるから位置を変えてもDataSourceはいじる必要はない
478デフォルトの名無しさん (ワッチョイ e25e-CmeR)
2019/12/29(日) 19:24:54.99ID:mqdEA2UD0479デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/29(日) 19:33:22.61ID:EA/Onx+o0 >>472
以下は読んだ。
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が圧倒的にいいのは事実だよ。あれと同じ物を自前で用意するのは無理だ。
以下は読んだ。
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が圧倒的にいいのは事実だよ。あれと同じ物を自前で用意するのは無理だ。
480デフォルトの名無しさん (ワッチョイ 6c88-hRE6)
2019/12/29(日) 19:53:49.10ID:RdqvkJW90481デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/29(日) 20:00:11.04ID:EA/Onx+o0 >>477
だからそれが駄目だと言ってるんだよ。
XAMLを変更=HTMLを変更と同じで、それだと、全く同じ関数とか使えないんだよ。
XAMLを弄って変更した場合、文書階層が変わるから、バブルしてくるイベントも経路が変わってしまうだろ。
すると、イベント周りも修正が必要になってくるだろ。
CSSだけで位置変更出来れば、本当に表示位置だけを変えられる。
バブルしてくるイベントはHTML通りにバブルしてくるから、見た目重なってもいない要素からもバブルしてくるようにも出来るんだが、
それだからこそ、同じプログラムで対応出来るんだよ。
違うのは人間からの見た目だけであって、プログラム上からの見た目は同じだから。
と、説明しても意味分からんと思うけど、多分やれば分かるよ。
「こんな手抜きの仕方があるのかよ!」みたいな事が結構出来たりするから。
典型的な例だと、HTML/CSSでは display:none (表示させないだけ、Formsで言う Control.Visible = false)を多用する。
勿論上記の通りFormsでも出来るけど、文化的にほぼ使われてないでしょ。(と俺は思っている)
ここら辺の手抜きの仕方がWeb系の方がこなれてる。
俺もそうだったが、,.NET界隈も真面目にプログラミングやりすぎてるんだよ。
「常に見えない設定の物を表示ルーチンに渡すのは無駄だ」というのは当たり前だけど、
それで別関数になるくらいなら、display:noneで同じ関数使おうぜ、ということ。
CSSの表現能力が高いからこれがかなり有効なんだよ。
だからそれが駄目だと言ってるんだよ。
XAMLを変更=HTMLを変更と同じで、それだと、全く同じ関数とか使えないんだよ。
XAMLを弄って変更した場合、文書階層が変わるから、バブルしてくるイベントも経路が変わってしまうだろ。
すると、イベント周りも修正が必要になってくるだろ。
CSSだけで位置変更出来れば、本当に表示位置だけを変えられる。
バブルしてくるイベントはHTML通りにバブルしてくるから、見た目重なってもいない要素からもバブルしてくるようにも出来るんだが、
それだからこそ、同じプログラムで対応出来るんだよ。
違うのは人間からの見た目だけであって、プログラム上からの見た目は同じだから。
と、説明しても意味分からんと思うけど、多分やれば分かるよ。
「こんな手抜きの仕方があるのかよ!」みたいな事が結構出来たりするから。
典型的な例だと、HTML/CSSでは display:none (表示させないだけ、Formsで言う Control.Visible = false)を多用する。
勿論上記の通りFormsでも出来るけど、文化的にほぼ使われてないでしょ。(と俺は思っている)
ここら辺の手抜きの仕方がWeb系の方がこなれてる。
俺もそうだったが、,.NET界隈も真面目にプログラミングやりすぎてるんだよ。
「常に見えない設定の物を表示ルーチンに渡すのは無駄だ」というのは当たり前だけど、
それで別関数になるくらいなら、display:noneで同じ関数使おうぜ、ということ。
CSSの表現能力が高いからこれがかなり有効なんだよ。
482デフォルトの名無しさん (ワッチョイ f67b-pUr/)
2019/12/29(日) 20:05:42.44ID:rG0bhEhQ0 かまうほうも頭おかしいんだけど自覚ないの
483デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/29(日) 20:06:05.21ID:EA/Onx+o0 >>478
原理原則論としてはそうなのだろうけど、だから逆に使いにくくなってるんだよ。
多分これも、JavaScriptみたいに「自前でやらないと発火しない」フレームワークを使えば分かるよ。
君が既に両方使ったことがあって、
HTML/CSS/JavaScriptよりも.NETの方が使いやすいと判断しているのなら、それでいいが。
原理原則論としてはそうなのだろうけど、だから逆に使いにくくなってるんだよ。
多分これも、JavaScriptみたいに「自前でやらないと発火しない」フレームワークを使えば分かるよ。
君が既に両方使ったことがあって、
HTML/CSS/JavaScriptよりも.NETの方が使いやすいと判断しているのなら、それでいいが。
484デフォルトの名無しさん (ワッチョイ 6c88-hRE6)
2019/12/29(日) 20:06:32.69ID:RdqvkJW90 なんでxamlとhtmlの比較の典型例にformsがでてくんの?
xamlでもコントロールの非表示なんて日常茶飯事だと思うが
xamlでもコントロールの非表示なんて日常茶飯事だと思うが
485デフォルトの名無しさん (ワッチョイ a642-K0SF)
2019/12/29(日) 20:08:02.86ID:kYkJMpoK0 cssを採用したjava fxってどうなったんだろうね?
486デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/29(日) 20:12:37.27ID:EA/Onx+o0 >>480
ん?Pythonについてなら君の言うとおり、
> ゲーム開発においてスクリプト言語が来る時代は来るかもしれんがそれはunityにはこんだろう
これについては納得したぞ。俺の負けでいい。
あのブログはもう2-3年前になるが、まあ、少なくともunityにはスクリプトは来ないね。
あれはC#と心中する、という決断だ。(逆に言えばC#は死なないとunityは判断してる)
ん?Pythonについてなら君の言うとおり、
> ゲーム開発においてスクリプト言語が来る時代は来るかもしれんがそれはunityにはこんだろう
これについては納得したぞ。俺の負けでいい。
あのブログはもう2-3年前になるが、まあ、少なくともunityにはスクリプトは来ないね。
あれはC#と心中する、という決断だ。(逆に言えばC#は死なないとunityは判断してる)
487デフォルトの名無しさん (ワッチョイ d81b-hoej)
2019/12/29(日) 20:20:44.20ID:PurJ6L2e0 差し支えなければどなたか>>464を…
488デフォルトの名無しさん (ワッチョイ aa01-Nxir)
2019/12/29(日) 20:21:07.58ID:2GmPR76J0 >>481
> XAMLを弄って変更した場合、文書階層が変わるから、バブルしてくるイベントも経路が変わってしまうだろ。
WPFではイベントは直接使わないよ(使うこともできるけどあまりよろしくない)
モデル側でコマンドを定義してコントロールにバインドする
って言っても君にはちんぷんかんぷんかもね
まあ理解する気なさそうだから君はそのままでいいと思うよw
> XAMLを弄って変更した場合、文書階層が変わるから、バブルしてくるイベントも経路が変わってしまうだろ。
WPFではイベントは直接使わないよ(使うこともできるけどあまりよろしくない)
モデル側でコマンドを定義してコントロールにバインドする
って言っても君にはちんぷんかんぷんかもね
まあ理解する気なさそうだから君はそのままでいいと思うよw
489デフォルトの名無しさん (ブーイモ MM5a-Wq+o)
2019/12/29(日) 20:21:43.91ID:by75XqYfM >>486
俺は複数の分野を横断的に知ってて各方面の弱いところをよく知ってる、だからマウントとれる、
と思ってるのかもしれないけど、職業プログラマだったらそんなの実務レベルで当たり前で、
むしろある分野を専門的にやってる人には勝てないなと思ってるからそんな大げさな物言いはしないんだけどね。
(〇〇の分野だと□□という概念があるんだけど、△△だとそういう概念はある?ぐらいに控えめに話題にする)
「C#信者」、「FORTRAN信者」だの、「Web系の馬鹿共」だの、「HTMLの良さがわからないのは君が知らないからだ」だの、
「説明しても意味わからんと思うけど」だの、よくもまあ自分以外を下に見る発言が沢山出てくるもんだ。
皆、あんたが偉そうに発言する割には、中身が誰でも思いつくことでしかも間違いが多いからツッコミを入れてるだけだぞ。それを「こいつはわからないから反論してきてるんだ」と思うようじゃ単なる天狗で自分の成長につながらないよ。
このスレでたった2日やりとりしたぐらいで、経験知識不足で頓珍漢な理屈を並べてると思われちゃってるんだから。
最終的に、実世界で相手されなくなって5chに書き込むしかなくなる悲しい人生になるぞ。
> 「今でもFORTRAN向けBLASの一つの実装がアップデートされている」
正直笑ってしまった。わかってないようだがOpenBLASはFORTRANのコードをコンパイルしてCから呼び出すんだよ。
FORTRAN専用のコードじゃない。CやFORTRANで呼び出せる共通バイナリをFORTRANで書いてるの。
俺は複数の分野を横断的に知ってて各方面の弱いところをよく知ってる、だからマウントとれる、
と思ってるのかもしれないけど、職業プログラマだったらそんなの実務レベルで当たり前で、
むしろある分野を専門的にやってる人には勝てないなと思ってるからそんな大げさな物言いはしないんだけどね。
(〇〇の分野だと□□という概念があるんだけど、△△だとそういう概念はある?ぐらいに控えめに話題にする)
「C#信者」、「FORTRAN信者」だの、「Web系の馬鹿共」だの、「HTMLの良さがわからないのは君が知らないからだ」だの、
「説明しても意味わからんと思うけど」だの、よくもまあ自分以外を下に見る発言が沢山出てくるもんだ。
皆、あんたが偉そうに発言する割には、中身が誰でも思いつくことでしかも間違いが多いからツッコミを入れてるだけだぞ。それを「こいつはわからないから反論してきてるんだ」と思うようじゃ単なる天狗で自分の成長につながらないよ。
このスレでたった2日やりとりしたぐらいで、経験知識不足で頓珍漢な理屈を並べてると思われちゃってるんだから。
最終的に、実世界で相手されなくなって5chに書き込むしかなくなる悲しい人生になるぞ。
> 「今でもFORTRAN向けBLASの一つの実装がアップデートされている」
正直笑ってしまった。わかってないようだがOpenBLASはFORTRANのコードをコンパイルしてCから呼び出すんだよ。
FORTRAN専用のコードじゃない。CやFORTRANで呼び出せる共通バイナリをFORTRANで書いてるの。
490デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/29(日) 20:23:58.98ID:EA/Onx+o0491デフォルトの名無しさん (ワッチョイ 6c88-hRE6)
2019/12/29(日) 20:25:19.89ID:RdqvkJW90492デフォルトの名無しさん (ワッチョイ aa01-Nxir)
2019/12/29(日) 20:25:25.54ID:2GmPR76J0 >>484
たぶんID:EA/Onx+o0はWPFのことをFormsをXMLで記述できるようにしたもの程度の認識なんだろうと思う
たぶんID:EA/Onx+o0はWPFのことをFormsをXMLで記述できるようにしたもの程度の認識なんだろうと思う
493デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/29(日) 20:33:25.70ID:EA/Onx+o0 >>488
> モデル側でコマンドを定義してコントロールにバインドする
そんなことになってんのかよ。
んー、まあ何か理由はあるんだろうけど、格好良すぎて余計に分かりにくくなってる気はするが。
まあいずれにしても俺の勉強不足はそのとおり。俺はWPFはやってないし、今すぐやれる準備もしてないからね。
>>489
だからそもそもマウント取りに来ていると考えているのが間違いなんだよ。
なんで一々そんなことしないといけないんだよ。
> FORTRAN専用のコードじゃない。CやFORTRANで呼び出せる共通バイナリをFORTRANで書いてるの。
おーマジか。知らんかったわ。というかFORTRANのバイナリなんて呼び出そうともしたこと無いし。
してOpenBLAS以外はFORTRANで書かれているのか?
Cじゃねえの?という気はするし、それ以前にアセンブラで書く気はするが。(勿論Cのインラインアセンブラな)
> モデル側でコマンドを定義してコントロールにバインドする
そんなことになってんのかよ。
んー、まあ何か理由はあるんだろうけど、格好良すぎて余計に分かりにくくなってる気はするが。
まあいずれにしても俺の勉強不足はそのとおり。俺はWPFはやってないし、今すぐやれる準備もしてないからね。
>>489
だからそもそもマウント取りに来ていると考えているのが間違いなんだよ。
なんで一々そんなことしないといけないんだよ。
> FORTRAN専用のコードじゃない。CやFORTRANで呼び出せる共通バイナリをFORTRANで書いてるの。
おーマジか。知らんかったわ。というかFORTRANのバイナリなんて呼び出そうともしたこと無いし。
してOpenBLAS以外はFORTRANで書かれているのか?
Cじゃねえの?という気はするし、それ以前にアセンブラで書く気はするが。(勿論Cのインラインアセンブラな)
494デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/29(日) 20:37:07.30ID:EA/Onx+o0 >>491
> 勝ちとか負けとかそんな話してないんですが…
メンドクセエ奴だな、じゃあどう言って欲しかったんだよ?
俺のことをどう見るかは君が決めることであって、俺がどうこう言っても意味無いだろ。
好きにすればいい。
> 勝ちとか負けとかそんな話してないんですが…
メンドクセエ奴だな、じゃあどう言って欲しかったんだよ?
俺のことをどう見るかは君が決めることであって、俺がどうこう言っても意味無いだろ。
好きにすればいい。
495デフォルトの名無しさん (ワッチョイ 6c88-hRE6)
2019/12/29(日) 20:44:08.21ID:RdqvkJW90 >>494
適当な知識を撒き散らし嘘を広めるような言動をやめてほしかったんですよ
適当な知識を撒き散らし嘘を広めるような言動をやめてほしかったんですよ
496デフォルトの名無しさん (ブーイモ MM5a-Wq+o)
2019/12/29(日) 20:44:40.41ID:by75XqYfM >>493
初めの主張を否定されたら「知らんかったわ。だけどこれはどうなの?」とか言って話をずらすのは、
気付いてないのかもしれないが、マウントを取る行為そのもの。
会話をしている相手への礼儀に欠いている。
少なくともFORTRANが現状では死んだ言語だという主張は間違いなわけだ。あんたが呼び出そうとしたこともないかどうかで事実が変わる訳でもない。
やったことない領域は分からないんだと謙虚な態度で考えることがエンジニアリングにおいても人間関係においても大事。
伝聞からの外挿で精度の悪い話を吹聴しても勝てないんだよ。相手は大抵人間じゃないか自分より能力や経験値が高いから。
日常が精度の悪い話で勝てる状況なら、正直その環境を見直した方がいいと思うぞ。低レベルな環境で過ごしてて、知識や技術は身につかないのに歳だけ取るということになるからね。
エンジニアリングを生業にしてないのなら、まあ、趣味の範囲で好きに生きるといいと思うよ。
初めの主張を否定されたら「知らんかったわ。だけどこれはどうなの?」とか言って話をずらすのは、
気付いてないのかもしれないが、マウントを取る行為そのもの。
会話をしている相手への礼儀に欠いている。
少なくともFORTRANが現状では死んだ言語だという主張は間違いなわけだ。あんたが呼び出そうとしたこともないかどうかで事実が変わる訳でもない。
やったことない領域は分からないんだと謙虚な態度で考えることがエンジニアリングにおいても人間関係においても大事。
伝聞からの外挿で精度の悪い話を吹聴しても勝てないんだよ。相手は大抵人間じゃないか自分より能力や経験値が高いから。
日常が精度の悪い話で勝てる状況なら、正直その環境を見直した方がいいと思うぞ。低レベルな環境で過ごしてて、知識や技術は身につかないのに歳だけ取るということになるからね。
エンジニアリングを生業にしてないのなら、まあ、趣味の範囲で好きに生きるといいと思うよ。
497デフォルトの名無しさん (ブーイモ MM5a-Wq+o)
2019/12/29(日) 20:52:25.70ID:by75XqYfM >>496
マウント行為の重要なところが抜けてた。、他人を信者呼ばわりしたり、専門的にやってる人を「馬鹿共」と言ったり「分からないだろうけど」「知らないんだろうけれど」と決めつけたり、
なんの根拠もなしに他人を下に見て一方的な勝利宣言をするこれらの発言、マウント以外になんか理由があるのかい?
マウント行為の重要なところが抜けてた。、他人を信者呼ばわりしたり、専門的にやってる人を「馬鹿共」と言ったり「分からないだろうけど」「知らないんだろうけれど」と決めつけたり、
なんの根拠もなしに他人を下に見て一方的な勝利宣言をするこれらの発言、マウント以外になんか理由があるのかい?
498デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/29(日) 20:52:59.69ID:EA/Onx+o0 >>495
嘘は広めてないだろ。
俺は俺の見解を述べてるだけで、間違いはその都度認めてるつもりだが。
俺は広報しているのではなく、会話をしているだけだ。
紛らわしいから白黒正せ、というのがあれば、一々挙げてくれたら回答するが。
既に言ったがunityにはPython(というかスクリプト)は来ないだろう、というのは君の見解の方が正しいだろう。
嘘は広めてないだろ。
俺は俺の見解を述べてるだけで、間違いはその都度認めてるつもりだが。
俺は広報しているのではなく、会話をしているだけだ。
紛らわしいから白黒正せ、というのがあれば、一々挙げてくれたら回答するが。
既に言ったがunityにはPython(というかスクリプト)は来ないだろう、というのは君の見解の方が正しいだろう。
499デフォルトの名無しさん (ワッチョイ 6c88-hRE6)
2019/12/29(日) 21:03:21.41ID:RdqvkJW90 >>498
広めるような、ね。
知識が無いのに明言してんじゃん
知識ある人がちょっと突っ込むだけで破綻するのになんで適当なこと言ったの?
知らないなら質問するだけにするか始めから触れなきゃ良いだけなのに
俺は突っ込めんがfortranもwpfも同じ流れじゃん
突っ込めない人間から見れば真実に見えかねない
広めるような、ね。
知識が無いのに明言してんじゃん
知識ある人がちょっと突っ込むだけで破綻するのになんで適当なこと言ったの?
知らないなら質問するだけにするか始めから触れなきゃ良いだけなのに
俺は突っ込めんがfortranもwpfも同じ流れじゃん
突っ込めない人間から見れば真実に見えかねない
500デフォルトの名無しさん (ワッチョイ 3ab9-JRPA)
2019/12/29(日) 21:08:15.64ID:poQrkzj50 ここの書き込み毎日凄いね。
ついてけね〜
C++のめんどくさいから来たから有用な書き込み求むわ。
ついてけね〜
C++のめんどくさいから来たから有用な書き込み求むわ。
501デフォルトの名無しさん (ワッチョイ d87b-Zxhf)
2019/12/29(日) 21:09:38.83ID:YKlCMf1b0 >>500
ここ質問スレのふらっとの隔離スレだから有用な書き込みなんか期待するのが間違い
ここ質問スレのふらっとの隔離スレだから有用な書き込みなんか期待するのが間違い
502デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/29(日) 21:15:40.85ID:EA/Onx+o0 >>496
> 少なくともFORTRANが現状では死んだ言語だという主張は間違いなわけだ。
そんなことはない。というかマジでこれは止めろ。
現状のHPCはどう見てもAI/MLであって、そこが環境を用意していない以上、死んだも同然だ。
君はCOBOLを現役だ、と言っているに等しい。(いや、アセンブラが現役だ、の方が近いか?)
若い研究者が今からFORTRANに賭けたらいきなり死ぬんだから、こんな事を言ってはいけない。
君こそ、
> 手続き型言語だったら考え方は大して変わらないからね。
というのならさっさとCに乗り換えるべきで、今の若手にはCを強制すべきだ。
まあ君がFORTRAN使いでカチンと来ているのは分かったが、しかしさすがに今の若手に
> FORTRANが主役 (>>459)
はマジで止めろ。
というか君の発言は「FORTRAN信者」と言われても全く文句言えないレベルだと思うが。
>>497
して
> と、説明しても意味分からんと思うけど、多分やれば分かるよ。 (>>481)
は馬鹿にしてないだろ。こんな説明では説明がイマイチで分からないのは当然だけど、やれば分かる、と言っているだけだ。
まあそれ以外は馬鹿にしているのも多々あるが、それは本当に馬鹿にすべきだからだよ。
例えば、「Web系の馬鹿共」、実際に行ってCSSのページとか見てみればいい。
そこじゃねえんだよ、ってところで頑張ってて、肝心のそこだよ、ってところが抜けてるんだよ。
だから本当にWeb系は玉石混淆(といえばよく聞こえるが、ほぼゴミ)なんだよ。
これは事実だし、実際Web系は馬鹿にされまくってるだろ。PHPerとか特に。
それは馬鹿にされるだけの理由が確かにあるんだよ。(これも本当に、見れば分かるよ。
なお俺はPHPerは過小評価されすぎで、むしろJavaScripterの方が問題だと思っている)
ただし上手いところは本当に上手くCSSを使い、
え?この関数しかないの?こんなんで出来るの?スゲー、みたいな構造になってたりする。
そういうところは勿論馬鹿にしてないし、するはずもない。
要は、馬鹿だから馬鹿にする、というだけの話で、それ以上でもそれ以下でもないし、
それが俺は匿名掲示板のいいところだと思っている。
> 少なくともFORTRANが現状では死んだ言語だという主張は間違いなわけだ。
そんなことはない。というかマジでこれは止めろ。
現状のHPCはどう見てもAI/MLであって、そこが環境を用意していない以上、死んだも同然だ。
君はCOBOLを現役だ、と言っているに等しい。(いや、アセンブラが現役だ、の方が近いか?)
若い研究者が今からFORTRANに賭けたらいきなり死ぬんだから、こんな事を言ってはいけない。
君こそ、
> 手続き型言語だったら考え方は大して変わらないからね。
というのならさっさとCに乗り換えるべきで、今の若手にはCを強制すべきだ。
まあ君がFORTRAN使いでカチンと来ているのは分かったが、しかしさすがに今の若手に
> FORTRANが主役 (>>459)
はマジで止めろ。
というか君の発言は「FORTRAN信者」と言われても全く文句言えないレベルだと思うが。
>>497
して
> と、説明しても意味分からんと思うけど、多分やれば分かるよ。 (>>481)
は馬鹿にしてないだろ。こんな説明では説明がイマイチで分からないのは当然だけど、やれば分かる、と言っているだけだ。
まあそれ以外は馬鹿にしているのも多々あるが、それは本当に馬鹿にすべきだからだよ。
例えば、「Web系の馬鹿共」、実際に行ってCSSのページとか見てみればいい。
そこじゃねえんだよ、ってところで頑張ってて、肝心のそこだよ、ってところが抜けてるんだよ。
だから本当にWeb系は玉石混淆(といえばよく聞こえるが、ほぼゴミ)なんだよ。
これは事実だし、実際Web系は馬鹿にされまくってるだろ。PHPerとか特に。
それは馬鹿にされるだけの理由が確かにあるんだよ。(これも本当に、見れば分かるよ。
なお俺はPHPerは過小評価されすぎで、むしろJavaScripterの方が問題だと思っている)
ただし上手いところは本当に上手くCSSを使い、
え?この関数しかないの?こんなんで出来るの?スゲー、みたいな構造になってたりする。
そういうところは勿論馬鹿にしてないし、するはずもない。
要は、馬鹿だから馬鹿にする、というだけの話で、それ以上でもそれ以下でもないし、
それが俺は匿名掲示板のいいところだと思っている。
503デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/29(日) 21:23:23.75ID:EA/Onx+o0 >>499
> 突っ込めない人間から見れば真実に見えかねない
だから具体的にどれについてだ?
真実に見えかねないから全部訂正して回れ、というのなら、一々挙げろ。対応はする。
単に黙れ、というだけなら、お前が去れ。
ここは自由に意見を述べられる場所であって、それ以上でも以下でもない。
意見を自由に述べる以上、全部「正しい」なんて事にはならない。
というか、仮に全部「正しい」のであれば、そもそも議論が成立しない。
だから、俺の見解が間違っているというのなら、その意見を具体的に述べろと言っている。
そして必要なら俺は訂正する、とも言っている。
というのは>>498で述べたとおりの内容であって、お前が分からないようだから一端咀嚼したが、
無限ループするようならもう無視するから、その辺よろしく。
> 突っ込めない人間から見れば真実に見えかねない
だから具体的にどれについてだ?
真実に見えかねないから全部訂正して回れ、というのなら、一々挙げろ。対応はする。
単に黙れ、というだけなら、お前が去れ。
ここは自由に意見を述べられる場所であって、それ以上でも以下でもない。
意見を自由に述べる以上、全部「正しい」なんて事にはならない。
というか、仮に全部「正しい」のであれば、そもそも議論が成立しない。
だから、俺の見解が間違っているというのなら、その意見を具体的に述べろと言っている。
そして必要なら俺は訂正する、とも言っている。
というのは>>498で述べたとおりの内容であって、お前が分からないようだから一端咀嚼したが、
無限ループするようならもう無視するから、その辺よろしく。
504デフォルトの名無しさん (ワッチョイ 6c88-hRE6)
2019/12/29(日) 21:36:21.89ID:RdqvkJW90 >>503
突っ込めない人間が居ない話題についてはどう訂正なんかするんだよって話だよ
君の無知からくる発言全てにその分野の知識ある人間からツッコミ入れさせるの?
始めから知らん内容を推測で発言すべきじゃないと言ってんの
間違ってるなら訂正してやるから教えろ
じゃなくて間違ってる可能性の高い内容を流布すんなって話
無闇に手を広げずに自分が話せる内容に留めておけ
知見を広げたいための会話ならそうなるようなレスをしろ
突っ込めない人間が居ない話題についてはどう訂正なんかするんだよって話だよ
君の無知からくる発言全てにその分野の知識ある人間からツッコミ入れさせるの?
始めから知らん内容を推測で発言すべきじゃないと言ってんの
間違ってるなら訂正してやるから教えろ
じゃなくて間違ってる可能性の高い内容を流布すんなって話
無闇に手を広げずに自分が話せる内容に留めておけ
知見を広げたいための会話ならそうなるようなレスをしろ
505デフォルトの名無しさん (ワッチョイ 3868-K0SF)
2019/12/29(日) 21:52:09.23ID:cgMj5yHh0 もー放っておけよ
こんだけデタラメ積み重ねてりゃ内容わからん人間でも
他人をディベートごっこに巻き込んでるだけで
なにひとつ言ってることが信用できないと既に印象付いてるから大丈夫だよ
1を聞いて-10を語るキチガイ相手じゃまともな方が何も得るもの無さすぎてかわいそうだわ
こんだけデタラメ積み重ねてりゃ内容わからん人間でも
他人をディベートごっこに巻き込んでるだけで
なにひとつ言ってることが信用できないと既に印象付いてるから大丈夫だよ
1を聞いて-10を語るキチガイ相手じゃまともな方が何も得るもの無さすぎてかわいそうだわ
506デフォルトの名無しさん (アウアウウー Sab5-655U)
2019/12/29(日) 21:54:28.45ID:axIq/xVYa これ数日前にusingウゼーとかゴネてた人?w
なんかすごい執念だね
でも結局何が言いたいんだろうw
なんかすごい執念だね
でも結局何が言いたいんだろうw
507デフォルトの名無しさん (ワッチョイ 8e7b-0Y9p)
2019/12/29(日) 21:57:34.59ID:4DsKC9Uu0 中身のない長文かけたら作文楽だったんだろうなあ
508デフォルトの名無しさん (アウアウウー Sab5-655U)
2019/12/29(日) 21:59:52.09ID:axIq/xVYa >>508
そうそう、書くんだったら普通に英文和訳の方が力が伸びますね、そもそも嘘は書けないし
そうそう、書くんだったら普通に英文和訳の方が力が伸びますね、そもそも嘘は書けないし
510デフォルトの名無しさん (ワッチョイ 4697-esi/)
2019/12/29(日) 23:12:04.78ID:ecPco4090 >>502
数値計算屋がFortranを捨てるべき3つの理由
(リンクがRock54で貼れないので、ググってくれ)
今でもこんな記事が書かれるほど、現場ではFORTRANが使われているということだろ。
自分はFORTRANはほとんど書いたことはないし、Cなんて当然のように使ってるし、人に教えるのならPythonだ。
(なぜ手続き型言語だとCなのかも謎だが)
FORTRAN使いとかいうのもお得意の決めつけなわけよ。
HPCはどう見てもAI/MLというのは、根拠がどこかにある話なのかな。よく知らないので否定しないので教えてくれ。HPCをどういう意味として使っているのかも教えてくれ。
数値計算屋がFortranを捨てるべき3つの理由
(リンクがRock54で貼れないので、ググってくれ)
今でもこんな記事が書かれるほど、現場ではFORTRANが使われているということだろ。
自分はFORTRANはほとんど書いたことはないし、Cなんて当然のように使ってるし、人に教えるのならPythonだ。
(なぜ手続き型言語だとCなのかも謎だが)
FORTRAN使いとかいうのもお得意の決めつけなわけよ。
HPCはどう見てもAI/MLというのは、根拠がどこかにある話なのかな。よく知らないので否定しないので教えてくれ。HPCをどういう意味として使っているのかも教えてくれ。
511デフォルトの名無しさん (ワッチョイ 4697-esi/)
2019/12/29(日) 23:13:45.21ID:ecPco4090 >>502
「説明しても意味分からんと思うけど」
は、通常「説明しても(お前が馬鹿だから)意味が分からないと思うけど」と解釈される。馬鹿にする意図がないなら「この説明では伝わらないかもしれないが」のように書くべきだろう。
また、Web系が馬鹿にされるべき理由があろうとも、その理由が会話の内容と関係のないものなら無文脈に馬鹿にすべきじゃないだろう。
レッテル貼りして否定して回るのは紛れもないマウンティングなんだよ。
マウンティングする気がないのなら、発言の仕方に気をつけよう。端的に言ってあんたの発言は精度も態度も雑すぎて、聞き手に対して無礼極まりない。いくら内容が正しくても相手の機嫌を損ねてまともに聞いてもらえないぞ。
そんな奴は知に対して素直じゃない、とか思うかもしれないが、知に対して素直になりたいのなら、知以外の部分で余計なマイナスの修飾をすべきじゃない。
504とは違う意味になるが、「知見を広げたいための会話ならそうなるようなレスをしろ」というのはそのとおりだ。
中学生とかじゃなくてもういい大人なんだろうから、態度についてちょっとでも意見されたときに、脊髄反射的に否定するんじゃなくて、
一旦自分にそういうところは本当にあっただろうか、メタな視点で振り返ることができるようになろうよ。
それをした上で自分の行為はマウンティングじゃない、と客観的な言葉で説明できるのならそれはそれで良いからさ。
「説明しても意味分からんと思うけど」
は、通常「説明しても(お前が馬鹿だから)意味が分からないと思うけど」と解釈される。馬鹿にする意図がないなら「この説明では伝わらないかもしれないが」のように書くべきだろう。
また、Web系が馬鹿にされるべき理由があろうとも、その理由が会話の内容と関係のないものなら無文脈に馬鹿にすべきじゃないだろう。
レッテル貼りして否定して回るのは紛れもないマウンティングなんだよ。
マウンティングする気がないのなら、発言の仕方に気をつけよう。端的に言ってあんたの発言は精度も態度も雑すぎて、聞き手に対して無礼極まりない。いくら内容が正しくても相手の機嫌を損ねてまともに聞いてもらえないぞ。
そんな奴は知に対して素直じゃない、とか思うかもしれないが、知に対して素直になりたいのなら、知以外の部分で余計なマイナスの修飾をすべきじゃない。
504とは違う意味になるが、「知見を広げたいための会話ならそうなるようなレスをしろ」というのはそのとおりだ。
中学生とかじゃなくてもういい大人なんだろうから、態度についてちょっとでも意見されたときに、脊髄反射的に否定するんじゃなくて、
一旦自分にそういうところは本当にあっただろうか、メタな視点で振り返ることができるようになろうよ。
それをした上で自分の行為はマウンティングじゃない、と客観的な言葉で説明できるのならそれはそれで良いからさ。
512デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/30(月) 01:03:51.03ID:y1laSdPm0 >>510
> HPCをどういう意味
HighPerformaceComputingだよ。普通に使われてる言葉だ。
> HPCはどう見てもAI/ML
むしろ今それ以外どこだと言うんだ?俺は君がここに疑問を持つことが疑問だが。
> HPCをどういう意味
HighPerformaceComputingだよ。普通に使われてる言葉だ。
> HPCはどう見てもAI/ML
むしろ今それ以外どこだと言うんだ?俺は君がここに疑問を持つことが疑問だが。
513デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/30(月) 01:04:22.43ID:y1laSdPm0 >>511
どうでもいいわ。ここはお前の日本語力の養成所ではない。
その後に「多分やれば分かるよ」と続けているのだから、
普通に読めばある程度相手の技術力に信頼を置いていることは明白だし、
仮にそれが君みたいに誤読してかってに切れられたとしてもマジで割とどうでもいい。
ついでに言うと、誤読でなく、実際に俺の人格が糞で切れていたとしても、どうでもいい。
マウンティングだと取りたければ取ればいい。
ただ、俺は君自身が「本当の議論」をしたことがないだけだと思う。
君が議論に人格を持ち込む奴なのは>>489が端的だし、それ以前から色々におわしていた。
君はリアルでもそういう議論『ごっこ』をして、反対意見を『年長者』という勢いで潰してきているのだろう。
が、そもそも俺は話者の人格なんて見てないし、興味もない。
そしていくら人格について言われても、意見を引っ込める気はない。
それとこれとは全く別だからだ。
俺はこのスタンスでずっと続けているが、繰り返すがそもそも俺は相手の人格になんて興味なく、
相手が技術的に糞だった場合はズタボロに言うものの、こちらが間違いなら普通に負けを認めてるから、
そもそも相手の技術力が高い場合にはさほど衝突しない。
だから俺はこれで全く問題ないし、ここではこのスタンスが最適だと経験的に結論づけてる。
当初は確かに俺も丁寧にやってたが、結局それだと馬鹿が図に乗るだけで収拾がつかなくなるだけだった。
馬鹿に優しいと、馬鹿にとっての楽園になってしまって、余計に馬鹿が集まる循環にしかならなかった。
だから馬鹿は叩かれるべきだし、当然俺が馬鹿だと思えば叩いて来ればいい。
そうして馬鹿はたたき出される、ということにしないと、匿名掲示板の健全さは保てない、と知った。
そしてお前らが技術的に叩けなくなったら「人格ガー」と言い出すのも理解している。
どうでもいいわ。ここはお前の日本語力の養成所ではない。
その後に「多分やれば分かるよ」と続けているのだから、
普通に読めばある程度相手の技術力に信頼を置いていることは明白だし、
仮にそれが君みたいに誤読してかってに切れられたとしてもマジで割とどうでもいい。
ついでに言うと、誤読でなく、実際に俺の人格が糞で切れていたとしても、どうでもいい。
マウンティングだと取りたければ取ればいい。
ただ、俺は君自身が「本当の議論」をしたことがないだけだと思う。
君が議論に人格を持ち込む奴なのは>>489が端的だし、それ以前から色々におわしていた。
君はリアルでもそういう議論『ごっこ』をして、反対意見を『年長者』という勢いで潰してきているのだろう。
が、そもそも俺は話者の人格なんて見てないし、興味もない。
そしていくら人格について言われても、意見を引っ込める気はない。
それとこれとは全く別だからだ。
俺はこのスタンスでずっと続けているが、繰り返すがそもそも俺は相手の人格になんて興味なく、
相手が技術的に糞だった場合はズタボロに言うものの、こちらが間違いなら普通に負けを認めてるから、
そもそも相手の技術力が高い場合にはさほど衝突しない。
だから俺はこれで全く問題ないし、ここではこのスタンスが最適だと経験的に結論づけてる。
当初は確かに俺も丁寧にやってたが、結局それだと馬鹿が図に乗るだけで収拾がつかなくなるだけだった。
馬鹿に優しいと、馬鹿にとっての楽園になってしまって、余計に馬鹿が集まる循環にしかならなかった。
だから馬鹿は叩かれるべきだし、当然俺が馬鹿だと思えば叩いて来ればいい。
そうして馬鹿はたたき出される、ということにしないと、匿名掲示板の健全さは保てない、と知った。
そしてお前らが技術的に叩けなくなったら「人格ガー」と言い出すのも理解している。
514デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/30(月) 01:05:20.88ID:y1laSdPm0 もう一度言う、「FORTRANが主流だ」(>>438)という嘘を平気でつくのは止めろ。
本当にそれは害悪だ。俺の人格云々ではなく、そっちの方が大問題だ。
これは見解の相違とかではなく、事実をねじ曲げてるレベルだからだ。
が、これ以上はどう見ても水掛け論だから、一応纏めておく。
君
・スーパーコンピュータで科学技術計算する分野では今でもFORTRANが主役(>>438)
理由はOpenBLASの実装がFORTRANで書かれているから(>>441)
俺
・FORTRANなんぞとっくに死んでる
理由は現在のHPCの主戦場であるAI/MLの中心に位置するCUDA/TensorFlow等に於いて
FORTRANはそもそもプロットフォームとして提供することすら議論されていない。
(ただしCUDAにはたまたま勝手ポートをした会社があり、それを買収して公式化されたので使えるが)
これをどちらが正しいと取るかは読者の判断だ。
技術的内容より人格だ、と思うのならそれでいいし、逆に、俺の人格は糞でも筋は通っている、と思うのも自由だ。
本当にそれは害悪だ。俺の人格云々ではなく、そっちの方が大問題だ。
これは見解の相違とかではなく、事実をねじ曲げてるレベルだからだ。
が、これ以上はどう見ても水掛け論だから、一応纏めておく。
君
・スーパーコンピュータで科学技術計算する分野では今でもFORTRANが主役(>>438)
理由はOpenBLASの実装がFORTRANで書かれているから(>>441)
俺
・FORTRANなんぞとっくに死んでる
理由は現在のHPCの主戦場であるAI/MLの中心に位置するCUDA/TensorFlow等に於いて
FORTRANはそもそもプロットフォームとして提供することすら議論されていない。
(ただしCUDAにはたまたま勝手ポートをした会社があり、それを買収して公式化されたので使えるが)
これをどちらが正しいと取るかは読者の判断だ。
技術的内容より人格だ、と思うのならそれでいいし、逆に、俺の人格は糞でも筋は通っている、と思うのも自由だ。
515デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/30(月) 01:06:18.52ID:y1laSdPm0 >>504
そもそもそのスタンスが間違ってるんだよ。
発言の自由があるということは、結果的に間違っている発言もある程度存在することを許容しないといけないし、
そもそもここは学校のように「正しい知識を教えてくれる場所」ではない。
勝手に各自が発言した内容を、自身で精査して、どれが正しそうかを君自身が掴み取らなければならない。
それに君が人格フィルターを使うのも自由だし、それ以外を使うのも自由だけど、
いずれにしても君自身が「精査」出来ないのなら、ここを使って「正しい」知識を得るのは無理だ。
俺は意図的に間違いを言っているつもりはない。
だから間違っていると思うなら突っ込んでくれればいいし、勿論ブッ叩いてくるのもありだし、放置ならそれでもいい。
ただ、「正しい発言しかするな」は「発言の自由」とは原理的に両立しないし、そもそも俺は一応「正しい」と思って発言している。
だから君の態度がナンセンスなんだよ。
あと、ここはディベートが出来る場所ではない。>>505
あくまでもパネルディスカッションであり、「この問題については俺はこう思う」以上のことは出来ない。
それで複数人から意見を聞いて、どれが正しいかを判断するのは読者自身だ。それは読者の責任であり、俺の責任ではない。
繰り返すが、俺は一応正しいと思って言っているし、同様に、間違いだと思うことには噛みついている。
それが俺の責任範囲であり、それ以上のことは出来ない。
各意見を並べた上で、どれを採るかを決めるのは、読者の判断であり、俺はそれに関与出来ない。
俺は人格者だからーみたいなことを言う気も毛頭無い。俺の発言を全て読んだ上で、君がどう判断するかは、君の自由だ。
この態度に徹しきれないのは、君たちが議論慣れしてないからだ。それは自覚した方がいい。
>>464,487
巻き込んで申し訳なかった。
ただ申し訳ないが、俺にはそれに答えられる知識がない。
タイミングが悪かったのはそちらの責任ではあるが、流し去ってしまったことについては謝っておく。
そもそもそのスタンスが間違ってるんだよ。
発言の自由があるということは、結果的に間違っている発言もある程度存在することを許容しないといけないし、
そもそもここは学校のように「正しい知識を教えてくれる場所」ではない。
勝手に各自が発言した内容を、自身で精査して、どれが正しそうかを君自身が掴み取らなければならない。
それに君が人格フィルターを使うのも自由だし、それ以外を使うのも自由だけど、
いずれにしても君自身が「精査」出来ないのなら、ここを使って「正しい」知識を得るのは無理だ。
俺は意図的に間違いを言っているつもりはない。
だから間違っていると思うなら突っ込んでくれればいいし、勿論ブッ叩いてくるのもありだし、放置ならそれでもいい。
ただ、「正しい発言しかするな」は「発言の自由」とは原理的に両立しないし、そもそも俺は一応「正しい」と思って発言している。
だから君の態度がナンセンスなんだよ。
あと、ここはディベートが出来る場所ではない。>>505
あくまでもパネルディスカッションであり、「この問題については俺はこう思う」以上のことは出来ない。
それで複数人から意見を聞いて、どれが正しいかを判断するのは読者自身だ。それは読者の責任であり、俺の責任ではない。
繰り返すが、俺は一応正しいと思って言っているし、同様に、間違いだと思うことには噛みついている。
それが俺の責任範囲であり、それ以上のことは出来ない。
各意見を並べた上で、どれを採るかを決めるのは、読者の判断であり、俺はそれに関与出来ない。
俺は人格者だからーみたいなことを言う気も毛頭無い。俺の発言を全て読んだ上で、君がどう判断するかは、君の自由だ。
この態度に徹しきれないのは、君たちが議論慣れしてないからだ。それは自覚した方がいい。
>>464,487
巻き込んで申し訳なかった。
ただ申し訳ないが、俺にはそれに答えられる知識がない。
タイミングが悪かったのはそちらの責任ではあるが、流し去ってしまったことについては謝っておく。
516デフォルトの名無しさん (ワッチョイ 4d63-hRE6)
2019/12/30(月) 01:20:14.54ID:oG91u3Zf0 >>515
515の2行目を読んでから514の1行目読んでみなよw
常に正しい情報しか発信しないが理想論でしか無いのは当然
だからといって間違った情報を流布していい免罪符にはならない
間違ってないことが望ましいしそうなるように努めるべき
君のレスはどれも適当に言いくるめようと自身に都合の良いような情報を作っているように見える
事実unityで適当こいたしwpf周りも相当怪しい
fortranは俺にはさっぱりだがこの流れなら君の意見に対する信頼度は皆無
君は自分が正しいと思っていると言うがもう少し自身のハードルをあげたほうが良い
usingの頃からあらゆる方面についてさんざんツッコミを受けているんだから
515の2行目を読んでから514の1行目読んでみなよw
常に正しい情報しか発信しないが理想論でしか無いのは当然
だからといって間違った情報を流布していい免罪符にはならない
間違ってないことが望ましいしそうなるように努めるべき
君のレスはどれも適当に言いくるめようと自身に都合の良いような情報を作っているように見える
事実unityで適当こいたしwpf周りも相当怪しい
fortranは俺にはさっぱりだがこの流れなら君の意見に対する信頼度は皆無
君は自分が正しいと思っていると言うがもう少し自身のハードルをあげたほうが良い
usingの頃からあらゆる方面についてさんざんツッコミを受けているんだから
517デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/30(月) 02:05:00.30ID:y1laSdPm0 >>516
何度も言っているが、君がそう判断するならそれでいい。
ただ俺は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には、でしかないよ。
何度も言っているが、君がそう判断するならそれでいい。
ただ俺は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には、でしかないよ。
518デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/30(月) 02:17:14.52ID:y1laSdPm0 >>516
> 515の2行目を読んでから514の1行目読んでみなよw
あ?ダブスタって話か?
なら俺は「分かり切っている嘘には噛みつく」という、君の言う
> 間違ってないことが望ましいしそうなるように努めるべき
をやってるだけだな。それでどっちが間違っているかを判断するのは君の責任だ。
さっぱりなら、「こういう事があった」ということだけ覚えていればいい。
そして後日、分かるようになったときに思い出したら、ああ、そういうことだったのか、でいい。
相手が言うことを止めることは無理だから、精々こちらは噛みつくことしか出来ない。
それで判断が保留されるのなら、それでも及第点ではある。
それが俺の精一杯だよ。
> 515の2行目を読んでから514の1行目読んでみなよw
あ?ダブスタって話か?
なら俺は「分かり切っている嘘には噛みつく」という、君の言う
> 間違ってないことが望ましいしそうなるように努めるべき
をやってるだけだな。それでどっちが間違っているかを判断するのは君の責任だ。
さっぱりなら、「こういう事があった」ということだけ覚えていればいい。
そして後日、分かるようになったときに思い出したら、ああ、そういうことだったのか、でいい。
相手が言うことを止めることは無理だから、精々こちらは噛みつくことしか出来ない。
それで判断が保留されるのなら、それでも及第点ではある。
それが俺の精一杯だよ。
519デフォルトの名無しさん (アウアウウー Sab5-655U)
2019/12/30(月) 02:59:24.65ID:IsEWodDca >>517
割り込んで申し訳ないけどusingについては結構奇妙なこと言ってると思うよw
まず、コンピュータのリソースには希少どころか物理デバイスみたいに排他的にしか
利用できないものもあるので、解放されるタイミングをプログラマが制御できないのは困ると思うよ。
非同期メソッドがあるC#ならなおさら「メソッドのスコープを抜けたら解放」なんてそんないい加減な話困っちゃうでしょw
次に、希少なリソースを握ってるオブジェクトだからってそれを戻り値にできないような言語、
普通は使いたくないのでは?その制約はどういう利益のための代償ですか?w
こういうの「倒錯」って言うんだと思うよw
強迫神経症ともいうねw
そもそも大して冗長でもないusuingを目障りだ、という問題意識が恐らく盛大に間違っているんだと思うけどw
割り込んで申し訳ないけどusingについては結構奇妙なこと言ってると思うよw
まず、コンピュータのリソースには希少どころか物理デバイスみたいに排他的にしか
利用できないものもあるので、解放されるタイミングをプログラマが制御できないのは困ると思うよ。
非同期メソッドがあるC#ならなおさら「メソッドのスコープを抜けたら解放」なんてそんないい加減な話困っちゃうでしょw
次に、希少なリソースを握ってるオブジェクトだからってそれを戻り値にできないような言語、
普通は使いたくないのでは?その制約はどういう利益のための代償ですか?w
こういうの「倒錯」って言うんだと思うよw
強迫神経症ともいうねw
そもそも大して冗長でもないusuingを目障りだ、という問題意識が恐らく盛大に間違っているんだと思うけどw
520デフォルトの名無しさん (ワッチョイ f12d-vQnI)
2019/12/30(月) 05:35:58.11ID:TxCLIlob0 Qiitaでやれ
521デフォルトの名無しさん (ワッチョイ 4697-esi/)
2019/12/30(月) 07:15:03.12ID:tsk9MmEe0 >>512
AI/MLはHPC分野で新たにシェアが伸びた分野ではあると思うが、
今までの数値シミュレーションだって当然需要がなくなるわけもなく、HPC分野の大きな一ジャンルだろう。
"High Performance Computing (HPC) on Azure"というページをググって見てくれ。AI/MLとは別に項目になっているのだから、
AI/MLに食われるような存在ではないということだろう。
そして、根拠を示してくれと言ったのだがそこはスルーなのな。
その根拠を示さない限りは、
>>514の言説の仮定の一つとなっている、「HPCは科学技術計算ではなくAI/MLである」の正しさが検証できず、
HPCでFORTRANなんか使われてない、は示せない。AI/MLではFORTRANなんか使われてない、としか言ってないだろう。
事実を捻じ曲げている、というのなら、明確な根拠をどうぞ。
>>513
あんたの大層な論の細部がめちゃくちゃだからツッコミを入れると、「信者」だの「知らないだけ」だの言って
ズレた反応を示しながら相手の発言と自分の知識の間違ったところのすり合わせをしないから「人格に問題がある」って言ってるんだよ。
端的に言うと、「馬鹿って言ってるけどお前のほうが〇〇の理由で馬鹿だぞ」と言われたときに、「〇〇は果たして間違っていただろうか?」と考えず、
「いや、やっぱりお前のほうが馬鹿」ってのを繰り返してるんだよ。思い込みを指摘されて、根拠はあるの?と言われてもまだ思い込みで返してくる。
少なくとも調べなおそうよ。
もう、技術的にあんたの経験不足、知識不足を指摘するのは諦めてるんだけど、あんたは人を馬鹿にできるほど経験も知識もない。
WindowsのGUIアプリはなんでもかんでもブラウザベースでOK、とか、インターネットにつながってない環境は考慮する必要ない、とか、
そりゃそういう世界もあって良いけど、そうじゃない世界もあって、そこでは通用しない考え方なんだよ。
自分の考えが通用しないからって、「そんな世界はない」と言ってるようだけれども、事実そんな世界はあるんだよ。
仕事でそんな世界にアプリを納品する必要があったら、ブラウザベースじゃないGUIアプリを作るとか、
インターネットに繋がってなくても当然のように使える開発プラットフォームを使うとか、別の方法をとるまでだ。
ちなみにSIerではないからね。設計から実装まで任されててもたまにそういうところはある。
そんなときにあんただったらどうするんだい?「こんな馬鹿な環境では仕事してらんないから辞めてやる!」のか?
AI/MLはHPC分野で新たにシェアが伸びた分野ではあると思うが、
今までの数値シミュレーションだって当然需要がなくなるわけもなく、HPC分野の大きな一ジャンルだろう。
"High Performance Computing (HPC) on Azure"というページをググって見てくれ。AI/MLとは別に項目になっているのだから、
AI/MLに食われるような存在ではないということだろう。
そして、根拠を示してくれと言ったのだがそこはスルーなのな。
その根拠を示さない限りは、
>>514の言説の仮定の一つとなっている、「HPCは科学技術計算ではなくAI/MLである」の正しさが検証できず、
HPCでFORTRANなんか使われてない、は示せない。AI/MLではFORTRANなんか使われてない、としか言ってないだろう。
事実を捻じ曲げている、というのなら、明確な根拠をどうぞ。
>>513
あんたの大層な論の細部がめちゃくちゃだからツッコミを入れると、「信者」だの「知らないだけ」だの言って
ズレた反応を示しながら相手の発言と自分の知識の間違ったところのすり合わせをしないから「人格に問題がある」って言ってるんだよ。
端的に言うと、「馬鹿って言ってるけどお前のほうが〇〇の理由で馬鹿だぞ」と言われたときに、「〇〇は果たして間違っていただろうか?」と考えず、
「いや、やっぱりお前のほうが馬鹿」ってのを繰り返してるんだよ。思い込みを指摘されて、根拠はあるの?と言われてもまだ思い込みで返してくる。
少なくとも調べなおそうよ。
もう、技術的にあんたの経験不足、知識不足を指摘するのは諦めてるんだけど、あんたは人を馬鹿にできるほど経験も知識もない。
WindowsのGUIアプリはなんでもかんでもブラウザベースでOK、とか、インターネットにつながってない環境は考慮する必要ない、とか、
そりゃそういう世界もあって良いけど、そうじゃない世界もあって、そこでは通用しない考え方なんだよ。
自分の考えが通用しないからって、「そんな世界はない」と言ってるようだけれども、事実そんな世界はあるんだよ。
仕事でそんな世界にアプリを納品する必要があったら、ブラウザベースじゃないGUIアプリを作るとか、
インターネットに繋がってなくても当然のように使える開発プラットフォームを使うとか、別の方法をとるまでだ。
ちなみにSIerではないからね。設計から実装まで任されててもたまにそういうところはある。
そんなときにあんただったらどうするんだい?「こんな馬鹿な環境では仕事してらんないから辞めてやる!」のか?
522デフォルトの名無しさん (ブーイモ MM5e-7Yd4)
2019/12/30(月) 09:16:55.19ID:bS1/9EJkM 年末に何やってんだ君たち暇なの?
家族や友人とは交流しないの?
家族や友人とは交流しないの?
523デフォルトの名無しさん (ワッチョイ df01-qwE9)
2019/12/30(月) 09:58:05.51ID:EEF4A29R0 中途半端な知識で何とか丸め込もう、話を付け替えて何とかしようとするから長文になる
わかってる人は、核心付くだけで済むから短文で済む
長くコンピュータに関わってたら、それぞれ皆わかってる程度の内容を書き連ねて暇だね〜
えっ!? 君園児? それなら凄いわ
わかってる人は、核心付くだけで済むから短文で済む
長くコンピュータに関わってたら、それぞれ皆わかってる程度の内容を書き連ねて暇だね〜
えっ!? 君園児? それなら凄いわ
524デフォルトの名無しさん (アウアウウー Sab5-655U)
2019/12/30(月) 10:14:08.57ID:enwINxmVa 何でもブラウザでできる時代になる論は20年前にも10年前にあったw
これ数年前にも書いたけど、そういうドリーマーにGMailやOutllook.comのUIが
どう見えているのか興味はあるねw
何年たってもどっか使いづらいままだよねw
UIの使い辛さ以上の利便性があるから使われているだけのことで
これ数年前にも書いたけど、そういうドリーマーにGMailやOutllook.comのUIが
どう見えているのか興味はあるねw
何年たってもどっか使いづらいままだよねw
UIの使い辛さ以上の利便性があるから使われているだけのことで
525デフォルトの名無しさん (ワッチョイ e25e-CmeR)
2019/12/30(月) 10:31:39.03ID:duSdEw3c0 outlookのWebUIは最近の365だと割とまともじゃないか?
使えない機能が多いのは確かに考えもんだけど。
使えない機能が多いのは確かに考えもんだけど。
526デフォルトの名無しさん (アウアウウー Sa83-BCWm)
2019/12/30(月) 10:36:33.41ID:5236BLqUa 今のOutlookのUIってクライアント版もかなりWeb寄りになってるから、その気になればWebベースでも十分再現できそう
プログラマにとって最も馴染みの深いツールの一つであるテキストエディタがVSCodeでWebベースになった時点で、もう言い訳はきかんよ
プログラマにとって最も馴染みの深いツールの一つであるテキストエディタがVSCodeでWebベースになった時点で、もう言い訳はきかんよ
527デフォルトの名無しさん (ワッチョイ d81b-hoej)
2019/12/30(月) 17:39:30.58ID:sCWLu8Vm0 using はユージングって読む人が多いけど、ついウシングって読んでしまう。VBのときのストラコンブとかと同じような感覚で
528デフォルトの名無しさん (ワッチョイ ac63-RbSw)
2019/12/30(月) 17:49:06.40ID:ATxCdpD+0 その読み方はした事ないけど自分の中で使っちゃうやつってのはあるね
charは脳内だといつもチャー読みだわ
charは脳内だといつもチャー読みだわ
529デフォルトの名無しさん (ワッチョイ 29ad-WVy2)
2019/12/30(月) 19:59:49.22ID:87J66wvt0 気絶するほど悩ましいな
530デフォルトの名無しさん (スフッ Sd94-hoej)
2019/12/30(月) 20:29:05.94ID:5ZlpxjqAd char は敢えてシャアと読むべきだね
https://marycore.jp/programmer/char-aznable-type/
https://marycore.jp/programmer/char-aznable-type/
531デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/30(月) 20:43:25.72ID:y1laSdPm0 >>521
いやもうお前はいいよ。
前半はどういう論理でどう白黒つけたいのかさっぱり分からんし、後半は要するに俺への文句だろ。
君の中では俺は糞という結論が出ているのだし、それでいい。
それを周りの人がどう取るかも含めて読者の自由だ。
俺は技術論しかする気ないんだよ。
一応OpenBLAS見てみたんだが、やっぱFORTRANが生きているとは言い難いぞ。
アーキ毎に高速化されてる奴はkernelの中に入っているが、アセンブラとCしかない。
高速化されてない奴は確かにFORTRANの実装を呼んでるっぽいので、
実際に呼ばれるFORTRAN/C/アセンブラの割合がどれくらいかと、
最近他にFORTRANで改訂された物がどれくらいあるかだね。
つってもBLASの作りだと、単なる(FORTRANで書かれた)アセンブラライブラリでしかない。
現役だというのならまずその上位コードがFORTRANで書かれてないといけない。
いやもうお前はいいよ。
前半はどういう論理でどう白黒つけたいのかさっぱり分からんし、後半は要するに俺への文句だろ。
君の中では俺は糞という結論が出ているのだし、それでいい。
それを周りの人がどう取るかも含めて読者の自由だ。
俺は技術論しかする気ないんだよ。
一応OpenBLAS見てみたんだが、やっぱFORTRANが生きているとは言い難いぞ。
アーキ毎に高速化されてる奴はkernelの中に入っているが、アセンブラとCしかない。
高速化されてない奴は確かにFORTRANの実装を呼んでるっぽいので、
実際に呼ばれるFORTRAN/C/アセンブラの割合がどれくらいかと、
最近他にFORTRANで改訂された物がどれくらいあるかだね。
つってもBLASの作りだと、単なる(FORTRANで書かれた)アセンブラライブラリでしかない。
現役だというのならまずその上位コードがFORTRANで書かれてないといけない。
532デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/30(月) 20:43:49.47ID:y1laSdPm0 なお論調がまた勘違いして読み間違っているようだからもう一度はっきり言っておくと、
俺は君の意見なんて全く認めてないし、FORTRANは死んでると今も認識してる。
そしてお前は本当に議論が出来ないようだが、お前が今やるべきは、
A. 俺の『意見』を否定することにより、俺の『意見』を無効化する
B. 俺の『人格』を否定することにより、ここの人格重視の馬鹿C#er共と一緒に喚き立てて俺の発言全てを無効化したことにする
ではなくて、
C. 君の意見を補強する材料を提示して、俺の意見を木っ端微塵にする
なんだよ。お前みたいな議論が出来ない馬鹿はAやBにこだわるのが常だけど、
それだと、-1が0にしかならず、結果、その議論は何も得る物が無く、結論も出ない。
そうではなく、やるべきはCであって、+10とかぶっちぎってしまうことであり、
それが出来れば俺が-20とか出さないと勝てなくなるんだよ。
議論は足の引っ張り合いではなく、突っ張りあいをやるべきなんだよ。
お前は最新のプラットフォームで相手にもされてないのがどれだけのことなのか理解出来ないのか?
そしてこれを越える材料を持って来いと言ってるんだよ。
なおお前が実際にFORTRANでスパコン使いまくってる、というのなら俺にブチ切れるのも分かるが、
そうでないと言うのだから、ここにこだわる理由も分からんがな。
そして材料が無いなら、蒸し返そうが何しようがそれ以上話は進みようがないだろ。
「FORTRANが主役」「FORTRANはもう死んでる」で読者に判断を委ねるで済ませられない理由は?
> 別に項目になっているのだから、
> AI/MLに食われるような存在ではないということだろう。
お前はそもそも「スパコン」が何か理解出来てないようだが、何故ここまでこだわる?
俺は君の意見なんて全く認めてないし、FORTRANは死んでると今も認識してる。
そしてお前は本当に議論が出来ないようだが、お前が今やるべきは、
A. 俺の『意見』を否定することにより、俺の『意見』を無効化する
B. 俺の『人格』を否定することにより、ここの人格重視の馬鹿C#er共と一緒に喚き立てて俺の発言全てを無効化したことにする
ではなくて、
C. 君の意見を補強する材料を提示して、俺の意見を木っ端微塵にする
なんだよ。お前みたいな議論が出来ない馬鹿はAやBにこだわるのが常だけど、
それだと、-1が0にしかならず、結果、その議論は何も得る物が無く、結論も出ない。
そうではなく、やるべきはCであって、+10とかぶっちぎってしまうことであり、
それが出来れば俺が-20とか出さないと勝てなくなるんだよ。
議論は足の引っ張り合いではなく、突っ張りあいをやるべきなんだよ。
お前は最新のプラットフォームで相手にもされてないのがどれだけのことなのか理解出来ないのか?
そしてこれを越える材料を持って来いと言ってるんだよ。
なおお前が実際にFORTRANでスパコン使いまくってる、というのなら俺にブチ切れるのも分かるが、
そうでないと言うのだから、ここにこだわる理由も分からんがな。
そして材料が無いなら、蒸し返そうが何しようがそれ以上話は進みようがないだろ。
「FORTRANが主役」「FORTRANはもう死んでる」で読者に判断を委ねるで済ませられない理由は?
> 別に項目になっているのだから、
> AI/MLに食われるような存在ではないということだろう。
お前はそもそも「スパコン」が何か理解出来てないようだが、何故ここまでこだわる?
「FORTRAN」「求人」でたくさん引っかかるのですが
本当に FORTRAN は死んだのでしょうか?
本当に FORTRAN は死んだのでしょうか?
534デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/30(月) 20:57:59.29ID:y1laSdPm0 >>533
お前にレスするのは不本意だが、なかなか良いツッコミだ。
が、俺は
> あれはスパコンのCOBOL扱いになってるはずだが。
> (もしかしてベクトルはFORTRANしか受け付けないのかな?これはあり得るが) (>>439)
と既に言ってるだろ。
COBOLなら求人があるのは分かるよな?そういうことだ。
http://labs.timedia.co.jp/2017/06/gnufortran.html
お前にレスするのは不本意だが、なかなか良いツッコミだ。
が、俺は
> あれはスパコンのCOBOL扱いになってるはずだが。
> (もしかしてベクトルはFORTRANしか受け付けないのかな?これはあり得るが) (>>439)
と既に言ってるだろ。
COBOLなら求人があるのは分かるよな?そういうことだ。
http://labs.timedia.co.jp/2017/06/gnufortran.html
535デフォルトの名無しさん (ワッチョイ 412f-fJ/L)
2019/12/30(月) 21:35:10.50ID:EmtYQ5a60 最新、トップシェア以外のものは死んでるという前提の理論はいらん
536デフォルトの名無しさん (ササクッテロ Spea-hLsL)
2019/12/30(月) 21:44:50.82ID:XBOZEUQCp いやスパコン言ってるなら既に出されてる京のpdfを否定する資料をまず出せば?
相手にされてないってものCUDA Fortranで自分で否定してるし
なんか対等にやりあってる風を装ってるけど
既に木っ端微塵されたところから全然建て直しできてねえぞ?
相手にされてないってものCUDA Fortranで自分で否定してるし
なんか対等にやりあってる風を装ってるけど
既に木っ端微塵されたところから全然建て直しできてねえぞ?
537デフォルトの名無しさん (ワッチョイ bade-zEes)
2019/12/30(月) 22:05:30.33ID:uKQ1L5j80538デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/30(月) 22:13:55.24ID:y1laSdPm0 まあFORTRANの話はいずれにしてもスレチだし、俺も終わりでいい。
ただお前らが思っている世界とスパコン界隈は全然状況が違うが、
それにしても興味もないだろうし、お前らに俺が間違っているとされても俺は問題ないので。
ただ、俺の話を少しでも信じる気があれば、
「FORTRANなんて既に死んでる」と言っていた奴が居たことを頭に留めておいて欲しい。
そしてもしなにか機会が発生したら、その時に俺が言っていたことを吟味してくれればいい。
それだけで、だいぶ違うはずだから。
ただお前らが思っている世界とスパコン界隈は全然状況が違うが、
それにしても興味もないだろうし、お前らに俺が間違っているとされても俺は問題ないので。
ただ、俺の話を少しでも信じる気があれば、
「FORTRANなんて既に死んでる」と言っていた奴が居たことを頭に留めておいて欲しい。
そしてもしなにか機会が発生したら、その時に俺が言っていたことを吟味してくれればいい。
それだけで、だいぶ違うはずだから。
539デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/30(月) 22:16:46.91ID:y1laSdPm0 >>519
そう思うならそれでよし。
君は今の.NETの実装、つまり俺の纏めた 2 が妥当だと思ってるんだろ?
ならそう言えばいいだけ。
余分な人格評価とかすると(一般的には)君の評判自体も落ちると思うぜ。
そこも含めて自由にすればいいとも思うが。
> そもそも大して冗長でもないusuingを目障りだ、という問題意識が恐らく盛大に間違っている
これはちょっと違ってな、というか俺も以前は今の君のように何も考えずに「書くものだ」で書いてたんだけど、
それだと「書ける人」にしかならないんだよ。
ただの1行、ただの1ステートメントですら、
「本当にこれ必要なのか?無くすことは出来ないのか?」と考えないと、本当に余分のないコードにはならない。
ジョブスがやってた、「ボタンは一つにしろ」と同じだよ。
コードは、書くよりも、削る方が難しいし、削るときに腕前は上達する。
というのは以下のどこかにあったはずだが、出てこない。が、まあ、実感としてこれは当たってる。
https://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/
ググってたら出てきたからついでに
何事においても、完璧に到達するのは、 付け加えるものが何もなくなったときではなく、 削るものが何もなくなったときである。 (アントワーヌ・ド・サン=テグジュペリ)
そう思うならそれでよし。
君は今の.NETの実装、つまり俺の纏めた 2 が妥当だと思ってるんだろ?
ならそう言えばいいだけ。
余分な人格評価とかすると(一般的には)君の評判自体も落ちると思うぜ。
そこも含めて自由にすればいいとも思うが。
> そもそも大して冗長でもないusuingを目障りだ、という問題意識が恐らく盛大に間違っている
これはちょっと違ってな、というか俺も以前は今の君のように何も考えずに「書くものだ」で書いてたんだけど、
それだと「書ける人」にしかならないんだよ。
ただの1行、ただの1ステートメントですら、
「本当にこれ必要なのか?無くすことは出来ないのか?」と考えないと、本当に余分のないコードにはならない。
ジョブスがやってた、「ボタンは一つにしろ」と同じだよ。
コードは、書くよりも、削る方が難しいし、削るときに腕前は上達する。
というのは以下のどこかにあったはずだが、出てこない。が、まあ、実感としてこれは当たってる。
https://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/
ググってたら出てきたからついでに
何事においても、完璧に到達するのは、 付け加えるものが何もなくなったときではなく、 削るものが何もなくなったときである。 (アントワーヌ・ド・サン=テグジュペリ)
540デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/30(月) 22:21:24.79ID:y1laSdPm0 >>524
どっちが優れていたとしても、優れていた方がパクられて、最終的に同じUIになるのは確実だろ。
区別する意味ないと思うが。
ただ俺が言っているのは、君が勝手に想像しているそれではない。
俺は単に、
・HTMLの方がUIが作りやすい
と言っている。
例えば00年代初頭にはJavaでクライアントアプリを作って配布することもあった(と聞く)勤怠アプリ、
今ではWebアプリ一択だろ。これには、君らは
1. デプロイの手間がない
2. 鯖にデータが勝手に溜まる
だけだと思っているのだろうけど、俺は、
3. GUIを作るのが楽
がでかいと思っている。
そしてそれがデスクトップに出てきたのがelectronだ。当然1,2の利点はなく、3だけで勝負してる。
ならなんでUIが糞なのさ、というのは言ってしまえばWeb系のデザイナのセンスが糞だからだろ。
フラットデザインが糞なのは、マルチデバイス優先で手抜きされてるからのようだが。
> しかし、もっとも大きな理由は「マルチデバイスへの対応に最適だから」と言えます。
https://webbu.jp/flatdesign-2762
どっちが優れていたとしても、優れていた方がパクられて、最終的に同じUIになるのは確実だろ。
区別する意味ないと思うが。
ただ俺が言っているのは、君が勝手に想像しているそれではない。
俺は単に、
・HTMLの方がUIが作りやすい
と言っている。
例えば00年代初頭にはJavaでクライアントアプリを作って配布することもあった(と聞く)勤怠アプリ、
今ではWebアプリ一択だろ。これには、君らは
1. デプロイの手間がない
2. 鯖にデータが勝手に溜まる
だけだと思っているのだろうけど、俺は、
3. GUIを作るのが楽
がでかいと思っている。
そしてそれがデスクトップに出てきたのがelectronだ。当然1,2の利点はなく、3だけで勝負してる。
ならなんでUIが糞なのさ、というのは言ってしまえばWeb系のデザイナのセンスが糞だからだろ。
フラットデザインが糞なのは、マルチデバイス優先で手抜きされてるからのようだが。
> しかし、もっとも大きな理由は「マルチデバイスへの対応に最適だから」と言えます。
https://webbu.jp/flatdesign-2762
541デフォルトの名無しさん (ササクッテロ Spea-hLsL)
2019/12/30(月) 22:44:33.73ID:XBOZEUQCp 散々中立ぶっててこの未練がましさはさすがに草
無能さをさも自分がニュートラルであると振る舞って誤魔化す手合いだな
もうちっとまともな化けの皮を被れ
無能さをさも自分がニュートラルであると振る舞って誤魔化す手合いだな
もうちっとまともな化けの皮を被れ
542デフォルトの名無しさん (ワッチョイ df01-qwE9)
2019/12/30(月) 23:05:34.31ID:EEF4A29R0 コンピュータ関係者向けの漫談ぶっこんで、盛大に白けて終わったな
543デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/30(月) 23:16:18.62ID:y1laSdPm0 >>541
メンドクセエ奴だな。
TensorFlowは既に言ったろ。>>445
ついでにTPUも確認してみた。>>456
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/
メンドクセエ奴だな。
TensorFlowは既に言ったろ。>>445
ついでにTPUも確認してみた。>>456
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/
544デフォルトの名無しさん (ワッチョイ 9b02-DZC8)
2019/12/30(月) 23:20:33.54ID:CqEb/nEc0 ヤーッホーフォートランランラン
ヤーッホーフォートランランラン
て歌ってたな。
30年前だけど。
ヤーッホーフォートランランラン
て歌ってたな。
30年前だけど。
545デフォルトの名無しさん (ササクッテロ Spea-hLsL)
2019/12/30(月) 23:50:47.66ID:XBOZEUQCp やっぱり終わらない笑
そしてまた持論の範囲を狭めて説得力ごと削ってゆくスタイルはもはや芸人である
そしてまた持論の範囲を狭めて説得力ごと削ってゆくスタイルはもはや芸人である
546デフォルトの名無しさん (ラクペッ MMb7-f88z)
2019/12/31(火) 02:01:20.46ID:YC1setdFM ガイジの群れ
547デフォルトの名無しさん (ワッチョイ 9cb2-kAdm)
2019/12/31(火) 02:52:44.77ID:R+4lw4Fp0 おまえらいい加減にしないとpythonいっちゃうぞ?
549デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/31(火) 19:20:27.09ID:uqnsAvu+0 >>524
補足。
WPFは糞だが、これは『現在の』HTMLと比べるからであって、
WPFが登場/仕様検討された頃のHTMLと比べればましだと思うよ。
だからMSが間違ったとか技術不足ではなくて、単に、進化の速度が遅いだけ。
それはMSも分かっていて.NETもアーリーリリースに切り替えたけど、それにはお前らは不満たらたらなんだろ?
なおWebの状況は「仕様に採用された!やったぜ!」とか騒いでいたから
(数ヶ月後に)使おうと思ったら未実装で使えないとか、
或いは新規機能もバグってて使い物にならないとか、普通にある。たぶん.NETの方がまだましなんじゃないかな。
ただ、何だかんだで仕様が決まってさえすれば次第に実装はされるから、結果的な進化速度は早くなる。
おかげでWeb系は「この機能は使っていい、これは駄目」みたいな全く無駄な努力を常に強いられる糞環境なものも事実だけど。
でもこの構造だと一度抜かされたら二度と追いつけないんだよ。で、今もうそうなってると思うよ。
そしてWeb系もそんなに勤勉なわけでもないから、WPFを勉強してまでデスクトップアプリを作ろうとはしない。
それは君らがHTMLを勉強してまでWebアプリを作ろうとはしないのと同じように。
だから結果的に分断されていたわけだが、垣根はなくなりつつあるし、そこまで余裕かませる理由が分からんけどね。
C#でちゃんと『プログラミングが出来る』のなら、JavaScriptの修得自体は容易なのは事実だけど、
『.NETを知っているだけ』ならほぼゼロからやり直しだよ。
とはいえ個人的には、既に言ったがPHPerは馬鹿にされすぎてるが実はそこそこ実力はあり、
調子に乗りすぎてるのはJavaScripterで「お前らがやってるのはプログラミングではなく塗り絵だ」のレベルが多いから、
C#erが大量流入して皆殺しにして欲しいのだけど。
補足。
WPFは糞だが、これは『現在の』HTMLと比べるからであって、
WPFが登場/仕様検討された頃のHTMLと比べればましだと思うよ。
だからMSが間違ったとか技術不足ではなくて、単に、進化の速度が遅いだけ。
それはMSも分かっていて.NETもアーリーリリースに切り替えたけど、それにはお前らは不満たらたらなんだろ?
なおWebの状況は「仕様に採用された!やったぜ!」とか騒いでいたから
(数ヶ月後に)使おうと思ったら未実装で使えないとか、
或いは新規機能もバグってて使い物にならないとか、普通にある。たぶん.NETの方がまだましなんじゃないかな。
ただ、何だかんだで仕様が決まってさえすれば次第に実装はされるから、結果的な進化速度は早くなる。
おかげでWeb系は「この機能は使っていい、これは駄目」みたいな全く無駄な努力を常に強いられる糞環境なものも事実だけど。
でもこの構造だと一度抜かされたら二度と追いつけないんだよ。で、今もうそうなってると思うよ。
そしてWeb系もそんなに勤勉なわけでもないから、WPFを勉強してまでデスクトップアプリを作ろうとはしない。
それは君らがHTMLを勉強してまでWebアプリを作ろうとはしないのと同じように。
だから結果的に分断されていたわけだが、垣根はなくなりつつあるし、そこまで余裕かませる理由が分からんけどね。
C#でちゃんと『プログラミングが出来る』のなら、JavaScriptの修得自体は容易なのは事実だけど、
『.NETを知っているだけ』ならほぼゼロからやり直しだよ。
とはいえ個人的には、既に言ったがPHPerは馬鹿にされすぎてるが実はそこそこ実力はあり、
調子に乗りすぎてるのはJavaScripterで「お前らがやってるのはプログラミングではなく塗り絵だ」のレベルが多いから、
C#erが大量流入して皆殺しにして欲しいのだけど。
550デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/31(火) 19:21:12.67ID:uqnsAvu+0 ただ逆に言えば、そんな馬鹿ばっかでも何とかなってしまうのが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の実力なんだよ。
ただし言語としてはかなり最悪の部類であるのも事実だが。
それは構造的に三層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の実力なんだよ。
ただし言語としてはかなり最悪の部類であるのも事実だが。
551デフォルトの名無しさん (ワッチョイ 7f7b-JrBF)
2019/12/31(火) 19:40:51.62ID:uqnsAvu+0 >>548
君は多分狙いすぎてるんだよ。
投稿自体の切れ味は割といいと思うんだけど、『常に』ムカつくタイミングで出てくるから、
イラッとするし、そういうことを狙っている(そういうことしかしない)のだと取られてしまう。
また、大体は議論が紛糾している時であって、
レス付けたら余計に話がおかしくなるから無視するしかない、
みたいなタイミングで『しか』出て来ないのもどうにかしろとは思うよ。
話をしたいのなら、普通に話に混ざった方がいい。
いや俺はツッコミ専門だ、話なんてする気無い、というのならそれも自由だが、それだと今後とも嫌われると思うよ。
ただ俺は君の空気を読まないスタンスは素晴らしいと思う。
そもそもここではネットならではの議論をすべきであって、それは
「ここで突っ込んだら相手の面子丸つぶれだな…でも明らかに間違いだしな…」みたいなところで躊躇する必要がまるでないことであって、
馬鹿がよくやってる罵倒合戦ではないんだよ。
君はこれは完全に出来てて議論慣れしてるところはいいと思うよ。
ただ繰り返すが、話をする気があるのなら、出てくるタイミングが酷すぎる。
君は多分狙いすぎてるんだよ。
投稿自体の切れ味は割といいと思うんだけど、『常に』ムカつくタイミングで出てくるから、
イラッとするし、そういうことを狙っている(そういうことしかしない)のだと取られてしまう。
また、大体は議論が紛糾している時であって、
レス付けたら余計に話がおかしくなるから無視するしかない、
みたいなタイミングで『しか』出て来ないのもどうにかしろとは思うよ。
話をしたいのなら、普通に話に混ざった方がいい。
いや俺はツッコミ専門だ、話なんてする気無い、というのならそれも自由だが、それだと今後とも嫌われると思うよ。
ただ俺は君の空気を読まないスタンスは素晴らしいと思う。
そもそもここではネットならではの議論をすべきであって、それは
「ここで突っ込んだら相手の面子丸つぶれだな…でも明らかに間違いだしな…」みたいなところで躊躇する必要がまるでないことであって、
馬鹿がよくやってる罵倒合戦ではないんだよ。
君はこれは完全に出来てて議論慣れしてるところはいいと思うよ。
ただ繰り返すが、話をする気があるのなら、出てくるタイミングが酷すぎる。
552デフォルトの名無しさん (ワッチョイ dfa9-bj0c)
2019/12/31(火) 21:01:44.58ID:3He7PpF20 長ったらしい説明は要点がボケる傾向にある。
553デフォルトの名無しさん (ワッチョイ f12d-vQnI)
2019/12/31(火) 21:07:56.98ID:KGMG1qTB0 もうあんたら、学歴ジャンケンでどっちが頭がいいのか決着をつけたらどうだ?
それかQiitaに行けよ
それかQiitaに行けよ
554デフォルトの名無しさん (ワッチョイ ef4f-K0SF)
2019/12/31(火) 21:25:28.17ID:YPeginhU0 長文連投キチガイの法則はデスノートなみに正確だということ
555デフォルトの名無しさん (ワッチョイ d81b-hoej)
2019/12/31(火) 23:51:30.11ID:uRSSI5660 今年最後にあぼーんで埋まってゆく…
556デフォルトの名無しさん (ワッチョイ 4d61-N0L+)
2020/01/01(水) 00:38:31.16ID:NLfsRE4W0 そういえば、なぜJavaScriptに初心者が魅了されるのかというと、
コンパイラがなくてもすぐに始められるために、初めて触る言語が
それであることが多く、それに慣れてしまっているからではないかと思う。
しかし、Promise(とasync)の辺りとか、イベントのキャプチャーフレーズ、
ターゲットフレーズ、バブリングフェーズの違いや preventDefault や
stopPropagation を正しく理解するのはかなり難しい。
PromiseとResponceに、ServiceWorkerと responseWith、waitUntil
などの辺りなどは、ちゃんとした仕様が書いてあるサイトを見つけるのすら
難しい。
コンパイラがなくてもすぐに始められるために、初めて触る言語が
それであることが多く、それに慣れてしまっているからではないかと思う。
しかし、Promise(とasync)の辺りとか、イベントのキャプチャーフレーズ、
ターゲットフレーズ、バブリングフェーズの違いや preventDefault や
stopPropagation を正しく理解するのはかなり難しい。
PromiseとResponceに、ServiceWorkerと responseWith、waitUntil
などの辺りなどは、ちゃんとした仕様が書いてあるサイトを見つけるのすら
難しい。
557デフォルトの名無しさん (ワッチョイ 4d61-N0L+)
2020/01/01(水) 00:43:43.30ID:NLfsRE4W0 >>549
なぜ、HTMLアプリが増大しているかの理由については以下も参考になる。
OSとみなした場合に、WindowsやAndoridに比べてシェアが圧倒的に大きいからと考えられるそうだ:
【Wasm】ブラウザをOSとみなすとシェアはTOP
https://medaka.5ch.net/test/read.cgi/prog/1576520355/
なぜ、HTMLアプリが増大しているかの理由については以下も参考になる。
OSとみなした場合に、WindowsやAndoridに比べてシェアが圧倒的に大きいからと考えられるそうだ:
【Wasm】ブラウザをOSとみなすとシェアはTOP
https://medaka.5ch.net/test/read.cgi/prog/1576520355/
558デフォルトの名無しさん (ワッチョイ 797b-s4wZ)
2020/01/01(水) 13:50:13.63ID:6pvjYbyn0 >>556
それもあるが、敷居が低いのは「インタプリタがある」からだよ。PHPもこれがデカい。
C#もあるにはあるようだけど、構造的に本物と全く同一動作というわけには行かないだろうから、ここも本質的に敷居が高くなってる。
https://ufcpp.net/study/csharp/cheatsheet/apscripting/
だたまあ、ある程度慣れれば「インタプリタでのデバッグなんて効率悪すぎ」で使わないのも事実だが。
この意味だとC#やJavaはプロ仕様で、いわゆるスクリプト言語は「アマ向け」なんだけど、
国民総プログラマ時代(俺はこれには大反対だけど)には敷居が低い言語の方が向いているんだよ。
JavaScriptは以前は環境が要らない、というのが大きかったけど、
スマホだと開発者ツールがついてないから以前のようにF12を押すだけ、とは行かない。
一応C#はコンパイラはWindows同梱だし(csc.exe)、ここについては形式的には完了してる。
ただ、HTMLは見た目のインパクトが大きい。例えば、
<img src="xxxx" style="position:fixed">
だけで画像がポップアップする。これは俺には「たったこれだけ?」と衝撃だった。
同様に、他言語/環境から入ったらその簡単さに衝撃を受ける。それくらい簡単さが違う。
それもあるが、敷居が低いのは「インタプリタがある」からだよ。PHPもこれがデカい。
C#もあるにはあるようだけど、構造的に本物と全く同一動作というわけには行かないだろうから、ここも本質的に敷居が高くなってる。
https://ufcpp.net/study/csharp/cheatsheet/apscripting/
だたまあ、ある程度慣れれば「インタプリタでのデバッグなんて効率悪すぎ」で使わないのも事実だが。
この意味だとC#やJavaはプロ仕様で、いわゆるスクリプト言語は「アマ向け」なんだけど、
国民総プログラマ時代(俺はこれには大反対だけど)には敷居が低い言語の方が向いているんだよ。
JavaScriptは以前は環境が要らない、というのが大きかったけど、
スマホだと開発者ツールがついてないから以前のようにF12を押すだけ、とは行かない。
一応C#はコンパイラはWindows同梱だし(csc.exe)、ここについては形式的には完了してる。
ただ、HTMLは見た目のインパクトが大きい。例えば、
<img src="xxxx" style="position:fixed">
だけで画像がポップアップする。これは俺には「たったこれだけ?」と衝撃だった。
同様に、他言語/環境から入ったらその簡単さに衝撃を受ける。それくらい簡単さが違う。
559デフォルトの名無しさん (ワッチョイ 797b-s4wZ)
2020/01/01(水) 13:50:36.93ID:6pvjYbyn0 Promiseは俺に言わせれば完全な糞仕様で、あれは入れるべきではなかった。
C#でasync/awaitだけで問題ないのが分かっていたのに、止めることも出来ず、
今でも「あれがないとasyncが理解出来ない(キリッ」と嘯いて正当化してるわけだが。
JavaScriptは本当に仕様委員会自体が糞で、仕様に政治を持ち込んだりもしてる。(httpSでしか使えない新仕様とかある)
完全に自殺中だ、というのが俺の見方だ。
ただそもそもPromise自体は「非同期を無理に同期的に組む」時に必要なものであって、組み方で回避出来る。
JavaScripterは非同期を極めているつもりの奴が多いが、
JSのは上手く色々省けるようにした「なんちゃって非同期」でしかなく、(これ自体は素晴らしいことだし、大成功だが)
連中はガチの非同期を知らないから、ここら辺を何度説明しても理解出来ない。
まあいずれにしても、ヘルズバーグも「でもPromiseはねーわ」だったし、俺はC#の判断の方が断然正しいと思う。
イベントバブルについては、理解すること自体は簡単だが、
それを上手く利用した構造を作ることは「ちゃんと設計する能力」が必要になる。(そんなに難しくもないと思うが、慣れは必要)
ただ、そこを何も考えない作りの時に威力を発揮するのがjQueryであり、
要はForms同様各GUIコンポーネントにイベントを一々付けていくわけであるが、
これをやってて、そしてまた、それでも問題ない事が多いのもまた事実だよ。
なおこれはWebページのみならず、一般のGUIもそう。
だから.NETはちょっと格好いいところを目指しすぎてて敷居が上がっている、とは思う。
といってもこれはWPFでも技術的には出来ることではあるから、コミュニティ的なもの、
つまりいまだにjQueryみたいな糞を使っていても大して文句を言われない、というところの違いかも。
JavaScriptは一部から生理的に拒絶されていたりするのでelectronも直接の驚異にはならないかもしれない。
パンドラの箱が開くのは、PythonがJS並の速度を持ったときだとは思う。
C#でasync/awaitだけで問題ないのが分かっていたのに、止めることも出来ず、
今でも「あれがないとasyncが理解出来ない(キリッ」と嘯いて正当化してるわけだが。
JavaScriptは本当に仕様委員会自体が糞で、仕様に政治を持ち込んだりもしてる。(httpSでしか使えない新仕様とかある)
完全に自殺中だ、というのが俺の見方だ。
ただそもそもPromise自体は「非同期を無理に同期的に組む」時に必要なものであって、組み方で回避出来る。
JavaScripterは非同期を極めているつもりの奴が多いが、
JSのは上手く色々省けるようにした「なんちゃって非同期」でしかなく、(これ自体は素晴らしいことだし、大成功だが)
連中はガチの非同期を知らないから、ここら辺を何度説明しても理解出来ない。
まあいずれにしても、ヘルズバーグも「でもPromiseはねーわ」だったし、俺はC#の判断の方が断然正しいと思う。
イベントバブルについては、理解すること自体は簡単だが、
それを上手く利用した構造を作ることは「ちゃんと設計する能力」が必要になる。(そんなに難しくもないと思うが、慣れは必要)
ただ、そこを何も考えない作りの時に威力を発揮するのがjQueryであり、
要はForms同様各GUIコンポーネントにイベントを一々付けていくわけであるが、
これをやってて、そしてまた、それでも問題ない事が多いのもまた事実だよ。
なおこれはWebページのみならず、一般のGUIもそう。
だから.NETはちょっと格好いいところを目指しすぎてて敷居が上がっている、とは思う。
といってもこれはWPFでも技術的には出来ることではあるから、コミュニティ的なもの、
つまりいまだにjQueryみたいな糞を使っていても大して文句を言われない、というところの違いかも。
JavaScriptは一部から生理的に拒絶されていたりするのでelectronも直接の驚異にはならないかもしれない。
パンドラの箱が開くのは、PythonがJS並の速度を持ったときだとは思う。
560デフォルトの名無しさん (ワッチョイ 2e10-ZrpS)
2020/01/01(水) 20:06:48.58ID:qG+Zau3f0561デフォルトの名無しさん (ドコグロ MM75-VrsN)
2020/01/02(木) 12:00:38.14ID:TpBXcd1kM562デフォルトの名無しさん (ワッチョイ 797b-s4wZ)
2020/01/02(木) 19:11:21.24ID:FzsUW8F+0 >>561
そりゃTaskも最早ゴミだからだよ。
実際「asyncと書いておけば、後は小さいオッサンが何とかしてくれる」程度の理解で問題ないように出来てるだろ。
C#1.0からasyncだったら神だったろうよ。
そして俺はお前らの「今はもう要らない」仕様についても崇拝を続ける姿勢を信者だと揶揄してるんだよ。
ただJavaSriptのasync/awaitはMS主導なのか?だったらPromiseにこだわるのは政治か。
JavaScriptの仕様委員会は本当にどうしようもないな。
そりゃTaskも最早ゴミだからだよ。
実際「asyncと書いておけば、後は小さいオッサンが何とかしてくれる」程度の理解で問題ないように出来てるだろ。
C#1.0からasyncだったら神だったろうよ。
そして俺はお前らの「今はもう要らない」仕様についても崇拝を続ける姿勢を信者だと揶揄してるんだよ。
ただJavaSriptのasync/awaitはMS主導なのか?だったらPromiseにこだわるのは政治か。
JavaScriptの仕様委員会は本当にどうしようもないな。
563デフォルトの名無しさん (ドコグロ MM75-VrsN)
2020/01/02(木) 19:24:07.49ID:TpBXcd1kM >>562
アホか
C#のasync/awaitがTaskのシンタックスシュガーであるのと同様に、
JavaScriptのasync/awaitもPromiseのシンタックスシュガーに他ならない
そして、あなたが敵視している「JavaScriptの仕様委員会」において仕様策定をリードしているのは紛れもなくMSであり、
あなたの敬愛するヘルスバーグもいわばJavaScriptのパイロット版ともいえるTypeScriptの開発を通じて関わっている
アホか
C#のasync/awaitがTaskのシンタックスシュガーであるのと同様に、
JavaScriptのasync/awaitもPromiseのシンタックスシュガーに他ならない
そして、あなたが敵視している「JavaScriptの仕様委員会」において仕様策定をリードしているのは紛れもなくMSであり、
あなたの敬愛するヘルスバーグもいわばJavaScriptのパイロット版ともいえるTypeScriptの開発を通じて関わっている
564デフォルトの名無しさん (ブーイモ MM62-OcRt)
2020/01/02(木) 19:34:18.12ID:haQBNDzzM 古い技術より新しい技術のほうが優れてるから最初からそっちだったらいいのに、なんて言うのは誰でもできるわな
それと非同期処理はasync/awaitが覇権を握ったけど並列処理でまだまだTaskが現役だぞ
それと非同期処理はasync/awaitが覇権を握ったけど並列処理でまだまだTaskが現役だぞ
565デフォルトの名無しさん (ワッチョイ 2e63-QvtZ)
2020/01/02(木) 19:52:10.23ID:9KDR5rd70 Taskイラネって、WaitAllみたいなユースケースは頭にないんだろうな
障害児はプログラミングなんかしなくていいんだぜ
迷惑だからな
新海面処分場に自主的に向かってくれや生ゴミ
障害児はプログラミングなんかしなくていいんだぜ
迷惑だからな
新海面処分場に自主的に向かってくれや生ゴミ
566デフォルトの名無しさん (ワッチョイ 2e1b-MkYf)
2020/01/02(木) 20:25:41.97ID:HeIctSc70567デフォルトの名無しさん (ワッチョイ 06ad-IH4P)
2020/01/02(木) 20:32:51.61ID:cbHiY2pH0 プログラミングしてないから、Taskが必要なケースも知らないんじゃない?
568デフォルトの名無しさん (ワッチョイ 797b-s4wZ)
2020/01/02(木) 20:58:20.51ID:FzsUW8F+0 >>563
そりゃお前のスタンスがおかしい。敵視とかそういう問題ではない。
俺はゴミをゴミだと言ってるだけ。いい仕様を制定出来てれば褒めてるよ。
逆にお前らはポジショントークしかしてないだろ。
つまりC#を使ってるから(どんな糞仕様であっても)C#は素晴らしい、でしかない。それを信者だと言ってるんだよ。
比較的C#はマシなのは事実だが、全部素晴らしいわけもない。
>>565
それもPromise擁護のお約束だが、
asyncで済む場合にほぼ全員がasyncを選択する時点でPromiseはゴミでしかないよ。
だからPromiseにはそれ以外の機能もあるもん!というわけだが、
実際Promiseが無くても書けるし、難しくもないし、必要な時もそうないだろ。
○と○をくっつけたらチョー便利!なんてのはよく初心者がやってるが、それと同レベルだよ。
そりゃお前のスタンスがおかしい。敵視とかそういう問題ではない。
俺はゴミをゴミだと言ってるだけ。いい仕様を制定出来てれば褒めてるよ。
逆にお前らはポジショントークしかしてないだろ。
つまりC#を使ってるから(どんな糞仕様であっても)C#は素晴らしい、でしかない。それを信者だと言ってるんだよ。
比較的C#はマシなのは事実だが、全部素晴らしいわけもない。
>>565
それもPromise擁護のお約束だが、
asyncで済む場合にほぼ全員がasyncを選択する時点でPromiseはゴミでしかないよ。
だからPromiseにはそれ以外の機能もあるもん!というわけだが、
実際Promiseが無くても書けるし、難しくもないし、必要な時もそうないだろ。
○と○をくっつけたらチョー便利!なんてのはよく初心者がやってるが、それと同レベルだよ。
569デフォルトの名無しさん (ワッチョイ 797b-s4wZ)
2020/01/02(木) 20:58:47.18ID:FzsUW8F+0 >>564
その通りだ。だから俺の方がヘルスバーグより賢いなんて言う気もないし、実際言ってもないだろ。
ただ、だからといって、古い技術の方がよかった、なんて事にもならないんだよ。
ゴミはゴミだと正しく認識するべき。
> 並列処理
元々の問題はC#が即時関数(ラムダ)を軽視してたことだろう。
とはいえC#は対応も他言語(C++/Java)と比べて早かったのも事実だが。
確かに並列に関しては今後とも残るかもしれん。
ただC#がTaskを用意したのは「UIコンポーネントはUIスレッドで」という.NETフレームワークの思想の為であり、
俺はこれがそもそも疑問なんだがな。GUIはタスクランチャーだと割り切り、
・GUIからの呼び出しは「新規スレッド」か「UIスレッド」か選べるようにする。
・UIコンポーネントはどのスレッドからでもいじれるようにする。
・そこで競合するなら自前で同期化機構を書け
でよかったと思うし、実際これで当初「Task素晴らしい!」みたいなことを言われていたのは大体解決出来るだろ。
要は「重いジョブ」「そのGUI出力」を同じ関数内に記述したいけど、それは「.NETフレームワーク的には出来ない」だけであって、
自分でおかしな縛りを導入して、それに対する解を用意してって、マッチポンプでしかないだろ。
ただまあ、馬鹿が多いようなので無駄に噛みつかれないようにもう一度言っておくと、
確かに並列用途にはTaskは残るかもしれんね。
だからといってPromiseがいいって事にもならんが。
その通りだ。だから俺の方がヘルスバーグより賢いなんて言う気もないし、実際言ってもないだろ。
ただ、だからといって、古い技術の方がよかった、なんて事にもならないんだよ。
ゴミはゴミだと正しく認識するべき。
> 並列処理
元々の問題はC#が即時関数(ラムダ)を軽視してたことだろう。
とはいえC#は対応も他言語(C++/Java)と比べて早かったのも事実だが。
確かに並列に関しては今後とも残るかもしれん。
ただC#がTaskを用意したのは「UIコンポーネントはUIスレッドで」という.NETフレームワークの思想の為であり、
俺はこれがそもそも疑問なんだがな。GUIはタスクランチャーだと割り切り、
・GUIからの呼び出しは「新規スレッド」か「UIスレッド」か選べるようにする。
・UIコンポーネントはどのスレッドからでもいじれるようにする。
・そこで競合するなら自前で同期化機構を書け
でよかったと思うし、実際これで当初「Task素晴らしい!」みたいなことを言われていたのは大体解決出来るだろ。
要は「重いジョブ」「そのGUI出力」を同じ関数内に記述したいけど、それは「.NETフレームワーク的には出来ない」だけであって、
自分でおかしな縛りを導入して、それに対する解を用意してって、マッチポンプでしかないだろ。
ただまあ、馬鹿が多いようなので無駄に噛みつかれないようにもう一度言っておくと、
確かに並列用途にはTaskは残るかもしれんね。
だからといってPromiseがいいって事にもならんが。
570デフォルトの名無しさん (ワッチョイ e12d-XiJJ)
2020/01/02(木) 21:08:54.36ID:+muZM7K/0 高卒の天才みたいな人はいらないよ
571デフォルトの名無しさん (ワッチョイ c2b9-rouQ)
2020/01/02(木) 21:28:42.78ID:eV/mpEQr0 C#ならではのアプリよろしく。
572デフォルトの名無しさん (ワッチョイ 814f-UAPS)
2020/01/02(木) 21:31:55.72ID:qr+4fHWP0 もしかして「シンタックスシュガー」が理解できてないとか。
573デフォルトの名無しさん (ワッチョイ 06ad-IH4P)
2020/01/02(木) 21:36:12.24ID:cbHiY2pH0 > ・UIコンポーネントはどのスレッドからでもいじれるようにする。
この時点でマルチスレッドプログラミングまともにしたことない感が…
この時点でマルチスレッドプログラミングまともにしたことない感が…
575デフォルトの名無しさん (ブーイモ MMb6-OcRt)
2020/01/02(木) 21:59:18.76ID:PZFQVuh5M 別にUIコンポーネントのためにTaskを用意したわけではないが
576デフォルトの名無しさん (ワッチョイ 42ba-M1Rv)
2020/01/02(木) 22:26:33.22ID:qsQZs66Y0 Task登場前に比べれば段違いで楽になったわけやしな
その後直ぐにasync出たのも時代的に仕方なかったわけで
その後直ぐにasync出たのも時代的に仕方なかったわけで
577デフォルトの名無しさん (ワッチョイ 49a7-HDsw)
2020/01/02(木) 23:06:36.82ID:ZgXvL7GY0 俺がasync/awaitを使うとだいたいハングアップするんだけど
みんなどういう場面で使ってるの?
みんなどういう場面で使ってるの?
578デフォルトの名無しさん (ワッチョイ 797b-s4wZ)
2020/01/02(木) 23:07:01.36ID:FzsUW8F+0 >>573,574
だからそれが俺には謎なんだよ。やれば出来る範囲としか思えない。
実際、お前らが今バインディングしている先も、一々排他チェックなんてしてないだろ。
そもそもGUIではレーシング時には「前の値」でも「後の値」でもどっちでもいいケースでほぼ全部で、
問題のあるところだけmutex等の遅い同期化機構でも全く問題ないんだよ。
MSはGUIがプチフリするのが許せなくて、30秒以上(だったかな?)のジョブをUIスレッドでやったら警告を出し、
他スレに強制移転させたわけだが、その時に仕様的にはそのままGUI出力出来なかったというのが元の問題だろ。
しかし button_onClickに最初から他スレで問題ないし、
そもそもお前らみたいに「DIコンテナが正義」ならどうせStringBuilder/TextBox等に直書きなんてあり得ないのだから、
必要ならDIコンテナ先で排他/同期で全く問題ないし、これの方が実際生産性も高いだろ。
ただこれは俺にとってはかねてからの疑問で、これを5chで言うのも初めてではない。
他言語、例えばJavaScriptも形式は違うが一応「UIはシングルスレッド」になっているので、何かあったのだとは思う。
色々聞いた限り、Javaで昔マルチスレッドなGUIがあって、盛大にそこでやらかしたから、
それ以降はシングルスレッドなのだ、との説を聞いたのだけど、これについて知っている奴はいるか?
ただそれにしても、その時はマルチスレッドにみんな慣れていなかったからであって、今なら普通にこなせるとも思うが。
>>575
ではなんだよ?
並列処理、というのは後付だと思うが。
だからそれが俺には謎なんだよ。やれば出来る範囲としか思えない。
実際、お前らが今バインディングしている先も、一々排他チェックなんてしてないだろ。
そもそもGUIではレーシング時には「前の値」でも「後の値」でもどっちでもいいケースでほぼ全部で、
問題のあるところだけmutex等の遅い同期化機構でも全く問題ないんだよ。
MSはGUIがプチフリするのが許せなくて、30秒以上(だったかな?)のジョブをUIスレッドでやったら警告を出し、
他スレに強制移転させたわけだが、その時に仕様的にはそのままGUI出力出来なかったというのが元の問題だろ。
しかし button_onClickに最初から他スレで問題ないし、
そもそもお前らみたいに「DIコンテナが正義」ならどうせStringBuilder/TextBox等に直書きなんてあり得ないのだから、
必要ならDIコンテナ先で排他/同期で全く問題ないし、これの方が実際生産性も高いだろ。
ただこれは俺にとってはかねてからの疑問で、これを5chで言うのも初めてではない。
他言語、例えばJavaScriptも形式は違うが一応「UIはシングルスレッド」になっているので、何かあったのだとは思う。
色々聞いた限り、Javaで昔マルチスレッドなGUIがあって、盛大にそこでやらかしたから、
それ以降はシングルスレッドなのだ、との説を聞いたのだけど、これについて知っている奴はいるか?
ただそれにしても、その時はマルチスレッドにみんな慣れていなかったからであって、今なら普通にこなせるとも思うが。
>>575
ではなんだよ?
並列処理、というのは後付だと思うが。
579デフォルトの名無しさん (ブーイモ MMb6-OcRt)
2020/01/02(木) 23:48:39.72ID:PZFQVuh5M >>578
マルチスレッドとマルチスレッド以外のあらゆる非同期、並列処理を統一的に扱うための抽象化だよ
歴史的な経緯で非同期、並列処理のやり方がマチマチでわかりにくかったからTaskにまとめた
これにより雑魚プログラマでも簡単に安全にイイカンジに最適化された非同期、並列処理を実装できるようになった
さらに統一的な抽象を得たことによって言語レベルでasync awaitを導入する基礎ができた
UIスレッドなんてのはオマケもいいとこだ
マルチスレッドとマルチスレッド以外のあらゆる非同期、並列処理を統一的に扱うための抽象化だよ
歴史的な経緯で非同期、並列処理のやり方がマチマチでわかりにくかったからTaskにまとめた
これにより雑魚プログラマでも簡単に安全にイイカンジに最適化された非同期、並列処理を実装できるようになった
さらに統一的な抽象を得たことによって言語レベルでasync awaitを導入する基礎ができた
UIスレッドなんてのはオマケもいいとこだ
580デフォルトの名無しさん (ワッチョイ 06ad-IH4P)
2020/01/02(木) 23:59:29.88ID:cbHiY2pH0 >>578
mutexを緻密にやればrace conditionが発生するし、
雑にやればパフォーマンスの低下を引き起こすと思うけど
UIの実装なんてあんまり真剣に考えたくないところなんだから、
別スレッドからUIスレッドへ実行すべきブロックをキューに追加するぐらいが丁度いいと思うが。
逆に、「やれば出来る範囲」と言うけど、実際にUIスレッドをスレッドセーフにしてまともなGUIフレームワークになっているものってあるの?
mutexを緻密にやればrace conditionが発生するし、
雑にやればパフォーマンスの低下を引き起こすと思うけど
UIの実装なんてあんまり真剣に考えたくないところなんだから、
別スレッドからUIスレッドへ実行すべきブロックをキューに追加するぐらいが丁度いいと思うが。
逆に、「やれば出来る範囲」と言うけど、実際にUIスレッドをスレッドセーフにしてまともなGUIフレームワークになっているものってあるの?
581デフォルトの名無しさん (ワッチョイ 06ad-IH4P)
2020/01/03(金) 00:04:21.64ID:jYqYJjY40 すまん、race conditionではなくデッドロックだ
582デフォルトの名無しさん (ワッチョイ 3db2-GLZk)
2020/01/03(金) 00:13:26.64ID:hATKQL5q0 マルチスレッドに分散処理させてた結果を最終的に本体スレッドで受け取る時に、queueで待機させて結局同期的にDBに書き込んでるんだけど、意味あるのかな?
583デフォルトの名無しさん (アウアウウー Saa5-VrsN)
2020/01/03(金) 00:17:52.23ID:O846x913a584デフォルトの名無しさん (ワッチョイ 797b-s4wZ)
2020/01/03(金) 00:48:08.71ID:fU3ErGER0 >>579
俺はそうは思わんね。
> あらゆる非同期、並列処理を統一的に扱うための抽象化
これは単なる「関数」で超大昔に終わってる。
つまり、非同期でも、並列でも、エントリポイントは「関数」であり、つまり渡す物も「関数」であり、
その上の階層で非同期か並列かを選べるのだから、「関数」で抽象化は完成してる。
実際、ちゃんと組んであれば、内部の関数はマルチスレッド/シングルスレッド/同期/非同期のどれで用いるにしても、
一字も変更する必要がなく、変更されるのは最上位での呼び出し方だけだろ。
これが「抽象化」が「関数」で完全に済んでいる証拠。
(というよりは、こうなる為のお作法として「グローバル禁止」等があるわけだが)
async/Taskがいいのは「その場に書ける」「戻り値を取れる」からであり、
抽象化してるとするなら、「同期」と「非同期」を抽象化してる。
(ただしキーワードが必要なので厳密には抽象化出来ているわけではないが)
だから、簡単で直感的な「同期」記述とほぼ同じ記述で「非同期」が出来るから美味しいだけであって、
それ以上でもそれ以下でもない。
そしてC#に非同期が必須みたいになったのはフレームワークの仕様の問題であり、これは回避出来たと思ってる。
俺はそうは思わんね。
> あらゆる非同期、並列処理を統一的に扱うための抽象化
これは単なる「関数」で超大昔に終わってる。
つまり、非同期でも、並列でも、エントリポイントは「関数」であり、つまり渡す物も「関数」であり、
その上の階層で非同期か並列かを選べるのだから、「関数」で抽象化は完成してる。
実際、ちゃんと組んであれば、内部の関数はマルチスレッド/シングルスレッド/同期/非同期のどれで用いるにしても、
一字も変更する必要がなく、変更されるのは最上位での呼び出し方だけだろ。
これが「抽象化」が「関数」で完全に済んでいる証拠。
(というよりは、こうなる為のお作法として「グローバル禁止」等があるわけだが)
async/Taskがいいのは「その場に書ける」「戻り値を取れる」からであり、
抽象化してるとするなら、「同期」と「非同期」を抽象化してる。
(ただしキーワードが必要なので厳密には抽象化出来ているわけではないが)
だから、簡単で直感的な「同期」記述とほぼ同じ記述で「非同期」が出来るから美味しいだけであって、
それ以上でもそれ以下でもない。
そしてC#に非同期が必須みたいになったのはフレームワークの仕様の問題であり、これは回避出来たと思ってる。
585デフォルトの名無しさん (ワッチョイ 06ad-IH4P)
2020/01/03(金) 00:57:27.50ID:jYqYJjY40 >>584
GUIなんて「グローバル変数」の典型例だと思うけど、
設計モチベーションの一つとして、GUIを便利に書く言語となってほしいってのがおそらく合ったと思うけおd、
それでも「回避できた」可能性はあるの?
GUIなんて「グローバル変数」の典型例だと思うけど、
設計モチベーションの一つとして、GUIを便利に書く言語となってほしいってのがおそらく合ったと思うけおd、
それでも「回避できた」可能性はあるの?
586デフォルトの名無しさん (ワッチョイ 797b-s4wZ)
2020/01/03(金) 01:06:44.31ID:fU3ErGER0 >>580
> UIの実装なんてあんまり真剣に考えたくないところなんだから、
これはその通りだ。
> 別スレッドからUIスレッドへ実行すべきブロックをキューに追加するぐらいが丁度いいと思うが。
そしてこれがInvokeというわけか?
まあ.NET的にはそうなのかもしれん。
> 実際にUIスレッドをスレッドセーフにしてまともなGUIフレームワークになっているものってあるの?
知らん。だから聞いている。
無いのは、無い理由があるとは思うのだけど。(そしてそれが、昔Javaで…だと聞いているだけ)
> UIの実装なんてあんまり真剣に考えたくないところなんだから、
これはその通りだ。
> 別スレッドからUIスレッドへ実行すべきブロックをキューに追加するぐらいが丁度いいと思うが。
そしてこれがInvokeというわけか?
まあ.NET的にはそうなのかもしれん。
> 実際にUIスレッドをスレッドセーフにしてまともなGUIフレームワークになっているものってあるの?
知らん。だから聞いている。
無いのは、無い理由があるとは思うのだけど。(そしてそれが、昔Javaで…だと聞いているだけ)
587デフォルトの名無しさん (ワッチョイ 4d61-N0L+)
2020/01/03(金) 01:12:48.79ID:T8mFSGHc0 JavaScriptのPromiseが難しいのは、then のブロック内の最後の行で実行した関数の戻り値が勝手に次のプロミスにチェーンしていくみたいなところ。
ここが難しいのは、JavaScriptには明確な型が無いので公式サイトのサンプルを見ても、関数の戻り値がどんな内容(型)のデータを返しているのか分かりにくいところ。
それぞれの関数のドキュメントを調べてもそれが結局分からない。
同じ関数でも時と場合によって返すデータの型(?)が変わってしまうようなケースすらあるかも知れないし。
いまのところまだ理解できないのは、fetch でResponseオブジェクトを返すような処理。
ドキュメントの説明で、関数のプロトタイプ宣言の様な部分でも型がちゃんと書いてないので理解が難しい。
ここが難しいのは、JavaScriptには明確な型が無いので公式サイトのサンプルを見ても、関数の戻り値がどんな内容(型)のデータを返しているのか分かりにくいところ。
それぞれの関数のドキュメントを調べてもそれが結局分からない。
同じ関数でも時と場合によって返すデータの型(?)が変わってしまうようなケースすらあるかも知れないし。
いまのところまだ理解できないのは、fetch でResponseオブジェクトを返すような処理。
ドキュメントの説明で、関数のプロトタイプ宣言の様な部分でも型がちゃんと書いてないので理解が難しい。
588デフォルトの名無しさん (ワッチョイ 4d61-N0L+)
2020/01/03(金) 01:16:10.63ID:T8mFSGHc0 >>587
みなさん、これをすらすらと理解できますでしょうか?
自分はなかなか理解できません。
https://developer.mozilla.org/ja/docs/Web/API/Fetch_API/Using_Fetch#Response_objects
みなさん、これをすらすらと理解できますでしょうか?
自分はなかなか理解できません。
https://developer.mozilla.org/ja/docs/Web/API/Fetch_API/Using_Fetch#Response_objects
589デフォルトの名無しさん (ワッチョイ 797b-s4wZ)
2020/01/03(金) 01:34:14.56ID:fU3ErGER0 >>585
回避出来たも何も、それ以前にする必要がないんだよ、割と。
例えば>>253,259、画面のGUIコンポーネントを直接参照して動作時は画面ロックの方がよかった、というわけだが、
実際これでも「自家用アプリに簡単にGUIを付けたいだけ」なら全く問題ない。
そして、演算実行中は放置だから、他スレッドとも競合なんてしないんだよ。
格好良くいえば、「運用で回避する」ということになる。
勿論プログラムとしては色々ヤバイが、必要なら真面目に同期取ればいいだけ。
手抜きなら「動作中は触るな」で十分、というわけだ。
クラッシュするのは例えばログ出力用TextBoxに複数から同時に書き込まれた時だが、
そもそもそれは複数出力元がある=複数の計算ルーチンが同時に起動する事が必要で、
全くのGUI初心者が最初に組むアプリではないんだよ。
それを非同期で別スレ起動してInvokeしろとか、かなり敷居を上げてしまってるだろ。
(もっとも、警告を無視してUIスレッドで計算して、当然GUIはフリーズ、みたいなことも出来たが)
回避出来たも何も、それ以前にする必要がないんだよ、割と。
例えば>>253,259、画面のGUIコンポーネントを直接参照して動作時は画面ロックの方がよかった、というわけだが、
実際これでも「自家用アプリに簡単にGUIを付けたいだけ」なら全く問題ない。
そして、演算実行中は放置だから、他スレッドとも競合なんてしないんだよ。
格好良くいえば、「運用で回避する」ということになる。
勿論プログラムとしては色々ヤバイが、必要なら真面目に同期取ればいいだけ。
手抜きなら「動作中は触るな」で十分、というわけだ。
クラッシュするのは例えばログ出力用TextBoxに複数から同時に書き込まれた時だが、
そもそもそれは複数出力元がある=複数の計算ルーチンが同時に起動する事が必要で、
全くのGUI初心者が最初に組むアプリではないんだよ。
それを非同期で別スレ起動してInvokeしろとか、かなり敷居を上げてしまってるだろ。
(もっとも、警告を無視してUIスレッドで計算して、当然GUIはフリーズ、みたいなことも出来たが)
590デフォルトの名無しさん (ブーイモ MMb6-OcRt)
2020/01/03(金) 01:47:00.56ID:VBfxgT36M >>584
超大昔に終わってないから出来損ないのインターフェイスや実装がポンポン出てきて混乱したんだよ
でマイクロソフトが主導してC#における標準的な抽象としてTaskを導入した
プログラマはみんなそれを受け入れてTaskを使うようになった
超大昔に終わってないから出来損ないのインターフェイスや実装がポンポン出てきて混乱したんだよ
でマイクロソフトが主導してC#における標準的な抽象としてTaskを導入した
プログラマはみんなそれを受け入れてTaskを使うようになった
591デフォルトの名無しさん (ワッチョイ 4d61-N0L+)
2020/01/03(金) 01:53:44.42ID:T8mFSGHc0 >>588
追記:
thenブロック内部の関数の戻り値が Response「型」の場合でも、
直後のthenブロック内部の関数の引数が必ずしもResponse「型」ではないこともあるようで、その場合は、型の「自動変換」が行われているのではないかと思えるんです。
C++の場合だとプロトタイプ宣言などの関数宣言があるのでそれが分かり易いのですが、JavaScriptだと本当に型変換が行われているかどうかも不明確で理解が難しくなっています。
仮引数の型に可能性の幅が出てくる可能性があり、結局どのような「型」になっているか分からないので、どのクラス(?)のドキュメントを読んでいいのかも分からないので理解に時間が掛かります。
候補となりそうなクラスや関数の解説文を手当たり次第に読んでみて辻褄の合うようなものを自分なりに見つけてこないといけないようです。
C/C++ではなかった苦労がそこにあります。
追記:
thenブロック内部の関数の戻り値が Response「型」の場合でも、
直後のthenブロック内部の関数の引数が必ずしもResponse「型」ではないこともあるようで、その場合は、型の「自動変換」が行われているのではないかと思えるんです。
C++の場合だとプロトタイプ宣言などの関数宣言があるのでそれが分かり易いのですが、JavaScriptだと本当に型変換が行われているかどうかも不明確で理解が難しくなっています。
仮引数の型に可能性の幅が出てくる可能性があり、結局どのような「型」になっているか分からないので、どのクラス(?)のドキュメントを読んでいいのかも分からないので理解に時間が掛かります。
候補となりそうなクラスや関数の解説文を手当たり次第に読んでみて辻褄の合うようなものを自分なりに見つけてこないといけないようです。
C/C++ではなかった苦労がそこにあります。
592デフォルトの名無しさん (ワッチョイ 8201-TJkF)
2020/01/03(金) 02:26:10.78ID:cSDCrnP10 >>588
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(…);
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(…);
593デフォルトの名無しさん (ワッチョイ 8201-TJkF)
2020/01/03(金) 02:31:11.54ID:cSDCrnP10 >>591
>直後のthenブロック内部の関数の引数が必ずしもResponse「型」ではないこともあるようで
んんん??
thenは2つコールバック関数を引数にとって
一つはresolveした場合、もう一つはrejectされた場合。
fetchが返すpromiseがresolveした場合は必ずResponseオブジェクトじゃないの?
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/then
>直後のthenブロック内部の関数の引数が必ずしもResponse「型」ではないこともあるようで
んんん??
thenは2つコールバック関数を引数にとって
一つはresolveした場合、もう一つはrejectされた場合。
fetchが返すpromiseがresolveした場合は必ずResponseオブジェクトじゃないの?
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/then
>>578
>Javaで昔マルチスレッドなGUIがあって、盛大にそこでやらかしたから、
Java ライブラリの GUI(基本は awt) ってそんなんだったかな…近々 awt を頭から見直そうと思っていますのでそのときに考えて見ます
>Javaで昔マルチスレッドなGUIがあって、盛大にそこでやらかしたから、
Java ライブラリの GUI(基本は awt) ってそんなんだったかな…近々 awt を頭から見直そうと思っていますのでそのときに考えて見ます
595デフォルトの名無しさん (ワッチョイ 06e9-W0QA)
2020/01/03(金) 10:59:52.40ID:3J/SmROP0 javaのフィールドに倣ってプロパティの接頭語にアンダースコアを付けるべきか悩んでいるのですがベテランの皆様はどう思われますか?
596デフォルトの名無しさん (ブーイモ MMb6-OcRt)
2020/01/03(金) 11:03:04.63ID:VBfxgT36M 好きにすればいいよ
どっちでも文法的に正しいし、どっちがより良いかは証明不可能
どっちでも文法的に正しいし、どっちがより良いかは証明不可能
>>595
それはハンガリアン(の一種)といって悪い作法だと思います
それはハンガリアン(の一種)といって悪い作法だと思います
598デフォルトの名無しさん (ワッチョイ 4d61-N0L+)
2020/01/03(金) 14:09:52.04ID:T8mFSGHc0 >>592
A Promise that resolves to a Response object.
この言い回しが分かりにくて
「Responseオブジェクトを解決するところの1つのPromise」
とはコードで書くとどういうPromiseの事を言っているのか分かりません。
A Promise that resolves to a Response object.
この言い回しが分かりにくて
「Responseオブジェクトを解決するところの1つのPromise」
とはコードで書くとどういうPromiseの事を言っているのか分かりません。
599デフォルトの名無しさん (ワッチョイ 4d61-N0L+)
2020/01/03(金) 14:15:20.54ID:T8mFSGHc0 >>598
リンク先にあった、以下のコードを見ればどういうことなのかは大体理解はできそうですが。
「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();
})
リンク先にあった、以下のコードを見ればどういうことなのかは大体理解はできそうですが。
「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();
})
600デフォルトの名無しさん (ワッチョイ 797b-s4wZ)
2020/01/03(金) 15:32:49.36ID:fU3ErGER0 >>590
FrameworkOnFrameworkが日常的になっている時点で、
機能的に足りない=そのFrameworkが糞、なのは明らかだろ。
>>594
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よりは》近い)
FrameworkOnFrameworkが日常的になっている時点で、
機能的に足りない=そのFrameworkが糞、なのは明らかだろ。
>>594
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よりは》近い)
601デフォルトの名無しさん (ワッチョイ 797b-s4wZ)
2020/01/03(金) 15:33:08.37ID:fU3ErGER0 これらやその他の記事を読む限り、
Javaはどうもマルチスレッド周りの問題をまともに解決しに行ったように見える。
時代的に「最先端言語」としての矜持があったのかもしれん。
結果、爆死して今に至るのかも。
例によってデッドロック周りがやたら記述されているが、これに関しては、
折角ポインタを廃止して消し去った、「悪いプログラム片が少し混入しただけでアプリ全体がアウト」
になるCの問題点がそのまま復活してしまうから、Javaとしては絶対に許せない。
かといって、上手い解決策も見つけられてない。
ただ、デッドロックは多分今の若者が教育されているほどには驚異にはならない。
あれはアホみたいに「一つ確保して、その場ですぐ返す」構造にすればそもそも回避出来る。
つまりロック周り自体ではなくて、その上位構造から単純化してしまって解決する方がいいのだけど、
それをしようとはしていない。
逆にそれをしたのが.NETで、言うなれば全部のUIコンポーネントで一つのmutex、
それをUIスレッドが握りつぶす(他に渡さない)から他が触れず、Invokeするしかなくなる。
OOP初心者が訳の分からないクラス構成にすることはよくあるが、同様に、
Javaでマルチスレッド初心者が訳の分からないロック機構(しかもバグってる)を作りまくったのかもしれん。
.NETはそれよりは、仕様的に回りくどい構造になるがアホでも組める方を選んだのだろう。
とはいえそれもFrameworkOnFrameworkしたくなってしまうほど糞で、実際それをやらかし、
Task/asyncで収まった、というのが現在か。(話を総合すると)
歴史の流れとしては極めて妥当なのかもしれん。
Javaはどうもマルチスレッド周りの問題をまともに解決しに行ったように見える。
時代的に「最先端言語」としての矜持があったのかもしれん。
結果、爆死して今に至るのかも。
例によってデッドロック周りがやたら記述されているが、これに関しては、
折角ポインタを廃止して消し去った、「悪いプログラム片が少し混入しただけでアプリ全体がアウト」
になるCの問題点がそのまま復活してしまうから、Javaとしては絶対に許せない。
かといって、上手い解決策も見つけられてない。
ただ、デッドロックは多分今の若者が教育されているほどには驚異にはならない。
あれはアホみたいに「一つ確保して、その場ですぐ返す」構造にすればそもそも回避出来る。
つまりロック周り自体ではなくて、その上位構造から単純化してしまって解決する方がいいのだけど、
それをしようとはしていない。
逆にそれをしたのが.NETで、言うなれば全部のUIコンポーネントで一つのmutex、
それをUIスレッドが握りつぶす(他に渡さない)から他が触れず、Invokeするしかなくなる。
OOP初心者が訳の分からないクラス構成にすることはよくあるが、同様に、
Javaでマルチスレッド初心者が訳の分からないロック機構(しかもバグってる)を作りまくったのかもしれん。
.NETはそれよりは、仕様的に回りくどい構造になるがアホでも組める方を選んだのだろう。
とはいえそれもFrameworkOnFrameworkしたくなってしまうほど糞で、実際それをやらかし、
Task/asyncで収まった、というのが現在か。(話を総合すると)
歴史の流れとしては極めて妥当なのかもしれん。
602デフォルトの名無しさん (ブーイモ MMb6-OcRt)
2020/01/03(金) 15:58:36.89ID:NacIP61HM >>600
君いわく超大昔にとっくに解決したはずのものが現実には多くの糞を生んだ
しかし新たに設けた抽象化であるTaskがそれれらの大部分を解決したということだな
君の言う関数という抽象化は非同期処理の現実には大して役に立たなかった
事実は事実として受け止めたほうがいいよ
君いわく超大昔にとっくに解決したはずのものが現実には多くの糞を生んだ
しかし新たに設けた抽象化であるTaskがそれれらの大部分を解決したということだな
君の言う関数という抽象化は非同期処理の現実には大して役に立たなかった
事実は事実として受け止めたほうがいいよ
603デフォルトの名無しさん (ワッチョイ 797b-s4wZ)
2020/01/03(金) 17:14:48.26ID:fU3ErGER0 >>602
まあ俺のスタンスは変わらんけどな。一応纏めておくと、以下。
・Taskはゴミ。今となっては(非同期には)要らない。
・asyncは「抽象化」ではなく非同期の「記法」。
・asyncにより非同期の煩雑さは解決された。
簡単に記述出来る「記法」が足りなかったのに、非同期強制部分が.NETにあった為に多くの糞を生んだ。
元々はラムダや匿名関数周りが弱かったからであり、これらが最初からあればもうだいぶましだった。
実際、JavaScriptのイベントモデルだと、Taskなんて無くてもC#程酷いことにはならない。
そう出来なかったのはC#の問題であり、(といっても既に解決済みだが)
逆にWeb系は馬鹿でも出来るようになっているからこそ馬鹿が調子こいてる。(簡単なこと自体は素晴らしいことだが)
君がこれらを認めないのは君の自由。
まあ俺のスタンスは変わらんけどな。一応纏めておくと、以下。
・Taskはゴミ。今となっては(非同期には)要らない。
・asyncは「抽象化」ではなく非同期の「記法」。
・asyncにより非同期の煩雑さは解決された。
簡単に記述出来る「記法」が足りなかったのに、非同期強制部分が.NETにあった為に多くの糞を生んだ。
元々はラムダや匿名関数周りが弱かったからであり、これらが最初からあればもうだいぶましだった。
実際、JavaScriptのイベントモデルだと、Taskなんて無くてもC#程酷いことにはならない。
そう出来なかったのはC#の問題であり、(といっても既に解決済みだが)
逆にWeb系は馬鹿でも出来るようになっているからこそ馬鹿が調子こいてる。(簡単なこと自体は素晴らしいことだが)
君がこれらを認めないのは君の自由。
604デフォルトの名無しさん (ブーイモ MMb6-OcRt)
2020/01/03(金) 17:23:20.75ID:RiNqytdzM 多くのケースでasyncawaitでコーディングしたほうが簡単だがTaskが要らないわけではない
並列処理では相変わらずTaskが活躍している
またasyncawaitを実装するためにはTaskという抽象が必要だった
関数で抽象は完結してるなどとトンチンカンなことを主張して思考停止していたらasyncawaitの発明には到達できなかった
並列処理では相変わらずTaskが活躍している
またasyncawaitを実装するためにはTaskという抽象が必要だった
関数で抽象は完結してるなどとトンチンカンなことを主張して思考停止していたらasyncawaitの発明には到達できなかった
605デフォルトの名無しさん (ワッチョイ c9e5-pIXJ)
2020/01/03(金) 17:35:57.54ID:VSKvK8ih0 並列処理はうまく書けないからasync/awaitは中途半端な糞!にならないのが不思議だなあ
てかこのひと年末からずっと何かにつけて「ほにゃららは糞!おまえらは信者!」から入るのに
ひたすら教えられてるだけなのが面白いね
てかこのひと年末からずっと何かにつけて「ほにゃららは糞!おまえらは信者!」から入るのに
ひたすら教えられてるだけなのが面白いね
606デフォルトの名無しさん (ワッチョイ 8201-TJkF)
2020/01/03(金) 17:56:04.43ID:cSDCrnP10 >>598
スレチな気もするが一応回答しとく
Promiseってのは処理が終わってるかもしれないし
まだ終わってないかもしれないという文脈付きで値を運ぶ入れ物
処理が終わってる場合は、成功してるケースもあれば失敗してるケースもある
つまり下記3つのうちいずれか1つの状態にある
1. Pending:まだ終わってない/結果待ち
2. Fulfilled: 成功で処理完了済み(=Resolved)
3. Rejected: 失敗で処理完了済み
「戻り値が A Promise that resolves to a Response object」というのは
戻り値はPromise(=文脈付きで値を運ぶ入れ物)で
成功で処理が完了済みの状態になった場合
入れ物の中身は「a Response object」になるPromiseですよって意味
スレチな気もするが一応回答しとく
Promiseってのは処理が終わってるかもしれないし
まだ終わってないかもしれないという文脈付きで値を運ぶ入れ物
処理が終わってる場合は、成功してるケースもあれば失敗してるケースもある
つまり下記3つのうちいずれか1つの状態にある
1. Pending:まだ終わってない/結果待ち
2. Fulfilled: 成功で処理完了済み(=Resolved)
3. Rejected: 失敗で処理完了済み
「戻り値が A Promise that resolves to a Response object」というのは
戻り値はPromise(=文脈付きで値を運ぶ入れ物)で
成功で処理が完了済みの状態になった場合
入れ物の中身は「a Response object」になるPromiseですよって意味
607デフォルトの名無しさん (ワッチョイ 8201-TJkF)
2020/01/03(金) 18:03:40.42ID:cSDCrnP10 >>599
>.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
>.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
608デフォルトの名無しさん (ワッチョイ 797b-s4wZ)
2020/01/03(金) 19:11:10.09ID:fU3ErGER0 >>605
そうとしか取れないのはお前が馬鹿な信者だからだ。
俺はそもそもasyncが悪いなんて言う気もない。いい物はいいと認めるだけ。
お前みたいな馬鹿信者は俺という『人』を全否定したいから、全部否定するとか、
お前みたいな馬鹿でも明らかに分かるほど間違った態度を取ってくれないと困るようだが。
> 並列処理
そりゃ重要度が違うからな。実際、お前ら並列処理なんて書いてないだろ。
スパコンのこと何にも知らないようだし。(これ自体はC#的には問題ないが)
C#/.NETが扱うのは、そもそも並列が効くような案件でもないし。
対して非同期は.NET的には日常的に必要な物になってしまってるだろ。
ただまあ、お前らがTaskにこだわるのなら、第一級関数ってのも意味があるのかもね。
Task自体はラムダをオブジェクト化したようなものであり、関数型で言う第一級関数的なものだ。
JavaScriptならFunctionにメソッド生やして全部Task的にすることも可能だ。(やったら別の意味で殺されるはずだが)
俺には第一級関数の有り難み自体はよく分からないのだけど。
そうとしか取れないのはお前が馬鹿な信者だからだ。
俺はそもそもasyncが悪いなんて言う気もない。いい物はいいと認めるだけ。
お前みたいな馬鹿信者は俺という『人』を全否定したいから、全部否定するとか、
お前みたいな馬鹿でも明らかに分かるほど間違った態度を取ってくれないと困るようだが。
> 並列処理
そりゃ重要度が違うからな。実際、お前ら並列処理なんて書いてないだろ。
スパコンのこと何にも知らないようだし。(これ自体はC#的には問題ないが)
C#/.NETが扱うのは、そもそも並列が効くような案件でもないし。
対して非同期は.NET的には日常的に必要な物になってしまってるだろ。
ただまあ、お前らがTaskにこだわるのなら、第一級関数ってのも意味があるのかもね。
Task自体はラムダをオブジェクト化したようなものであり、関数型で言う第一級関数的なものだ。
JavaScriptならFunctionにメソッド生やして全部Task的にすることも可能だ。(やったら別の意味で殺されるはずだが)
俺には第一級関数の有り難み自体はよく分からないのだけど。
609デフォルトの名無しさん (ブーイモ MMb6-OcRt)
2020/01/03(金) 19:31:35.35ID:rBRy8LznM > C#/.NETが扱うのは、そもそも並列が効くような案件でもないし。
やっぱり使ったことない人だったか
やっぱり使ったことない人だったか
610デフォルトの名無しさん (スププ Sd62-IJNu)
2020/01/03(金) 19:35:32.04ID:FQOC+LzKd 通信やファイル等々は並列化前提くらい当たり前に使う部分
そもそもまともに開発したことないんでしょ、彼は
そもそもまともに開発したことないんでしょ、彼は
611デフォルトの名無しさん (ワッチョイ c9e5-pIXJ)
2020/01/03(金) 19:40:22.89ID:VSKvK8ih0 >>608
> 馬鹿でも明らかに分かるほど間違った態度を取ってくれないと困るようだが。
馬鹿がasyncマンセーTaskは糞なんて明らかに分かるほど間違った態度を取ってるから別に困って無いよ?
> そりゃ重要度が違うからな。実際、お前ら並列処理なんて書いてないだろ。
まあ日常的に並列処理を書いて無いならasync信者になるのも止む無しだね
粒度の粗いAPIを呼び出しているだけで済むプログラマ人生なのが良くわかる
まさに「馬鹿でも出来るようになっているからこそ馬鹿が調子こいてる。」
> 馬鹿でも明らかに分かるほど間違った態度を取ってくれないと困るようだが。
馬鹿がasyncマンセーTaskは糞なんて明らかに分かるほど間違った態度を取ってるから別に困って無いよ?
> そりゃ重要度が違うからな。実際、お前ら並列処理なんて書いてないだろ。
まあ日常的に並列処理を書いて無いならasync信者になるのも止む無しだね
粒度の粗いAPIを呼び出しているだけで済むプログラマ人生なのが良くわかる
まさに「馬鹿でも出来るようになっているからこそ馬鹿が調子こいてる。」
612デフォルトの名無しさん (ワッチョイ 06ad-eGyC)
2020/01/03(金) 20:21:02.89ID:jYqYJjY40 並列実行をHPC系の計算でしか使わないと思ってるのかなあ
スマホゲームにだって使われている、カジュアルに使えなくちゃ今時大変な機能だと思うけど
スマホゲームにだって使われている、カジュアルに使えなくちゃ今時大変な機能だと思うけど
613デフォルトの名無しさん (ワッチョイ 49a7-HDsw)
2020/01/03(金) 23:02:49.12ID:O+Z2CAJQ0 c#の並列処理ってコントロールが糞だから仕方なくって場面ばっかりだけどね
そもそも並列処理って実現方法に2つあって
並列で動く2つの処理を
処理Aと処理Bとしたときに
[方法1]
言語の並列機構に任せて
処理Aと処理Bをそれぞれ独立で実行する
もちろん処理過程や処理結果も表示通知する機能が存在する
[方法2]
処理Aと処理Bをブツ切りにした
処理A1~N、処理B1~Nをループで
処理A1
処理B1
表示
処理A2
処理B2
表示
・
・
・
という具合で実行
色々触ってきたけど[方法1]で
実行できた言語って一度もネーな(笑)
そもそも並列処理って実現方法に2つあって
並列で動く2つの処理を
処理Aと処理Bとしたときに
[方法1]
言語の並列機構に任せて
処理Aと処理Bをそれぞれ独立で実行する
もちろん処理過程や処理結果も表示通知する機能が存在する
[方法2]
処理Aと処理Bをブツ切りにした
処理A1~N、処理B1~Nをループで
処理A1
処理B1
表示
処理A2
処理B2
表示
・
・
・
という具合で実行
色々触ってきたけど[方法1]で
実行できた言語って一度もネーな(笑)
614デフォルトの名無しさん (ワッチョイ e12d-XiJJ)
2020/01/03(金) 23:20:55.60ID:mMttcVtS0 そうだね、パソコンがなんでもやってくれると君みたいな頭でもプログラムが書けるね
615デフォルトの名無しさん (ワッチョイ 8201-TJkF)
2020/01/03(金) 23:21:49.89ID:cSDCrnP10 とりあえず並列処理と並行処理は区別しよう
616デフォルトの名無しさん (ワッチョイ 797b-s4wZ)
2020/01/03(金) 23:46:23.43ID:fU3ErGER0 >>610
既に突っ込まれてはいるが、それは一応「並列(Parallelism)」ではなく、「平行(Concurrency)」という。
が、まあ、これはさておき、君の使い方はやはり平行でなく非同期(Asynchronous)だと思うよ。
実際、例えば、「asyncブロック」というのが次に来たとして、仕様は、
・これまでの記述の複数のasync文を async { } で囲うことが出来ます。
・asyncブロック内のasync文は同時にディスパッチされます。
・全てのasync文が完了次第、asyncブロックを抜けます。
という、async { } で囲うだけ!簡単!楽チン!な物が提供されたら、
今お前らが使っているであろうTask<TResult>は不要になるだろ。
ディスパッチャを自前で書く気がなければTaskは基本的に要らないと思うけど。
本来「平行」の場合は表ジョブと裏ジョブの同期は割と厳密に取る。
手が空き次第捌け、順番はどうでもいい、は非同期の使い方で、大概はほぼこれだろ。
既に突っ込まれてはいるが、それは一応「並列(Parallelism)」ではなく、「平行(Concurrency)」という。
が、まあ、これはさておき、君の使い方はやはり平行でなく非同期(Asynchronous)だと思うよ。
実際、例えば、「asyncブロック」というのが次に来たとして、仕様は、
・これまでの記述の複数のasync文を async { } で囲うことが出来ます。
・asyncブロック内のasync文は同時にディスパッチされます。
・全てのasync文が完了次第、asyncブロックを抜けます。
という、async { } で囲うだけ!簡単!楽チン!な物が提供されたら、
今お前らが使っているであろうTask<TResult>は不要になるだろ。
ディスパッチャを自前で書く気がなければTaskは基本的に要らないと思うけど。
本来「平行」の場合は表ジョブと裏ジョブの同期は割と厳密に取る。
手が空き次第捌け、順番はどうでもいい、は非同期の使い方で、大概はほぼこれだろ。
617デフォルトの名無しさん (ワッチョイ 797b-s4wZ)
2020/01/03(金) 23:48:32.86ID:fU3ErGER0 × 平行
○ 並行
○ 並行
618デフォルトの名無しさん (ワッチョイ 797b-s4wZ)
2020/01/04(土) 00:04:34.11ID:kFIotbKU0619デフォルトの名無しさん (アウアウエー Sa4a-OcRt)
2020/01/04(土) 00:09:37.91ID:OgXWl81Pa やっぱり使ったことない人だったか
620デフォルトの名無しさん (ブーイモ MMb6-OcRt)
2020/01/04(土) 00:48:40.79ID:4F9nlIzrM 通信やファイル処理はCPUとは別のデバイスが同時に処理するから並列処理
ネットワークやディスクにアクセス中にスレッド消費されたら使い物にならん
ネットワークやディスクにアクセス中にスレッド消費されたら使い物にならん
621デフォルトの名無しさん (ワッチョイ e12d-XiJJ)
2020/01/04(土) 01:17:00.82ID:ebUznjxj0 誤った指摘をしている人がいますが、>>610は、相当ミスらない限り並列処理かつ非同期処理です
並行処理である保証は全くありません
並行処理である保証は全くありません
622デフォルトの名無しさん (ワッチョイ 422c-RM0q)
2020/01/04(土) 02:02:38.56ID:X7t3Qsuc0 並列は、CPU に使う用語
並行は、処理に使う用語
並行は、処理に使う用語
623デフォルトの名無しさん (ワッチョイ 426a-UAPS)
2020/01/04(土) 02:34:27.40ID:WRfbnwnP0 こんだけ暴れておいてこの結末w
624デフォルトの名無しさん (ワッチョイ 8201-TJkF)
2020/01/04(土) 02:47:20.03ID:oEJCGEWJ0 >>620,621
ファイルや通信のI/O処理中にCPUでは別の処理をするってのは
典型的な並行処理の例で一般的には並列処理とは呼ばないぞ
ファイルがパーティション分割されてて
100パーティション同時に書き込みを行うような処理なら並列処理
基礎的なことなのでもうちょい勉強してくれ
ファイルや通信のI/O処理中にCPUでは別の処理をするってのは
典型的な並行処理の例で一般的には並列処理とは呼ばないぞ
ファイルがパーティション分割されてて
100パーティション同時に書き込みを行うような処理なら並列処理
基礎的なことなのでもうちょい勉強してくれ
625デフォルトの名無しさん (ワッチョイ e12d-XiJJ)
2020/01/04(土) 03:01:30.66ID:ebUznjxj0 >>624
>>621は冗談で言ってるんだとは思いますし、何が一般的かは知りませんが、私はこの並行処理の記述に従って理解しています
https://docs.microsoft.com/en-us/dotnet/standard/parallel-programming/
なお、私の知る限りでは他分野でも同じです
>>621は冗談で言ってるんだとは思いますし、何が一般的かは知りませんが、私はこの並行処理の記述に従って理解しています
https://docs.microsoft.com/en-us/dotnet/standard/parallel-programming/
なお、私の知る限りでは他分野でも同じです
626デフォルトの名無しさん (ブーイモ MM62-OcRt)
2020/01/04(土) 07:26:04.88ID:SQI5AQb9M >>624
並行処理ってのは、単一の主体が短いタイムスパンで複数の処理を切り替えて処理することによって、まるで並列処理をしているように見せかける技術のことな
言うまでもないが、並列処理は複数の主体が、見せかけじゃなく同時に別の処理をしてる場合な
例えばこうだ
var t1 = CalcSomething();
var t2 = DownloadFile();
var t3 = ReadFile();
1つの物理装置が、少しCPU処理→少しファイル処理→少しネットワーク処理、と繰り返して3つの処理を同時に処理してるように見せてるなら並行処理だ
でも実際には、別々の物理装置によって計算、ネットワークアクセス、ファイルアクセスを同時に処理するので、これは並行処理ではなく並列処理だ
基本的なことなので、勉強してくれまじで
並行処理ってのは、単一の主体が短いタイムスパンで複数の処理を切り替えて処理することによって、まるで並列処理をしているように見せかける技術のことな
言うまでもないが、並列処理は複数の主体が、見せかけじゃなく同時に別の処理をしてる場合な
例えばこうだ
var t1 = CalcSomething();
var t2 = DownloadFile();
var t3 = ReadFile();
1つの物理装置が、少しCPU処理→少しファイル処理→少しネットワーク処理、と繰り返して3つの処理を同時に処理してるように見せてるなら並行処理だ
でも実際には、別々の物理装置によって計算、ネットワークアクセス、ファイルアクセスを同時に処理するので、これは並行処理ではなく並列処理だ
基本的なことなので、勉強してくれまじで
627デフォルトの名無しさん (スププ Sd62-IJNu)
2020/01/04(土) 07:33:09.39ID:wUfYsbyMd C#で並列処理を勉強しようとしたら大抵初めに出てくるParallel.Forすら知らないんでしょ
だから英単語出してきてまでそれは平行だ!とか指摘しちゃう
英単語わかってるなら並列だってわかるはずのにw
もう以前からびっくりするくらい知識が浅い
だから英単語出してきてまでそれは平行だ!とか指摘しちゃう
英単語わかってるなら並列だってわかるはずのにw
もう以前からびっくりするくらい知識が浅い
628デフォルトの名無しさん (スププ Sd62-IJNu)
2020/01/04(土) 07:49:31.73ID:wUfYsbyMd あとマルチproccessとマルチthreadも同じやね
using System.Threadingも書いたことなんだろう
C#に無知でこれらを知らないは別に良いけど一般的なソフトウェア開発で並列処理なんて書かないとかいう指摘も的外れ
C#に関することに無知なのは触ってなけりゃ普通のことだろうけど今や当たり前に行われる並列処理をスパコンのものでお前らにはわからんだろうな、とか言っちゃうのは技術者としてどうかと思う
using System.Threadingも書いたことなんだろう
C#に無知でこれらを知らないは別に良いけど一般的なソフトウェア開発で並列処理なんて書かないとかいう指摘も的外れ
C#に関することに無知なのは触ってなけりゃ普通のことだろうけど今や当たり前に行われる並列処理をスパコンのものでお前らにはわからんだろうな、とか言っちゃうのは技術者としてどうかと思う
629デフォルトの名無しさん (ワッチョイ 49a7-HDsw)
2020/01/04(土) 08:29:25.67ID:zoxkJgWd0 プログラム内の厳密な並列ってなくね?
おそらく無理じゃね
同じメモリ空間をCPUが同時にアクセスできないよね?
paralle.forとか俺はこんないい加減な前準備でできると思ってないけどね
どういう仕組みか知らんけどw
多分なんちゃってだろ
やった感じ直列で処理したほうが早い感じになってうんこだったよ
ちなみにフルHDの画像処理を上から三等分にしてparalle.forでやってみたがクソ遅い上に並列にやってない気がしたけど
みんなはこんなもん使えてるの?
ところでスレッドってスレッドスイッチするし積まれたタスクを順番に処理してるだけだよな?
その切替タイミングはプログラム内のsleepやDoEventsだよね?
おそらく無理じゃね
同じメモリ空間をCPUが同時にアクセスできないよね?
paralle.forとか俺はこんないい加減な前準備でできると思ってないけどね
どういう仕組みか知らんけどw
多分なんちゃってだろ
やった感じ直列で処理したほうが早い感じになってうんこだったよ
ちなみにフルHDの画像処理を上から三等分にしてparalle.forでやってみたがクソ遅い上に並列にやってない気がしたけど
みんなはこんなもん使えてるの?
ところでスレッドってスレッドスイッチするし積まれたタスクを順番に処理してるだけだよな?
その切替タイミングはプログラム内のsleepやDoEventsだよね?
630デフォルトの名無しさん (ワッチョイ ed38-M1Rv)
2020/01/04(土) 08:50:02.37ID:oslWCP6e0 変なの増えた
631デフォルトの名無しさん (ワッチョイ 4201-19tT)
2020/01/04(土) 09:09:30.45ID:H9Ya7buR0632デフォルトの名無しさん (ワッチョイ 0642-UAPS)
2020/01/04(土) 09:10:51.45ID:SF9EFyjm0 >>629
パイプラインとかキャッシュとかレジスタとかマルチスレッドとか、CPUの技術を少しは勉強したほうがいい
パイプラインとかキャッシュとかレジスタとかマルチスレッドとか、CPUの技術を少しは勉強したほうがいい
633デフォルトの名無しさん (ワッチョイ 49a7-HDsw)
2020/01/04(土) 09:16:33.71ID:zoxkJgWd0 >>631
え?じゃあどこ?
え?じゃあどこ?
634デフォルトの名無しさん (ワッチョイ 49a7-HDsw)
2020/01/04(土) 09:23:34.37ID:zoxkJgWd0 >>632
それを実際に言語の機能に適用してるかどうかは別だよね?
なんか超遅かったよ
もし並列に動いてるなら画像処理は単純に三分の一で終わったはずだよね?
ところがむしろ3倍以上かかってるんだな
なんか前準備に色々条件があるのか?
こんなもん役に立たないのか?
該当する処理が本当に適用できるのかはチェックが必要だと思うな
それを実際に言語の機能に適用してるかどうかは別だよね?
なんか超遅かったよ
もし並列に動いてるなら画像処理は単純に三分の一で終わったはずだよね?
ところがむしろ3倍以上かかってるんだな
なんか前準備に色々条件があるのか?
こんなもん役に立たないのか?
該当する処理が本当に適用できるのかはチェックが必要だと思うな
635デフォルトの名無しさん (ワッチョイ 425e-ZJRt)
2020/01/04(土) 09:34:32.95ID:ljwPgx+b0 スレッド切り替えと言うが、今日日マルチコアだぞ。
Parallel.Forも一つだけど、PLINQなんかも実は色々効いてくる。
まあ、Taskは便利よ。
スレッドプールを有効利用するのは手でやると事故るので、Taskに任せるほうがよかろう。
その上でUIスレッドに返したければUIスレッドに返すコード書けば良いだけなんだし。
逆に言うと、UIスレッドからTaskをawaitしたときに元のスレッドに戻って来てる事自体が例外的な処理に近い。
Parallel.Forも一つだけど、PLINQなんかも実は色々効いてくる。
まあ、Taskは便利よ。
スレッドプールを有効利用するのは手でやると事故るので、Taskに任せるほうがよかろう。
その上でUIスレッドに返したければUIスレッドに返すコード書けば良いだけなんだし。
逆に言うと、UIスレッドからTaskをawaitしたときに元のスレッドに戻って来てる事自体が例外的な処理に近い。
636デフォルトの名無しさん (スププ Sd62-IJNu)
2020/01/04(土) 09:44:36.22ID:wUfYsbyMd parallelにしてもちゃんと理解してないと遅くなることだってありうるよ
並列化できない処理をparallelしたって切り替え処理とかが無駄に働いて逆に遅くなることもある
コードでも上げてみりゃどこが間違ってるか指摘できる人もいるんじゃない?
並列化できない処理をparallelしたって切り替え処理とかが無駄に働いて逆に遅くなることもある
コードでも上げてみりゃどこが間違ってるか指摘できる人もいるんじゃない?
637デフォルトの名無しさん (ワッチョイ 49a7-HDsw)
2020/01/04(土) 09:49:49.34ID:zoxkJgWd0638デフォルトの名無しさん (ワッチョイ 49a7-HDsw)
2020/01/04(土) 09:54:48.34ID:zoxkJgWd0 >>635
それ並列でやった処理結果まとめられないじゃん
やりにくいし
結局処理単位は自分でブツ切りにしないと途中経過出力できないし
実質この手の機能ってc++の頃から別に便利でもなんでもないゴミクズ機能で停滞してるよね?
それ並列でやった処理結果まとめられないじゃん
やりにくいし
結局処理単位は自分でブツ切りにしないと途中経過出力できないし
実質この手の機能ってc++の頃から別に便利でもなんでもないゴミクズ機能で停滞してるよね?
639デフォルトの名無しさん (ワッチョイ 4201-19tT)
2020/01/04(土) 09:57:09.90ID:H9Ya7buR0 >>633
プリエンプティブ でググってこい
プリエンプティブ でググってこい
640デフォルトの名無しさん (スププ Sd62-IJNu)
2020/01/04(土) 09:59:40.19ID:wUfYsbyMd >>637
いや、あんたが何かを勘違いしてるかもしれないことをコードレビューしてあげようかって言ってあげてんのw
詳細な実装は開示しないけど俺が試したら遅くなった!parallelなんかまともに使えない!って主張なの?
世界中のプログラマが有益に利用してるんだから間違って利用しちゃってるなら正せばいいだけじゃん
ググりゃ腐るほど日本語でも記事はヒットするんだし
いや、あんたが何かを勘違いしてるかもしれないことをコードレビューしてあげようかって言ってあげてんのw
詳細な実装は開示しないけど俺が試したら遅くなった!parallelなんかまともに使えない!って主張なの?
世界中のプログラマが有益に利用してるんだから間違って利用しちゃってるなら正せばいいだけじゃん
ググりゃ腐るほど日本語でも記事はヒットするんだし
641デフォルトの名無しさん (スププ Sd62-IJNu)
2020/01/04(土) 10:01:55.73ID:wUfYsbyMd 3分割したら3倍異常遅くなるって例えば各スレッドでファイルを読み込んでるだけじゃねーの?
そんなやり方したらそりゃ遅くなるよね
そんなやり方したらそりゃ遅くなるよね
642デフォルトの名無しさん (ワッチョイ 49a7-HDsw)
2020/01/04(土) 10:02:04.61ID:zoxkJgWd0 >>640
フルHD画像処理を上から三等分でparalle.forって言ってんだからやって動くサンプル出してこいよ
おそらくdobon辺りに貼るだけでparalle.forかけて画像処理ループさせるだけだ
10分だぞ
やりたきゃ頑張れ
フルHD画像処理を上から三等分でparalle.forって言ってんだからやって動くサンプル出してこいよ
おそらくdobon辺りに貼るだけでparalle.forかけて画像処理ループさせるだけだ
10分だぞ
やりたきゃ頑張れ
643デフォルトの名無しさん (ワッチョイ 426a-UAPS)
2020/01/04(土) 10:14:00.73ID:WRfbnwnP0 GAIJI vs GAIJI
644デフォルトの名無しさん (ササクッテロ Spf1-wZ3g)
2020/01/04(土) 10:18:25.47ID:dtJSIh3jp ヤベエ逸材多過ぎだろこのスレw
今までどこに潜んでたんだコイツら
今までどこに潜んでたんだコイツら
645デフォルトの名無しさん (ワッチョイ 425e-ZJRt)
2020/01/04(土) 10:31:54.67ID:ljwPgx+b0 >>638
纏められるよ。
PLINQ使ってみ。
途中経過が必要ってこと自体、多分並列化出来てないから考え方がおかしいよ。
並列にやってるんだから途中経過なんて足し込まないと出せない事はやるべきじゃないでしょ。
足しこみは並列にできないんだから、そこで足並み揃えちゃったらそりゃ並列に動かんよ。
纏められるよ。
PLINQ使ってみ。
途中経過が必要ってこと自体、多分並列化出来てないから考え方がおかしいよ。
並列にやってるんだから途中経過なんて足し込まないと出せない事はやるべきじゃないでしょ。
足しこみは並列にできないんだから、そこで足並み揃えちゃったらそりゃ並列に動かんよ。
646デフォルトの名無しさん (ワッチョイ 797b-s4wZ)
2020/01/04(土) 10:57:29.93ID:kFIotbKU0 まあとりあえず、「並列」「並行」については最近は混同されてるし、実際混同しても問題ない領域が多いし、
文系馬鹿C#erが主流なこのスレでその厳密性を求める意味はない。
ただまあ、ファイルとCPUでは速度差がありすぎるから、
まともなスケジューラーなら並列に書いてても並行になってしまうとも思うが。
しかしMSはそこも含めて隠蔽しようって事なんだろ。これ自体はいい。
> Parallel.For
これはちょっと筋が悪い。現在の主流はMap/Reduceなんだから、そっちに合わせた方がよかった。
お前らが速くなるならないでグダグダ言っているのも、結局はこれで、Map/Reduceが効く場合は速くなり、
そうでない場合は速くならず、場合によっては遅くなる、というだけ。別に不思議なことではない。
ただまあ、君らも分かっているとおり、レンダリングの場合は分割は効果があるから、
・書き方が悪い
・今はそこまでParallel.Forの出来がよくない
のどちらかで、まあそれを揉めているわけだが、今の状況はさておき、
最終的にはこのコードで簡単楽チンに数倍速を得よう、ってのは間違ってはいない。
問題はやはりMap/Reduceでないことで、結局、「関数」で処理を抽象化出来ているから
関数を直接扱う「関数型」の方がI/Fは綺麗に並んでしまう。
そこをForにこだわったのは間違いだと思うよ。
文系馬鹿C#erが主流なこのスレでその厳密性を求める意味はない。
ただまあ、ファイルとCPUでは速度差がありすぎるから、
まともなスケジューラーなら並列に書いてても並行になってしまうとも思うが。
しかしMSはそこも含めて隠蔽しようって事なんだろ。これ自体はいい。
> Parallel.For
これはちょっと筋が悪い。現在の主流はMap/Reduceなんだから、そっちに合わせた方がよかった。
お前らが速くなるならないでグダグダ言っているのも、結局はこれで、Map/Reduceが効く場合は速くなり、
そうでない場合は速くならず、場合によっては遅くなる、というだけ。別に不思議なことではない。
ただまあ、君らも分かっているとおり、レンダリングの場合は分割は効果があるから、
・書き方が悪い
・今はそこまでParallel.Forの出来がよくない
のどちらかで、まあそれを揉めているわけだが、今の状況はさておき、
最終的にはこのコードで簡単楽チンに数倍速を得よう、ってのは間違ってはいない。
問題はやはりMap/Reduceでないことで、結局、「関数」で処理を抽象化出来ているから
関数を直接扱う「関数型」の方がI/Fは綺麗に並んでしまう。
そこをForにこだわったのは間違いだと思うよ。
647デフォルトの名無しさん (ワッチョイ 2e7b-nWGE)
2020/01/04(土) 11:03:02.06ID:DH3JGq6p0 とりまコード見ないとなんとも
なんかで排他制御でも効いてるんだろうけど
なんかで排他制御でも効いてるんだろうけど
648デフォルトの名無しさん (ワッチョイ 8201-TJkF)
2020/01/04(土) 11:03:38.49ID:oEJCGEWJ0649デフォルトの名無しさん (ワッチョイ c242-UAPS)
2020/01/04(土) 11:11:54.60ID:8gIJKMuI0 そもそもawait/asyncは、非同期処理を同期処理のようにかける仕組みであって
マルチタスクそのものじゃなくて周辺技術だよな
マルチタスクそのものじゃなくて周辺技術だよな
650デフォルトの名無しさん (ブーイモ MM62-OcRt)
2020/01/04(土) 11:53:37.81ID:SQI5AQb9M >>648
いや、そっちが理解間違ってるよ
並列処理は複数の装置で複数の処理を同時に実行すること
並行処理は単一の装置に複数の処理をスケジューリングして、順番に実行することによって巨視的に並列処理のように見せかけること
複数の装置にスケジューリングすることを並行処理と呼んでる場合もあるが、それは正確には並列処理と並列処理のハイブリッドだな
君が言ってる同時に処理される場合もある、というのはこのことだろうな
いや、そっちが理解間違ってるよ
並列処理は複数の装置で複数の処理を同時に実行すること
並行処理は単一の装置に複数の処理をスケジューリングして、順番に実行することによって巨視的に並列処理のように見せかけること
複数の装置にスケジューリングすることを並行処理と呼んでる場合もあるが、それは正確には並列処理と並列処理のハイブリッドだな
君が言ってる同時に処理される場合もある、というのはこのことだろうな
651デフォルトの名無しさん (ワッチョイ 814f-UAPS)
2020/01/04(土) 12:07:21.44ID:hpecUN4N0 >>650
どっちが正しいと断言するつもりはないけど、この並列処理と並行処理の定義はどこから持ってきたものなの?
どっちが正しいと断言するつもりはないけど、この並列処理と並行処理の定義はどこから持ってきたものなの?
652デフォルトの名無しさん (ワッチョイ 425e-ZJRt)
2020/01/04(土) 12:08:56.85ID:ljwPgx+b0 >>646
自動的に適切な単位に分割されたMapとReduceがPLINQで実現できると思うんだが。
自動的に適切な単位に分割されたMapとReduceがPLINQで実現できると思うんだが。
653デフォルトの名無しさん (ドコグロ MM75-19tT)
2020/01/04(土) 12:27:07.45ID:LH34clIMM654デフォルトの名無しさん (ワッチョイ 2ee3-E95m)
2020/01/04(土) 13:10:03.26ID:9r4/dVyW0 この年末からのつまんねえ言葉遊びの流れほんとクソ
655デフォルトの名無しさん (ワッチョイ 312f-RM0q)
2020/01/04(土) 15:56:23.34ID:zGBEMeLs0 装置どうこうで並列や並行いってるやつらは
まずマルチコアなCPUを装置としてどう見てるのか書け
話はそれからだ
まずマルチコアなCPUを装置としてどう見てるのか書け
話はそれからだ
656デフォルトの名無しさん (ワッチョイ 797b-s4wZ)
2020/01/04(土) 19:35:04.89ID:kFIotbKU0 >>652
実際効果が出ているのならそれでいいと思うよ。
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としてはプログラミングモデルを提供してきた、というところか。
実際効果が出ているのならそれでいいと思うよ。
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としてはプログラミングモデルを提供してきた、というところか。
657デフォルトの名無しさん (ワッチョイ 797b-s4wZ)
2020/01/04(土) 19:37:21.95ID:kFIotbKU0 asyncも、ググれば分かると思うが、実はasync/awaitの片方はキーワードとしては要らない。
その場合には実行/フェンスについて、実行は今まで通り記述した時点で開始、
フェンスは結果を使うところで暗黙的に、ということになる。(つまり今ならawaitが要らない)
これはこの界隈ではすごく一般的な考え方で、
例えばアセンブラでDIVやSQRT命令みたいにレイテンシが長い命令を配置したとき、
結果レジスタを使わない場合はどんどん流し、結果レジスタを使う場合だけそこで一旦停止して結果待ち、という事を30年前からやっている。
だから「非同期」というよりは「並列化+パイプライン(可変長レイテンシ)」として考える方がいいのかもしれないけど、
いずれにしても今は「明示的にawaitを書く」というある意味MSらしくない、
どちらかというとWeb系的ドベタ仕様で、だからこそ君らもTaskマンセーな訳だが、
こう説明されれば「あ、確かにawaitいらねえな」とはすぐに分かるだろ。
多分君らが非同期にだいぶ慣れた頃にawaitは廃止されると思うよ。
そして「非同期」と「同期」は一文字も変わらない同じ関数で実行可能となり、完全な抽象化が実現出来ることになる。
ただし、今の仕様が悪いか、と言われれば、必ずしもそうでもない。
俺がさんざん言っているとおり、MSは若干エレガントなところを狙いすぎていて、
ライト層がちょっと置いてきぼりになってる感がある。(Web系に比べて)
そしてさんざん君らがTaskマンセーしているとおり、ベタな仕様には分かりやすいという大きな利点がある。
ただそれにしても、繰り返すが、CPUのパイプライン構造を知っていれば、あ、確かに間抜けな仕様だな、とはすぐに分かるだろ。
俺が信者だと揶揄しているのはそこら辺であってさ。
その場合には実行/フェンスについて、実行は今まで通り記述した時点で開始、
フェンスは結果を使うところで暗黙的に、ということになる。(つまり今ならawaitが要らない)
これはこの界隈ではすごく一般的な考え方で、
例えばアセンブラでDIVやSQRT命令みたいにレイテンシが長い命令を配置したとき、
結果レジスタを使わない場合はどんどん流し、結果レジスタを使う場合だけそこで一旦停止して結果待ち、という事を30年前からやっている。
だから「非同期」というよりは「並列化+パイプライン(可変長レイテンシ)」として考える方がいいのかもしれないけど、
いずれにしても今は「明示的にawaitを書く」というある意味MSらしくない、
どちらかというとWeb系的ドベタ仕様で、だからこそ君らもTaskマンセーな訳だが、
こう説明されれば「あ、確かにawaitいらねえな」とはすぐに分かるだろ。
多分君らが非同期にだいぶ慣れた頃にawaitは廃止されると思うよ。
そして「非同期」と「同期」は一文字も変わらない同じ関数で実行可能となり、完全な抽象化が実現出来ることになる。
ただし、今の仕様が悪いか、と言われれば、必ずしもそうでもない。
俺がさんざん言っているとおり、MSは若干エレガントなところを狙いすぎていて、
ライト層がちょっと置いてきぼりになってる感がある。(Web系に比べて)
そしてさんざん君らがTaskマンセーしているとおり、ベタな仕様には分かりやすいという大きな利点がある。
ただそれにしても、繰り返すが、CPUのパイプライン構造を知っていれば、あ、確かに間抜けな仕様だな、とはすぐに分かるだろ。
俺が信者だと揶揄しているのはそこら辺であってさ。
658デフォルトの名無しさん (ワッチョイ a2ac-+zdV)
2020/01/04(土) 19:51:30.64ID:dJY1KQxf0 別スレ立てたら?
659デフォルトの名無しさん (ワッチョイ 797b-s4wZ)
2020/01/04(土) 19:54:05.88ID:kFIotbKU0 もしかしたら伝わらないか?とも思うので一応。
俺は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つずつステップ実行されてしまう、という事になっている。
俺は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つずつステップ実行されてしまう、という事になっている。
660デフォルトの名無しさん (ワッチョイ dd5f-BfT8)
2020/01/04(土) 20:06:59.76ID:tMXF89W90 >>659
そのコードじゃ非同期処理が完了してなくても"〜 are ready"って表示されるだろ。
そのコードじゃ非同期処理が完了してなくても"〜 are ready"って表示されるだろ。
661デフォルトの名無しさん (ワッチョイ 2e7b-nWGE)
2020/01/04(土) 20:09:00.48ID:DH3JGq6p0 c++スレにいた長文マンかなこいつ
662デフォルトの名無しさん (ワッチョイ 797b-s4wZ)
2020/01/04(土) 20:44:38.22ID:kFIotbKU0 >>660
まあそこはツッコミ来るかとは思っていたが…。
ぶっちゃけ、その通りだ。そしてそれで問題ないんだよ。
結果を確認しに行けば確かに出来ている(ようにしか見えない)からね。
時間軸上で遅延が発生するだけで、論理的な動作としては全く問題ない。
これは例えばJavaScriptでは大昔から実装済みで、getElementsByClassNameがそうなってる。
https://developer.mozilla.org/ja/docs/Web/API/Document/getElementsByClassName
これで問題が発生しているケースなんてない。
馬鹿が「getElementsByClassNameは圧倒的に速い」みたいなブログを書いている、というのは結構あったが。
ただ、まあ、何らかのフェンス構文自体が必要なのは認める。
しかし、当然だがフェンス自体は不要なら書かないものだし、
普通に「返り値を使う」いわゆるお行儀のいいプログラミングをしている限り、実際に不要だ。
だからじきに、みんなが「await って実は要らなくね?毎回お約束的に書かされるだけだろ。」
と思いだした頃に、廃止されるんじゃないかな。
そしたらその階層を取り扱う必要もなくなり、Taskも廃止できる。
まあそこはツッコミ来るかとは思っていたが…。
ぶっちゃけ、その通りだ。そしてそれで問題ないんだよ。
結果を確認しに行けば確かに出来ている(ようにしか見えない)からね。
時間軸上で遅延が発生するだけで、論理的な動作としては全く問題ない。
これは例えばJavaScriptでは大昔から実装済みで、getElementsByClassNameがそうなってる。
https://developer.mozilla.org/ja/docs/Web/API/Document/getElementsByClassName
これで問題が発生しているケースなんてない。
馬鹿が「getElementsByClassNameは圧倒的に速い」みたいなブログを書いている、というのは結構あったが。
ただ、まあ、何らかのフェンス構文自体が必要なのは認める。
しかし、当然だがフェンス自体は不要なら書かないものだし、
普通に「返り値を使う」いわゆるお行儀のいいプログラミングをしている限り、実際に不要だ。
だからじきに、みんなが「await って実は要らなくね?毎回お約束的に書かされるだけだろ。」
と思いだした頃に、廃止されるんじゃないかな。
そしたらその階層を取り扱う必要もなくなり、Taskも廃止できる。
663デフォルトの名無しさん (ワッチョイ 7197-IH4P)
2020/01/04(土) 20:59:50.92ID:W0mLC2oD0 >>657 >>662
awaitの結果を必ずしも使うとは限らないのに、本気で言ってるの?
async Task<void>のメソッドなんていくらでも作ることあるだろ。
そりゃ、async Task<bool>にでもしてtrueでも返すようにして、if文で判定するとかはできるけど、そんなの正直言ってasync/awaitからの退化だよ。
C#では非同期実行の方が基本的にはあえてさせることなんだから、awaitなくしたとして
コードを読んでてもわからないところが非同期になっていたら結構困ると思うけどなぁ。
なんでもかんでもどうやらある程度経験が豊富そうなJSを基準に考えちゃうみたいだけど、非同期が当たり前のJSとはとりまく環境が違うと思うよ。
awaitの結果を必ずしも使うとは限らないのに、本気で言ってるの?
async Task<void>のメソッドなんていくらでも作ることあるだろ。
そりゃ、async Task<bool>にでもしてtrueでも返すようにして、if文で判定するとかはできるけど、そんなの正直言ってasync/awaitからの退化だよ。
C#では非同期実行の方が基本的にはあえてさせることなんだから、awaitなくしたとして
コードを読んでてもわからないところが非同期になっていたら結構困ると思うけどなぁ。
なんでもかんでもどうやらある程度経験が豊富そうなJSを基準に考えちゃうみたいだけど、非同期が当たり前のJSとはとりまく環境が違うと思うよ。
664デフォルトの名無しさん (ワッチョイ 9901-Ivq/)
2020/01/04(土) 21:49:39.49ID:kexvLmFr0 await不要って園児並みに相当バカ
無くなったら何が困るかの簡単なことに気づかないとか、普通の人でもわかることだよw
無くなったら何が困るかの簡単なことに気づかないとか、普通の人でもわかることだよw
665デフォルトの名無しさん (ブーイモ MM6d-GLZk)
2020/01/04(土) 21:59:07.73ID:xLbjEwkrM そろそろ冬休み終わるから謎の長文更新も途切れるかね?
666デフォルトの名無しさん (ワッチョイ 814f-UAPS)
2020/01/04(土) 22:10:43.14ID:hpecUN4N0 冬休み関係ない人かもしれない
667デフォルトの名無しさん (ブーイモ MM62-OcRt)
2020/01/04(土) 22:16:18.30ID:SQI5AQb9M 前にも言ったがそんなに素晴らしいものなら、C#の言語チームに提案してこい
誰にも相手にされんだろうが、ここでグダグダと怪文書を書き込み続けるよりは生産的だろ
誰にも相手にされんだろうが、ここでグダグダと怪文書を書き込み続けるよりは生産的だろ
668デフォルトの名無しさん (ワッチョイ 797b-s4wZ)
2020/01/04(土) 23:11:07.21ID:kFIotbKU0 >>663
> コードを読んでてもわからないところが非同期になっていたら結構困ると思うけどなぁ。
これはその通り。だから俺の理想は以下のコードになるけど、
これはおそらくプログラミング理論的には>>659より汚いコードだとされる。(抽象度が落ちてる)
Coffee cup = PourCoffee();
Console.WriteLine("coffee is ready");
Egg eggs = async FryEggs(2);
Bacon bacon = async FryBacon(3);
Toast toast = async ToastBread(2);
ApplyButter(toast); // ここでtoastが完了してないときだけは結果待ちで止まる
ApplyJam(toast);
Console.WriteLine("toast is ready");
Juice oj = PourOJ();
Console.WriteLine("oj is ready");
async_fence(); // これ以前のasync関数はこれ以降は完了していることが保証される
Console.WriteLine("eggs are ready");
Console.WriteLine("bacon is ready");
Console.WriteLine("Breakfast is ready!");
現行からの変更点としては、
・キーワードawaitをasyncに変更、書く場所は同じ、ただしwaitせず実行して貫通
・キーワードasyncは呼び出し側に明示的に付け、定義側には要らない
・必要ならasync_fence()でフェンス、無ければ実行結果が使われるときに自動的にフェンスされる
・Egg/Bacon/ToastはTaskではなく値、よってキャンセル等は面倒だがどうせしないからよし
ただこれだと async を async()として関数化してリッパーにすれば現行のC++等で実装出来そうな気がしてきた。
これは勝手にやってみるかも。
> 非同期が当たり前のJSとはとりまく環境が違うと思うよ。
コミュニティとしては君らの方が慣れてないだけで、プログラミングとしては大して変わらんよ。
JSもI/O以外は全部同期だし、非同期部分は限定されてる。(なおgetElementsByClassNameは非同期ではなく遅延評価)
> コードを読んでてもわからないところが非同期になっていたら結構困ると思うけどなぁ。
これはその通り。だから俺の理想は以下のコードになるけど、
これはおそらくプログラミング理論的には>>659より汚いコードだとされる。(抽象度が落ちてる)
Coffee cup = PourCoffee();
Console.WriteLine("coffee is ready");
Egg eggs = async FryEggs(2);
Bacon bacon = async FryBacon(3);
Toast toast = async ToastBread(2);
ApplyButter(toast); // ここでtoastが完了してないときだけは結果待ちで止まる
ApplyJam(toast);
Console.WriteLine("toast is ready");
Juice oj = PourOJ();
Console.WriteLine("oj is ready");
async_fence(); // これ以前のasync関数はこれ以降は完了していることが保証される
Console.WriteLine("eggs are ready");
Console.WriteLine("bacon is ready");
Console.WriteLine("Breakfast is ready!");
現行からの変更点としては、
・キーワードawaitをasyncに変更、書く場所は同じ、ただしwaitせず実行して貫通
・キーワードasyncは呼び出し側に明示的に付け、定義側には要らない
・必要ならasync_fence()でフェンス、無ければ実行結果が使われるときに自動的にフェンスされる
・Egg/Bacon/ToastはTaskではなく値、よってキャンセル等は面倒だがどうせしないからよし
ただこれだと async を async()として関数化してリッパーにすれば現行のC++等で実装出来そうな気がしてきた。
これは勝手にやってみるかも。
> 非同期が当たり前のJSとはとりまく環境が違うと思うよ。
コミュニティとしては君らの方が慣れてないだけで、プログラミングとしては大して変わらんよ。
JSもI/O以外は全部同期だし、非同期部分は限定されてる。(なおgetElementsByClassNameは非同期ではなく遅延評価)
669デフォルトの名無しさん (ワッチョイ 41e7-45U5)
2020/01/04(土) 23:27:22.94ID:Zo3qJxMY0 仕様を劣化させてるだけじゃん…
670デフォルトの名無しさん (ワッチョイ be02-AVGY)
2020/01/04(土) 23:40:07.01ID:y+CTQpVr0 >>668
暇だからリファクタリングしてあげた
var cup = PourCoffee();
Console.WriteLine("coffee is ready");
var eggs = FryEggsAsync(2);
var bacon = FryBaconAsync(3);
var toast = await ToastBreadAsync(2);
ApplyButter(toast);
ApplyJam(toast);
Console.WriteLine("toast is ready");
Juice oj = PourOJ();
Console.WriteLine("oj is ready");
await eggs;
await bacon;
Console.WriteLine("eggs are ready");
Console.WriteLine("bacon is ready");
Console.WriteLine("Breakfast is ready!");
コイツの管理者はコードレビュー大変そう
暇だからリファクタリングしてあげた
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!");
コイツの管理者はコードレビュー大変そう
671デフォルトの名無しさん (ワッチョイ 9901-pIXJ)
2020/01/04(土) 23:47:15.01ID:+Qzz4bCZ0 毎日毎日赤っ恥書きながらも上から目線を崩さない姿勢はだんだん可愛く見えてきたなw
672デフォルトの名無しさん (ワッチョイ 797b-s4wZ)
2020/01/04(土) 23:59:24.33ID:kFIotbKU0 >>670
それはawaitで書けばほぼ現行通りだろ、というわけか。
まあその通りだが、呼び出し側に async が付いているのがミソなんだよ。
今はそれが Task<TResult> だから明示的だが、var になると明示的でなくなる。これがよくない。
また現行の await は事実上フェンスとして使われているから、
君が書き直したその通りなのだけど、俺は既に言ったが、
「フェンスは出来るだけ使わない」(というよりこれは常識とされる)ので、ここが気に入らない。
書かずに済むのだから書かすなよ、だ。
そして現行の関数宣言部、 async を付けるわけだが、これは意味的に要らん。
(現行の仕様でも特に要らないはず)
ジョブの最上位関数はマルチスレッド/シングルスレッド./同期/非同期関係なく同一に書ける。
それをどう呼び出すかで同期/非同期等切り分けるべきであり、
定義側にわざわざ async と非同期専用みたいに書くのが気に入らない。
同期で呼び出したら同期で動作するだけの関数なのに、だ。
それはawaitで書けばほぼ現行通りだろ、というわけか。
まあその通りだが、呼び出し側に async が付いているのがミソなんだよ。
今はそれが Task<TResult> だから明示的だが、var になると明示的でなくなる。これがよくない。
また現行の await は事実上フェンスとして使われているから、
君が書き直したその通りなのだけど、俺は既に言ったが、
「フェンスは出来るだけ使わない」(というよりこれは常識とされる)ので、ここが気に入らない。
書かずに済むのだから書かすなよ、だ。
そして現行の関数宣言部、 async を付けるわけだが、これは意味的に要らん。
(現行の仕様でも特に要らないはず)
ジョブの最上位関数はマルチスレッド/シングルスレッド./同期/非同期関係なく同一に書ける。
それをどう呼び出すかで同期/非同期等切り分けるべきであり、
定義側にわざわざ async と非同期専用みたいに書くのが気に入らない。
同期で呼び出したら同期で動作するだけの関数なのに、だ。
673デフォルトの名無しさん (ワッチョイ 797b-s4wZ)
2020/01/05(日) 00:05:02.27ID:UANz5iul0 >>670
ああ、だから俺は、違いは
同期:
var eggs = FryEggsAsync(2);
非同期:
var eggs = async FryEggsAsync(2);
だけにして欲しいな、ということ。
現行のコードに async を挿入するだけでコアが余っていれば非同期でその関数が実行され、高速化する、ということ。
ああ、だから俺は、違いは
同期:
var eggs = FryEggsAsync(2);
非同期:
var eggs = async FryEggsAsync(2);
だけにして欲しいな、ということ。
現行のコードに async を挿入するだけでコアが余っていれば非同期でその関数が実行され、高速化する、ということ。
674デフォルトの名無しさん (オイコラミネオ MM49-Ivq/)
2020/01/05(日) 00:17:31.34ID:3JPcR/pBM 言語の感想文はブログで書け
薄っぺらい知識なのを宣伝してるだけだぞw
薄っぺらい知識なのを宣伝してるだけだぞw
675デフォルトの名無しさん (ワッチョイ be02-AVGY)
2020/01/05(日) 00:37:05.87ID:T90rRrA70 >>672
あなたの考える仕様はvarの比ではなく、暗黙的でわかりにくい
普通に変数にアクセスしているだけなのに、非同期処理と待ちが入るなんてはっきり言って迷惑
それと呼び出し先を非同期/同期の両方に対応させる設計は良い習慣ではない
・CPUバウンドなら同期的
・IOバウンドなら非同期的
大まかにこの基準で切り分けて、それをシグネチャで明示したほうがいい
あなたの考える仕様はvarの比ではなく、暗黙的でわかりにくい
普通に変数にアクセスしているだけなのに、非同期処理と待ちが入るなんてはっきり言って迷惑
それと呼び出し先を非同期/同期の両方に対応させる設計は良い習慣ではない
・CPUバウンドなら同期的
・IOバウンドなら非同期的
大まかにこの基準で切り分けて、それをシグネチャで明示したほうがいい
676デフォルトの名無しさん (ワッチョイ 426a-UAPS)
2020/01/05(日) 02:47:09.06ID:hKu0nmGg0 C#の仕様策定プロセスはオープンなんだからこんなところでウダウダ言ってないでgithubで提案してみれば?
ツッコミ入って「C#コミュニティはクソ!」って言い出す未来しか見えないけどさ
ツッコミ入って「C#コミュニティはクソ!」って言い出す未来しか見えないけどさ
677デフォルトの名無しさん (ワッチョイ 312f-RM0q)
2020/01/05(日) 04:32:02.28ID:Bbmuqtw40 まさかと思うけど、asyncなメソッドはawaitしないと呼び出せないとか思ってるんじゃないか
678デフォルトの名無しさん (ワッチョイ 797b-s4wZ)
2020/01/05(日) 09:05:43.12ID:UANz5iul0 >>675
varがわかりにくいというのはお前の慣れの問題。
> 待ちが入る
待っているのは同期設計だ。
毎行で「前行の終了を待つ」からブロッキングと呼ばれる。
> それと呼び出し先を非同期/同期の両方に対応させる設計は良い習慣ではない
そんなわけあるか。もう一度言うが、非同期ってのは呼び出し方法であって、ジョブそのもの(関数)の性質ではない。
例えば、MatrixMulという重たい計算があったとする。
すると、日常的にC#で並列をこなすお前らは、これを高速化する為に、Task<TResult>に分割するわけだろ。
その場合、MatrixMulは「同期関数」だが「非同期」で実行される。
「非同期」ってのは関数の性質ではなく、呼び出し方であって、逆に、「非同期関数」を「同期」で呼び出すことも当然出来る。
だから被呼び出し関数に async を付けること自体がナンセンスなんだよ。
付けるとしたら、呼び出し部分か型で、
var eggs = async FryEggs(2);
AsyncTask<Egg> = FryEggs(2);
であって、お前の流儀は
Task<Egg> = FryEggsAsync(2);
なんだろうけど、これはナンセンスなんだよ。ハンガリアンならぬ、アシンカリアンでしかない。
だから、今の仕様は
A. 非同期に慣れてないC#erへの補助輪
B. ヘルスバーグが中二病全開
C. 実はコンパイラの都合で、async付けてくれればパッチ当てがメチャ楽だったから適当こいて付けさせた
のどれかで、俺はBだと思うけど。
なお気持ち悪さではSQLをべた書きするLinqの方が上だと思う。
でも linq を使った関数に一々 linq を付けることもないし、
同様に parallel を使ったら parallel を付けて回る、ということもないんだろ。
await 使ったら async 付ける、ってのは全くナンセンスだよ。
非同期は、今後は、今のお前らが思っているほどは特別なものではなくなるんだよ。これはもう確定してるだろ。
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 付ける、ってのは全くナンセンスだよ。
非同期は、今後は、今のお前らが思っているほどは特別なものではなくなるんだよ。これはもう確定してるだろ。
679デフォルトの名無しさん (ワッチョイ 9901-Ivq/)
2020/01/05(日) 09:35:53.95ID:kO8WyPRk0680デフォルトの名無しさん (ワッチョイ be02-AVGY)
2020/01/05(日) 10:52:51.13ID:T90rRrA70 >>678
自分はvarがわかりにくいとは思ってない
>var になると明示的でなくなる。これがよくない。
あなたがvarをよく思ってなさそうなので、あなたの考えた謎仕様のほうがそれより遥かにわかりにくいですよ、と言っただけ
>そんなわけあるか。もう一度言うが、非同期ってのは呼び出し方法であって、ジョブそのもの(関数)の性質ではない。
これも間違い
例えば、ネットワークやファイルなどIOバウンドな処理は、CPUとは異なるデバイスで処理されるので、原理的に非同期にするしかない
呼び出し先の性質によって非同期が確定する典型例
CPUバウンドの場合、呼び出し先で非同期をサポートすることも可能だが、基本的にそうする必要は無い
スレッディングのコストは無料じゃないのだから、呼び出し先はすべて同期的に実装して切り替えオーバーヘッドを減らしたほうが、全体的なパフォーマンスが向上する
UIと止めずに応答性を高めたいだとか、非同期にする明確な理由が出来たらそこで初めてTask.Runすればいい
上で基本的にと書いたのは、CPUを食い尽くしてでもいいから時間的に早く処理を終わらせたい、という理由で並列化する場合があるからだ
この場合は、プログラムを並列処理用に最適化して設計するのが定石だ
なので、この場合に関しては逆に非効率的な同期版をサポートする理由がなくなる
asyncが構文として不要なのはわかってるが、そんなつまらない話はあなた以外はだれもしてない
自分はvarがわかりにくいとは思ってない
>var になると明示的でなくなる。これがよくない。
あなたがvarをよく思ってなさそうなので、あなたの考えた謎仕様のほうがそれより遥かにわかりにくいですよ、と言っただけ
>そんなわけあるか。もう一度言うが、非同期ってのは呼び出し方法であって、ジョブそのもの(関数)の性質ではない。
これも間違い
例えば、ネットワークやファイルなどIOバウンドな処理は、CPUとは異なるデバイスで処理されるので、原理的に非同期にするしかない
呼び出し先の性質によって非同期が確定する典型例
CPUバウンドの場合、呼び出し先で非同期をサポートすることも可能だが、基本的にそうする必要は無い
スレッディングのコストは無料じゃないのだから、呼び出し先はすべて同期的に実装して切り替えオーバーヘッドを減らしたほうが、全体的なパフォーマンスが向上する
UIと止めずに応答性を高めたいだとか、非同期にする明確な理由が出来たらそこで初めてTask.Runすればいい
上で基本的にと書いたのは、CPUを食い尽くしてでもいいから時間的に早く処理を終わらせたい、という理由で並列化する場合があるからだ
この場合は、プログラムを並列処理用に最適化して設計するのが定石だ
なので、この場合に関しては逆に非効率的な同期版をサポートする理由がなくなる
asyncが構文として不要なのはわかってるが、そんなつまらない話はあなた以外はだれもしてない
681デフォルトの名無しさん (ワッチョイ 7197-eGyC)
2020/01/05(日) 11:21:56.38ID:dqyEtfEv0 なんで比較にLINQが出てくるのかめちゃくちゃ謎
SQLっぽい書き方のLINQしか知らないのかな?
メソッド拡張の方のLINQはmap/filter/reduceと書き方がちょっと違うだけの単なるメソッドを呼び出し
してるだけなんだけど。
SQLっぽい書き方のLINQしか知らないのかな?
メソッド拡張の方のLINQはmap/filter/reduceと書き方がちょっと違うだけの単なるメソッドを呼び出し
してるだけなんだけど。
682デフォルトの名無しさん (ワッチョイ 9901-Ivq/)
2020/01/05(日) 11:33:14.86ID:kO8WyPRk0683デフォルトの名無しさん (ブーイモ MMb6-OcRt)
2020/01/05(日) 12:17:09.89ID:As/vHaVrM awaitは必要だぞ
684デフォルトの名無しさん (ワッチョイ 797b-s4wZ)
2020/01/05(日) 14:01:08.94ID:UANz5iul0 >>680
なるほどお前が全然分かって無いというのは分かった。
根本的に勘違いしていると思うのだけど、ジョブの中身を同期専用/非同期専用で設計することはない。(というか、できない?)
既に言ったが、MatrixMul、要は行列の掛け算が100ジョブあったら、4CPUならそれを4個ずつ積むだけだ。
このとき吐けた順にガンガン積んで処理していきたいなら、
「非同期」にして最初から全部キューイングしてディスパッチャに任せるだけ。
ジョブ自体が「非同期」ではなく、ジョブの処理の仕方が「非同期」なんだよ。
MatrixMulを非同期専用に書き換える、なんて事はない。というか、出来ない。
> 例えば、ネットワークやファイルなどIOバウンドな処理は、CPUとは異なるデバイスで処理されるので、原理的に非同期にするしかない
これもない。というか、C#にしても、他の言語にしても、ファイルオープンは通常は同期だ。
ここはJavaScriptのスレではないのだが、それを間違えたか?
これについては「JavaScript 10k (またはc10k)」でググってくれた方がいいと思う。
Sleepがない方がパフォーマンスが出る!というのがJavaScriptの宗教だから、蕩々と説明してあるはず。
ただしJavaScriptもメジャーになってしまったし、おそらく以前ほど叩かれなくもなっているので、最近はこの話題も聞かないが。
I/Oを非同期として分離する必要があるのは、JavaScriptがSleep無しのシングルスレッドアーキテクチャだからであって、
Sleepありのマルチスレッドアーキテクチャならその必要はないし、C#含めて通常の言語は全部これだよ。
なるほどお前が全然分かって無いというのは分かった。
根本的に勘違いしていると思うのだけど、ジョブの中身を同期専用/非同期専用で設計することはない。(というか、できない?)
既に言ったが、MatrixMul、要は行列の掛け算が100ジョブあったら、4CPUならそれを4個ずつ積むだけだ。
このとき吐けた順にガンガン積んで処理していきたいなら、
「非同期」にして最初から全部キューイングしてディスパッチャに任せるだけ。
ジョブ自体が「非同期」ではなく、ジョブの処理の仕方が「非同期」なんだよ。
MatrixMulを非同期専用に書き換える、なんて事はない。というか、出来ない。
> 例えば、ネットワークやファイルなどIOバウンドな処理は、CPUとは異なるデバイスで処理されるので、原理的に非同期にするしかない
これもない。というか、C#にしても、他の言語にしても、ファイルオープンは通常は同期だ。
ここはJavaScriptのスレではないのだが、それを間違えたか?
これについては「JavaScript 10k (またはc10k)」でググってくれた方がいいと思う。
Sleepがない方がパフォーマンスが出る!というのがJavaScriptの宗教だから、蕩々と説明してあるはず。
ただしJavaScriptもメジャーになってしまったし、おそらく以前ほど叩かれなくもなっているので、最近はこの話題も聞かないが。
I/Oを非同期として分離する必要があるのは、JavaScriptがSleep無しのシングルスレッドアーキテクチャだからであって、
Sleepありのマルチスレッドアーキテクチャならその必要はないし、C#含めて通常の言語は全部これだよ。
685デフォルトの名無しさん (アウアウウー Saa5-CnQr)
2020/01/05(日) 14:56:44.29ID:MI3jwdk/a なんか言い争ってる両者ともそもそも同期非同期の意味が分かってない予感w
686デフォルトの名無しさん (ワッチョイ be02-AVGY)
2020/01/05(日) 14:57:08.99ID:T90rRrA70 >>684
>要は行列の掛け算が100ジョブあったら〜
これは呼び出し先を同期的に実装して、呼び出し元で非同期実行してるパターン
>>680で言うと
>CPUバウンドの場合〜
の段落のこと
このパターンでは呼び出し先は同期版だけサポートすればよく、非同期版までサポートする必要はない
無意味に同期/非同期の両方をサポートしなくていい
>C#にしても、他の言語にしても、ファイルオープンは通常は同期だ。
違う
ファイルIOは背後で非同期的に処理されているが、APIの中でブロックしているから同期的に見えているだけ
昔は言語側の非同期サポートが洗練されていなかったため、妥協してこういう書き方に落ち着いた
C#ではTaskとawaitが導入されて、非同期処理の記述が大きく改善されたため、
原理的に非同期なものは余計なことをしないで、非同期なものとして作れば良い、ということになった
このパターンでは呼び出し先は非同期版だけサポートすればよく、同期版までサポートする必要はない
処理の性質によって同期版か非同期版のどちらかだけを作ればよろしい
>要は行列の掛け算が100ジョブあったら〜
これは呼び出し先を同期的に実装して、呼び出し元で非同期実行してるパターン
>>680で言うと
>CPUバウンドの場合〜
の段落のこと
このパターンでは呼び出し先は同期版だけサポートすればよく、非同期版までサポートする必要はない
無意味に同期/非同期の両方をサポートしなくていい
>C#にしても、他の言語にしても、ファイルオープンは通常は同期だ。
違う
ファイルIOは背後で非同期的に処理されているが、APIの中でブロックしているから同期的に見えているだけ
昔は言語側の非同期サポートが洗練されていなかったため、妥協してこういう書き方に落ち着いた
C#ではTaskとawaitが導入されて、非同期処理の記述が大きく改善されたため、
原理的に非同期なものは余計なことをしないで、非同期なものとして作れば良い、ということになった
このパターンでは呼び出し先は非同期版だけサポートすればよく、同期版までサポートする必要はない
処理の性質によって同期版か非同期版のどちらかだけを作ればよろしい
687デフォルトの名無しさん (ドコグロ MM0a-VrsN)
2020/01/05(日) 15:01:43.69ID:jkDw/EWEM こんなくだらん喧嘩の起きる余地がないGoが流行るのも納得
688デフォルトの名無しさん (ワッチョイ 797b-s4wZ)
2020/01/05(日) 15:26:07.93ID:UANz5iul0 >>686
> 無意味に同期/非同期の両方をサポートしなくていい
無意味も何も、普通に作ったら両対応にしかならないと思うぞ。
逆に、そうならないのなら、コーディングを見直した方がいい。
後半については、多分お前の「非同期」は一般の意味とは違うと思うが、
同期APIと非同期APIの両方が用意されている場合、今後は非同期APIだけ使え、というのはお前の自由だ.。
ただ現実として世の大勢は同期APIで、そしてこれで全く問題ない場合が多く、そうはならないと思うけど。
(例えばファイルなら中身がないと次の処理が出来ず、話を進めようがない事が多い)
なお非同期縛りが心地よいのならJavaScriptを勧める。あれは宗教的にそうなってる。
今はAPIの中身についての話なんてしてない。それがお前流の逃げならそれでもいいが、
ここは「C#でどう書くか」の階層の話をするところであって、APIの中身ガーとか言うのなら最低限先にそう言っておくべきだろ。
ただ俺はそれについてつき合う気はないが。(他の人が食いつくのは自由)
> 無意味に同期/非同期の両方をサポートしなくていい
無意味も何も、普通に作ったら両対応にしかならないと思うぞ。
逆に、そうならないのなら、コーディングを見直した方がいい。
後半については、多分お前の「非同期」は一般の意味とは違うと思うが、
同期APIと非同期APIの両方が用意されている場合、今後は非同期APIだけ使え、というのはお前の自由だ.。
ただ現実として世の大勢は同期APIで、そしてこれで全く問題ない場合が多く、そうはならないと思うけど。
(例えばファイルなら中身がないと次の処理が出来ず、話を進めようがない事が多い)
なお非同期縛りが心地よいのならJavaScriptを勧める。あれは宗教的にそうなってる。
今はAPIの中身についての話なんてしてない。それがお前流の逃げならそれでもいいが、
ここは「C#でどう書くか」の階層の話をするところであって、APIの中身ガーとか言うのなら最低限先にそう言っておくべきだろ。
ただ俺はそれについてつき合う気はないが。(他の人が食いつくのは自由)
689デフォルトの名無しさん (ワッチョイ ed0c-UAPS)
2020/01/05(日) 15:40:34.39ID:eKdfVC3B0 そもC#はSTAとMTAの両方、なんなら混在する環境に対応しなければならないので
どっちかで綺麗に書けるかけるからこうすべきだってお花畑はなかなか通用しないのよね
結局C#においてはasync/awaitもTaskの中で頻発する特定のパターンを楽にしてくれるだけ
>今後は非同期APIだけ使え
新規のAPIではMSはそういう方針だねえ(winrt)
どっちかで綺麗に書けるかけるからこうすべきだってお花畑はなかなか通用しないのよね
結局C#においてはasync/awaitもTaskの中で頻発する特定のパターンを楽にしてくれるだけ
>今後は非同期APIだけ使え
新規のAPIではMSはそういう方針だねえ(winrt)
690デフォルトの名無しさん (ワッチョイ dd02-yXa+)
2020/01/05(日) 18:06:33.11ID:VTWLVkpA0 WPFではファイル操作関数を同期的に呼び出せたが、UWPだと許されない。
ちっちゃいファイルの読込みでGUIの遅延も体感できないぐらいだけどダメなんだ。
ちょっとしたプログラム書く時に面倒だね。
ちっちゃいファイルの読込みでGUIの遅延も体感できないぐらいだけどダメなんだ。
ちょっとしたプログラム書く時に面倒だね。
691デフォルトの名無しさん (ワッチョイ 4d42-UAPS)
2020/01/05(日) 18:11:57.59ID:qdBxOc2v0 >>690
async/awaitあるから普通は問題無くかけるけど、コンストラクターでファイル弄るときは面倒なんだよな
async/awaitあるから普通は問題無くかけるけど、コンストラクターでファイル弄るときは面倒なんだよな
692デフォルトの名無しさん (ワッチョイ dd02-yXa+)
2020/01/05(日) 18:23:07.47ID:VTWLVkpA0 >>690だけど、ちょっと間違った。
同期的には書けるけど、プライマリスレッド(GUI)からだとダメなんだ。
同期的には書けるけど、プライマリスレッド(GUI)からだとダメなんだ。
693デフォルトの名無しさん (ドコグロ MM0a-VrsN)
2020/01/05(日) 19:12:31.63ID:jkDw/EWEM GUIアプリならネイティブスレッドのコストは問題にならないから、
GUIをフリーズさせたくないならイベントハンドラでスレッド起こしてあとは全部同期で書くのが一番シンプルで分かりやすい
最近のC#のasync信仰はWebで膨大なリクエストを捌くときの話で、WinのGUIアプリには全くと言い切っていいほど関係ないよ
GUIをフリーズさせたくないならイベントハンドラでスレッド起こしてあとは全部同期で書くのが一番シンプルで分かりやすい
最近のC#のasync信仰はWebで膨大なリクエストを捌くときの話で、WinのGUIアプリには全くと言い切っていいほど関係ないよ
694デフォルトの名無しさん (ワッチョイ 9901-Ivq/)
2020/01/05(日) 19:23:11.93ID:kO8WyPRk0 >>693
guiのイベントでawaitじゃあかんの?
guiのイベントでawaitじゃあかんの?
695デフォルトの名無しさん (ドコグロ MM0a-VrsN)
2020/01/05(日) 19:34:01.01ID:jkDw/EWEM >>694
もちろんawaitはするよ。
await Task.Run(() => {
//あとは全部同期処理
})
イベントハンドラでこう書くだけ。
コントロールを触るときにInvokeが必要なことさえ忘れなければこれでいい。
ちなみにGoはこの考え方を更に突き詰めて、スレッドを独自の軽量な仕組みに置き換えることでWebも全部同期で書けるようにしてるね。
もちろんawaitはするよ。
await Task.Run(() => {
//あとは全部同期処理
})
イベントハンドラでこう書くだけ。
コントロールを触るときにInvokeが必要なことさえ忘れなければこれでいい。
ちなみにGoはこの考え方を更に突き詰めて、スレッドを独自の軽量な仕組みに置き換えることでWebも全部同期で書けるようにしてるね。
696デフォルトの名無しさん (ワッチョイ 06de-HDsw)
2020/01/05(日) 19:38:18.63ID:AZQzKocv0 invokeしても死ぬときあんじゃん?
→運が悪かったと諦める
→解決するまでひたすら回避策を突っ込んでいく
→マイクロソフトに電話かける
→上記を制限時間いっぱいまで全部やってみる
→運が悪かったと諦める
→解決するまでひたすら回避策を突っ込んでいく
→マイクロソフトに電話かける
→上記を制限時間いっぱいまで全部やってみる
697デフォルトの名無しさん (ブーイモ MM62-eGyC)
2020/01/05(日) 20:03:16.92ID:qqN6BGPlM ファイルオープンは同期的とかいう謎の断定の声もあるけど、
UWPだとオープンも非同期なんだね。
https://docs.microsoft.com/ja-jp/windows/uwp/files/quickstart-reading-and-writing-files
アクセスするストレージへがローカルストレージだけじゃなくてクラウドストレージなのも一般的になってきたから、
ファイルを開くために必要な一連の操作もタイムアウトして失敗する可能性を考えなくちゃならなくなったということなのかな。
UWPだとオープンも非同期なんだね。
https://docs.microsoft.com/ja-jp/windows/uwp/files/quickstart-reading-and-writing-files
アクセスするストレージへがローカルストレージだけじゃなくてクラウドストレージなのも一般的になってきたから、
ファイルを開くために必要な一連の操作もタイムアウトして失敗する可能性を考えなくちゃならなくなったということなのかな。
698デフォルトの名無しさん (ワッチョイ 9901-Ivq/)
2020/01/05(日) 20:08:14.69ID:kO8WyPRk0 >>695
なんだ… それなら
〉最近のC#のasync信仰はWebで膨大なリクエストを捌くときの話で、WinのGUIアプリには全くと言い切っていいほど関係ないよ
とちゃうやん
頭ではわかっているのに言い方が間違ってる(言い方が悪い)人時々いるよな
なんだ… それなら
〉最近のC#のasync信仰はWebで膨大なリクエストを捌くときの話で、WinのGUIアプリには全くと言い切っていいほど関係ないよ
とちゃうやん
頭ではわかっているのに言い方が間違ってる(言い方が悪い)人時々いるよな
699デフォルトの名無しさん (ワッチョイ dd02-yXa+)
2020/01/05(日) 20:47:26.26ID:VTWLVkpA0700デフォルトの名無しさん (ワッチョイ 7197-IH4P)
2020/01/05(日) 20:59:12.88ID:dqyEtfEv0 >>699
UIスレッドでawaitしてもブロッキングにはならないと思うけど。
await以降のコードがawaitしている処理が終わったら実行されるだけで、
処理中は一旦asyncのメソッドを抜けてイベントループに戻るよ
UIスレッドでawaitしてもブロッキングにはならないと思うけど。
await以降のコードがawaitしている処理が終わったら実行されるだけで、
処理中は一旦asyncのメソッドを抜けてイベントループに戻るよ
701デフォルトの名無しさん (アウアウウー Saa5-VrsN)
2020/01/05(日) 21:07:50.78ID:3XFOch5ma702デフォルトの名無しさん (ワッチョイ dd5f-BfT8)
2020/01/05(日) 21:15:43.37ID:GaCs2bDS0703デフォルトの名無しさん (ワッチョイ 9901-Ivq/)
2020/01/05(日) 22:16:53.04ID:kO8WyPRk0 >>701
実行ボタンの場合、何も書かないほうが稀だと思うけど
実行ボタンの場合、何も書かないほうが稀だと思うけど
704デフォルトの名無しさん (アウアウウー Saa5-VrsN)
2020/01/05(日) 22:31:27.48ID:3XFOch5ma >>703
処理結果の反映にInvoke使うんなら不要でしょ
処理結果の反映にInvoke使うんなら不要でしょ
705デフォルトの名無しさん (ワッチョイ 9901-Ivq/)
2020/01/05(日) 22:43:52.66ID:kO8WyPRk0 >>704
ボタンの連打対策が必要とか、普通にプログラム書いてる人ならわかると思うんだけど
ボタンの連打対策が必要とか、普通にプログラム書いてる人ならわかると思うんだけど
706デフォルトの名無しさん (アウアウウー Saa5-VrsN)
2020/01/05(日) 22:53:53.05ID:3XFOch5ma707デフォルトの名無しさん (アウアウウー Saa5-VrsN)
2020/01/05(日) 23:03:25.02ID:3XFOch5ma もしかして705はBeginInvokeと勘違いしてるんだろうか
InvokeはUIスレッド上で実際に処理が完了するまで呼出元のスレッドをブロックするから、連打対策のような用途にも使えるんだよ
なぜかコピペサイトではBeginInvokeだけ紹介されてることが多くて、意外とInvokeの方は知られてなかったりするんだよね
よく理解しないで使ってデッドロックさせるアホがいるからかな
InvokeはUIスレッド上で実際に処理が完了するまで呼出元のスレッドをブロックするから、連打対策のような用途にも使えるんだよ
なぜかコピペサイトではBeginInvokeだけ紹介されてることが多くて、意外とInvokeの方は知られてなかったりするんだよね
よく理解しないで使ってデッドロックさせるアホがいるからかな
708デフォルトの名無しさん (アウアウウー Saa5-CnQr)
2020/01/05(日) 23:09:20.18ID:MI3jwdk/a 何を争ってるのかよく分からんけど、連打対策になるって主張もよく分かんないねw
709デフォルトの名無しさん (アウアウウー Saa5-VrsN)
2020/01/05(日) 23:12:07.22ID:3XFOch5ma いや、そもそも処理終了後にEnabledを戻すだけならBeginInvokeでもいいか
細かいことを言えばInvoke/BeginInvokeだと一度メッセージループに処理が返ってしまい連打を防ぎきれない可能性があるから
無効化の方はRunの前にやっておく方がベターだけど、いずれにせよ後続処理はRunの中からInvoke/BeginInvokeで問題ないね
(というか振る舞いは等価)
細かいことを言えばInvoke/BeginInvokeだと一度メッセージループに処理が返ってしまい連打を防ぎきれない可能性があるから
無効化の方はRunの前にやっておく方がベターだけど、いずれにせよ後続処理はRunの中からInvoke/BeginInvokeで問題ないね
(というか振る舞いは等価)
710デフォルトの名無しさん (ワッチョイ 3102-UAPS)
2020/01/05(日) 23:13:02.39ID:XwlRh/tg0 継続ブロックがUIスレッドに戻ってくるからInvoke不要ってのがasyncイベントハンドラの価値じゃねえのん
逆にメリットそれだけだからTaskに包んで書こうが構わんやろって向きもあるんだろうけど
マそもそも同期コンテキストの前提がおけないライブラリ内のコードでは
継続ブロックがどのスレッドで動き出すかわからないなんてことも普通にあるので
ConfigureAwaitとか必要悪ともお付き合いせにゃならんのが辛いところネー
逆にメリットそれだけだからTaskに包んで書こうが構わんやろって向きもあるんだろうけど
マそもそも同期コンテキストの前提がおけないライブラリ内のコードでは
継続ブロックがどのスレッドで動き出すかわからないなんてことも普通にあるので
ConfigureAwaitとか必要悪ともお付き合いせにゃならんのが辛いところネー
711デフォルトの名無しさん (ワッチョイ 7197-IH4P)
2020/01/05(日) 23:19:25.32ID:dqyEtfEv0 >>706
それはTaskだけでなんでも出来るからawaitなんかいらないよ言ってることにならない?
もちろんInvoke使えばできるだろうけど、アニメーションなんかが絡むとコールバックだらけになりそうな気がする。
Task.Runの中のInvokeにはプログレスバーを進める、テキストエリアにテキストログを出す、
みたいなあまり本質的でないUIの変更にとどめておいて、本格的な処理結果の表示はawait以降に書く、なんてのも
コードの読みやすさの確保のためには有効な手順じゃないかな。自分はそうしてる。
それはTaskだけでなんでも出来るからawaitなんかいらないよ言ってることにならない?
もちろんInvoke使えばできるだろうけど、アニメーションなんかが絡むとコールバックだらけになりそうな気がする。
Task.Runの中のInvokeにはプログレスバーを進める、テキストエリアにテキストログを出す、
みたいなあまり本質的でないUIの変更にとどめておいて、本格的な処理結果の表示はawait以降に書く、なんてのも
コードの読みやすさの確保のためには有効な手順じゃないかな。自分はそうしてる。
712デフォルトの名無しさん (ワッチョイ 9901-Ivq/)
2020/01/06(月) 00:46:28.60ID:3wPOSvMe0 >>709
実際にそんなソース書くようなやつはセンス無いから、営業や総務に異動させるわ
実際にそんなソース書くようなやつはセンス無いから、営業や総務に異動させるわ
713デフォルトの名無しさん (ワッチョイ 9901-W0QA)
2020/01/06(月) 18:16:42.26ID:Qm/elW020 ファイルサーバにC#のサービスを常駐させてクライアントからリクエスト受けたらdosコマンドを実行したいのですがどういう技術で実現出来るでしょうか?
単純にサービスだとリクエストをどう受ければ良いのだろうと悩んでおります
単純にサービスだとリクエストをどう受ければ良いのだろうと悩んでおります
714デフォルトの名無しさん (ドコグロ MM75-VrsN)
2020/01/06(月) 18:26:36.55ID:+ezJCAApM そんなもんApacheでも立ててCGIでええやろ
C#なんぞ要らん
C#なんぞ要らん
715デフォルトの名無しさん (ワッチョイ 9901-W0QA)
2020/01/06(月) 18:33:44.24ID:Qm/elW020 昔なんですけどwebサーバ立てないでリクエスト受け付けるサービス作ってた人が居たんです
そんなこと出来るんだと思った数年後の現在調べてみても何の技術か解らず
C#で作られていたのは覚えてるのですが
そんなこと出来るんだと思った数年後の現在調べてみても何の技術か解らず
C#で作られていたのは覚えてるのですが
716デフォルトの名無しさん (ワッチョイ 9d17-UAPS)
2020/01/06(月) 18:38:57.81ID:X36Zclkj0 サービス作った人にやり方を聞けばいいのでは
717デフォルトの名無しさん (ワッチョイ 42ad-f3Fz)
2020/01/06(月) 18:42:12.36ID:HrPzlOWn0 >>713
https://dobon.net/vb/dotnet/internet/tcpclientserver.html
ソケットで受けてProcess.Startとかすればいけると思うけどあまりお勧めしない
https://dobon.net/vb/dotnet/internet/tcpclientserver.html
ソケットで受けてProcess.Startとかすればいけると思うけどあまりお勧めしない
718デフォルトの名無しさん (ブーイモ MMb6-OcRt)
2020/01/06(月) 18:48:18.84ID:sG64rza2M System.Net.HttpListenerのこと言ってる?
719デフォルトの名無しさん (ワッチョイ dd5f-BtD6)
2020/01/06(月) 21:20:55.59ID:/c/Em2OW0 >>715
TcpListener/TcpClientでSocketをそのまま使うかWCFかな
TcpListener/TcpClientでSocketをそのまま使うかWCFかな
720デフォルトの名無しさん (ワッチョイ 8201-TJkF)
2020/01/06(月) 21:47:44.44ID:78RinjQr0 >>713
どうやって実現するかを考える前に
解決したい問題を定義することからはじめたほうがいい
そうしないと適切な選択肢を発見できない可能性が高いから
このケースで問題の定義ってのは
「どういう処理を、どういう理由で、どういう制約の中で実行したいのか」
どうやって実現するかを考える前に
解決したい問題を定義することからはじめたほうがいい
そうしないと適切な選択肢を発見できない可能性が高いから
このケースで問題の定義ってのは
「どういう処理を、どういう理由で、どういう制約の中で実行したいのか」
721デフォルトの名無しさん (ワッチョイ 422c-RM0q)
2020/01/07(火) 00:56:13.00ID:ueOqy5pf0 >>715
そりゃ、Ruby でも、socket モジュールで、TCP サーバーを作れるけど、そんな面倒な事はしない。
Sinatra を使えば、ルーティングまで出来るし、
他にも、PowerShell から、1-liner で、
Rubyで作られた、遅い標準ウェブサーバーの、WEBrick も起動できる
ruby -run -e httpd . -p 8080
そのフォルダに、index.html があれば、
何も考えなくても、これでブラウザからアクセスできる
http://localhost:8080
そりゃ、Ruby でも、socket モジュールで、TCP サーバーを作れるけど、そんな面倒な事はしない。
Sinatra を使えば、ルーティングまで出来るし、
他にも、PowerShell から、1-liner で、
Rubyで作られた、遅い標準ウェブサーバーの、WEBrick も起動できる
ruby -run -e httpd . -p 8080
そのフォルダに、index.html があれば、
何も考えなくても、これでブラウザからアクセスできる
http://localhost:8080
722デフォルトの名無しさん (ワッチョイ ade6-UAPS)
2020/01/07(火) 01:21:55.02ID:j8v37+r+0 IIS Expressは?
723デフォルトの名無しさん (ワッチョイ e2cf-UAPS)
2020/01/07(火) 01:28:51.16ID:ROWMtFOx0 C#で作られたらしいのになぜか他言語推しするやつw
724デフォルトの名無しさん (ワッチョイ 9901-W0QA)
2020/01/07(火) 07:07:29.19ID:HzCvb3eG0 WCFという言葉を聞いた事があるのでそれかと思います
調べてみます
ありがとうございます
調べてみます
ありがとうございます
725デフォルトの名無しさん (ワッチョイ 9901-W0QA)
2020/01/07(火) 07:12:14.82ID:HzCvb3eG0726デフォルトの名無しさん (ワンミングク MM92-Lg55)
2020/01/07(火) 16:22:44.68ID:W35nJ2lzM .NET 5で何か変わると思う?
727デフォルトの名無しさん (ドコグロ MM75-VrsN)
2020/01/07(火) 17:03:30.97ID:muv+YNpYM .NET5は4.x以前とは全くの別物であり、何もかも変わると思っておけばいい
業務ドカタは永遠に4.8から移行しないだろうから、Web系との間で深刻な分断が生じることになる
業務ドカタは永遠に4.8から移行しないだろうから、Web系との間で深刻な分断が生じることになる
728デフォルトの名無しさん (ワッチョイ d188-IJNu)
2020/01/07(火) 18:26:40.26ID:RhWBTAz60 未だにwin7な企業もわんさかいるし4.8は向こう5年くらいは現役になっちゃうだろうねー
729デフォルトの名無しさん (ワッチョイ c210-E95m)
2020/01/07(火) 18:51:41.45ID:4CH2lMXx0 ぇー
4.8から5に移植する必要がでてくるの?
4.8から5に移植する必要がでてくるの?
730デフォルトの名無しさん (ワッチョイ e2cf-UAPS)
2020/01/07(火) 19:12:37.85ID:ROWMtFOx0 そんな変わらんから
731デフォルトの名無しさん (ドコグロ MM75-VrsN)
2020/01/07(火) 20:12:30.06ID:muv+YNpYM >>730
WebFormsが使えないから、既存の.NETアプリの半分くらいは完全に死亡するよ
WebFormsが使えないから、既存の.NETアプリの半分くらいは完全に死亡するよ
732デフォルトの名無しさん (ドコグロ MM75-VrsN)
2020/01/07(火) 20:26:57.89ID:muv+YNpYM あとヤバいのはWCF&.NET Remoting死亡あたりだな
経験上、Classic ASP.NETは使ってるつもりがなくてもユーティリティ類を使ってしまってるケースが結構多くて、大規模なアプリはだいたい死ぬ
経験上、Classic ASP.NETは使ってるつもりがなくてもユーティリティ類を使ってしまってるケースが結構多くて、大規模なアプリはだいたい死ぬ
733デフォルトの名無しさん (ドコグロ MM75-VrsN)
2020/01/07(火) 20:32:52.17ID:muv+YNpYM あと厄介なのがNuGetの依存関係ね
SDKのバージョンを上げるとだいたいNuGetパッケージのバージョンアップ祭りになるんで、だいたいどっかの破壊的変更を踏んで逝く
SDKのバージョンを上げるとだいたいNuGetパッケージのバージョンアップ祭りになるんで、だいたいどっかの破壊的変更を踏んで逝く
734デフォルトの名無しさん (ワッチョイ 426a-UAPS)
2020/01/07(火) 22:31:07.85ID:o9NgJRxS0735デフォルトの名無しさん (ワッチョイ 0642-UAPS)
2020/01/07(火) 23:04:37.23ID:wcxyvOp00 >>734
VB6はC#より早いしWinFormsと見た目もそれほど変わらんからな
VB6はC#より早いしWinFormsと見た目もそれほど変わらんからな
736デフォルトの名無しさん (ワッチョイ 9d17-UAPS)
2020/01/07(火) 23:20:19.80ID:b0Bey+qG0 VS2010以降の操作性に慣れたらVB6には戻りたくないわ
737デフォルトの名無しさん (アウアウウー Saa5-VrsN)
2020/01/07(火) 23:26:15.05ID:8JDfUSzea .NET CoreはLTSでも3年でサポートが切れる
もし.NET5も同じならドカタITでは互換性以前に検討にも値しないレベル
もし.NET5も同じならドカタITでは互換性以前に検討にも値しないレベル
738デフォルトの名無しさん (ワッチョイ 7fad-wbog)
2020/01/08(水) 00:38:18.01ID:HFuLNThA0 Java8的な感じで残りそうな気もする
4.8で打ち止めなら枯れて安定してるし
4.8で打ち止めなら枯れて安定してるし
739デフォルトの名無しさん (ワッチョイ 5fae-Hp8P)
2020/01/08(水) 17:07:05.84ID:Jh9kZvPt0 WinFormのTextboxやRichTextBoxを使用して、
エスケープシーケンスの様に文字単位で色を変えることは可能でしょうか?
String str = "例文:\red赤\r\n \green緑\r\n \black黒\r\n"; // \red \green \blackは仮想のエスケープシーケンス
TextBox.Text = str;
例えば上記で、赤・緑・黒の色がそれぞれ変えるのは可能でしょうか?
それともエスケープシーケンスは改行やTABにだけ対応していて、
色までは対応していなくて不可能でしょうか?
エスケープシーケンスの様に文字単位で色を変えることは可能でしょうか?
String str = "例文:\red赤\r\n \green緑\r\n \black黒\r\n"; // \red \green \blackは仮想のエスケープシーケンス
TextBox.Text = str;
例えば上記で、赤・緑・黒の色がそれぞれ変えるのは可能でしょうか?
それともエスケープシーケンスは改行やTABにだけ対応していて、
色までは対応していなくて不可能でしょうか?
740デフォルトの名無しさん (ワキゲー MM7f-DGfv)
2020/01/08(水) 17:42:23.45ID:S7vQ7ZowM \redって赤と復帰文字+edの区別つかないじゃん
それはともかくRichTextBoxとRTFを使えばまあ似たようなことはできる
RTFを一から書くのは拷問だけど
それはともかくRichTextBoxとRTFを使えばまあ似たようなことはできる
RTFを一から書くのは拷問だけど
741デフォルトの名無しさん (アウアウウー Saa3-7oRq)
2020/01/08(水) 18:32:11.60ID:6iphn5xQa >>739
ちょっと何言ってるのかよく分からないけど、
C#のコードでエスケープシーケンスを含む文字列リテラルを書いた時、
それがそのままバイナリになると勘違いしてない?
あれ、コンパイラが対応する文字に置き換えてるんだよw
ちょっと何言ってるのかよく分からないけど、
C#のコードでエスケープシーケンスを含む文字列リテラルを書いた時、
それがそのままバイナリになると勘違いしてない?
あれ、コンパイラが対応する文字に置き換えてるんだよw
742デフォルトの名無しさん (ワッチョイ ff28-wBwZ)
2020/01/11(土) 10:46:33.04ID:IVNUyUW+0 C#でできることってすべてF#で(多少複雑になったとしても)実現できますか?
同じ共通言語基盤上にあってもC#だけで可能なことってあるんでしょうか。
(もちろん、どちらも計算完備なのでC#でできることは
それこそBASICでもできるでしょうが、そういう意味ではなくて
.NET上での共通性の話です)
同じ共通言語基盤上にあってもC#だけで可能なことってあるんでしょうか。
(もちろん、どちらも計算完備なのでC#でできることは
それこそBASICでもできるでしょうが、そういう意味ではなくて
.NET上での共通性の話です)
743デフォルトの名無しさん (ドコグロ MM7f-JyDu)
2020/01/11(土) 12:49:57.55ID:Uc6AtsCZM744デフォルトの名無しさん (ワッチョイ ff28-wBwZ)
2020/01/11(土) 16:36:56.68ID:IVNUyUW+0745デフォルトの名無しさん (ワッチョイ ff7c-DGfv)
2020/01/14(火) 09:13:37.09ID:/tPlPF6x0 https://www.atmarkit.co.jp/ait/articles/1710/03/news018.html
一応C#も対話的に実行できる
一応C#も対話的に実行できる
746デフォルトの名無しさん (ブーイモ MM0f-rUPC)
2020/01/14(火) 09:19:18.61ID:HiotJy5MM >>745
へーこれってどんな仕組み?コンパイル必要としてないの?
へーこれってどんな仕組み?コンパイル必要としてないの?
747742 (ワッチョイ 7e28-V2kM)
2020/01/15(水) 18:27:50.06ID:YlxQUfnE0748デフォルトの名無しさん (ブーイモ MMcd-gA+Q)
2020/01/15(水) 21:17:39.40ID:jOuGOKj7M なんだと…ゴゴゴゴ
749デフォルトの名無しさん (ワッチョイ d197-sxSO)
2020/01/15(水) 23:02:14.43ID:k9iUnicj0 C# Interactive, 64bitで実行できるようになるのはいつなのかねえ。便利なんだけどたまに困る。
xamarin workbookとかも代替であるんだろうけど。
xamarin workbookとかも代替であるんだろうけど。
750デフォルトの名無しさん (ワッチョイ cd90-JESV)
2020/01/16(木) 00:16:18.83ID:CC5bpFwG0 誰だってわかりやすくて書きやすい言語でプログラミングしたいに決まってんじゃん
C#はまだわかるけど難解ぶってるオナニー言語は滅んだ方がいいね
C#はまだわかるけど難解ぶってるオナニー言語は滅んだ方がいいね
751デフォルトの名無しさん (ワッチョイ ae8f-A78j)
2020/01/17(金) 01:22:15.96ID:atTN5w3j0 まあ、たしかに defun(((((( なんか嫌だもんな。
752デフォルトの名無しさん (ワッチョイ 5f15-1kxO)
2020/01/24(金) 22:14:55.39ID:k9osu5pp0 forおじさんなるキーワードを知ったんだけど今forは使っちゃいかんの?
c#には直接関係ないけどさ
c#には直接関係ないけどさ
753デフォルトの名無しさん (ワッチョイ 5f6a-bOFn)
2020/01/24(金) 22:23:17.00ID:ckgx8D9Z0 他にbetterな方法がある場合でも、とにかくforをつかえってのを揶揄してるだけでしょ
754デフォルトの名無しさん (ブーイモ MMcf-PIvP)
2020/01/24(金) 22:59:35.08ID:1f1Z8E2rM マーティンも今どきforは臭いからパイプライン使えみたいなこと言ってたな
755デフォルトの名無しさん (ワッチョイ 6a02-ZTBJ)
2020/02/04(火) 07:23:29.54ID:2P9jYwzY0 ifとforで何重にもネストさせるやつ未だにいるからな
レビューで暴言吐きそうになって困るからやめてほしい
レビューで暴言吐きそうになって困るからやめてほしい
756デフォルトの名無しさん (JP 0H2e-5BC/)
2020/02/04(火) 08:13:40.65ID:oN9vo+PdH757デフォルトの名無しさん (ワッチョイ 3628-A+Jj)
2020/02/04(火) 12:44:04.58ID:M0ahQJ780 見た目だけじゃなくて処理効率も変わるのかな?
C#みたいな言語だとforだろうがmapだろうがコンパイラがよしなに最適化してくれそう(適当)
C#みたいな言語だとforだろうがmapだろうがコンパイラがよしなに最適化してくれそう(適当)
758デフォルトの名無しさん (オッペケ Srbd-Y6bJ)
2020/02/04(火) 19:03:41.12ID:XAK/YcTOr 実際意味は違うので用途次第ということ
759デフォルトの名無しさん (ワッチョイ a902-nz5b)
2020/02/04(火) 22:00:23.17ID:kfb5o96m0 期待通りの順番で処理してもらえるのか?
不安なんでfor使ったりすることあるね。
不安なんでfor使ったりすることあるね。
760デフォルトの名無しさん (ブーイモ MM8e-YgEg)
2020/02/04(火) 22:07:47.88ID:Z8KA+tSJM 順番が気になる処理はなるべく書かない
761デフォルトの名無しさん (ワッチョイ 6663-3Mgd)
2020/02/04(火) 22:56:53.13ID:ozqUNPd80 馬鹿の一つ覚え
762デフォルトの名無しさん (ワッチョイ 9f6a-56gX)
2020/02/05(水) 00:50:35.93ID:+dC8QpOa0 >>754
すまん、ジジイなんで勉強したいからソース教えてほしい
すまん、ジジイなんで勉強したいからソース教えてほしい
763デフォルトの名無しさん (ワッチョイ d724-56gX)
2020/02/05(水) 13:31:41.51ID:OSDzuje90764デフォルトの名無しさん (ワンミングク MM7f-gP8z)
2020/02/05(水) 14:05:00.81ID:AaNsO0iwM 可読性より性能重視でfor使いまくることあるです
765デフォルトの名無しさん (ブーイモ MMcf-gAEv)
2020/02/05(水) 14:14:25.44ID:N1rQ6Y7rM 性能が必要なら言語かえますし
766デフォルトの名無しさん (JP 0H4f-w9wO)
2020/02/05(水) 18:36:26.77ID:NPiSCXLeH アセンブラ最速(要最適化)
767デフォルトの名無しさん (オッペケ Sr0b-RXZG)
2020/02/05(水) 21:42:19.79ID:qmME163kr レベル高いのはlinqやforをちゃんと使い分けれる人
レベルが低い人はどちらかしか使わない人
レベルが低い人はどちらかしか使わない人
768デフォルトの名無しさん (ワッチョイ 3715-VkLk)
2020/02/05(水) 23:51:29.21ID:JHMrCxaG0 Linqってnullがあった時面倒な印象がある
実装当時はselectみたいな予約語を中途半端に実装したってどっかで見た記憶があるけど増えたのかね?
実装当時はselectみたいな予約語を中途半端に実装したってどっかで見た記憶があるけど増えたのかね?
769デフォルトの名無しさん (ワッチョイ 5797-IOUD)
2020/02/06(木) 11:04:45.02ID:y+neP3Z40 もちろんLINQでもforでも書けるけど、LINQで遅そうな処理で、それが作っている
ソフトの決定的なパフォーマンス問題につながりそうなら、forで書いてみて
ベンチマークしてどっちを採用するか決めるかな。
forの方がありとあらゆる言語で書ける書き方だから当然書けるけど、
LINQの方はPythonの内包表記やmap/filter/reduceの書き方に近くいから
こっちも当然書けるし、短いし一時変数用意しなくていいから基本LINQ使っちゃうよね。
ソフトの決定的なパフォーマンス問題につながりそうなら、forで書いてみて
ベンチマークしてどっちを採用するか決めるかな。
forの方がありとあらゆる言語で書ける書き方だから当然書けるけど、
LINQの方はPythonの内包表記やmap/filter/reduceの書き方に近くいから
こっちも当然書けるし、短いし一時変数用意しなくていいから基本LINQ使っちゃうよね。
770デフォルトの名無しさん (ブーイモ MMbf-gAEv)
2020/02/06(木) 12:27:26.13ID:BIpKXfQOM forでないと書けないってコードが汚いだけの場合が殆どだからまずそっちをリファクタリングする
すると自然とLINQで書けるようになる
LINQで遅いのは件数が多すぎるかキャッシュを使ってない場合なので実はforに変えただけじゃたかが知れてる
すると自然とLINQで書けるようになる
LINQで遅いのは件数が多すぎるかキャッシュを使ってない場合なので実はforに変えただけじゃたかが知れてる
771デフォルトの名無しさん (オッペケ Sr0b-RXZG)
2020/02/06(木) 18:42:57.79ID:ePr9F6TEr あまり大したことに使ってなさそう
772デフォルトの名無しさん (オッペケ Sr0b-RXZG)
2020/02/06(木) 18:45:07.13ID:ePr9F6TEr > forでないと書けないってコードが汚いだけの場合が殆ど
そうは思わないけどw
そうは思わないけどw
773デフォルトの名無しさん (オッペケ Sr0b-RXZG)
2020/02/06(木) 18:54:05.90ID:ePr9F6TEr774デフォルトの名無しさん (オッペケ Sr0b-RXZG)
2020/02/06(木) 18:55:11.26ID:ePr9F6TEr linqでしか書けない人は最下層
forでしか書けない人はそのやや上
forでしか書けない人はそのやや上
775デフォルトの名無しさん (ブーイモ MMbf-gAEv)
2020/02/06(木) 19:33:48.33ID:BIpKXfQOM forでしか書かない人は使い物にならないおじいさん
無理してでもLINQでしか書かないのはまだまだ研鑽が足りない
意識しなくても自然とLINQになってるのが達人プログラマ
無理してでもLINQでしか書かないのはまだまだ研鑽が足りない
意識しなくても自然とLINQになってるのが達人プログラマ
776デフォルトの名無しさん (ワッチョイ d701-3aYi)
2020/02/06(木) 20:55:07.31ID:WBT6cCNm0 POSTとかGETのレスポンス速度って、自分の回線速度と相手側のサーバー速度依存ですか?
プログラムの処理でコンマ数秒でも早くする方法ってあったりします?
プログラムの処理でコンマ数秒でも早くする方法ってあったりします?
777デフォルトの名無しさん (オッペケ Sr0b-RXZG)
2020/02/06(木) 21:12:13.83ID:ePr9F6TEr 普通はないよ
アメリカとかにPOSTして帰って来てるんだとしたらそもそも物理的な距離も問題になる
アメリカとかにPOSTして帰って来てるんだとしたらそもそも物理的な距離も問題になる
778デフォルトの名無しさん (オッペケ Sr0b-RXZG)
2020/02/06(木) 21:16:32.05ID:ePr9F6TEr どうでもいいけど回線速度と言うのも変な表現だな
帯域依存だな
最初のレスポンス自体が帰ってくる速度は同じだけど取れる帯域が広いと早くダウンロードが終わる
帯域依存だな
最初のレスポンス自体が帰ってくる速度は同じだけど取れる帯域が広いと早くダウンロードが終わる
779デフォルトの名無しさん (ワッチョイ d72f-ndoi)
2020/02/06(木) 22:57:37.84ID:O+zcmlkO0 ダウンロードの時間じゃなくてレスポンスの話だろ
帯域よりレイテンシのほうが問題だと思うが
帯域よりレイテンシのほうが問題だと思うが
780デフォルトの名無しさん (JP 0H4f-w9wO)
2020/02/07(金) 08:11:56.59ID:EMrYQo7/H 相手側のサーバーまで全部依存ですよね
ちなみに、普通にwebとかで見えてるサーバーは、必ずping返してくれるの?
ちなみに、普通にwebとかで見えてるサーバーは、必ずping返してくれるの?
781デフォルトの名無しさん (オッペケ Sr0b-glrA)
2020/02/07(金) 12:33:07.85ID:etaMDs5Yr ping返さないサーバはいくらでもある
782デフォルトの名無しさん (アウウィフ FF9b-VM48)
2020/02/07(金) 17:30:10.02ID:PWhN+bN7F783デフォルトの名無しさん (アウアウカー Sa6b-Za6j)
2020/02/07(金) 20:27:13.28ID:q5ptBTCZa フォームデータなのに?
784デフォルトの名無しさん (ワッチョイ 571d-uqPE)
2020/02/07(金) 23:07:36.53ID:GxNDg+Fe0 【与沢翼】労働収入を高くしても無駄!税金でほとんど持っていかれますよ。
金持ちになるにはたった2つしか方法がない
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
金持ちになるにはたった2つしか方法がない
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
785デフォルトの名無しさん (ワッチョイ d735-oJhu)
2020/02/08(土) 18:20:20.80ID:0YppiA+B0 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では正常に動作します。
エラーの原因と解決策を教えてください。
ランタイム: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では正常に動作します。
エラーの原因と解決策を教えてください。
786デフォルトの名無しさん (ワッチョイ d735-oJhu)
2020/02/08(土) 18:23:37.92ID:0YppiA+B0 AngleSharpを入れるとこのエラーがでます。
AngleSharpを入れるとバイナリのフォルダにSystem.***という大量のDLLができます。
AngleSharpを入れるとバイナリのフォルダにSystem.***という大量のDLLができます。
787デフォルトの名無しさん (ワッチョイ d735-oJhu)
2020/02/08(土) 18:24:23.44ID:0YppiA+B0 ターゲットは.NET Framework4.6.1です
788デフォルトの名無しさん (オッペケ Sr0b-RXZG)
2020/02/08(土) 19:17:58.13ID:1TiVu9qyr789デフォルトの名無しさん (ワッチョイ d735-oJhu)
2020/02/08(土) 19:25:53.91ID:0YppiA+B0790デフォルトの名無しさん (ワッチョイ d735-oJhu)
2020/02/08(土) 19:31:11.67ID:0YppiA+B0 AngleSharpを入れるとそれを使用しなくても関係ないところでエラーが出る理由がわかりませんね
791デフォルトの名無しさん (オッペケ Sr0b-RXZG)
2020/02/08(土) 19:41:46.38ID:1TiVu9qyr バージョンがあってないからだろ
初心者向けのふらっとスレに行け
まず
.Netにはいろいろ種類があると言うことをしり特性を知れ
次に.net standardが何か調べろ
そして使いたいフレームワークが.net standardで何に当たるか調べろ
次にServicePointManager クラスが自分の使いたいフレームワークで使えるかどうかMSのサイトをみて調べろ
初心者向けのふらっとスレに行け
まず
.Netにはいろいろ種類があると言うことをしり特性を知れ
次に.net standardが何か調べろ
そして使いたいフレームワークが.net standardで何に当たるか調べろ
次にServicePointManager クラスが自分の使いたいフレームワークで使えるかどうかMSのサイトをみて調べろ
792デフォルトの名無しさん (ワッチョイ d735-oJhu)
2020/02/08(土) 19:54:30.33ID:0YppiA+B0 こちらの質問は却下します
793デフォルトの名無しさん (オッペケ Sr0b-RXZG)
2020/02/08(土) 19:59:03.78ID:1TiVu9qyr standardというパワー綴り
794デフォルトの名無しさん (ワッチョイ de89-GUQA)
2020/02/13(木) 11:12:59.64ID:cLFC91tC0 startupでデフォルトのDB接続先でapp.CreatePerOwinContextを登録してるのだが
途中でDB接続先を変更出来たりしないですか?
コントローラーのOnActionExecutingでfilterContext.HttpContext.GetOwinContext().Set(wkUserManager);
で変更したんだが、他画面にいくとリセットされてるというか元が変わってないというか
途中でDB接続先を変更出来たりしないですか?
コントローラーのOnActionExecutingでfilterContext.HttpContext.GetOwinContext().Set(wkUserManager);
で変更したんだが、他画面にいくとリセットされてるというか元が変わってないというか
795デフォルトの名無しさん (ワッチョイ 1f24-2Bv+)
2020/02/13(木) 19:44:16.71ID:o7NRbkWy0 ライブラリの話が出ているので自分も質問させて頂きたいんですが、SevenZipSharp(by squid-box)使ってる方いないでしょうか?
分割されたRAR5.0を解凍する際にファイルが壊れてる的なエラーが出て解凍できないことがあるのはバグでしょうか?(純正7Zipアプリでなら正常に解凍できるため実際には壊れていない)
どうやら1GB程以上の大きい分割ファイルだとそうなることが多いようで、数百MB程度の分割ファイルなら問題なく解凍は出来ます
単体のRARであれば1GB以上の巨大圧縮も解凍できるためメモリ周りのエラーと言う事でもなさそうなのですが
分割されたRAR5.0を解凍する際にファイルが壊れてる的なエラーが出て解凍できないことがあるのはバグでしょうか?(純正7Zipアプリでなら正常に解凍できるため実際には壊れていない)
どうやら1GB程以上の大きい分割ファイルだとそうなることが多いようで、数百MB程度の分割ファイルなら問題なく解凍は出来ます
単体のRARであれば1GB以上の巨大圧縮も解凍できるためメモリ周りのエラーと言う事でもなさそうなのですが
796デフォルトの名無しさん (ワッチョイ 477b-yNzz)
2020/02/15(土) 13:09:48.07ID:M9LrwgB50 TabControl上の『選択されていないTabPage上の』ボタンをプログラムからクリックしたいんだが、どうすればいいのだ?
試したことは以下。
((Button^)ctrl)->PerformClick(); // ボタンが見えてないと(ボタンのあるTabPageが選択されていないと)ClickEventが発生しない(以下※1)
((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を切り替えて逃げているが、
バッチ中に一々画面が変わるので出来ればそのままで処理したい。
試したことは以下。
((Button^)ctrl)->PerformClick(); // ボタンが見えてないと(ボタンのあるTabPageが選択されていないと)ClickEventが発生しない(以下※1)
((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を切り替えて逃げているが、
バッチ中に一々画面が変わるので出来ればそのままで処理したい。
797デフォルトの名無しさん (ワッチョイ 477b-yNzz)
2020/02/15(土) 13:10:05.98ID:M9LrwgB50 ※1
書いてあることとはこちらの状況と合致しているわけでもないが、とにかく見えてないと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
書いてあることとはこちらの状況と合致しているわけでもないが、とにかく見えてないと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
798デフォルトの名無しさん (アウアウウー Sac3-+wK4)
2020/02/15(土) 14:11:22.37ID:D6Qol+wpa >>796
表示されているかどうかの問題ではないと思う。
TabPageのコンテナ(およびその上のコントロール)はそのページが初めて
表示されるまで「作成」(CreateControl)されない仕様だった気が。
知らんけど
表示されているかどうかの問題ではないと思う。
TabPageのコンテナ(およびその上のコントロール)はそのページが初めて
表示されるまで「作成」(CreateControl)されない仕様だった気が。
知らんけど
799デフォルトの名無しさん (ワッチョイ 477b-yNzz)
2020/02/15(土) 14:34:26.54ID:M9LrwgB50 >>798
過去一度でも表示されたことがあるか、なら、確実に一度は表示されている。(初期画面のタブなので)
そして一応、直前に表示した状況でも試してみたが、やはりPerformClickは反応しない。
(「スクリプト実行ボタン」と「スクリプトから押したいボタン」が同一TabControlの別ページにあるので、
タブを切り替えた直後に実行ボタンを押してみたが、駄目だった)
ただしその挙動は少し覚えがあるというか、
大量にコントロールを並べていて描画がもたつく場合、タブを切り替える毎に再描画している雰囲気はあるから、
それに近い可能性(見えてないタブのコントロールを剥がすとか)もありえるとは思う。
過去一度でも表示されたことがあるか、なら、確実に一度は表示されている。(初期画面のタブなので)
そして一応、直前に表示した状況でも試してみたが、やはりPerformClickは反応しない。
(「スクリプト実行ボタン」と「スクリプトから押したいボタン」が同一TabControlの別ページにあるので、
タブを切り替えた直後に実行ボタンを押してみたが、駄目だった)
ただしその挙動は少し覚えがあるというか、
大量にコントロールを並べていて描画がもたつく場合、タブを切り替える毎に再描画している雰囲気はあるから、
それに近い可能性(見えてないタブのコントロールを剥がすとか)もありえるとは思う。
800デフォルトの名無しさん (ワッチョイ d201-b83C)
2020/02/15(土) 15:26:28.37ID:cTwFsuY/0 リファレンスには書いてないっぽいけど
ControlのCanSelectがtrueじゃないとPerformClick()はイベントを発生させない
https://referencesource.microsoft.com/#system.windows.forms/winforms/managed/system/winforms/Button.cs,346
ボタン側を拡張したりボタンが呼び出してるメソッドを直接呼べない状況なら
素直にTabをSelectする以外にないんじゃないかな
ControlのCanSelectがtrueじゃないとPerformClick()はイベントを発生させない
https://referencesource.microsoft.com/#system.windows.forms/winforms/managed/system/winforms/Button.cs,346
ボタン側を拡張したりボタンが呼び出してるメソッドを直接呼べない状況なら
素直にTabをSelectする以外にないんじゃないかな
801デフォルトの名無しさん (ワッチョイ d201-b83C)
2020/02/15(土) 15:33:35.56ID:cTwFsuY/0 InvokeOnClick()呼べる?
こっちなら何もチェックしてないっぽいけど
こっちなら何もチェックしてないっぽいけど
802デフォルトの名無しさん (ブーイモ MM0e-BzDP)
2020/02/15(土) 15:39:09.67ID:px7CuDIEM 別にボタン押すとこまで律儀に再現しなくても良いよ
イベントハンドラかその中で呼んでるサービスを直接呼び出せばいい
イベントハンドラかその中で呼んでるサービスを直接呼び出せばいい
803デフォルトの名無しさん (アウアウウー Sac3-+wK4)
2020/02/15(土) 15:48:29.89ID:D6Qol+wpa >>799
なるほど確かに初回表示済みかどうかにかかわらず表示されてない時はダネだね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 });
}
}
なるほど確かに初回表示済みかどうかにかかわらず表示されてない時はダネだね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 });
}
}
804デフォルトの名無しさん (ワッチョイ 477b-yNzz)
2020/02/15(土) 15:58:13.85ID:M9LrwgB50 >>800
おお、ありがとう。
ググりまくりはしたが、ソースコードをチェックするという発想はなかった。
> このプロパティは、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はリードオンリーだから、素直に表示させるのが一番マシなようだ。
>>801
InvokeOnClickもprotectedなので駄目のようだ。(C3767)
ただ、なんでCanSelectなんだよ?とは思ったので、なるほどInvokeOnClickか!とも一瞬思ったが。
何がしたいんだよこの仕様(CanSelect必須)は。
GUIが有効か見ているわけだが、それをプログラムからの操作に噛ませる意味はないはず。
おお、ありがとう。
ググりまくりはしたが、ソースコードをチェックするという発想はなかった。
> このプロパティは、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はリードオンリーだから、素直に表示させるのが一番マシなようだ。
>>801
InvokeOnClickもprotectedなので駄目のようだ。(C3767)
ただ、なんでCanSelectなんだよ?とは思ったので、なるほどInvokeOnClickか!とも一瞬思ったが。
何がしたいんだよこの仕様(CanSelect必須)は。
GUIが有効か見ているわけだが、それをプログラムからの操作に噛ませる意味はないはず。
805デフォルトの名無しさん (ワッチョイ 477b-yNzz)
2020/02/15(土) 16:08:02.82ID:M9LrwgB50 >>803
ありがとう。
ただ、リフレクションは嵌る原因になるので出来る限り回避している。理由は以下。
・C#ならさておき、VC++だとググッてもヒットしない。
・ならば勿論C#を参考にするわけだが、本来同じCLRでMSILなので全く同一の筈なのだが、
何故か一部異なっていたりして、そこで嵌る。(というか嵌ったことがある)
勿論使ってはいるが。
ただ、確かに今回はリフレクションでも対応出来る状況なので、最終的には使うかもしれないけど。
ありがとう。
ただ、リフレクションは嵌る原因になるので出来る限り回避している。理由は以下。
・C#ならさておき、VC++だとググッてもヒットしない。
・ならば勿論C#を参考にするわけだが、本来同じCLRでMSILなので全く同一の筈なのだが、
何故か一部異なっていたりして、そこで嵌る。(というか嵌ったことがある)
勿論使ってはいるが。
ただ、確かに今回はリフレクションでも対応出来る状況なので、最終的には使うかもしれないけど。
806デフォルトの名無しさん (アウアウエー Saaa-BzDP)
2020/02/15(土) 16:16:32.88ID:ZLgOs4gBa バッチ処理なのになんでFormsなんだ?
807デフォルトの名無しさん (ワッチョイ 639e-oFCC)
2020/02/15(土) 16:45:32.12ID:9gQJd/YW0 IEコンポーネントの代替品って何? ChromiumベースEdge のものは既に用意されてるの?
808デフォルトの名無しさん (アウアウウー Sac3-+wK4)
2020/02/15(土) 17:23:14.18ID:D6Qol+wpa >>805
ならこれでも出来た。
何か気づいてない弊害があったらごめんね
public static void RaiseClick(this Button button)
{
var parent = button.Parent;
if(parent is TabPage)
{
button.Parent = null;
button.PerformClick();
button.Parent = parent;
}
}
個人的にはこういうバットノウハウ感全開のコードは嫌いw
ならこれでも出来た。
何か気づいてない弊害があったらごめんね
public static void RaiseClick(this Button button)
{
var parent = button.Parent;
if(parent is TabPage)
{
button.Parent = null;
button.PerformClick();
button.Parent = parent;
}
}
個人的にはこういうバットノウハウ感全開のコードは嫌いw
809デフォルトの名無しさん (ワッチョイ 477b-yNzz)
2020/02/15(土) 17:54:52.64ID:M9LrwgB50 >>808
さすがに動的に剥がすのは色々副作用が発生しそうで怖い。
今のところ以下のコードでやっている。このままか、>>803にするかのどちらかだと思う。
if (ctrl->Parent->GetType()->Name=="TabPage") ((TabControl^)ctrl->Parent->Parent)->SelectedTab = (TabPage^)ctrl->Parent;
((Button^)ctrl)->PerformClick();
キャストが入ってうざくなっているが、要はボタンの親のタブページをその都度選択(表示)させている。
これで動いている。ただしタブが勝手に切り替わるので知らなければギョッとする。
直後に戻せばいいだけかもしれないが、それはそれで無駄にイベントが発生するし、とりあえず放置だ。
仕様だと分かったので諦めはつく。
しばらくこれで試して、問題がなければこのまま、といったところ。
現状TabControl内のTabControlなんて無いから、おそらくこの方法で問題ないと思っている。
(TabControlが入れ子になっている場合、おそらくリフレクションしかない)
さすがに動的に剥がすのは色々副作用が発生しそうで怖い。
今のところ以下のコードでやっている。このままか、>>803にするかのどちらかだと思う。
if (ctrl->Parent->GetType()->Name=="TabPage") ((TabControl^)ctrl->Parent->Parent)->SelectedTab = (TabPage^)ctrl->Parent;
((Button^)ctrl)->PerformClick();
キャストが入ってうざくなっているが、要はボタンの親のタブページをその都度選択(表示)させている。
これで動いている。ただしタブが勝手に切り替わるので知らなければギョッとする。
直後に戻せばいいだけかもしれないが、それはそれで無駄にイベントが発生するし、とりあえず放置だ。
仕様だと分かったので諦めはつく。
しばらくこれで試して、問題がなければこのまま、といったところ。
現状TabControl内のTabControlなんて無いから、おそらくこの方法で問題ないと思っている。
(TabControlが入れ子になっている場合、おそらくリフレクションしかない)
810デフォルトの名無しさん (ワッチョイ 9294-E40k)
2020/02/15(土) 17:56:21.16ID:KAWVCWpT0 ボタンのコードを呼び出すのは駄目なの?
811デフォルトの名無しさん (ワッチョイ 477b-yNzz)
2020/02/15(土) 18:28:50.09ID:M9LrwgB50 >>809訂正
× TabControlが入れ子になっている場合
○ TabControl内にGroupBox等があり、そこにボタンがある場合
809のコードだと直接の親しか見てないので、
TabControl内のボタンは階層的に直接TabPageに貼られている必要がある。
そうでなければ親を再帰で辿るか、リフレクションするか、だろう。
× TabControlが入れ子になっている場合
○ TabControl内にGroupBox等があり、そこにボタンがある場合
809のコードだと直接の親しか見てないので、
TabControl内のボタンは階層的に直接TabPageに貼られている必要がある。
そうでなければ親を再帰で辿るか、リフレクションするか、だろう。
812デフォルトの名無しさん (オッペケ Src7-oFCC)
2020/02/15(土) 19:38:08.16ID:VwQX+D5fr 馬鹿がこんがらがってるイメージ
ボタンクリックのイベントハンドラを表示
private void button1_Click(object sender, EventArgs e)
{
//
}
始めの{と終わりの}の間をすべて選択する
右クリック クイックアクションとリファクタリングを選択
メソッドの抽出を選択
適用をクリック
ボタンクリックのイベントハンドラを表示
private void button1_Click(object sender, EventArgs e)
{
//
}
始めの{と終わりの}の間をすべて選択する
右クリック クイックアクションとリファクタリングを選択
メソッドの抽出を選択
適用をクリック
813デフォルトの名無しさん (ブーイモ MM0e-BzDP)
2020/02/15(土) 19:45:46.32ID:nU62WrWUM814デフォルトの名無しさん (アウアウウー Sac3-+wK4)
2020/02/15(土) 20:31:48.09ID:D6Qol+wpa >>812
その程度の話なら既に指摘されてるよw
イベントハンドラは動的に変更されるかもしれないし、
ラムダ式や引数で与えられるデリゲートかもしれない。
だから普通質問者さんの問題意識は理解できると思うよw
イキってる君以外の人にはw
その程度の話なら既に指摘されてるよw
イベントハンドラは動的に変更されるかもしれないし、
ラムダ式や引数で与えられるデリゲートかもしれない。
だから普通質問者さんの問題意識は理解できると思うよw
イキってる君以外の人にはw
815デフォルトの名無しさん (アウアウエー Saaa-BzDP)
2020/02/15(土) 22:59:55.86ID:ZLgOs4gBa >>814
その動的に変わるかもしれない処理とやらを抽出するだけだろ?
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()
その動的に変わるかもしれない処理とやらを抽出するだけだろ?
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()
816デフォルトの名無しさん (アウアウウー Sac3-+wK4)
2020/02/16(日) 00:18:48.74ID:s243OsDZa なんかもうバカの壁だねw
ボタンのクリックをシミュレートしたいというのは十分理解できる話だし、
それをなるべくそのまま表現できるようなコードを書きたい、という動機も
普通に理解できる話だと思うんだけど。
>>815的な発想の問題点は、
(1) プログラマの意図と実際のコードに乖離がある
(2) だから呼び出しているメソッドが今本当にButtonのイベントハンドラに登録されているものと
同一であるか、という検証の必要性が発生する。
(3) ButtonのPerformClickの「仕様バグ」を回避するため、
という非本質的な目的のためにコードの設計に手を入れるのは本末転倒
なにが「だろ?」なんだろうね
スギちゃんかよだっせーwww
ボタンのクリックをシミュレートしたいというのは十分理解できる話だし、
それをなるべくそのまま表現できるようなコードを書きたい、という動機も
普通に理解できる話だと思うんだけど。
>>815的な発想の問題点は、
(1) プログラマの意図と実際のコードに乖離がある
(2) だから呼び出しているメソッドが今本当にButtonのイベントハンドラに登録されているものと
同一であるか、という検証の必要性が発生する。
(3) ButtonのPerformClickの「仕様バグ」を回避するため、
という非本質的な目的のためにコードの設計に手を入れるのは本末転倒
なにが「だろ?」なんだろうね
スギちゃんかよだっせーwww
817デフォルトの名無しさん (アウアウウー Sac3-+wK4)
2020/02/16(日) 00:20:18.56ID:s243OsDZa >>813の人も思いっきり倒錯してるねw
818デフォルトの名無しさん (ブーイモ MM0e-BzDP)
2020/02/16(日) 00:28:16.86ID:lYNu13iwM >>816
それより前の問題としてプログラマの意図がまず間違ってんだよ
魚をさばくのにノコギリでやろうとしてる状態
そこを正してからじゃないと話にならない
正さずにむりやり進めようとしてるからボタンクリックエミュレートなどという頭の悪い発想に固執する
挙げ句の果に画面上で見えてないと処理が走らない(涙)なんてバカバカしい罠にどハマリしちゃってるわけだ
はっきり言ってリフレクションはハマりやすいからダメだなんて言ってる場合じゃないよ
それより前の問題としてプログラマの意図がまず間違ってんだよ
魚をさばくのにノコギリでやろうとしてる状態
そこを正してからじゃないと話にならない
正さずにむりやり進めようとしてるからボタンクリックエミュレートなどという頭の悪い発想に固執する
挙げ句の果に画面上で見えてないと処理が走らない(涙)なんてバカバカしい罠にどハマリしちゃってるわけだ
はっきり言ってリフレクションはハマりやすいからダメだなんて言ってる場合じゃないよ
819デフォルトの名無しさん (ブーイモ MM0e-BzDP)
2020/02/16(日) 00:38:37.35ID:lYNu13iwM だいたいクライアントのやりたいことは自社アプケーションのオートメーションサポートだろうよ
それを素人の思いつきレベルの発想でUIのオートメーションに目的をすり替えたのが運の尽きだわな
レイヤの考え方が全くわかってないアマチュアの設計だからすんなりうまく行くはずがないんだ
見えてないと発火しないこと以外にいったいどんな罠が潜んでるかわかったもんじゃない
俺が提案した方法ならUIインフラに依存しなくなるから実行時の安定性と罠が少ないぶん高い生産性が期待できる
それを素人の思いつきレベルの発想でUIのオートメーションに目的をすり替えたのが運の尽きだわな
レイヤの考え方が全くわかってないアマチュアの設計だからすんなりうまく行くはずがないんだ
見えてないと発火しないこと以外にいったいどんな罠が潜んでるかわかったもんじゃない
俺が提案した方法ならUIインフラに依存しなくなるから実行時の安定性と罠が少ないぶん高い生産性が期待できる
820デフォルトの名無しさん (ワッチョイ d201-b83C)
2020/02/16(日) 01:57:42.29ID:iNVxJNOu0 アセンブリが自分や所属チーム/組織のコントロール下にないんじゃないのかな
違う理由かもしれないがそれと同じような制約下での話だと思われる
違う理由かもしれないがそれと同じような制約下での話だと思われる
821デフォルトの名無しさん (ワッチョイ 8361-IGGe)
2020/02/16(日) 03:27:20.73ID:QSu9wuIh0822デフォルトの名無しさん (ワッチョイ c602-ZgUM)
2020/02/16(日) 09:58:00.38ID:as0AlWv60 >>820
そういうときはUIAutomationかWinAppDriverを使うといいよ
どうせこのあと要求がどんどん増えてボタンクリックだけじゃ済まなくなるんでしょ
あとで苦労するハックはやめてマイクロソフトが整備してる道具を使おう
そういうときはUIAutomationかWinAppDriverを使うといいよ
どうせこのあと要求がどんどん増えてボタンクリックだけじゃ済まなくなるんでしょ
あとで苦労するハックはやめてマイクロソフトが整備してる道具を使おう
823デフォルトの名無しさん (ワッチョイ 477b-yNzz)
2020/02/16(日) 11:26:32.12ID:j/dbz9ZG0 >>819
まあその「俺のプログラムが一番だ」という姿勢は俺は嫌いではないし、
むしろプログラマは全員持つべきだとも思うけども、
動的結合の価値(意味)が分からないのなら、まずはそこを理解した方がいい。
現在、Clickイベントをエミュレーション出来ないGUIフレームワークなんて、存在してない。
リフレクションも割と一般的になりつつある。(常用するのはどうかとも思うが)
だから、使いどころはあるんだよ。
静的結合だけでやれ、みたいなのは言ってしまえばC++がそうだが、それでもRTTIは検討されている。
動的結合の価値は>>816も書いてくれているが、同様に以下でも触れられている。(これらだけでもないが)
https://www.atmarkit.co.jp/fdotnet/dotnettips/270performclick/performclick.html
言ってしまえば「実行速度を捨てて保守性を採る」わけであり、これが適切かどうかは状況によるので、
PerformClickやリフレクション等を使うこと自体が間違いだ、というのはさすがに行きすぎてる。
(なお既に言ったが、速度至上主義のC++は割とそういう思想だし、これも間違いでもないが)
ただそれはさておき、PowerShellは使ったこと無いから調べてみたが、確かに面白いものではある。
ポイントは、.NETオブジェクトをインスタンス化出来ることと、それらをパイプで流せる点か。
>>815を見る限り、C#等CLRな物ならリフレクションで内部の関数をぶち抜いて、自在に呼べるのか!
(名前があやふやだが確か)COMでも似たようなことをしていたMSならあり得るか!とも思ったが、
そうではなくて、自分で.NETクラスをインスタンス化して呼べるだけか?
まあそれでもリフレクションを使えば何でもありにはなるし、
.NETを使うだけで本式のバッチスクリプト環境が自動的に提供されてしまう、というのは画期的ではある。
ここら辺はMSの上手いところだとは思う。
まあその「俺のプログラムが一番だ」という姿勢は俺は嫌いではないし、
むしろプログラマは全員持つべきだとも思うけども、
動的結合の価値(意味)が分からないのなら、まずはそこを理解した方がいい。
現在、Clickイベントをエミュレーション出来ないGUIフレームワークなんて、存在してない。
リフレクションも割と一般的になりつつある。(常用するのはどうかとも思うが)
だから、使いどころはあるんだよ。
静的結合だけでやれ、みたいなのは言ってしまえばC++がそうだが、それでもRTTIは検討されている。
動的結合の価値は>>816も書いてくれているが、同様に以下でも触れられている。(これらだけでもないが)
https://www.atmarkit.co.jp/fdotnet/dotnettips/270performclick/performclick.html
言ってしまえば「実行速度を捨てて保守性を採る」わけであり、これが適切かどうかは状況によるので、
PerformClickやリフレクション等を使うこと自体が間違いだ、というのはさすがに行きすぎてる。
(なお既に言ったが、速度至上主義のC++は割とそういう思想だし、これも間違いでもないが)
ただそれはさておき、PowerShellは使ったこと無いから調べてみたが、確かに面白いものではある。
ポイントは、.NETオブジェクトをインスタンス化出来ることと、それらをパイプで流せる点か。
>>815を見る限り、C#等CLRな物ならリフレクションで内部の関数をぶち抜いて、自在に呼べるのか!
(名前があやふやだが確か)COMでも似たようなことをしていたMSならあり得るか!とも思ったが、
そうではなくて、自分で.NETクラスをインスタンス化して呼べるだけか?
まあそれでもリフレクションを使えば何でもありにはなるし、
.NETを使うだけで本式のバッチスクリプト環境が自動的に提供されてしまう、というのは画期的ではある。
ここら辺はMSの上手いところだとは思う。
824デフォルトの名無しさん (ワッチョイ 477b-yNzz)
2020/02/16(日) 11:28:34.74ID:j/dbz9ZG0 >>816
俺も「仕様バグ」に近いものだとは思うが、おそらく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
俺も「仕様バグ」に近いものだとは思うが、おそらく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
825デフォルトの名無しさん (ワッチョイ 1ede-sep5)
2020/02/16(日) 11:51:40.15ID:4ZDOKfwJ0826デフォルトの名無しさん (ブーイモ MM32-BzDP)
2020/02/16(日) 12:09:21.49ID:qmeSH89zM >>823
そのリンクの先はかなりクソコードだから鵜呑みにしないほうがいいぞ
まあ2005年の錆びついたものだしもともと低スキル向けの記事だからしょうがないけど
この記事の悪しき前提はViewに処理をベタ書きしちゃってることな
本来ならViewとModelを分離してView上のメニューとボタンからModelの同じメソッドをコールするのが正しい設計な
ViewとModelを分離してModelがViewに依存しなくなればModelをUIインフラから切り離して独立させることができる
そうすればオレオレスクリプトでオートメーションをサポートするといった要求にも容易に応えることができるようになる
UI操作をエミュレートするなどという泥臭いハックに頼らなくて済むのだ
そのリンクの先はかなりクソコードだから鵜呑みにしないほうがいいぞ
まあ2005年の錆びついたものだしもともと低スキル向けの記事だからしょうがないけど
この記事の悪しき前提はViewに処理をベタ書きしちゃってることな
本来ならViewとModelを分離してView上のメニューとボタンからModelの同じメソッドをコールするのが正しい設計な
ViewとModelを分離してModelがViewに依存しなくなればModelをUIインフラから切り離して独立させることができる
そうすればオレオレスクリプトでオートメーションをサポートするといった要求にも容易に応えることができるようになる
UI操作をエミュレートするなどという泥臭いハックに頼らなくて済むのだ
827デフォルトの名無しさん (ワッチョイ 477b-yNzz)
2020/02/16(日) 13:03:06.69ID:j/dbz9ZG0 >>826
このページのコードと用例が糞なのは事実として、エミュレーションが適切な場合もあるってことだよ。
だから現在の全てのGUIフレームワークはエミュレーション出来るようになってるし、
リフレクションも装備しつつある。
MとVを厳密に分離してVはMのラッパ扱いに留めろ、というのは現在の思想としては正しいとして、
2005頃には今ほど言われていなかった、というより、そのころの失敗を経て現在の思想があるわけだから、
このページに対してそれを言ってもしょうがない。
ただそれにしても、現在もまだエミュレーションの価値はあると思うよ。
今回の点に関しての不満なら、俺は
MS:「OnClickがprotectedで呼べないからPerformClickを用意しました」
俺:「なら最初からOnClickをpublicにしとけよ」
であって、private至上主義という勘違いオブジェクト指向の面影を.NETもまた引きずっている点についてだね。
このページのコードと用例が糞なのは事実として、エミュレーションが適切な場合もあるってことだよ。
だから現在の全てのGUIフレームワークはエミュレーション出来るようになってるし、
リフレクションも装備しつつある。
MとVを厳密に分離してVはMのラッパ扱いに留めろ、というのは現在の思想としては正しいとして、
2005頃には今ほど言われていなかった、というより、そのころの失敗を経て現在の思想があるわけだから、
このページに対してそれを言ってもしょうがない。
ただそれにしても、現在もまだエミュレーションの価値はあると思うよ。
今回の点に関しての不満なら、俺は
MS:「OnClickがprotectedで呼べないからPerformClickを用意しました」
俺:「なら最初からOnClickをpublicにしとけよ」
であって、private至上主義という勘違いオブジェクト指向の面影を.NETもまた引きずっている点についてだね。
828デフォルトの名無しさん (ワッチョイ 37de-sep5)
2020/02/16(日) 13:23:09.50ID:If0Pwz/d0 >>827
ウンコをいじる正当性を探すな
ウンコをいじる正当性を探すな
829デフォルトの名無しさん (ワッチョイ 477b-yNzz)
2020/02/16(日) 14:00:28.26ID:j/dbz9ZG0 エミュレーションの有用性が分からないのは根本的に経験が足りない。
何故現在の全てのGUIフレームワークがその機能を持っているのか、その意味をよく考えた方がいい。
そしてそのレベルの奴がコードの善し悪しを議論するのは5年早い。
ただ、このレベルの初心者と話をしても意味がないから俺はやる気無い。
お前らが正しいのなら、MSは数年以内に.NETからエミュレーション機能、
つまりPerformClick/OnClick/リフレクション等を全削除することになるが、
俺はこれはあり得ないとしか思えない。
正否は結果で判断でいい。
ここで低レベルな水掛け論をやる意味はない。
何故現在の全てのGUIフレームワークがその機能を持っているのか、その意味をよく考えた方がいい。
そしてそのレベルの奴がコードの善し悪しを議論するのは5年早い。
ただ、このレベルの初心者と話をしても意味がないから俺はやる気無い。
お前らが正しいのなら、MSは数年以内に.NETからエミュレーション機能、
つまりPerformClick/OnClick/リフレクション等を全削除することになるが、
俺はこれはあり得ないとしか思えない。
正否は結果で判断でいい。
ここで低レベルな水掛け論をやる意味はない。
830デフォルトの名無しさん (ワッチョイ 37de-sep5)
2020/02/16(日) 14:16:23.77ID:If0Pwz/d0 こんなクダンネーモン作ってる暇があるならメッセージボックスが後ろに回らないように修正しろ
831デフォルトの名無しさん (スフッ Sd32-yBe4)
2020/02/16(日) 14:20:38.32ID:WhOeRDRvd >>807
nugetにあるよ。
nugetにあるよ。
832デフォルトの名無しさん (ブーイモ MM0e-BzDP)
2020/02/16(日) 14:36:14.03ID:t/nUwzcTM >>827>>829
UI操作をエミュレートする需要があることは間違いではない
がしかしそれはUIコンポーネント実装のためだったりテストフレームワークのためだったりソースにアクセスできないGUIアプリケーションのオートメーションのためだったりであって
自社アプリにオートメーションサポートを実装するための基盤ではない
それをサポートを実現するまっとうな設計はUI層に依存しないAPIやCLIの提供であってUI操作とは全く逆の考え方だ
お前はノコギリにだって役目と需要があると言ってる
しかしノコギリは魚をさばくのには適さない
無論無理をすればノコギリで魚をさばくことはできるがそれはバカのやることだ
UI操作をエミュレートする需要があることは間違いではない
がしかしそれはUIコンポーネント実装のためだったりテストフレームワークのためだったりソースにアクセスできないGUIアプリケーションのオートメーションのためだったりであって
自社アプリにオートメーションサポートを実装するための基盤ではない
それをサポートを実現するまっとうな設計はUI層に依存しないAPIやCLIの提供であってUI操作とは全く逆の考え方だ
お前はノコギリにだって役目と需要があると言ってる
しかしノコギリは魚をさばくのには適さない
無論無理をすればノコギリで魚をさばくことはできるがそれはバカのやることだ
833デフォルトの名無しさん (ワッチョイ af97-hMlH)
2020/02/16(日) 15:56:01.41ID:4YtH0n6X0 年末年始年始に非同期処理で騒いでた人かな
834デフォルトの名無しさん (アウアウウー Sac3-+wK4)
2020/02/16(日) 18:17:51.00ID:vSVyAtifa >>832
あんたも相当しつこいねw
俺は質問者さんと別人だけど、ボタンやメニューのクリックをシミュレートしたい
場面というのは実際問題しばしば存在するよ
例えばクリックすると何か処理が走るボタンが複数あるとする。
この時、これを全部クリックしたのと同じ機能を果たすボタンが欲しい、
なんていうのは割とありがちな話。
あと、クリックで同じ機能を果たすボタンとメニューが存在する、なんてしょっちゅうある。
この場合はメニューの方のクリックをシミュレートするのが普通だと思うから
件の話を正当化する材料にはならないけどね。
あんたも相当しつこいねw
俺は質問者さんと別人だけど、ボタンやメニューのクリックをシミュレートしたい
場面というのは実際問題しばしば存在するよ
例えばクリックすると何か処理が走るボタンが複数あるとする。
この時、これを全部クリックしたのと同じ機能を果たすボタンが欲しい、
なんていうのは割とありがちな話。
あと、クリックで同じ機能を果たすボタンとメニューが存在する、なんてしょっちゅうある。
この場合はメニューの方のクリックをシミュレートするのが普通だと思うから
件の話を正当化する材料にはならないけどね。
835デフォルトの名無しさん (ワッチョイ 1ede-sep5)
2020/02/16(日) 18:27:35.97ID:Oyf7AnZI0836デフォルトの名無しさん (ワッチョイ 477b-yNzz)
2020/02/16(日) 18:32:01.24ID:j/dbz9ZG0 >>832
「UIに依存する」のではなく、「UIの代替を提供する」のであって、
UIが変更された場合にはUIと同じく変更されるのが正しいんだよ。この点が違う。
そしてソース変更無しで自動追従させる手法がエミュレーションになる。
「UIに依存する」というのは、UIとは本来関係ない事をUIを通してやってしまっていることにより、
UIが変更された場合に動かなくなって困る(動作が変わってしまう)ことを言ってるだろ。
そうじゃない。今回はそこは動作が変わるのが正しいんだよ。
それはさておき、PowerShellって流行ってるのか?
思想が面白いのは認めるが、これはつまり「.NETアプリをライブラリとして公開する」訳であり、
ガチのプログラマに対してソース公開して、後はお前が頑張れ、と言っているに近い。
勿論これで行ける奴はいいが、実際のところ、使う側はアプリを使いたいのであって、
ソースを読みたいわけでもなく、プログラミングしたいわけでもない。
そしてアプリと完全に密結合してしまうから、そもそも同レベルのプログラマじゃないとソースは読めない。
だから現実的に、アプリ+PowerShellで何とかしろ、と言われても、プログラマでも困ると思うが。
ただし再三言っているが、思想が面白いのは認める。
これにより、全ての.NETアプリはPowerShellライブラリとして動作し、
また、ガチのスクリプト環境が手に入るわけだ。これ自体は(有用性はともかく)面白い。
「UIに依存する」のではなく、「UIの代替を提供する」のであって、
UIが変更された場合にはUIと同じく変更されるのが正しいんだよ。この点が違う。
そしてソース変更無しで自動追従させる手法がエミュレーションになる。
「UIに依存する」というのは、UIとは本来関係ない事をUIを通してやってしまっていることにより、
UIが変更された場合に動かなくなって困る(動作が変わってしまう)ことを言ってるだろ。
そうじゃない。今回はそこは動作が変わるのが正しいんだよ。
それはさておき、PowerShellって流行ってるのか?
思想が面白いのは認めるが、これはつまり「.NETアプリをライブラリとして公開する」訳であり、
ガチのプログラマに対してソース公開して、後はお前が頑張れ、と言っているに近い。
勿論これで行ける奴はいいが、実際のところ、使う側はアプリを使いたいのであって、
ソースを読みたいわけでもなく、プログラミングしたいわけでもない。
そしてアプリと完全に密結合してしまうから、そもそも同レベルのプログラマじゃないとソースは読めない。
だから現実的に、アプリ+PowerShellで何とかしろ、と言われても、プログラマでも困ると思うが。
ただし再三言っているが、思想が面白いのは認める。
これにより、全ての.NETアプリはPowerShellライブラリとして動作し、
また、ガチのスクリプト環境が手に入るわけだ。これ自体は(有用性はともかく)面白い。
837デフォルトの名無しさん (ブーイモ MM0e-BzDP)
2020/02/16(日) 19:25:18.98ID:tfQsIfqsM838デフォルトの名無しさん (ブーイモ MM0e-BzDP)
2020/02/16(日) 19:46:27.53ID:tfQsIfqsM >>836
つまりお前が言いたいのは
スクリプティング機能の定石に反する糞仕様こそを求めているので今回に限り馬鹿なことをするのが正しい
ということか
PowerShellは流行ってるというかWindowsのシステム管理ではほぼ必須
OSにプレインストールされてるから開発環境用意するまでもないちょっとしたツールを作るのにも便利
今まさに話してるDSLを手軽に実装するための基盤としてもしばしば使われる
LinuxやMacで仕事してるなら触る機会ないだろうけどWindowsで開発してるなら触る機会は無数にあるはず
つまりお前が言いたいのは
スクリプティング機能の定石に反する糞仕様こそを求めているので今回に限り馬鹿なことをするのが正しい
ということか
PowerShellは流行ってるというかWindowsのシステム管理ではほぼ必須
OSにプレインストールされてるから開発環境用意するまでもないちょっとしたツールを作るのにも便利
今まさに話してるDSLを手軽に実装するための基盤としてもしばしば使われる
LinuxやMacで仕事してるなら触る機会ないだろうけどWindowsで開発してるなら触る機会は無数にあるはず
839デフォルトの名無しさん (ワッチョイ 9261-OxJ8)
2020/02/16(日) 20:13:22.98ID:lt2wlhEH0 >>796
おいもうそろそろこの話題締めて他所にいってくれや。
おいもうそろそろこの話題締めて他所にいってくれや。
840デフォルトの名無しさん (ワッチョイ 167b-4wVb)
2020/02/16(日) 20:16:51.11ID:ZkXecQUS0 ふらっと荒らしてこっち荒らして、いつも同じメンバーだろこれ
841デフォルトの名無しさん (オッペケ Src7-oFCC)
2020/02/16(日) 20:22:19.26ID:+zL5Le7jr もともと完全にちゃんとGUI操作したいなんて書いてないだろさ
途中から見てる人が勝手に条件を足してるだけで本来あるべき姿とかい離してる
途中で無駄にリフレクションが出てくるあたり初心者の匂いが出てる
ボタン押すにはタブを切り替えなくてはならないのに
画面が変わらないままでボタン押したいって言ってるから別にGUI操作自体を再現したいわけじゃない
途中から見てる人が勝手に条件を足してるだけで本来あるべき姿とかい離してる
途中で無駄にリフレクションが出てくるあたり初心者の匂いが出てる
ボタン押すにはタブを切り替えなくてはならないのに
画面が変わらないままでボタン押したいって言ってるから別にGUI操作自体を再現したいわけじゃない
842デフォルトの名無しさん (ワッチョイ 477b-yNzz)
2020/02/16(日) 20:24:37.87ID:j/dbz9ZG0 >>838
違う。定石に反しているのは君の方で、つまりはカッコイイソリューションを目指しすぎている。
馬鹿みたいなソリューションの方が、現実的に使いやすいことは多々ある。
多分、ちょっと若すぎて元気がありすぎるのだと思う。
これ自体は悪いことではなく、むしろ上達には必須の性格で、良いことだとは思うが、
世の中のアプリがどうなっているか、もう少し周りを見た方がいい。
GUIの自動化で一番簡単なソリューションは、GUIを記録してしまうことだ。…(A)
俺が昔使ったアプリだと、「ログ画面」にGUI操作と等価のコマンドが一々流れる、というのがあった。
そして自動化したい場合は、このログ画面内の該当部分をコピペしたファイルを読ませるだけ、というものだ。
当然、見れば分かる程度であり、例えばファイルを読み込んだらそのファイルパスがまんま表示されている。
なら、そこを変更するだけで同じ処理を他ファイルに適用出来るよね、というわけだ。
冷静に考えれば分かるが、Unixのshもこれと同様だ。(というより上記方式がshのパクリだが)
shもhistoryで出てくる履歴をコピペすればバッチファイルになるようになっている。
そして必要なら該当部分を変数化してループを回せ、ということでしかない。
俺は使ったことないけど、Webブラウザの自動化ツールとして有名なSeleniumも以下見る限り似たようなもんだ。
https://www.valtes.co.jp/qbookplus/509
だから、初段階のスクリプト環境はこの程度でいいし、実際、この程度でも相当有益なんだよ。
そしてそれを手っ取り早く実装する方法がGUIのエミュレーション(PerformClick等)になる。
だから、
> 自社アプリにオートメーションサポートを実装するための基盤ではない
これはちょっと意識が高すぎる。(気持ちは分からなくもないが)
PowerShellでオートメーション、というのはその先の先の先位で、
初期段階に於いては超オーバースペックでしかない。
そして殆どのアプリでは最終的にも必要としない。
違う。定石に反しているのは君の方で、つまりはカッコイイソリューションを目指しすぎている。
馬鹿みたいなソリューションの方が、現実的に使いやすいことは多々ある。
多分、ちょっと若すぎて元気がありすぎるのだと思う。
これ自体は悪いことではなく、むしろ上達には必須の性格で、良いことだとは思うが、
世の中のアプリがどうなっているか、もう少し周りを見た方がいい。
GUIの自動化で一番簡単なソリューションは、GUIを記録してしまうことだ。…(A)
俺が昔使ったアプリだと、「ログ画面」にGUI操作と等価のコマンドが一々流れる、というのがあった。
そして自動化したい場合は、このログ画面内の該当部分をコピペしたファイルを読ませるだけ、というものだ。
当然、見れば分かる程度であり、例えばファイルを読み込んだらそのファイルパスがまんま表示されている。
なら、そこを変更するだけで同じ処理を他ファイルに適用出来るよね、というわけだ。
冷静に考えれば分かるが、Unixのshもこれと同様だ。(というより上記方式がshのパクリだが)
shもhistoryで出てくる履歴をコピペすればバッチファイルになるようになっている。
そして必要なら該当部分を変数化してループを回せ、ということでしかない。
俺は使ったことないけど、Webブラウザの自動化ツールとして有名なSeleniumも以下見る限り似たようなもんだ。
https://www.valtes.co.jp/qbookplus/509
だから、初段階のスクリプト環境はこの程度でいいし、実際、この程度でも相当有益なんだよ。
そしてそれを手っ取り早く実装する方法がGUIのエミュレーション(PerformClick等)になる。
だから、
> 自社アプリにオートメーションサポートを実装するための基盤ではない
これはちょっと意識が高すぎる。(気持ちは分からなくもないが)
PowerShellでオートメーション、というのはその先の先の先位で、
初期段階に於いては超オーバースペックでしかない。
そして殆どのアプリでは最終的にも必要としない。
843デフォルトの名無しさん (ワッチョイ 477b-yNzz)
2020/02/16(日) 20:25:18.75ID:j/dbz9ZG0 例えば上記アプリ(A)方式だと、ループ機能すらないのだから、
アプリ(A)だけで100個のファイルに同じ処理を適用しようとすると困る。
そこでループ機能を、とか言い出すと色々他が必要になって結局PowerShell、という思想もありだが、
そうではなく、Perl等でファイル名だけ変更するスクリプトを作り、
それでループを回して作ったドベタに展開された糞長いバッチファイルをアプリ(A)に流し込む、
というのもありなんだよ。
全ての処理を自アプリでやろうとするから無理が発生する。
unixはこれと逆で、他コマンドで出来ることは自コマンドでするな、で上手く行ってるだろ。
ソースコードについてもそうだが、アプリについてもKISS原則は重要なんだよ。
そして話を戻すと、UIの自動化のド定番は「実際に行われたUIを記録してそのまま流すこと」であり、
「PowerShell等のガチスクリプト環境と連携すること」ではない。
だからクリックエミュレーション等も今のところは今後とも必要な機能でしかない。
が、まあ、PowerShellを推す気持ちも分からなくはない。
おそらくIEだとPowerShellで自動化出来ると推測されるので、
IEが天下取っていたときに自動化の流れが来てたら少しは違ったかもしれん。
アプリ(A)だけで100個のファイルに同じ処理を適用しようとすると困る。
そこでループ機能を、とか言い出すと色々他が必要になって結局PowerShell、という思想もありだが、
そうではなく、Perl等でファイル名だけ変更するスクリプトを作り、
それでループを回して作ったドベタに展開された糞長いバッチファイルをアプリ(A)に流し込む、
というのもありなんだよ。
全ての処理を自アプリでやろうとするから無理が発生する。
unixはこれと逆で、他コマンドで出来ることは自コマンドでするな、で上手く行ってるだろ。
ソースコードについてもそうだが、アプリについてもKISS原則は重要なんだよ。
そして話を戻すと、UIの自動化のド定番は「実際に行われたUIを記録してそのまま流すこと」であり、
「PowerShell等のガチスクリプト環境と連携すること」ではない。
だからクリックエミュレーション等も今のところは今後とも必要な機能でしかない。
が、まあ、PowerShellを推す気持ちも分からなくはない。
おそらくIEだとPowerShellで自動化出来ると推測されるので、
IEが天下取っていたときに自動化の流れが来てたら少しは違ったかもしれん。
844デフォルトの名無しさん (ブーイモ MM0e-BzDP)
2020/02/16(日) 20:55:58.19ID:tfQsIfqsM >>842
無知すぎて呆れる
世の中のサービスやアプリをちゃんと見てみろ
APIやCLIをサポートすることは多々あってもGUI操作をサポートしてるものなどごく少数派だ
UIとは読んで字のごとくユーザーのためのインターフェースであって自動化のためのインターフェースではない
APIとはアプリケーションプログラムのためのインターフェースであり自動化をサポートするならこちらを提供するのが当然の選択だ
APIやCLIのサポートが定石であってGUI操作は邪教徒の好む黒魔術でしかない
お前の常識は多分10年か20年前の辺境の集落での常識だ
現代のグローバルスタンダードに追いつく努力をしてくれ
無知すぎて呆れる
世の中のサービスやアプリをちゃんと見てみろ
APIやCLIをサポートすることは多々あってもGUI操作をサポートしてるものなどごく少数派だ
UIとは読んで字のごとくユーザーのためのインターフェースであって自動化のためのインターフェースではない
APIとはアプリケーションプログラムのためのインターフェースであり自動化をサポートするならこちらを提供するのが当然の選択だ
APIやCLIのサポートが定石であってGUI操作は邪教徒の好む黒魔術でしかない
お前の常識は多分10年か20年前の辺境の集落での常識だ
現代のグローバルスタンダードに追いつく努力をしてくれ
845デフォルトの名無しさん (ワッチョイ c602-ZgUM)
2020/02/16(日) 21:13:00.97ID:as0AlWv60 >GUIの自動化で一番簡単なソリューションは、GUIを記録してしまうことだ。…(A)
>俺が昔使ったアプリだと、「ログ画面」にGUI操作と等価のコマンドが一々流れる、というのがあった。
>そして自動化したい場合は、このログ画面内の該当部分をコピペしたファイルを読ませるだけ、というものだ。
>当然、見れば分かる程度であり、例えばファイルを読み込んだらそのファイルパスがまんま表示されている。
>なら、そこを変更するだけで同じ処理を他ファイルに適用出来るよね、というわけだ。
これ、昔作ったことが有るけど、最も上手くいった方法はMVCを徹底して、Cの入り口でコマンドオブジェクトをシリアライズして記録するパターンだったな
やってみればわかると思うけど、画面コントロールの操作ログを正確に記録するのも、再生するのも、一筋縄ではいかない
>俺が昔使ったアプリだと、「ログ画面」にGUI操作と等価のコマンドが一々流れる、というのがあった。
>そして自動化したい場合は、このログ画面内の該当部分をコピペしたファイルを読ませるだけ、というものだ。
>当然、見れば分かる程度であり、例えばファイルを読み込んだらそのファイルパスがまんま表示されている。
>なら、そこを変更するだけで同じ処理を他ファイルに適用出来るよね、というわけだ。
これ、昔作ったことが有るけど、最も上手くいった方法はMVCを徹底して、Cの入り口でコマンドオブジェクトをシリアライズして記録するパターンだったな
やってみればわかると思うけど、画面コントロールの操作ログを正確に記録するのも、再生するのも、一筋縄ではいかない
846デフォルトの名無しさん (ワッチョイ 639e-oFCC)
2020/02/16(日) 21:16:30.88ID:yo/bSae/0 COMで解決された問題を20年以上経って議論してる・・・
847デフォルトの名無しさん (ワッチョイ 126a-OxJ8)
2020/02/16(日) 21:58:35.37ID:5ncsgUM20 この話題をすり替えつつ自分の正当性をゴリ押しするスタイル、最近見ましたよね
明後日くらいには全然違う話題になってるぞきっとw
明後日くらいには全然違う話題になってるぞきっとw
848デフォルトの名無しさん (ワッチョイ 7317-OxJ8)
2020/02/16(日) 22:11:19.84ID:x7wMnJYb0 荒らしてるの毎回同じ人だよね
書き方に癖があるからすぐわかる
書き方に癖があるからすぐわかる
849デフォルトの名無しさん (アウアウウー Sac3-+wK4)
2020/02/16(日) 22:21:29.37ID:Z1hWCcVDa >>837
繰り返しになるけどね、そういう「プログラマの意図と実際のコードに乖離がある」
ことをやると別の仕事が増えるでしょ。
ボタンABCDEが全部クリックされたのと確実に同じことが起るって誰が確認して保証するの?
ボタンABCDEのクリックイベントの処理を後で変更した時、またそれをやりなおすの?
その確認作業を忘れたらどうするの?
こういう後の保守のことを考えないプログラマは愚鈍で無能。
倒錯してるよ君。
「する必要はない」のは、「クリックで実行される処理を順に実行する」なんて保守性を下げる
アホな手段を採用すること。
なぜ素直にボタンクリックをシミュレートしようとしないの。
繰り返しになるけどね、そういう「プログラマの意図と実際のコードに乖離がある」
ことをやると別の仕事が増えるでしょ。
ボタンABCDEが全部クリックされたのと確実に同じことが起るって誰が確認して保証するの?
ボタンABCDEのクリックイベントの処理を後で変更した時、またそれをやりなおすの?
その確認作業を忘れたらどうするの?
こういう後の保守のことを考えないプログラマは愚鈍で無能。
倒錯してるよ君。
「する必要はない」のは、「クリックで実行される処理を順に実行する」なんて保守性を下げる
アホな手段を採用すること。
なぜ素直にボタンクリックをシミュレートしようとしないの。
850デフォルトの名無しさん (ブーイモ MM0e-BzDP)
2020/02/16(日) 22:40:57.03ID:q02FpFyRM >>849
プログラマの真の意図は
ボタンを押したら複数の一連の処理をまとめて実行したい
メニューとボタンで同じ処理を実行したい
だろ
君が好きなボタンをエミュレートする方法は上記のプログラマの意図を実現する遠回りなやり方の1つだ
誰が確認するの?確認忘れたらどうすんの?なんて質問は自分は仕事でコード書いたことありませんと言っているようなものだから控えたほうがいい
テストを自動化するか人がやるか誰がやるかはチーム次第だがいずれにせよテストをしないわけがないではないか
そしてテストをするのはボタンをエミュレートする方式だろうが他のどうな方法だろうが同じことだ
まるで暗にエミュレートならテストを省略していいような言い方をするとああこいつはアマチュアなんだなとバレてしまうぞ
ちなみにテストの心配をするならなおさらUIに依存しない方式で書いたほうがいい
そうすればテストの自動化が容易になるから君が気にしてるテスト工数の増加やリグレッションの発生確率も最小化することができる
UIのエミュレートが正しく行われたことをテストするのはUI非依存のテストと比べると面倒な作業だよ
まあこんへんはアマチュアにはわかりにくいメリットかもしれないね
プログラマの真の意図は
ボタンを押したら複数の一連の処理をまとめて実行したい
メニューとボタンで同じ処理を実行したい
だろ
君が好きなボタンをエミュレートする方法は上記のプログラマの意図を実現する遠回りなやり方の1つだ
誰が確認するの?確認忘れたらどうすんの?なんて質問は自分は仕事でコード書いたことありませんと言っているようなものだから控えたほうがいい
テストを自動化するか人がやるか誰がやるかはチーム次第だがいずれにせよテストをしないわけがないではないか
そしてテストをするのはボタンをエミュレートする方式だろうが他のどうな方法だろうが同じことだ
まるで暗にエミュレートならテストを省略していいような言い方をするとああこいつはアマチュアなんだなとバレてしまうぞ
ちなみにテストの心配をするならなおさらUIに依存しない方式で書いたほうがいい
そうすればテストの自動化が容易になるから君が気にしてるテスト工数の増加やリグレッションの発生確率も最小化することができる
UIのエミュレートが正しく行われたことをテストするのはUI非依存のテストと比べると面倒な作業だよ
まあこんへんはアマチュアにはわかりにくいメリットかもしれないね
851デフォルトの名無しさん (ワッチョイ 122c-LiuO)
2020/02/16(日) 22:47:15.25ID:5EL9p8ON0 Seleniumデザインパターン&ベストプラクティス、2015、オライリー
この本は、Ruby, Selenium WebDriver でのテスト手法を書いた本
例えば、Ruby, Selenium WebDriverで、
Yahoo への自動ログインするスクリプトは、下を参照
【VBScript】WSHについて話し合うスレ【JScript】
https://mevius.5ch.net/test/read.cgi/tech/1578522041/27
この本は、Ruby, Selenium WebDriver でのテスト手法を書いた本
例えば、Ruby, Selenium WebDriverで、
Yahoo への自動ログインするスクリプトは、下を参照
【VBScript】WSHについて話し合うスレ【JScript】
https://mevius.5ch.net/test/read.cgi/tech/1578522041/27
852デフォルトの名無しさん (ワッチョイ 630c-OxJ8)
2020/02/16(日) 22:59:33.28ID:jBsklMHb0 そしてさも当然ように混じり込むいつものRubyキチ
853デフォルトの名無しさん (ワッチョイ 477b-yNzz)
2020/02/16(日) 23:43:22.86ID:j/dbz9ZG0 >>844
だから君は意識が高すぎるんだよ。
誰も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なんて無くてもやりたい放題だ。
これが、そそる、というのは分かる。
だから君は意識が高すぎるんだよ。
誰も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なんて無くてもやりたい放題だ。
これが、そそる、というのは分かる。
854デフォルトの名無しさん (ワッチョイ 477b-yNzz)
2020/02/17(月) 00:04:24.35ID:afVseoTo0 >>845
それがすんなり行くかどうかはアプリの作りによる。
例えば、VSのコンパイル機能は csc.exe へのフロントエンドでしか無く、コマンドラインオプションを作るだけの物ではあるだろ。
こういう場合は至って簡単で、そのまま吐くだけで済む。
上手く行かなかったとしたら、前回の内部状態と混線したのだろうけど、ぱっとは思いつかないね。
普通にアプリを作ってしまえば当然再現性はあり、
どのボタンを押したかをそのまま記録/再生すれば当然同じ結果は生成される。
それらを「人間が見て分かるそれなりのコマンド名」に落とし込むのは大変だろうけど、ぶっちゃけ、
CONTROL Button インスタンス名 Click
程度のDSLならその心配もない。
これ以上に格好良くしようとすると、色々大変なのは分かるが、正直、この程度でもDSLとしては十分だから問題はない。
(ちなみに一応言っておくと、Buttonのみならず、他全て、例えばradioButtonやNumericUpDown、TextBox等、
内部状態を変更するGUIコンポーネントについては全てこの方式で記録/再生してる。
そりゃ再生出来るに決まってるだろ、というのは分かると思う)
それがすんなり行くかどうかはアプリの作りによる。
例えば、VSのコンパイル機能は csc.exe へのフロントエンドでしか無く、コマンドラインオプションを作るだけの物ではあるだろ。
こういう場合は至って簡単で、そのまま吐くだけで済む。
上手く行かなかったとしたら、前回の内部状態と混線したのだろうけど、ぱっとは思いつかないね。
普通にアプリを作ってしまえば当然再現性はあり、
どのボタンを押したかをそのまま記録/再生すれば当然同じ結果は生成される。
それらを「人間が見て分かるそれなりのコマンド名」に落とし込むのは大変だろうけど、ぶっちゃけ、
CONTROL Button インスタンス名 Click
程度のDSLならその心配もない。
これ以上に格好良くしようとすると、色々大変なのは分かるが、正直、この程度でもDSLとしては十分だから問題はない。
(ちなみに一応言っておくと、Buttonのみならず、他全て、例えばradioButtonやNumericUpDown、TextBox等、
内部状態を変更するGUIコンポーネントについては全てこの方式で記録/再生してる。
そりゃ再生出来るに決まってるだろ、というのは分かると思う)
855デフォルトの名無しさん (ブーイモ MM0e-BzDP)
2020/02/17(月) 00:55:46.18ID:b+8cPYAUM >>853
いやいや誰も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普通に使っててもリフレクション使ったコードなんて滅多に書かねえよ
いやいや誰も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普通に使っててもリフレクション使ったコードなんて滅多に書かねえよ
856デフォルトの名無しさん (ワッチョイ b7a7-sep5)
2020/02/17(月) 01:21:39.40ID:HQMlSi3n0 処理の冒頭だけで途中でメッセージボックスが表示されてさらにユーザの追加入力が必要な処理はこれ使えねぇだろ
まさにゴミだろキングオブゴミだろ
まさにゴミだろキングオブゴミだろ
857デフォルトの名無しさん (ワッチョイ 634b-cV5V)
2020/02/17(月) 11:36:19.89ID:7RiN2OZY0 ThreadPool を使って、非同期に処理を実行しています。
特定のタイミングで ThreadPool に溜まっている処理を全て削除したいのですが、どのようにすればよいでしょうか。
// Threadの登録
ThreadPool.QueueUserWorkItem(new WaitCallback(ThreadMethod));
// ThreadMethod の処理が終わる前に abort させたい
スレ違いなら、誘導してもらえると助かります。
特定のタイミングで ThreadPool に溜まっている処理を全て削除したいのですが、どのようにすればよいでしょうか。
// Threadの登録
ThreadPool.QueueUserWorkItem(new WaitCallback(ThreadMethod));
// ThreadMethod の処理が終わる前に abort させたい
スレ違いなら、誘導してもらえると助かります。
858デフォルトの名無しさん (ワッチョイ f2cf-OxJ8)
2020/02/17(月) 12:34:12.65ID:7ui4xGiq0 古すぎるコード
859デフォルトの名無しさん (ワッチョイ ded6-dJav)
2020/02/17(月) 13:00:54.86ID:uup53KRg0 >>857
CancellationToken(CancellationTokenSource.Token)
CancellationToken(CancellationTokenSource.Token)
860デフォルトの名無しさん (アウアウウー Sac3-+wK4)
2020/02/17(月) 13:25:50.80ID:YCC5nnQ0a >>850
なんか話が噛み合ってないね。
ボタンABCDEを全部クリックしたのと同じことが起るボタンが欲しい、という要件が発生した時、
その責務をモデルに持たせるべきか、むしろUIレベルでやってしまった方がよいかは微妙で
ケースバイケースだと思う。
俺は後者の場合の話をしています。
これまでの流れからそれは自明だと思うけど。
どうでもいいけどこういうのってemulat"なの?
simulateでしょ?俺の認識がおかしいのかな。
emulateって言葉はこの世界ではハードウェアの機能をソフトで代替するって
ニュアンスが強いと思うんだけどどうかな
なんか話が噛み合ってないね。
ボタンABCDEを全部クリックしたのと同じことが起るボタンが欲しい、という要件が発生した時、
その責務をモデルに持たせるべきか、むしろUIレベルでやってしまった方がよいかは微妙で
ケースバイケースだと思う。
俺は後者の場合の話をしています。
これまでの流れからそれは自明だと思うけど。
どうでもいいけどこういうのってemulat"なの?
simulateでしょ?俺の認識がおかしいのかな。
emulateって言葉はこの世界ではハードウェアの機能をソフトで代替するって
ニュアンスが強いと思うんだけどどうかな
861デフォルトの名無しさん (アウアウウー Sac3-+wK4)
2020/02/17(月) 13:37:48.80ID:YCC5nnQ0a まああれだ、ボタンクリックをシミュレートするなんてなんかダサい、という
中二病的な発想は(同意はできないけど)理解はできないでもない
そういう人は「プログラマの意図と実際のコードに乖離がある」 ことの方には気持ち悪さを感じないんだねw
っていうか理解できないのか。>>850の人もそうだと思うけど。
だから、プログラマの意図というか要件は「ボタンABCDE全部が押されたのと同じことを起こすボタンが欲しい」
なんだけど。
中二病的な発想は(同意はできないけど)理解はできないでもない
そういう人は「プログラマの意図と実際のコードに乖離がある」 ことの方には気持ち悪さを感じないんだねw
っていうか理解できないのか。>>850の人もそうだと思うけど。
だから、プログラマの意図というか要件は「ボタンABCDE全部が押されたのと同じことを起こすボタンが欲しい」
なんだけど。
862デフォルトの名無しさん (ワッチョイ 1242-OxJ8)
2020/02/17(月) 14:03:27.84ID:/fXse39B0 俺なら「ボタンが同時に押されないように作る若しくは押されても一つだけ有効にする」で組む方を優先するわ
863デフォルトの名無しさん (ブーイモ MM0e-BzDP)
2020/02/17(月) 18:09:56.85ID:qOh2XpnLM864デフォルトの名無しさん (ワッチョイ ef7b-sg8N)
2020/02/17(月) 18:50:47.45ID:q0kZWH/L0 ワッチョイ 477b-yNzz
ブーイモ MM0e-BzDP
アウアウウー Sac3-+wK4
いつまで続ける気だよ役立たずどころかクソ迷惑
ブーイモ MM0e-BzDP
アウアウウー Sac3-+wK4
いつまで続ける気だよ役立たずどころかクソ迷惑
865デフォルトの名無しさん (ブーイモ MM0e-BzDP)
2020/02/17(月) 19:14:45.43ID:vEzx9LASM866デフォルトの名無しさん (ワッチョイ 477b-yNzz)
2020/02/17(月) 19:45:45.35ID:afVseoTo0 >>855
まあ君がどうしてもPowerShell推しなのはわかった。
> UI操作するオレオレDSLなんてまあバグだらけだろうな
それはオレオレDSLに無理に高度な機能を持たせすぎてるから。
つるんと書かれたDSLをただ上から順番に実行するだけ、しかもエミュレーションの時に、
何行のコードを追加し、何行の既存コードを変更する必要があると思ってるんだ?
面倒だから答えを言ってしまうが、追加が30-50行程度、既存変更は0行、つまり変更無しだ。
エミュレーションが開発的に強烈なのはこの、完全に外付け出来る点だ。
>>849,850の争点もここで、俺は849と思想が同じく、「そもそもテスト項目を増やすな」でしかない。
だからバグっててもDSLモジュール内で閉じてて精々DSL機能が使えなくなるだけで、
追加テストはエミュレーション部分のみ、というのは十分魅力的なんだよ。
そして君はAPIAPI言っているけど、PowerShellには特にAPIを用意する必要があるわけではないだろ。
publicにしてある関数を勝手に呼ぶだけ、精々ドキュメントを整備するくらいだ。
当然リフレクションを使えば内部関数等は全部抜けるので、呼ぶだけならいくらでも出来る。
リバースコンパイラを使えば分かるが、リフレクションでも割と読めるコードが得られる。
後は好きなだけハッキングしろ、でしかない。(これを、そそる、と言っている)
まあ君がどうしてもPowerShell推しなのはわかった。
> UI操作するオレオレDSLなんてまあバグだらけだろうな
それはオレオレDSLに無理に高度な機能を持たせすぎてるから。
つるんと書かれたDSLをただ上から順番に実行するだけ、しかもエミュレーションの時に、
何行のコードを追加し、何行の既存コードを変更する必要があると思ってるんだ?
面倒だから答えを言ってしまうが、追加が30-50行程度、既存変更は0行、つまり変更無しだ。
エミュレーションが開発的に強烈なのはこの、完全に外付け出来る点だ。
>>849,850の争点もここで、俺は849と思想が同じく、「そもそもテスト項目を増やすな」でしかない。
だからバグっててもDSLモジュール内で閉じてて精々DSL機能が使えなくなるだけで、
追加テストはエミュレーション部分のみ、というのは十分魅力的なんだよ。
そして君はAPIAPI言っているけど、PowerShellには特にAPIを用意する必要があるわけではないだろ。
publicにしてある関数を勝手に呼ぶだけ、精々ドキュメントを整備するくらいだ。
当然リフレクションを使えば内部関数等は全部抜けるので、呼ぶだけならいくらでも出来る。
リバースコンパイラを使えば分かるが、リフレクションでも割と読めるコードが得られる。
後は好きなだけハッキングしろ、でしかない。(これを、そそる、と言っている)
867デフォルトの名無しさん (ワッチョイ 477b-yNzz)
2020/02/17(月) 19:46:35.47ID:afVseoTo0 あと、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インタフェースに揃える美味さだ。だからみんなここから離れられない。
気づいていないんだろうけど、「テキストファイルで操作する」というのは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インタフェースに揃える美味さだ。だからみんなここから離れられない。
868デフォルトの名無しさん (ワッチョイ 477b-yNzz)
2020/02/17(月) 19:47:56.86ID:afVseoTo0 >>860
一応調べてみたが、この場合は微妙だし、どっちでも良いと思う。
> 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扱いの2つは、
simulatorが「このボタンをクリックしたら結果的にこの関数を実行する」と知っていて、
外面動作を合わせる為にそこを呼んでいる。
当然emulationの実行速度はsimulationと比べて遅い。
だから、最初からsome_func()呼べよ、という若さは分かるが、そこをケチっても実質的意味はない。
ここら辺は年を取れば老獪になるというか、手の抜きどころが分かるようになる。
emulation方式だと当然、UIスレッドがハングアップしていたら永久に処理されないし、
未処理のイベントがあればその後に処理されることになる。
ここら辺は完全にハードウェアマウスの動作と同じになる。
simulation方式だと、すぐに呼ばれる為、
非UIスレッドでDSLを処理した場合、未処理のUIイベントがあると処理順序が逆転してしまう。
だから、DSL実行環境とGUIの実行環境が同一の場合はDSL処理はUIスレッドでやるしかない。
だったら最初からPerformClickでやればそういう心配すらないだろ、ということになる。
一応調べてみたが、この場合は微妙だし、どっちでも良いと思う。
> 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扱いの2つは、
simulatorが「このボタンをクリックしたら結果的にこの関数を実行する」と知っていて、
外面動作を合わせる為にそこを呼んでいる。
当然emulationの実行速度はsimulationと比べて遅い。
だから、最初からsome_func()呼べよ、という若さは分かるが、そこをケチっても実質的意味はない。
ここら辺は年を取れば老獪になるというか、手の抜きどころが分かるようになる。
emulation方式だと当然、UIスレッドがハングアップしていたら永久に処理されないし、
未処理のイベントがあればその後に処理されることになる。
ここら辺は完全にハードウェアマウスの動作と同じになる。
simulation方式だと、すぐに呼ばれる為、
非UIスレッドでDSLを処理した場合、未処理のUIイベントがあると処理順序が逆転してしまう。
だから、DSL実行環境とGUIの実行環境が同一の場合はDSL処理はUIスレッドでやるしかない。
だったら最初からPerformClickでやればそういう心配すらないだろ、ということになる。
869デフォルトの名無しさん (ワッチョイ 477b-yNzz)
2020/02/17(月) 19:49:07.54ID:afVseoTo0 余談だが>>850のUIテストが安定しないのはこの辺が大きい。
要は、GUIなんて所詮人間相手前提で組んであるのであって、
CPUの速度でイベントを積まれた場合にも正しく動くレベルまでのテストは為されていない事も多い。
技術的に見ればアプリが糞で組み方が悪いだけだが、そこまで保証する意味もないのも事実。
結果、「人間がやると動くが、CPUでやると動かない」なんてのは割とよく遭遇することになる。
だからまあ、「UIテストは安定しないから出来るだけ回避」も一つの戦術だが、
「UIテストも安定するようにちゃんと設計する」も一つの戦術なんだけどね。
「安定しない」のはあんまり正当化していい話でもないし、
ちゃんと設計されているアプリしか触ったことのない人にとってはポカーンな話でもあるとは思うよ。
ちなみに、文句を言っている連中に合わせるとしたら、以下のようなDSLにすればいい。
CONTROL Button instancename Click // PerformClickを呼ぶ
some_func() // some_func()を直接呼ぶ
これで、好きな方使えで済む話で、実際も、これに近い。
(当然だがDSL用のコマンドは別に持ってて、全部大文字なのはそれらと被らない為の方策)
要は、GUIなんて所詮人間相手前提で組んであるのであって、
CPUの速度でイベントを積まれた場合にも正しく動くレベルまでのテストは為されていない事も多い。
技術的に見ればアプリが糞で組み方が悪いだけだが、そこまで保証する意味もないのも事実。
結果、「人間がやると動くが、CPUでやると動かない」なんてのは割とよく遭遇することになる。
だからまあ、「UIテストは安定しないから出来るだけ回避」も一つの戦術だが、
「UIテストも安定するようにちゃんと設計する」も一つの戦術なんだけどね。
「安定しない」のはあんまり正当化していい話でもないし、
ちゃんと設計されているアプリしか触ったことのない人にとってはポカーンな話でもあるとは思うよ。
ちなみに、文句を言っている連中に合わせるとしたら、以下のようなDSLにすればいい。
CONTROL Button instancename Click // PerformClickを呼ぶ
some_func() // some_func()を直接呼ぶ
これで、好きな方使えで済む話で、実際も、これに近い。
(当然だがDSL用のコマンドは別に持ってて、全部大文字なのはそれらと被らない為の方策)
870デフォルトの名無しさん (ワッチョイ 1fad-z23p)
2020/02/17(月) 19:55:08.69ID:Nkb49BjE0 議論が発散しててよくわかんないな。
何が何なの?全員、アブストを書いたらどうだ?
何が何なの?全員、アブストを書いたらどうだ?
871デフォルトの名無しさん (ブーイモ MM32-BzDP)
2020/02/17(月) 19:56:33.16ID:iNM+ZupGM >>866
論点をずらそうとしてるね
クソみたいなUI操作オレオレマクロよりUI非依存のPSのが低コストで品質がいいねというだけの話だろ
例としてPSを出したが別になんだっていいよ
最も大きな問題はインタプリタの方ではなくUI操作でオートメーションサポートするというバカバカしい発想の方な
オートメーションをサポートするならUI非依存のAPIを整備しろ
それが正しい道だ
論点をずらそうとしてるね
クソみたいなUI操作オレオレマクロよりUI非依存のPSのが低コストで品質がいいねというだけの話だろ
例としてPSを出したが別になんだっていいよ
最も大きな問題はインタプリタの方ではなくUI操作でオートメーションサポートするというバカバカしい発想の方な
オートメーションをサポートするならUI非依存のAPIを整備しろ
それが正しい道だ
872デフォルトの名無しさん (スッップ Sd32-3blX)
2020/02/17(月) 20:21:59.64ID:YeNwIpPfd 話がまとまってないのに余談とか言っちゃって相手もそれに乗っかちゃって…
これを繰り返すからいつまで経っても収束しないし元の議題が何だったかわかりづらくなる
これを繰り返すからいつまで経っても収束しないし元の議題が何だったかわかりづらくなる
873デフォルトの名無しさん (ワッチョイ 477b-yNzz)
2020/02/17(月) 20:24:09.75ID:afVseoTo0 >>860
>>868訂正、結果的に>>869は間違いなのでよろしく
俺の見解では全部simulationになる。
確認してみたら、PerformClickは同期イベントだった。
呼び出し履歴見る限り、Button.PerformClick->Button.Onclick->Control.OnClick->イベントハンドラ なので、
OnClickもほぼ確実に同期だと思われる。
だから呼称は全て simulation の方が妥当となる。
イベントキューとかは全く関係なくなるので、該当部分の869の話は間違いということでよろしく。
同期イベントなのは.NETの癌だと思っていたが、
この点に関しては同期イベントの方がプログラミングしやすい、というのは事実だな。
(俺の想定の非同期イベントだと俺のコードは動かないはずなのに気づき、確認したところ、同期だったorz)
>>868訂正、結果的に>>869は間違いなのでよろしく
俺の見解では全部simulationになる。
確認してみたら、PerformClickは同期イベントだった。
呼び出し履歴見る限り、Button.PerformClick->Button.Onclick->Control.OnClick->イベントハンドラ なので、
OnClickもほぼ確実に同期だと思われる。
だから呼称は全て simulation の方が妥当となる。
イベントキューとかは全く関係なくなるので、該当部分の869の話は間違いということでよろしく。
同期イベントなのは.NETの癌だと思っていたが、
この点に関しては同期イベントの方がプログラミングしやすい、というのは事実だな。
(俺の想定の非同期イベントだと俺のコードは動かないはずなのに気づき、確認したところ、同期だったorz)
874デフォルトの名無しさん (ワッチョイ 477b-yNzz)
2020/02/17(月) 20:40:15.99ID:afVseoTo0875デフォルトの名無しさん (ブーイモ MM0e-BzDP)
2020/02/17(月) 21:41:26.92ID:zVw4OscHM >>874
Selenium系はAPIを提供してないサイトのオートメーションをユーザーが苦労して泣く泣く自動化したい場合やテスト自動化で使うツールな
俺らが今議論してるのはユーザー目線じゃなくて提供者側なんだよ
提供者側がAPI実装を放棄してGUI操作をサポートするなど馬鹿なことだ
ユーザーに苦労を押しつけてはいけない
Selenium系はAPIを提供してないサイトのオートメーションをユーザーが苦労して泣く泣く自動化したい場合やテスト自動化で使うツールな
俺らが今議論してるのはユーザー目線じゃなくて提供者側なんだよ
提供者側がAPI実装を放棄してGUI操作をサポートするなど馬鹿なことだ
ユーザーに苦労を押しつけてはいけない
876デフォルトの名無しさん (アウアウウー Sac3-+wK4)
2020/02/17(月) 21:45:10.71ID:HH3Dtgxka >>863
複数のボタンを全部クリックした時の動作、なんていう下らない機能を
モデルに持たせることが正当化されるケースってむしろあんまりないと思うよw
ぱっと思いつくのは、ボタンABCDEをクリックした時の処理に共通する部分
(例えばファイルのopen/closeのような前処理後処理)があって、まとめてやる場合には
大幅な最適化が可能な場合。
この人本当にプログラマかな。
複数のボタンを全部クリックした時の動作、なんていう下らない機能を
モデルに持たせることが正当化されるケースってむしろあんまりないと思うよw
ぱっと思いつくのは、ボタンABCDEをクリックした時の処理に共通する部分
(例えばファイルのopen/closeのような前処理後処理)があって、まとめてやる場合には
大幅な最適化が可能な場合。
この人本当にプログラマかな。
877デフォルトの名無しさん (アウアウウー Sac3-+wK4)
2020/02/17(月) 21:49:38.11ID:HH3Dtgxka878デフォルトの名無しさん (ブーイモ MM0e-BzDP)
2020/02/17(月) 22:01:31.09ID:zVw4OscHM >>876
その糞設計だと要件変化ですぐにコードが汚染されるだろうなぁ
処理は今までどおり実行したいが特定のボタンだけ画面から削除したくなったせいで謎のHiddenボタンを置いたり
処理の結果で後続の処理を分岐したくなったせいで不自然な制御フラグフィールドが乱立したり
画面のデザイン変えただけなのになぜか処理の実行順序が変わったり
少し想像しただけでトラブルの兆しがするするでてくる
こういう発想はアマチュアらしくて微笑ましいけど業務で見かけたら説教しなきゃいけないぐらいだ
その糞設計だと要件変化ですぐにコードが汚染されるだろうなぁ
処理は今までどおり実行したいが特定のボタンだけ画面から削除したくなったせいで謎のHiddenボタンを置いたり
処理の結果で後続の処理を分岐したくなったせいで不自然な制御フラグフィールドが乱立したり
画面のデザイン変えただけなのになぜか処理の実行順序が変わったり
少し想像しただけでトラブルの兆しがするするでてくる
こういう発想はアマチュアらしくて微笑ましいけど業務で見かけたら説教しなきゃいけないぐらいだ
879デフォルトの名無しさん (ワッチョイ 932c-VKUZ)
2020/02/17(月) 22:05:59.99ID:dzSo2/zk0 >>863
各ボタンに割り当ててるコマンドをcomposite Commandで繋いで終わりじゃない?
各ボタンに割り当ててるコマンドをcomposite Commandで繋いで終わりじゃない?
880デフォルトの名無しさん (アウアウウー Sac3-+wK4)
2020/02/17(月) 22:08:44.55ID:HH3Dtgxka881デフォルトの名無しさん (アウアウウー Sac3-+wK4)
2020/02/17(月) 22:09:55.34ID:HH3Dtgxka どーでもいい非必然的な機能をモデルに持たせることは、
UIにベタベタ処理を実装するのと同じ糞設計ですw
UIにベタベタ処理を実装するのと同じ糞設計ですw
882デフォルトの名無しさん (アウアウウー Sac3-+wK4)
2020/02/17(月) 22:28:58.59ID:HH3Dtgxka 一応言い訳しておくけど、>>876に書いたみたいに最適化の恩恵なんかなくても
複数の処理をまとめて一度にやるメソッドをモデルが持つことが自然なケースはもちろん存在すると思う。
っでも俺が言っているのは「黒い白鳥もいる」だからね。
「白鳥は全部白いは間違っている」と言ってるだけだから
複数の処理をまとめて一度にやるメソッドをモデルが持つことが自然なケースはもちろん存在すると思う。
っでも俺が言っているのは「黒い白鳥もいる」だからね。
「白鳥は全部白いは間違っている」と言ってるだけだから
883デフォルトの名無しさん (ブーイモ MM0e-BzDP)
2020/02/17(月) 22:56:12.88ID:zVw4OscHM884デフォルトの名無しさん (ブーイモ MM0e-BzDP)
2020/02/17(月) 23:01:51.58ID:zVw4OscHM885デフォルトの名無しさん (ブーイモ MM0e-BzDP)
2020/02/17(月) 23:03:21.26ID:zVw4OscHM886デフォルトの名無しさん (ワッチョイ b7a7-sep5)
2020/02/17(月) 23:09:15.69ID:HQMlSi3n0 こない未来を予測してる奴はバカ
絶対失敗する
しかも、最悪の形で
絶対失敗する
しかも、最悪の形で
887デフォルトの名無しさん (ブーイモ MM0e-BzDP)
2020/02/17(月) 23:18:49.77ID:43uLIzGsM >>886
来るかもしれない未来を考えないのも同じぐらい馬鹿だな
そして未来がわからんなら余計な拡張性を導入するのではなくコードを容易に改修できるようにシンプルに保つことが重要
つまりシンプルなモデルにやりたいことを素直に書けばそれでいい
それで済むものをわざわざボタンクリックなんていうやらなくていい遠回りな方法で実装するのは後で困る馬鹿の典型例
来るかもしれない未来を考えないのも同じぐらい馬鹿だな
そして未来がわからんなら余計な拡張性を導入するのではなくコードを容易に改修できるようにシンプルに保つことが重要
つまりシンプルなモデルにやりたいことを素直に書けばそれでいい
それで済むものをわざわざボタンクリックなんていうやらなくていい遠回りな方法で実装するのは後で困る馬鹿の典型例
888デフォルトの名無しさん (ワッチョイ 477b-yNzz)
2020/02/18(火) 00:50:17.87ID:/0BlMKgF0 >>875
だから君はちょっと意識が高すぎるんだよ。
自動化したいユーザーは、今やったのと同じ操作を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なんてゴミになることになる。
俺はそんなことにはならないと思うけど。
だから君はちょっと意識が高すぎるんだよ。
自動化したいユーザーは、今やったのと同じ操作を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なんてゴミになることになる。
俺はそんなことにはならないと思うけど。
889デフォルトの名無しさん (ワッチョイ b7a7-sep5)
2020/02/18(火) 00:57:57.34ID:GPdxsdEp0890デフォルトの名無しさん (アウアウウー Sac3-I9Fa)
2020/02/18(火) 06:52:39.11ID:fxDAJd/Ea 言い合いになるなら
構わなきゃいいのになあw
構わなきゃいいのになあw
891デフォルトの名無しさん (ブーイモ MM32-BzDP)
2020/02/18(火) 07:50:57.99ID:LkwV7cyFM >>888
意識は高くない普通の感覚だよ
当たり前のことを当たり前にやるだけだ
モデルに処理を書いてビューに紐付けるってごくごく自然なコードだろ
しかもそれすればほとんどタダでオートメーションサポート機能が手にはいるんだぞ
ボタンクリックとかわざわざ苦労してトラブルを持ち込んでくる意味わからねえわ
マゾなのか
意識は高くない普通の感覚だよ
当たり前のことを当たり前にやるだけだ
モデルに処理を書いてビューに紐付けるってごくごく自然なコードだろ
しかもそれすればほとんどタダでオートメーションサポート機能が手にはいるんだぞ
ボタンクリックとかわざわざ苦労してトラブルを持ち込んでくる意味わからねえわ
マゾなのか
892デフォルトの名無しさん (JP 0H6e-1vH+)
2020/02/18(火) 07:59:37.22ID:ZOlvaa/TH >>889
その程度の回避策が思いつかないようなバカがいるとは
その程度の回避策が思いつかないようなバカがいるとは
893デフォルトの名無しさん (ブーイモ MM32-BzDP)
2020/02/18(火) 08:20:17.01ID:LkwV7cyFM >>888
ちなみにこのマクロでわかりやすいと思うのはお前だけだぞ
普通の人だったら
オートメーションなのなんでコントロールを操らないといけないんだ意味わからん
ボタンとかテキストとか書かれても何やってるか意味わからん
各行の関連性が意味わからん
操作してるインスタンスはどのフォームだよ意味わからん
などなど大混乱してしまう
ユーザーが見てわかりやすいレコードログってのは↓こういうものな
$model = $MyAppHost.Resolve("MyModel")
$model.FileName = "..."
$model.LoadFile()
$model.FilterA()
$model.SaveFile()
この処理をたとえばカレントディレクトリ全体に適用したいなーってユーザーが思ったらls | foreachでパイプするだけ
お前の大好きなコード生成みたいなバカバカしい無駄な苦労をしなくて済む
ちなみにこのマクロでわかりやすいと思うのはお前だけだぞ
普通の人だったら
オートメーションなのなんでコントロールを操らないといけないんだ意味わからん
ボタンとかテキストとか書かれても何やってるか意味わからん
各行の関連性が意味わからん
操作してるインスタンスはどのフォームだよ意味わからん
などなど大混乱してしまう
ユーザーが見てわかりやすいレコードログってのは↓こういうものな
$model = $MyAppHost.Resolve("MyModel")
$model.FileName = "..."
$model.LoadFile()
$model.FilterA()
$model.SaveFile()
この処理をたとえばカレントディレクトリ全体に適用したいなーってユーザーが思ったらls | foreachでパイプするだけ
お前の大好きなコード生成みたいなバカバカしい無駄な苦労をしなくて済む
894デフォルトの名無しさん (ワッチョイ 63de-sep5)
2020/02/18(火) 08:23:55.17ID:didWPBin0 >>892
そこ工夫が必要ならこんなくだらんメソッド呼ばんわw
そこ工夫が必要ならこんなくだらんメソッド呼ばんわw
895デフォルトの名無しさん (ブーイモ MM32-BzDP)
2020/02/18(火) 08:43:22.08ID:LkwV7cyFM >>888
例えばさぁ
お前のオレオレうんこマクロでファイルが存在しなかった場合のハンドリング処理はどうやって書くつもりなんだ?
ファイルの形式が間違ってた場合は?
セーブに失敗したときどうする?
指定したディレクトリツリーのファイルすべて処理したいときはどう書くんだ?
例えばさぁ
お前のオレオレうんこマクロでファイルが存在しなかった場合のハンドリング処理はどうやって書くつもりなんだ?
ファイルの形式が間違ってた場合は?
セーブに失敗したときどうする?
指定したディレクトリツリーのファイルすべて処理したいときはどう書くんだ?
896デフォルトの名無しさん (ワッチョイ 167b-4wVb)
2020/02/18(火) 21:08:13.91ID:U5rnBvKT0 直のWINAPI(というか多分アンマネージ)が混ざる動作だとDebugとReleaseで動き変わること割りとあってめんどくさいな
897デフォルトの名無しさん (ドコグロ MM47-P13C)
2020/02/19(水) 07:47:22.74ID:bztKe272M >>896
単なるお前のバグだろ
単なるお前のバグだろ
898デフォルトの名無しさん (ワイーワ2 FFdf-IPX/)
2020/02/19(水) 11:28:45.13ID:cGULNOoWF WINAPIのはDebugだと0埋めされるんだろ
そりゃ動作変わるって(バグがあればω)
そりゃ動作変わるって(バグがあればω)
899デフォルトの名無しさん (オイコラミネオ MMff-oN3k)
2020/02/19(水) 14:38:26.03ID:xNHctau2M 0じゃなく埋められる数値は何種類かある
デバッグリリースで挙動変わるのはほぼ確実にメモリ周りでなんかやらかしてるね
デバッグリリースで挙動変わるのはほぼ確実にメモリ周りでなんかやらかしてるね
900デフォルトの名無しさん (ワッチョイ c37b-1Vd5)
2020/02/19(水) 21:10:46.74ID:1xSUjqPH0 >>893
俺は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フォーマット(テキストと標準入出力)に揃えるのは、異様なほど自由度を提供する物なんだよ。
だからみんなそこから離れられない。
俺は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フォーマット(テキストと標準入出力)に揃えるのは、異様なほど自由度を提供する物なんだよ。
だからみんなそこから離れられない。
901デフォルトの名無しさん (ワッチョイ c37b-1Vd5)
2020/02/19(水) 21:11:45.68ID:1xSUjqPH0 君が間違えているのは、君が出来ているつもりになっている「レイヤー設計」だ。(>>819)
君の中ではPowerShell(中レベル)/アプリの2層しかないから
中レベルAPIをアプリ自体に求め、それで汎用性が全くなくなっている。
そうではなく、各言語向け中→低レベル変換ライブラリ(上記A,B等)を噛ませば、
各言語(中レベル)/各言語向けレベル変換ライブラリ/アプリ(低レベル)となり、
全ての言語で中レベルでも低レベルでも書ける状況になるだろ。
俺の好きなフォーマットで書かせろ、というのはいいが、それはAPIに直接求めるものではない。
どうせどんなAPI/フォーマットを提供したところで、全員が満足する事なんて無いんだ。
なら、上記のように、単純な関数化/ラップでそれぞれのオレオレ超最高フォーマットが手に入るのなら、
それは素晴らしいAPIってことになるんだよ。
そして本件なんて、文句を言った方が恥ずかしくなるレベルなのは君でも分かるだろ。
君の中ではPowerShell(中レベル)/アプリの2層しかないから
中レベルAPIをアプリ自体に求め、それで汎用性が全くなくなっている。
そうではなく、各言語向け中→低レベル変換ライブラリ(上記A,B等)を噛ませば、
各言語(中レベル)/各言語向けレベル変換ライブラリ/アプリ(低レベル)となり、
全ての言語で中レベルでも低レベルでも書ける状況になるだろ。
俺の好きなフォーマットで書かせろ、というのはいいが、それはAPIに直接求めるものではない。
どうせどんなAPI/フォーマットを提供したところで、全員が満足する事なんて無いんだ。
なら、上記のように、単純な関数化/ラップでそれぞれのオレオレ超最高フォーマットが手に入るのなら、
それは素晴らしいAPIってことになるんだよ。
そして本件なんて、文句を言った方が恥ずかしくなるレベルなのは君でも分かるだろ。
902デフォルトの名無しさん (ブーイモ MMff-o/5i)
2020/02/19(水) 22:47:18.69ID:Z9/2no0YM903デフォルトの名無しさん (ブーイモ MMff-o/5i)
2020/02/19(水) 22:52:36.17ID:Z9/2no0YM >>901
ホント残念なやつだな
アプリの中にさらに層が別れてるに決まってんだろ
それぞれの層をスクリプティング用に公開することもほぼノーコストでできる
薄汚いオレオレラッパーを大量生産する苦痛とは無縁だ
そんなこた言わなくてもわかることなんだがわからなかったか
ホント残念なやつだな
アプリの中にさらに層が別れてるに決まってんだろ
それぞれの層をスクリプティング用に公開することもほぼノーコストでできる
薄汚いオレオレラッパーを大量生産する苦痛とは無縁だ
そんなこた言わなくてもわかることなんだがわからなかったか
904デフォルトの名無しさん (ブーイモ MMff-o/5i)
2020/02/19(水) 23:21:51.22ID:Z9/2no0YM >>900
つうかな自由とハックを混同するな
そういうのは黒魔術的な方向に進化してあっという間にカオス化して行く
そんなものはだれもありがたがらない
製造元が頭の悪いマクロしか提供していないから泣く泣くラップ作業に着手するってんならまあ話はわかるが進んでやりたいことじゃねえわな
つうかな自由とハックを混同するな
そういうのは黒魔術的な方向に進化してあっという間にカオス化して行く
そんなものはだれもありがたがらない
製造元が頭の悪いマクロしか提供していないから泣く泣くラップ作業に着手するってんならまあ話はわかるが進んでやりたいことじゃねえわな
905デフォルトの名無しさん (ワッチョイ c37b-1Vd5)
2020/02/19(水) 23:22:37.14ID:1xSUjqPH0 >>902
まあもう一々答える気はないんだけどな。
本当に問題になることを突かれた場合は改善に繋がるから有用なのだけど、
君のレベルではそれは無理だし、実際に今回も恥ずかしいことになってるだろ。
多分君が根本的に間違っているのは、バグをバグと認識できてないことだ。
既に言ったがUIを噛ませて動作が不安定になるのは、明確にバグなんだよ。
それはCPUが余りまくっている暇人環境なら再現しにくいだけで、
他アプリでCPUを取られている場合においてはユーザー環境でも普通に再現する。
つまりCPUロードが高い状況では不安定になるわけで、これは普通にバグだよ。
だから君はまずそのバグを直さないといけない。
そうすると>>850の認識をだいぶ修正出来るだろうさ。
まあもう一々答える気はないんだけどな。
本当に問題になることを突かれた場合は改善に繋がるから有用なのだけど、
君のレベルではそれは無理だし、実際に今回も恥ずかしいことになってるだろ。
多分君が根本的に間違っているのは、バグをバグと認識できてないことだ。
既に言ったがUIを噛ませて動作が不安定になるのは、明確にバグなんだよ。
それはCPUが余りまくっている暇人環境なら再現しにくいだけで、
他アプリでCPUを取られている場合においてはユーザー環境でも普通に再現する。
つまりCPUロードが高い状況では不安定になるわけで、これは普通にバグだよ。
だから君はまずそのバグを直さないといけない。
そうすると>>850の認識をだいぶ修正出来るだろうさ。
906デフォルトの名無しさん (ブーイモ MMff-o/5i)
2020/02/19(水) 23:24:13.74ID:Z9/2no0YM907デフォルトの名無しさん (ブーイモ MMff-o/5i)
2020/02/19(水) 23:31:23.42ID:Z9/2no0YM >>905
つか不安定ってとこを拠り所にしてるようだが
仮に完全に安定しててもUI操作ベース貧弱文法のオレオレマクロなんて積極的に使う理由にならんからな
UI非依存のAPIを優先して他に何もなくてどうしてもUI操作せざるを得ないとなったらそこで初めて使うか別のツールに移行するか検討すんだよ
そこんとこはやく理解したほうがいいぞ
同僚や取引先にボタン押すオレオレマクロ機能をドヤ顔で提案して赤っ恥をかく前に気づいたほうがいい
これ本当に君が心配だから言ってる
つか不安定ってとこを拠り所にしてるようだが
仮に完全に安定しててもUI操作ベース貧弱文法のオレオレマクロなんて積極的に使う理由にならんからな
UI非依存のAPIを優先して他に何もなくてどうしてもUI操作せざるを得ないとなったらそこで初めて使うか別のツールに移行するか検討すんだよ
そこんとこはやく理解したほうがいいぞ
同僚や取引先にボタン押すオレオレマクロ機能をドヤ顔で提案して赤っ恥をかく前に気づいたほうがいい
これ本当に君が心配だから言ってる
908デフォルトの名無しさん (ブーイモ MMff-o/5i)
2020/02/19(水) 23:36:36.72ID:Z9/2no0YM しかもな
もし仮に百万歩譲ってUI操作をサポートしなきゃならんとなったとしてもだ
そんなものはUIA、WinAppDriver、Seleniumに任せときゃいいんだよ
時間と金をかけて赤っ恥マクロを製造する必要はない
もうすでにゴミマクロの億万倍便利なライブラリがあるんだからそれつかいなよ
エンドユーザだってそっち使うよ当たり前だろ
もし仮に百万歩譲ってUI操作をサポートしなきゃならんとなったとしてもだ
そんなものはUIA、WinAppDriver、Seleniumに任せときゃいいんだよ
時間と金をかけて赤っ恥マクロを製造する必要はない
もうすでにゴミマクロの億万倍便利なライブラリがあるんだからそれつかいなよ
エンドユーザだってそっち使うよ当たり前だろ
909デフォルトの名無しさん (ワッチョイ ff63-JjxG)
2020/02/20(木) 00:55:48.08ID:FY8QkcoV0 >>905
正常系だけ動けばいいマクロだったら人間用のUIを触るでもなんとかなるよ。
異常系もハンドリングしなければならないなら、何が出てくるかの一覧もないような、ダイアログに書かれてることを理解しなくちゃいけないんだから、網羅するのはめちゃくちゃ大変だと思わないかな。
人間用には問題を自然言語で全体的な説明する必要があって、
外部プログラム用には事前定義されたメッセージで問題を端的かつ詳細に伝える必要があって、
両者はプロトコルが大きく異なるんだから、人間用に外部プログラム用の伝え方をしたり、もしくはその逆ってのはどう考えても筋が悪い。
外部プログラムに人間シミュレーターをやらせたり、
人間に外部プログラムシミュレーターをやらせたら、
余計なレイヤーが必要になってバグの温床になるだろ。
「バグはバグだろ」とか言ってたって品質は改善しないので、そもそもバグが生まれにくい構造にしておくのが当たり前。
設計からやったことないのかな?
正常系だけ動けばいいマクロだったら人間用のUIを触るでもなんとかなるよ。
異常系もハンドリングしなければならないなら、何が出てくるかの一覧もないような、ダイアログに書かれてることを理解しなくちゃいけないんだから、網羅するのはめちゃくちゃ大変だと思わないかな。
人間用には問題を自然言語で全体的な説明する必要があって、
外部プログラム用には事前定義されたメッセージで問題を端的かつ詳細に伝える必要があって、
両者はプロトコルが大きく異なるんだから、人間用に外部プログラム用の伝え方をしたり、もしくはその逆ってのはどう考えても筋が悪い。
外部プログラムに人間シミュレーターをやらせたり、
人間に外部プログラムシミュレーターをやらせたら、
余計なレイヤーが必要になってバグの温床になるだろ。
「バグはバグだろ」とか言ってたって品質は改善しないので、そもそもバグが生まれにくい構造にしておくのが当たり前。
設計からやったことないのかな?
910デフォルトの名無しさん (ワッチョイ c37b-1Vd5)
2020/02/21(金) 23:28:13.08ID:UQ40Zz5M0911デフォルトの名無しさん (アウアウエー Sadf-o/5i)
2020/02/22(土) 00:53:29.41ID:eCNgUA1qa こういう返しをしてくるということは数日かけても本当に思いつかなかったんだなwww
912デフォルトの名無しさん (ワッチョイ e397-JjxG)
2020/02/22(土) 08:29:38.27ID:lw7HhssO0 >>910
あなたは話を逸らす傾向にあるから、その前に、まず、
「自分のオレオレマクロでは正常系での動作しか考えられていなくて、
正常系で動かないのであれば、バグはバグなんだから修正する必要があると言っていた。
だが、異常系への対応までは考慮することができていなかった」
ということを暗に表明していることを認めてもらえるかな?
異論があるならどこが違うのか指摘してくれ。
あなたは話を逸らす傾向にあるから、その前に、まず、
「自分のオレオレマクロでは正常系での動作しか考えられていなくて、
正常系で動かないのであれば、バグはバグなんだから修正する必要があると言っていた。
だが、異常系への対応までは考慮することができていなかった」
ということを暗に表明していることを認めてもらえるかな?
異論があるならどこが違うのか指摘してくれ。
913デフォルトの名無しさん (ワッチョイ ff63-ufZq)
2020/02/22(土) 10:09:00.65ID:hsz3eTB90 ガイジの相手をしているところが間違っているね
914デフォルトの名無しさん (アウウィフ FFe7-IPX/)
2020/02/22(土) 14:22:35.92ID:2qBDSHyDF 正常系と異常系がごちゃまぜで
どこが危なくてどこが危なくないのか全く区別がつかない
どこが危なくてどこが危なくないのか全く区別がつかない
915デフォルトの名無しさん (ワッチョイ 937b-UH+R)
2020/02/22(土) 14:33:37.40ID:4D2R9AsT0 毎度毎度スレ違いどころか明後日の方向レスの応酬やっている連中は病院行け
916デフォルトの名無しさん (ワッチョイ ff2c-lQWV)
2020/02/22(土) 14:53:22.79ID:qQaAG+8d0 漏れは、スクレイピングに、Ruby, Selenium WebDriver, Nokogiri を使う。
ブラウザの自動操作もできるし
ただ、各サイトの解析が大変。
特に、Ajax で動的に読み込むものは、読み込み前には存在しないから
ブラウザの自動操作もできるし
ただ、各サイトの解析が大変。
特に、Ajax で動的に読み込むものは、読み込み前には存在しないから
917デフォルトの名無しさん (ワッチョイ 232f-lQWV)
2020/02/23(日) 21:04:42.65ID:9ZBd+yN40 ところでこれ、既存の他アプリを操作するって話なの?
自分の既存アプリを多アプリが操作するって話なの?
多アプリで操作されるアプリを設計するって話なの?
自分の既存アプリを多アプリが操作するって話なの?
多アプリで操作されるアプリを設計するって話なの?
918デフォルトの名無しさん (アウアウウー Sa0f-ymO9)
2020/03/09(月) 14:45:58.49ID:aNmrWQjka こんな感じで
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がバカバカ発生して滅茶遅いのですが、なんでですか?
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がバカバカ発生して滅茶遅いのですが、なんでですか?
919デフォルトの名無しさん (ワッチョイ 4f7c-MjGO)
2020/03/09(月) 15:04:37.10ID:306ybdW+0 GCがバカバカ発生したってのはどうやって確認したの?
遅い理由がGCにあるってどうやって確認したの?
遅い理由がGCにあるってどうやって確認したの?
920デフォルトの名無しさん (アウアウウー Sa0f-ymO9)
2020/03/09(月) 15:07:43.02ID:aNmrWQjka >>919
デバッグで起動して、右側の診断ツールのプロセスメモリのグラフに黄色のマークがどんどん現れたのです。
デバッグで起動して、右側の診断ツールのプロセスメモリのグラフに黄色のマークがどんどん現れたのです。
921デフォルトの名無しさん (ワッチョイ 9f24-CBSz)
2020/03/09(月) 15:52:53.45ID:GI3THqg50 WinformsならSuspendLayout & ResumeRayout(true)で囲ってみては?
DataGridViewってItemsSourceに代入するとき以外は代入するたびに表示の更新されるよね、確か
DataGridViewってItemsSourceに代入するとき以外は代入するたびに表示の更新されるよね、確か
922デフォルトの名無しさん (アウアウウー Sa0f-ymO9)
2020/03/09(月) 16:45:24.00ID:aNmrWQjka >>921
やってみましたが変わらずです。
11列×256行で最初の2列はそのままで以降の列に計測値と計算値を代入して、次の測定でクリアするのですが、一回目は瞬時クリアで2回目以降は20秒くらい待たされます。
自動調節などは入れていません。
今まで同様なソフト作っていて初めての事です。
やってみましたが変わらずです。
11列×256行で最初の2列はそのままで以降の列に計測値と計算値を代入して、次の測定でクリアするのですが、一回目は瞬時クリアで2回目以降は20秒くらい待たされます。
自動調節などは入れていません。
今まで同様なソフト作っていて初めての事です。
923デフォルトの名無しさん (スッップ Sdbf-UVo+)
2020/03/09(月) 17:12:18.14ID:cFIy8do/d プロファイラでどこが時間くってるか見てみれば?
924デフォルトの名無しさん (ワイーワ2 FF3f-g6LZ)
2020/03/09(月) 18:10:16.08ID:T4gz2l9RF 何らかの代入してる方に問題ありそう
925デフォルトの名無しさん (ワッチョイ cb7b-NDfE)
2020/03/09(月) 18:28:22.35ID:UntOhQUT0926デフォルトの名無しさん (ワッチョイ 9f24-CBSz)
2020/03/09(月) 18:28:52.87ID:GI3THqg50 >>922
ちゃんと
TestDataGridView.SuspendLayout();
TestDataGridView.ResumeRayout(true);
って書いた?
これはコントロール毎にしか聞かないから、Form1のサスペンド呼び出しても子コントロールには効かない
ちゃんと
TestDataGridView.SuspendLayout();
TestDataGridView.ResumeRayout(true);
って書いた?
これはコントロール毎にしか聞かないから、Form1のサスペンド呼び出しても子コントロールには効かない
927デフォルトの名無しさん (ワッチョイ 9f24-CBSz)
2020/03/09(月) 19:15:42.50ID:GI3THqg50 TestDataGridView.SuspendLayout();
//ここにTestDataGridViewの処理を書く
TestDataGridView.ResumeRayout(true);
いずれにしても20秒も掛かるとなると他に原因ありそうだな
一応自分はFlowLayoutPanelに自作コントロールをListViewのように並べるというソフト作ってた時、
1000個以上のアイテムを一気に追加すると数秒ラグってたのがこの手法によってほぼ一瞬で表示されるようにはなったが
//ここにTestDataGridViewの処理を書く
TestDataGridView.ResumeRayout(true);
いずれにしても20秒も掛かるとなると他に原因ありそうだな
一応自分はFlowLayoutPanelに自作コントロールをListViewのように並べるというソフト作ってた時、
1000個以上のアイテムを一気に追加すると数秒ラグってたのがこの手法によってほぼ一瞬で表示されるようにはなったが
928デフォルトの名無しさん (スッップ Sdbf-UVo+)
2020/03/09(月) 19:28:18.48ID:JH2CO7i+d デバッガ表示見てるんだからプロファイラで問題箇所特定が一番早くて確実
その上で最小再現コード作ったり他の設定いじったり試行錯誤してみればいい
なんで便利な標準ツールを使わずに他の手法を進めるのか理解できない
その上で最小再現コード作ったり他の設定いじったり試行錯誤してみればいい
なんで便利な標準ツールを使わずに他の手法を進めるのか理解できない
929デフォルトの名無しさん (ワッチョイ 9f94-ymO9)
2020/03/09(月) 21:38:17.90ID:aWxXRkAf0 >>926
for文の前後に入れました。
for文の前後に入れました。
930デフォルトの名無しさん (ワッチョイ 9f94-ymO9)
2020/03/09(月) 21:39:54.00ID:aWxXRkAf0 >>928
すまん、使いこなせないのだ。
すまん、使いこなせないのだ。
931デフォルトの名無しさん (ワッチョイ 9f94-ymO9)
2020/03/09(月) 21:50:06.25ID:aWxXRkAf0932デフォルトの名無しさん (ワッチョイ 0ff8-7NIE)
2020/03/09(月) 22:06:22.62ID:eHGFA/ZF0 trueを渡せば停止中にキューに溜まってたものを一括でレイアウトするから低負荷にレイアウトが出来るって仕組みだったはず
なのでtrue引数入れないとパフォーマンス上の恩恵は得られない
なのでtrue引数入れないとパフォーマンス上の恩恵は得られない
933デフォルトの名無しさん (ワッチョイ 8b63-UVo+)
2020/03/10(火) 00:40:45.03ID:rLdwFfVF0 >>930
vs プロファイラでググればすぐ出てくる
どの関数がどれくらい処理時間くってるか全部出してくれる
何なら関数内のどの行がどれだけ処理時間かかってるかまでわかる
この点だけを調べるならマジで簡単だから一度試してみるといいよ
vs プロファイラでググればすぐ出てくる
どの関数がどれくらい処理時間くってるか全部出してくれる
何なら関数内のどの行がどれだけ処理時間かかってるかまでわかる
この点だけを調べるならマジで簡単だから一度試してみるといいよ
934デフォルトの名無しさん (アウアウウー Sa0f-ymO9)
2020/03/10(火) 12:16:47.67ID:FjsT0ZiBa true入れましたが駄目でした。
プロファイラ使ってみました。
1回目の状態です。
http://imgur.com/QRNwSP5.png
瞬時です。
2回目です。
http://imgur.com/cfzhpIi.png
時間かかってます。
セルに代入している時にGCが一杯発生してます。
http://imgur.com/IEzLFZa.png
使い方間違っているのかな?
プロファイラ使ってみました。
1回目の状態です。
http://imgur.com/QRNwSP5.png
瞬時です。
2回目です。
http://imgur.com/cfzhpIi.png
時間かかってます。
セルに代入している時にGCが一杯発生してます。
http://imgur.com/IEzLFZa.png
使い方間違っているのかな?
935デフォルトの名無しさん (アウウィフ FF0f-g6LZ)
2020/03/10(火) 18:15:47.21ID:X+eVfRrsF static な Main() の中で
await を使うと Main() に async が必要と言われ
Main() に async を付けると怒られました><
await を使うと Main() に async が必要と言われ
Main() に async を付けると怒られました><
936デフォルトの名無しさん (ワッチョイ 9f63-hmaZ)
2020/03/10(火) 20:13:50.16ID:bus7JDt50 C#7.1(だっけ?)以降なら書けるから更新する
もしくはstatic async Task AsyncMain()みたいなのを挟む
もしくはstatic async Task AsyncMain()みたいなのを挟む
937デフォルトの名無しさん (ワッチョイ 4feb-xiWk)
2020/03/10(火) 20:16:20.56ID:M4Rwf6kV0 >>934
直接dataGridView触るとやたら遅くなるケースがあるから
データの追加削除等全部mainlistの方でやって、
こんな感じで更新する形に落ち着いたような 全然覚えてないような・・・
SortableBindingList<Model.hoge> sortableList = new SortableBindingList<Model.hoge>(Model.mainlist);
dataGridView1.DataSource = sortableList
C#も話題もよく分かってないから 見当違いだったらすまんね!
直接dataGridView触るとやたら遅くなるケースがあるから
データの追加削除等全部mainlistの方でやって、
こんな感じで更新する形に落ち着いたような 全然覚えてないような・・・
SortableBindingList<Model.hoge> sortableList = new SortableBindingList<Model.hoge>(Model.mainlist);
dataGridView1.DataSource = sortableList
C#も話題もよく分かってないから 見当違いだったらすまんね!
938デフォルトの名無しさん (ワッチョイ 9f94-ymO9)
2020/03/10(火) 21:16:42.17ID:aFJ9tE+S0 >>937
ありがとう。
直接アクセスすると良くなさそうなんでlistでバインディング出来るか試そうとしてました。
明日、トライします。
MFCで少し書いていましたがC#だとめちゃくちゃ短いソースになるんで勉強します!
ハード周りはC++のDLLでやれそうで明るい未来になりそうです。
ありがとう。
直接アクセスすると良くなさそうなんでlistでバインディング出来るか試そうとしてました。
明日、トライします。
MFCで少し書いていましたがC#だとめちゃくちゃ短いソースになるんで勉強します!
ハード周りはC++のDLLでやれそうで明るい未来になりそうです。
939デフォルトの名無しさん (ワッチョイ 4b2f-4muP)
2020/03/10(火) 21:22:21.07ID:vi5fh4S80 DataGridViwのなんかのイベントで重い処理やってんじゃないのか
940デフォルトの名無しさん (ワッチョイ 4feb-xiWk)
2020/03/10(火) 21:50:05.36ID:M4Rwf6kV0 >>938
SortableBindingListに関しては下記のページより、
https://docs.microsoft.com/ja-jp/previous-versions/dotnet/articles/ms993236(v=msdn.10)?redirectedfrom=MSDN
ぐぐって何番目かに出てくる、動物病院のページが参考になったよ 先生凄い
dataGridViewって利用者多いと思うんだけど、どれがスマートな利用方法かは調べにくいよね 頑張って!
>>939
詳しい解説や dataGridViewこう使うのが一番賢いぜ!って内容凄く聞いてみたい
SortableBindingListに関しては下記のページより、
https://docs.microsoft.com/ja-jp/previous-versions/dotnet/articles/ms993236(v=msdn.10)?redirectedfrom=MSDN
ぐぐって何番目かに出てくる、動物病院のページが参考になったよ 先生凄い
dataGridViewって利用者多いと思うんだけど、どれがスマートな利用方法かは調べにくいよね 頑張って!
>>939
詳しい解説や dataGridViewこう使うのが一番賢いぜ!って内容凄く聞いてみたい
941デフォルトの名無しさん (ワッチョイ 7957-LOeD)
2020/03/11(水) 01:54:34.80ID:zwwCe0yv0942デフォルトの名無しさん (ワッチョイ 9d2c-yhz0)
2020/03/12(木) 22:19:30.41ID:hbFLurwA0 がんばって
943デフォルトの名無しさん (アウアウクー MM05-RK3s)
2020/03/18(水) 17:22:22.56ID:rMJu+eWXM autoScrollをtrueにしたPanel内で例えばcomboboxにフォーカスすると、スクロールバーが自動で上まで移動してしまいます。
それを解決するにはScrollToControlメソッドをoverrideしたPanelを作成すれば良いというところまではわかったのですが、
SplitContainer内のPanelの場合はどのようにすれば良いのかがわかりません。あまり頭が良くないので具体的なコードで教えていただけると助かります。
それを解決するにはScrollToControlメソッドをoverrideしたPanelを作成すれば良いというところまではわかったのですが、
SplitContainer内のPanelの場合はどのようにすれば良いのかがわかりません。あまり頭が良くないので具体的なコードで教えていただけると助かります。
944デフォルトの名無しさん (ワッチョイ 597b-EBql)
2020/03/18(水) 18:35:28.79ID:Mnonc2v70 >>943
SplitContainerのSplitterPanelはsealed classになっているからそっちで何とかしようとするとめんどくさそう
SplitterPanelの上にSizeとAnchor合わせた「ScrollToControlメソッドをoverrideしたPanel」を重ねるのが楽じゃない?
SplitContainerのSplitterPanelはsealed classになっているからそっちで何とかしようとするとめんどくさそう
SplitterPanelの上にSizeとAnchor合わせた「ScrollToControlメソッドをoverrideしたPanel」を重ねるのが楽じゃない?
945デフォルトの名無しさん (アウアウウー Sa5d-TlPw)
2020/03/18(水) 18:37:11.63ID:i82q/1/Aa >>943
正攻法でやるの面倒そうだから、その魔改造したPanelをSplitterPanelに入れて
Dock = Fillにしたら?
それにしても糞UIだねそれw
見えないComboBoxにフォーカスが当たっててマウスホイールに触っちゃったりしたら
いろいろイライラが募りそうw
正攻法でやるの面倒そうだから、その魔改造したPanelをSplitterPanelに入れて
Dock = Fillにしたら?
それにしても糞UIだねそれw
見えないComboBoxにフォーカスが当たっててマウスホイールに触っちゃったりしたら
いろいろイライラが募りそうw
946デフォルトの名無しさん (アウアウクー MM05-RK3s)
2020/03/19(木) 11:38:19.13ID:iNMTXluDM >>945-945
ありがとうございます。無事に実装できました。
ありがとうございます。無事に実装できました。
947デフォルトの名無しさん (ワッチョイ 09c3-0roG)
2020/03/26(木) 14:02:01.81ID:WnIwPUvR0 これ同一人物で精神分裂病だろ
948デフォルトの名無しさん (ラクッペペ MM96-Uc92)
2020/03/26(木) 19:03:41.94ID:hr2wCIjAM 怖いことを言わないで
949デフォルトの名無しさん (ワッチョイ 8101-C6bq)
2020/03/27(金) 12:50:41.91ID:GP64i6UA0 実行モジュールをWindowsサーバーに常駐させてクライアントPCからのリクエストでサーバー上でコマンドを実行する
という仕組みに最適な.NETプロジェクトって何だと思いますか?
IIS建ててWebサービスかなと思うのですが1つのサービスのためにIIS建てるのは何か大袈裟だなと思いまして
よりモダンでイケてる仕組みがあったらお聞かせ頂きたいと
という仕組みに最適な.NETプロジェクトって何だと思いますか?
IIS建ててWebサービスかなと思うのですが1つのサービスのためにIIS建てるのは何か大袈裟だなと思いまして
よりモダンでイケてる仕組みがあったらお聞かせ頂きたいと
950デフォルトの名無しさん (ドコグロ MM1d-eCbu)
2020/03/27(金) 13:21:30.88ID:US1WE8+5M 常駐のための設定とか信頼性とか監視とか考えたら結局IISの方が手っ取り早くて楽
モダンでイケてるとか言い出したら今時WinサーバーかよとかオンプレかよとかAWSやGCPでKubernetes使えとかそういうそもそも論にしかならないのでナンセンス
モダンでイケてるとか言い出したら今時WinサーバーかよとかオンプレかよとかAWSやGCPでKubernetes使えとかそういうそもそも論にしかならないのでナンセンス
951デフォルトの名無しさん (ワッチョイ 92ad-Lzc3)
2020/03/27(金) 13:27:10.68ID:vRdj9EFz0952デフォルトの名無しさん (ワッチョイ 5ef2-Bt6E)
2020/03/27(金) 13:51:20.69ID:qYMoCqhd0 名前付きパイプとかは?
953デフォルトの名無しさん (ワッチョイ f54b-XmHu)
2020/03/27(金) 14:14:26.54ID:Y964uCoh0 Windows限定で良いなら MSMQ とかは?
954デフォルトの名無しさん (スフッ Sdb2-uolS)
2020/03/27(金) 15:13:13.57ID:paZiMxhtd >>949
embedIOで雑なHTTPサーバ作る。超楽。
embedIOで雑なHTTPサーバ作る。超楽。
955デフォルトの名無しさん (ワイーワ2 FF1a-nBi6)
2020/03/27(金) 15:21:11.20ID:9RtDMjhbF956デフォルトの名無しさん (ワイーワ2 FF1a-nBi6)
2020/03/27(金) 15:23:45.35ID:9RtDMjhbF windows 限定でセキュリティ気にしないなら psexec
957デフォルトの名無しさん (ワッチョイ 6e7c-yUDG)
2020/03/27(金) 15:31:45.21ID:ITHcMNsn0 インターネットに公開するのかイントラネット内だけの話なのかで大分変わりそうだが
958デフォルトの名無しさん (ワッチョイ 5e2c-2pFN)
2020/03/27(金) 17:16:14.97ID:cwhPeqJj0 Ruby なら、コマンドプロンプト・PowerShell から、1-liner で、
Rubyで作られた遅いウェブサーバー、WEBrick が起動する
ruby -run -e httpd . -p 8080
そのフォルダに、index.html があれば、これでブラウザからアクセスできる
http://localhost:8080
Rubyで作られた遅いウェブサーバー、WEBrick が起動する
ruby -run -e httpd . -p 8080
そのフォルダに、index.html があれば、これでブラウザからアクセスできる
http://localhost:8080
959デフォルトの名無しさん (ワッチョイ 8101-C6bq)
2020/03/27(金) 17:36:28.44ID:GP64i6UA0 知らない技術が出てきて勉強になります
C#でさささと書ければ良いので色々試させて頂きます
C#でさささと書ければ良いので色々試させて頂きます
960デフォルトの名無しさん (ワッチョイ d201-skQs)
2020/03/27(金) 17:39:24.99ID:aLfv28Wa0 要件まとめずに実装方法から入ってあとで後悔するパターンだね
個人用途ならいいんだけど
個人用途ならいいんだけど
961デフォルトの名無しさん (ワッチョイ 8101-C6bq)
2020/03/27(金) 17:40:11.90ID:GP64i6UA0962デフォルトの名無しさん (ワッチョイ 8101-C6bq)
2020/03/27(金) 17:49:36.14ID:GP64i6UA0 >>960
一部のチーム員が使うサーバ管理ツールです
すでにある実行ファイルを任意のタイミングで実行するのみのもの
DB使ったフラグのやり取りしてもと思ったのですが、実行ファイルをポーリングさせてリクエスト監視するのは効率悪いなと断念しました
一部のチーム員が使うサーバ管理ツールです
すでにある実行ファイルを任意のタイミングで実行するのみのもの
DB使ったフラグのやり取りしてもと思ったのですが、実行ファイルをポーリングさせてリクエスト監視するのは効率悪いなと断念しました
963デフォルトの名無しさん (ワッチョイ d201-skQs)
2020/03/27(金) 18:53:19.57ID:aLfv28Wa0 利用者がWindowsのサーバー管理をしてるんなら
Powershellが第一候補なんじゃないかな
認証やロギングの要件わからないけど
Invoke-Commandだけでも結構なことができるよ
Powershellが第一候補なんじゃないかな
認証やロギングの要件わからないけど
Invoke-Commandだけでも結構なことができるよ
964デフォルトの名無しさん (ワッチョイ 852c-zagE)
2020/03/27(金) 19:24:21.17ID:dVgXV7dy0 >>949
そんな時こそD-COMだよ!
そんな時こそD-COMだよ!
965デフォルトの名無しさん (ワッチョイ 6502-Cd0d)
2020/03/28(土) 10:22:41.18ID:PEtLg9Oh0 staticな拡張メソッドが作れれば割と便利な気がしないこともない
966デフォルトの名無しさん (ワッチョイ f62f-2pFN)
2020/03/29(日) 17:16:53.96ID:eP0h1Frc0967デフォルトの名無しさん (ドコグロ MM9a-eCbu)
2020/03/29(日) 20:16:57.43ID:8urZoGoxM >>966
それは回答になってないだろ
winサービスを自前で作るんならクライアントから要求を受ける仕組みもセットで示さないと
まあその場合大抵はTCP系だろうが、だったら素直に最初からIISの方が手っ取り早い
それは回答になってないだろ
winサービスを自前で作るんならクライアントから要求を受ける仕組みもセットで示さないと
まあその場合大抵はTCP系だろうが、だったら素直に最初からIISの方が手っ取り早い
968デフォルトの名無しさん (ワッチョイ f1ad-cy2b)
2020/03/29(日) 22:37:41.11ID:Qec2KlTa0 何言ってんだこの馬鹿
969デフォルトの名無しさん (ワッチョイ 926a-Cd0d)
2020/03/29(日) 22:55:05.70ID:mCKUE4Oo0 誰に言ってんだw
970デフォルトの名無しさん (ワッチョイ 8101-C6bq)
2020/03/31(火) 07:19:23.62ID:gCUhLr340971デフォルトの名無しさん (ワッチョイ 9201-aXsr)
2020/03/31(火) 09:05:17.85ID:WgVk0vye0 >>949
.NETでないとダメなの?
> 実行モジュールをWindowsサーバーに常駐させてクライアントPCからのリクエストでサーバー上でコマンドを実行する
要件がこれだけならサーバーにOpenSSH入れてクライアントからログインしてコマンド投げるコード書けばいいだけかと
.NETでないとダメなの?
> 実行モジュールをWindowsサーバーに常駐させてクライアントPCからのリクエストでサーバー上でコマンドを実行する
要件がこれだけならサーバーにOpenSSH入れてクライアントからログインしてコマンド投げるコード書けばいいだけかと
972デフォルトの名無しさん (ワッチョイ f62f-2pFN)
2020/03/31(火) 11:55:30.26ID:zne18ccq0973デフォルトの名無しさん (ドコグロ MM9a-aXsr)
2020/03/31(火) 12:32:35.41ID:MF8ritPeM974デフォルトの名無しさん (ワッチョイ 5d60-bVUD)
2020/04/01(水) 18:52:20.36ID:yix2qnAq0 C#はどうなるの?
975デフォルトの名無しさん (ワイーワ2 FF93-Wy2p)
2020/04/01(水) 18:57:27.33ID:86v82W0VF 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
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
976デフォルトの名無しさん (ブーイモ MM79-reLO)
2020/04/01(水) 22:59:28.02ID:r1g6bMKoM >>974
なくなるよ
なくなるよ
977デフォルトの名無しさん (ワッチョイ 2302-CuPJ)
2020/04/01(水) 23:58:48.00ID:ec43qMfS0 次世代言語C7に駆逐されることになってる
978デフォルトの名無しさん (ワッチョイ 6db2-vpK5)
2020/04/02(木) 00:44:38.21ID:+8nGzjLo0 エイプリルフールとかつまらん
979デフォルトの名無しさん (ワッチョイ 2361-bVUD)
2020/04/02(木) 05:56:15.64ID:JxZO1Jli0 どんな言語も永遠ではない
980デフォルトの名無しさん (ワッチョイ 6524-PBD1)
2020/04/02(木) 08:26:22.53ID:mZYQaqTk0 >>977
CR7な
CR7な
981デフォルトの名無しさん (ワッチョイ 857b-jIYQ)
2020/04/04(土) 17:48:48.50ID:+BZEhhGG0 次スレは新しく立てずにこっちで
C#, C♯, C#相談室 Part94
https://mevius.5ch.net/test/read.cgi/tech/1553075856/
即死判定無いし削除依頼は機能してないからゴミスレがどんどん増える
C#, C♯, C#相談室 Part94
https://mevius.5ch.net/test/read.cgi/tech/1553075856/
即死判定無いし削除依頼は機能してないからゴミスレがどんどん増える
982デフォルトの名無しさん (ワッチョイ fff2-IHcq)
2020/04/18(土) 16:53:08.80ID:+KNBZdEV0 スーパーマン・・・(´・ω・`)
983デフォルトの名無しさん (アウアウウー Sa1b-7wDT)
2020/04/20(月) 16:09:08.11ID:mmgnUp0pa c#からsql serverにアクセスして、SQLを文字列で作成して問い合わせるときに、「@」が付いている箇所があるんですが、何かわかりますか?
調べるとdeclareで変数を宣言するときに使うみたいなのですが、declare文もないので分からない状況です。
調べるとdeclareで変数を宣言するときに使うみたいなのですが、declare文もないので分からない状況です。
984デフォルトの名無しさん (ワッチョイ d733-YvxL)
2020/04/20(月) 16:18:49.92ID:nx4AJKqq0 >>983
パラメーター?
パラメーター?
985デフォルトの名無しさん (アウアウウー Sa1b-7wDT)
2020/04/20(月) 16:29:05.98ID:mmgnUp0pa >>984
おそらくそうです
おそらくそうです
986デフォルトの名無しさん (ワッチョイ b74b-LSCM)
2020/04/20(月) 16:35:08.97ID:q7S5vlT10 var foo = @"ABC\DEF";
とかなら、'\'等をエスケープシーケンスとして使用せず、そのままの文字として使用する場合に使います。
よくあるのがフルパスでファイルやフォルダを指定するときですね。
SQL文自体に@があるならパラメータでしょう。
とかなら、'\'等をエスケープシーケンスとして使用せず、そのままの文字として使用する場合に使います。
よくあるのがフルパスでファイルやフォルダを指定するときですね。
SQL文自体に@があるならパラメータでしょう。
987デフォルトの名無しさん (アウアウウー Sa1b-7wDT)
2020/04/20(月) 16:41:59.33ID:mmgnUp0pa988デフォルトの名無しさん (ワッチョイ b74b-LSCM)
2020/04/20(月) 16:54:38.86ID:q7S5vlT10 パラメータはインジェクション対策によく使われます。
この辺りを説明すると長くなるので、SQL インジェクションなどのキーワードで検索してみてください。
パラメータをSQL文(declare等)で定義する事はありません。
この辺りを説明すると長くなるので、SQL インジェクションなどのキーワードで検索してみてください。
パラメータをSQL文(declare等)で定義する事はありません。
989デフォルトの名無しさん (アウアウウー Sa1b-7wDT)
2020/04/20(月) 17:27:24.54ID:mmgnUp0pa >>988
調べてみます。ありがとうございます。
調べてみます。ありがとうございます。
990デフォルトの名無しさん (ドコグロ MMdf-Wm+M)
2020/04/20(月) 18:16:45.61ID:5/um/alTM991デフォルトの名無しさん (アウアウウー Sa1b-7wDT)
2020/04/20(月) 19:37:03.58ID:mmgnUp0pa992デフォルトの名無しさん (ワッチョイ bf2f-8Jcx)
2020/04/20(月) 20:31:50.14ID:3RmvNNii0 会社のコードなのにまず社内で聞かないでここで聞くとかもう
993デフォルトの名無しさん (アウアウウー Sa1b-7wDT)
2020/04/20(月) 21:49:20.00ID:mmgnUp0pa >>992
返す言葉もございません
返す言葉もございません
994デフォルトの名無しさん (ワッチョイ 37b2-BRXw)
2020/04/21(火) 02:26:03.39ID:1MDMdwK80 まあなんだ、埋めてみよか
995デフォルトの名無しさん (ワッチョイ b74b-LSCM)
2020/04/21(火) 10:29:34.91ID:Sho77XeS0 埋めついでに
全部そのまま晒すのではなくて、コードの一部とを変数名等を変えて(hogeとか、barとか)やれば問題ないよ。
それもダメとかいう会社は、そもそも5chアクセスなんて許してくれないだろw
全部そのまま晒すのではなくて、コードの一部とを変数名等を変えて(hogeとか、barとか)やれば問題ないよ。
それもダメとかいう会社は、そもそも5chアクセスなんて許してくれないだろw
996デフォルトの名無しさん (アウアウエー Sadf-xa8R)
2020/04/21(火) 12:58:40.66ID:dT9nwdnwa そんな書き換えで晒すとか
人生棒に振るからやめとけ
人生棒に振るからやめとけ
997デフォルトの名無しさん (ワッチョイ 773a-Ho7r)
2020/04/21(火) 14:00:27.73ID:dg2zqYC90 単純化しただけで人生棒にふるってどういうことよ
イミフすぎるぞ
イミフすぎるぞ
998デフォルトの名無しさん (ラクッペペ MM8f-rn04)
2020/04/21(火) 14:04:03.43ID:atc0jbknM SqlClientとかがどんなsql吐いてるか一回ぐらい確認したほうがいいよ
999デフォルトの名無しさん (アウアウウー Sa1b-7wDT)
2020/04/21(火) 14:11:12.72ID:HBEA6Nica 993です。
SqlClientも見てみるようやってみます。
後は社内のわかる人にタイミング見つけて聞いてみます。
SqlClientも見てみるようやってみます。
後は社内のわかる人にタイミング見つけて聞いてみます。
1000デフォルトの名無しさん (ワッチョイ 9f01-7Des)
2020/04/21(火) 14:19:24.31ID:9fcQjJm80 ↓ここの例にある@id, @descがSqlParameter
https://docs.microsoft.com/en-us/dotnet/api/system.data.sqlclient.sqlcommand.prepare?view=netframework-4.8
https://docs.microsoft.com/en-us/dotnet/api/system.data.sqlclient.sqlcommand.prepare?view=netframework-4.8
10011001
Over 1000Thread このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 917日 13時間 38分 2秒
新しいスレッドを立ててください。
life time: 917日 13時間 38分 2秒
10021002
Over 1000Thread 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
レス数が1000を超えています。これ以上書き込みはできません。
ニュース
- 備蓄米、小売店へ流通しているのは放出量の1.97%どまり [お断り★]
- 【コメ】日本人の主食が変わる?価格高騰収まらない米に代わり 麺類、シリアルなど売り上げ増 [ぐれ★] ★2 [ぐれ★]
- 日本経済低迷の理由は日本人の意地悪さ説、前澤友作氏が私見「よく分かる」 [少考さん★]
- 「スマホをカーナビ代わり」手持ち操作で一発免停のケースも、ホルダーに固定は安全運転義務違反も [お断り★]
- 東海道新幹線 運転見合わせ範囲拡大 上り新大阪~浜松 下り東京~新大阪 岐阜羽島~米原で停電発生 [ぐれ★]
- “強気価格”も納得か!「ダウンタウンチャンネル」に「ごっつ」「松本紳助」など“過去作アーカイブ”案 [ネギうどん★]
- 【悲報】議員「AIにクリエイターの仕事奪われたらどうすんの?」政府「ハロワに行け」 [445972832]
- 大阪万博内の8ヶ所のトイレを巡るトイレツアーを開催 [931948549]
- ▶4期生の人気徹底考察🏡
- さっき公園でカラスがカラスの上に乗っかってたんだけど
- 死にたい
- 【悲報】トランプ大統領の対中制裁関税、中国の工場をグレートアメリカではなくインドへ移転させてしまう。バカみたいな関税だな [519511584]