■ このスレッドは過去ログ倉庫に格納されています
C#, C♯, C＃相談室 Part95
- 92 ：デフォルトの名無しさん ：2019/06/09(日) 20:44:11.71 ID:zPw/481Xa.net
- >>91
ありがとうございます
・コードビハインドでの実装
・prismを使わない場合のMVVMの実装
・prismを使った場合の実装
をそれぞれ一通り確認して、仕組みの勉強は軽くだけですがしてみました
今後開発するにあたって仕組みの理解を深めつつ、どの手法で行うのがいいのか聞いてみました
formの経験はそこそこあるのですが、WPFは初めてなのでアドバイス助かります
- 93 ：デフォルトの名無しさん ：2019/06/23(日) 15:07:10.60 ID:4oGZ8zjy0.net
- DDDを体現するためビジネスロジックは全て日本語で表現しようと思うのですがC#の仕様的に発生する不都合って何か考えられますか？
- 94 ：デフォルトの名無しさん ：2019/06/23(日) 15:12:31.08 ID:q/+ohx0h0.net
- 全て日本語で表現したらキーワードが構文エラーになるのでは
例えば制御文がビジネスロジックではないとは言いますまい
- 95 ：デフォルトの名無しさん ：2019/06/23(日) 15:41:55.57 ID:4589uE1UM.net
- C#は日本語問題ないでしょ
- 96 ：デフォルトの名無しさん ：2019/06/23(日) 19:49:13.23 ID:XYuZEt+Z0.net
- 日本語にすることで理解しやすくなるんならOK
- 97 ：デフォルトの名無しさん ：2019/06/23(日) 23:01:38.80 ID:939gOEnE0.net
- 変数やデービーのカラムを日本語にすると、たしかにシステム的にわかりやすい気はするんだけど、コーディングの時に変換しなきゃいけないめんどうくささがあるのよ。コーディングするときって、せいぜいコメンティングぐらいしか変換しないので書きづらい
- 98 ：デフォルトの名無しさん ：2019/06/23(日) 23:05:28.73 ID:d7dmSNhX0.net
- ぴゅう太の日本語ベーシック思い出してしまった
- 99 ：デフォルトの名無しさん ：2019/06/24(月) 00:11:23.94 ID:BrGul7Md0.net
- 日本語使うと入力補完は効きにくくなるだろうな
- 100 ：デフォルトの名無しさん ：2019/06/24(月) 07:43:23.14 ID:INU2Nep40.net
- >>99
コード書く側として痛いですねそれ
でもドメインと共通の言葉を持つ方が要件洗い出しで有利ですからね
悩むなぁ
- 101 ：デフォルトの名無しさん ：2019/06/24(月) 07:44:36.74 ID:INU2Nep40.net
- 要件洗い出しは関係ないですね
要件とコードの対応と言うべきですか
- 102 ：デフォルトの名無しさん ：2019/06/24(月) 13:24:04.39 ID:BrGul7Md0.net
- ハンガリアン記法+日本語名というのを考えたことはある
これならVSの入力補完が多少は効くはず
実践したことはない
- 103 ：デフォルトの名無しさん ：2019/06/24(月) 15:17:24.99 ID:8JMYiMGy0.net
- class FileInfoファイル情報 {
public string FilePathファイルパス { get; }
}
こんなんでよくね（適当
- 104 ：デフォルトの名無しさん ：2019/06/24(月) 20:48:54.28 ID:zxVE+D4VM.net
- >>97
>>103 みたいに変換せずにそのまま書けばいいんじゃね？
- 105 ：デフォルトの名無しさん ：2019/06/24(月) 22:34:42.57 ID:C8NcvPkq0.net
- 変換もあれだけど、そもそもガリガリコード書くときにime使わんめえ
- 106 ：デフォルトの名無しさん ：2019/06/25(火) 00:19:38.21 ID:fdS9q1aa0.net
- 法律とか簿記の用語とかバンバン出てくるようなやつは全面漢字の方が仕様ととのチェックが楽だった
〜に係る〜、とかそんなの
- 107 ：デフォルトの名無しさん ：2019/06/25(火) 01:16:15.18 ID:mH+I2Nvc0.net
- グローバリゼーションが絶対ありえないなら有効かもなー
今までコード補完使いまくるから強引に英語化していたけど、
法律関連とか無理に英語化しても結局コード補完で悩みそうだし、
日本語のままがいいなんてケースもあるんだな
適切な英語に訳すことができたとしても
大きいプロジェクトなら大量の用語の日本語と英語間の対応を全員が把握するなんて困難だもんな
- 108 ：デフォルトの名無しさん ：2019/06/25(火) 07:33:14.34 ID:RLkxwly20.net
- やはり日本語は有効ですね
クライアントが日本人なら属性とクラスとメソッドは日本語で書きます
- 109 ：デフォルトの名無しさん ：2019/06/25(火) 07:37:02.66 ID:RLkxwly20.net
- バリバリのjava使いはクラスに日本語使うなんてファックすんぞと怒りますがC#erは意外と受け入れてくれそうで良かったです
流石に先進的です
- 110 ：デフォルトの名無しさん ：2019/06/26(水) 19:29:12.31 ID:bHDlLtN30.net
- 買収劇を繰り返して競争相手をなくして言っているような企業には、
著作権法で守る必要はない。独占禁止法や不正競争防止法に条項を
追加して、著作憲法によう保護が適用されないようにし、
ライセンスを無視してコピーして使って良いことにしなければならない。
そういう法律を作ろう。MSのやり方は我慢の限度を超えている。
- 111 ：デフォルトの名無しさん ：2019/06/26(水) 19:30:07.76 ID:bHDlLtN30.net
- 買収劇を繰り返して競争相手をなくして行っているような企業には、
著作権法で守る必要はない。独占禁止法や不正競争防止法に条項を
追加して、著作憲法による不正コピーの禁止が適用されないようにし、
ライセンスを無視してコピーして使って良いことにしなければならない。
そういう法律を作ろう。MSのやり方は我慢の限度を超えている。
- 112 ：デフォルトの名無しさん ：2019/06/26(水) 19:33:56.13 ID:y6o5vel10.net
- ハナちゃんのパパ？
- 113 ：デフォルトの名無しさん ：2019/06/29(土) 19:59:50.56 ID:YcHWvjCx0.net
- FuncかActionで表現した方が定義やIntelliSenseを見たときに分かりやすいから
デリゲートを自分で定義して使うのではなくFunc、Actionを使え、という主張を以前見たことがあるのですが、どう思いますか？
- 114 ：デフォルトの名無しさん ：2019/06/29(土) 20:18:03.17 ID:PRWAmALBa.net
- どう思いますかって言われても困ると思うよw
- 115 ：デフォルトの名無しさん ：2019/06/30(日) 20:22:22.67 ID:KUa1H9ms0.net
- インテリセンスのない環境でコードを見たときにって話なら分からんでもないけど
インテリセンス前提で自作クラスが分かりにくいとか、どういう主張なんだか理解できん
- 116 ：デフォルトの名無しさん ：2019/06/30(日) 22:36:06.16 ID:E9GgFL0oa.net
- インテリセス云々以前の問題でFunc Action の方が見易い
ってか、いい加減 return void を認めて、その二つを統一してくれ！
- 117 ：デフォルトの名無しさん ：2019/06/30(日) 22:53:18.91 ID:UMa0Fer9a.net
- Predicateみたいに可読性への寄与度から専用の方が好ましい場合もあるし、
EventHandlerみたいにジェネリックの型パラメータを制約したい場合もあるよ
何でも汎用のFuncやActionがあれば用が足りると思うのはあまりに単細胞
- 118 ：デフォルトの名無しさん：2019/07/02(火) 02:22:58.15 ID:dLGrC1W28
- >>108 ユーザから見えるのは英語だが、内部では一部日本語も使ってる。
英語だけで命名しようとすると「なんにしようか」と悩むんだよな。
悩んでつけたやつってパっと頭に出てこないから。。
- 119 ：デフォルトの名無しさん ：2019/07/09(火) 12:56:17.51 ID:8vBp03U7a.net
- List<XXXX> abc;
このXXXXを変数で指定するのはどうしたらいいのでしょう？
class XXXX {}というクラス定義をSystem.Reflection.Emitをつかって動的に生成しているのですが、
List<>のような使い方はどうしたらいいのかで詰まっています
- 120 ：デフォルトの名無しさん ：2019/07/09(火) 13:43:55.71 ID:yquUIfg/0.net
- >>119
型を変数に格納し動的にジェネリックの型指定をしたい https://social.msdn.microsoft.com/Forums/vstudio/ja-JP/cb8828d1-cd21-409c-bfb6-23db768e65aa/22411124342279325968123952668432013123752120530340123951247212?forum=csharpgeneralja
- 121 ：デフォルトの名無しさん ：2019/07/09(火) 14:21:23.40 ID:8vBp03U7a.net
- なんとかなりそう。ありがとう
- 122 ：デフォルトの名無しさん ：2019/07/10(水) 13:09:36.44 ID:0hCGlEp90.net
- >121
後学のために教えてほしい
なんでList<Object>ではだめなの？
- 123 ：デフォルトの名無しさん ：2019/07/10(水) 14:01:08.12 ID:mry5rpAoa.net
- listは例で出しただけで実際は別の扱ってる
クラスの中でtypeに応じて処理してるから、objectだと処理をしてくれない
- 124 ：デフォルトの名無しさん ：2019/07/10(水) 15:37:43.85 ID:ousD8GLzd.net
- それはインターフェース作るべきでは…？
- 125 ：デフォルトの名無しさん ：2019/07/10(水) 15:48:11.66 ID:mry5rpAoa.net
- そういうクラス作っててインターフェース用意してないのはMSだから、こっちとしてはどうしようもない
オープンソースライブラリだから作り直すって手もあるにはあるけどｗ
- 126 ：デフォルトの名無しさん ：2019/07/10(水) 18:54:55.06 ID:Pc5iw8Z80.net
- 自分の設計力不足をMSのせいにするなよ
- 127 ：デフォルトの名無しさん ：2019/07/10(水) 19:00:13.51 ID:BgjseyMO0.net
- >>125
答え出てるじゃん
自分で作りなよ
- 128 ：デフォルトの名無しさん ：2019/07/10(水) 22:41:42.75 ID:r/PFuwdP0.net
- typeに応じてやる処理を抽象化すればinterfaceのリストで事足りるってことじゃないんか
- 129 ：デフォルトの名無しさん ：2019/07/21(日) 23:27:31.90 ID:lGaupOsP0.net
- >>10
結局これは
https://mevius.5ch.net/test/read.cgi/tech/1563258983/31
こういうことだったんだな
ファイナライザは確認してないがDisposeした後に2回動かすと確かにちゃんと片づけられる
GC.Collect使わなくてもある程度まで積みあがったら片付けられたけど自分の環境で試したら１ＧＢまでそのままだったｗ
- 130 ：デフォルトの名無しさん ：2019/07/22(月) 07:36:47.16 ID:1xNSkDCq0.net
- ファイナライザが実装されているオブジェクトは
自分でDisposeを呼ばないまま参照されなくなった場合
GC二回後にメモリが回収される（ファイナライザ待ちは世代昇格されるのであくまでGC.Collectでフル実行した場合の回数）
という仕組みなのでそれで問題が解決するなら結局どっかでDispose忘れてるんじゃねという話に戻るだけだょ
まあそもそもDisposeでファイナライザ抑制してなかったり
フレームワーク側で無駄に参照掴んでたりってパターンもあるから誰が戦犯かはそれだけじゃわからんけど
- 131 ：デフォルトの名無しさん ：2019/08/12(月) 14:38:09.12 ID:kdU0FwTT0.net
- C#の国際規格についてちょっと聞きたい。そんな高級な質問じゃないんだけど……。
https://www.ecma-international.org/publications/standards/Ecma-334.htm
C# 5.0相当のISO/IEC 23270が2018年に公開されたけど、これに対応する日本産業規格って発行されるのだろうか？
そして発行されるとしていつごろになるんだろう。
この辺りの動向についてご存知のかたいます？
- 132 ：デフォルトの名無しさん ：2019/08/13(火) 08:39:07.10 ID:OBL8K+z10.net
- 知らんけど
ISOの2003版がJISの2005版、2006版が2008版になってるから
今回も2020版ぐらいになるんじゃね
- 133 ：デフォルトの名無しさん ：2019/08/15(木) 06:29:42.47 ID:KFntKln70.net
- 東京五輪の影響で規格化が遅れそう…
- 134 ：デフォルトの名無しさん ：2019/08/26(月) 22:54:59.78 ID:llFp3/Xa0.net
- スレッド数が64を超えるcpuアフィニティの設定てどうするの？
- 135 ：デフォルトの名無しさん ：2019/08/28(水) 07:10:45.65 ID:Zi6oAw3b0.net
- VScodeで脳死プログラミングができると聞いたのですが本当ですか？
- 136 ：デフォルトの名無しさん ：2019/09/04(水) 00:05:09.92 ID:bsu7VNi60.net
- 昔のWin32アプリは、WinMain関数のnCmdShow引数で表示方法を得られましたが
int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow);
WinFormアプリはどうやって得ればよいのでしょうか？
- 137 ：デフォルトの名無しさん ：2019/09/04(水) 09:33:16.14 ID:E2wRgXH30.net
- GetStartupInfoを使う
MINIMIZE/MAXIMIZEだけならFormのWndProcをオーバーライドしてbase.WndProc後のm_Msg==1の時のthis.WindowState見るというのも
- 138 ：デフォルトの名無しさん ：2019/09/05(木) 18:54:53.82 ID:HPpIgnWU0.net
- >136
ありがとうございます
諸事情によりEXEとフォーム持つDLLが分離しているため
APIで取得することにしました
- 139 ：デフォルトの名無しさん ：2019/09/25(水) 07:50:08.17 ID:yu694yUKa.net
- 今までほぼformアプリの開発しかしてきてないんですが、ASP.NETの開発やらないといけなくなりました
習得は結構大変ですか？おすすめの書籍などあれば教えていただきたいです
- 140 ：デフォルトの名無しさん ：2019/09/25(水) 20:17:31.78 ID:EcWtzQyLM.net
- わいも知りたい
- 141 ：デフォルトの名無しさん ：2019/09/25(水) 22:10:57.54 ID:9Q76ghao0.net
- FindIndex使えばループ書かなくても一行で済むじゃん綺麗じゃんと思ったんですけど、時間測ったらループ回すのより10倍くらい遅いんですよ
でも10倍って言っても0.00001と0.0001のオーダーでの差でぶっちゃけ体感時間には全く差が無し
そんな高速化が求められるようなプログラムでも無いんですが、こうなったら速度と可読性のうちこっちを優先させるみたいな基準って無いですかねぇ
- 142 ：デフォルトの名無しさん ：2019/09/25(水) 22:20:32.97 ID:VqafUfZJ0.net
- まず可読性を優先、体感でわかるレベルで問題になるところ「だけ」速度を考えろ
- 143 ：デフォルトの名無しさん ：2019/09/26(木) 02:48:32.55 ID:en+kNYvx0.net
- https://kakaku.com/prdcompare/prdcompare.aspx?pd_cmpkey=K0001020506_K0001013459_K0001020508_K0001020509&pd_ctg=0150&spec=101_1-1-2-3-4,102_2-1-2-3-4-5-6,103_3-1-2-3,104_4-1-2-3-4-5-6-7-8-9-10-11-12-13-14-15,105_5-1-2
- 144 ：デフォルトの名無しさん ：2019/10/30(水) 18:23:48.89 ID:NKPTY8aU0.net
- ・変数名は意味の読み取れない1文字2文字ばかり
・関数名は中身と一致してない上に連番
・意地でも動的配列を使わずに宣言の際に要素数100とか宣言する
・複数のオブジェクトを使いたいときはわざわざ
public class Persons
{
public n = 0; // 要素数
person[] arr = null;
]
みたいなクラスを作る
そんなC#を書く隣の上司をなんとかする方法を相談したい……（スレ違い）
- 145 ：デフォルトの名無しさん ：2019/10/30(水) 19:38:29.73 ID:2ARpxczkr.net
- サルでも解るシリーズの書籍を誕生日に贈る。
- 146 ：デフォルトの名無しさん ：2019/10/30(水) 21:14:47.10 ID:hAwpvm3E0.net
- プルリクで却下できないん？
- 147 ：デフォルトの名無しさん ：2019/10/30(水) 21:50:28.28 ID:doIb6RUv0.net
- メソッドの戻り値がどのようなものなのか、コード上で分かりやすく修飾する方法ってないのでしょうか？
雰囲気としてはこんな感じに書きたいのですが、こういう需要ってないんでしょうか・・・・
(FirstName : string, FamilyName : string) Name(){return ("aiueo", "700");}
- 148 ：デフォルトの名無しさん ：2019/10/30(水) 21:53:35.09 ID:zxDW+B/R0.net
- >>147
そういうのはタプルよりもFirstNameとFamilyNameプロパティ持ったPersonクラス作るほうがわかりやすくない？
- 149 ：デフォルトの名無しさん ：2019/10/30(水) 22:54:56.03 ID:Gqhw4MMca.net
- ドキュメンテーションコメントでも書けばいいんじゃ
- 150 ：デフォルトの名無しさん ：2019/10/30(水) 23:06:52.77 ID:Ve/HJIbT0.net
- tupleを返す
class/struct作ってその型で返す
out引数使う
お好きなのをどうぞ
個人的には場合によりけりでどのパターンも使う
- 151 ：デフォルトの名無しさん ：2019/10/30(水) 23:08:32.80 ID:Ve/HJIbT0.net
- コード見て思ったけどもしかしてtupleに名前つけられるのを知らないだけだったりする？
- 152 ：デフォルトの名無しさん ：2019/10/30(水) 23:58:19.82 ID:3bs3H/Xu0.net
- え、tupleに名前付けられるの?
Item1とか分かりにくすぎて嫌だからクラス作ってたけど名前つけられるならtupleでいいな
- 153 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 8a01-ODnH)：2019/10/31(Thu) 00:18:43 ID:JXLI+jKB0.net
- (string FirstName, string FamilyName) Name(){return ("aiueo", "700");}
って書けるよってことでしょ
using Name = System.Tuple<string, string>;
usingでaliasは設定できるけどこっちは使いみち少ない
- 154 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 6763-ORrh)：2019/10/31(Thu) 00:50:52 ID:MkAQwKar0.net
- tupleのitem1とかにはプログラマが自由に命名できるしVSの補完候補にもちゃんと出てきてくれるよ
その1箇所でしか使わないような内容ならtupleで十分
- 155 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 9e2d-46hx)：2019/10/31(Thu) 01:30:49 ID:7TTG6xuA0.net
- まじか、全然知らなかったよ
ありがとう
- 156 ：デフォルトの名無しさん ：2019/11/01(金) 06:58:19.64 ID:POn0QVxB0.net
- >>144
その上司も含めてコーディング規約を作ればええやん
- 157 ：デフォルトの名無しさん ：2019/11/01(金) 08:13:50.59 ID:bPRiWep60.net
- >>156
互換性を保つために、.NET2.0相当の記述方式とする
これマジでありました・・・
- 158 ：デフォルトの名無しさん ：2019/11/01(金) 08:44:40.64 ID:oh61GAM5a.net
- >>157
それで皆が納得してるなら従うしかないな
- 159 ：デフォルトの名無しさん ：2019/11/01(金) 09:22:46.81 ID:luUnrp0t0.net
- 「互換性を保つため」とかならまだしも「今までこれでやって来たからこのままで問題ないだろ」って言ってそう
- 160 ：デフォルトの名無しさん ：2019/11/01(金) 19:09:11.77 ID:EqckBJhH0.net
- LINQ分からん奴が言いそうね
- 161 ：デフォルトの名無しさん ：2019/11/01(金) 22:43:07.33 ID:MCB8CVSf0.net
- ワイの上司は使わなくてもいい新しい機能容赦なく使ってくるので困る…
- 162 ：デフォルトの名無しさん ：2019/11/01(金) 22:53:20.80 ID:luUnrp0t0.net
- たしかにそれはそれでうざいかも…
でも今使わない機能でも知っておくのはいいことだよ
- 163 ：デフォルトの名無しさん ：2019/11/02(土) 00:21:45.36 ID:Hd3sBx8l0.net
- えーそんな上司羨ましいけど
こんな書き方あるんですね！みたいに話せそうで楽しそうじゃん
- 164 ：デフォルトの名無しさん ：2019/11/02(土) 01:35:16.42 ID:gWk8WKKS0.net
- 使わなくていい、のレベルによるかな
使うべきではないところで無理に新機能入れるのはやだな
慣れてないがために可読性が…くらいなら入れてほしい
var初期の頃とか後者な感じ
- 165 ：デフォルトの名無しさん ：2019/11/02(土) 09:30:28.25 ID:esIitHWU0.net
- >>164
> 慣れてないがために可読性が…くらいなら入れてほしい
> var初期の頃とか後者な感じ
そのレベルなら>>161も別に困らないだろ
- 166 ：デフォルトの名無しさん ：2019/11/02(土) 09:45:46.24 ID:gWk8WKKS0.net
- >>165
だから入れてほしいいうてるやん
前者だったらやだないうてるやん
- 167 ：デフォルトの名無しさん ：2019/11/02(土) 10:17:49.05 ID:esIitHWU0.net
- >>166
日本語不自由なの？
> var初期の頃とか後者な感じ
なら>>161もいちいちレスなんてしないだろうってこと
- 168 ：デフォルトの名無しさん ：2019/11/02(土) 10:43:02.41 ID:pWYzNK5/d.net
- >>167
今でもたまに居るのに初期の頃なんてvar反対派がどれだけいたと思ってんの？
日本語得意だと159のレスだけでそんな背景まで読み取れんの？
- 169 ：デフォルトの名無しさん ：2019/11/02(土) 11:39:00.90 ID:vl/bFsjFM.net
- >>168
昔の話をいつまでも引きずる爺乙
お前みたいな奴が拗らせると>>144の上司みたいになるんだろうなw
- 170 ：デフォルトの名無しさん ：2019/11/02(土) 11:47:25.61 ID:pWYzNK5/d.net
- >>169
？？？
日本語不自由はそちらじゃないのか？キャッチボールになってないぞ
- 171 ：デフォルトの名無しさん ：2019/11/02(土) 11:56:17.08 ID:Hd3sBx8l0.net
- vs2019なんだけどvar書いたら明示的な書き方に変更しねぇ？ってメッセージ出してくるのではーんそういう方針になったんかと思ってたんだけどあれぇ？
- 172 ：デフォルトの名無しさん ：2019/11/02(土) 12:46:00.84 ID:esIitHWU0.net
- >>170
そりゃお前みたいな頭の硬い爺とキャッチボールなんて成り立たんしw
- 173 ：デフォルトの名無しさん ：2019/11/02(土) 16:58:33.03 ID:km6s5e3E0.net
- >>171
デフォルトがそっちなだけで逆にも設定できるけどね
- 174 ：デフォルトの名無しさん ：2019/11/02(土) 23:56:05.01 ID:kSdsB0kB0.net
- 大量にキューに入れておいた情報を順次取り出して
10程度の芸列でどんどん処理していくのは
どういう感じで書けばいいですか。
とりあえず直近では処理の結果は個別にファイルにサクセイ・書き込みです。
- 175 ：デフォルトの名無しさん ：2019/11/02(土) 23:58:30.80 ID:dJ3V2vrm0.net
- >>174
>10程度の芸列でどんどん処理していくのは
芸列とはなんですか？
>とりあえず直近では処理の結果は個別にファイルにサクセイ・書き込みです。
「個別にファイル作成・書き込み」の意味をもっと詳しく。
- 176 ：デフォルトの名無しさん ：2019/11/03(日) 00:17:01.38 ID:1Yjm47HG0.net
- >>174
芸列クラスと芸行キューを使う感じで書けばいいと思います。
https://docs.microsoft.com/ja-jp/dotnet/api/system.threading.tasks.parallel
https://docs.microsoft.com/ja-jp/dotnet/api/system.collections.concurrent.concurrentqueue-1
- 177 ：デフォルトの名無しさん ：2019/11/03(日) 00:38:06.74 ID:y3onw07e0.net
- すみません。
芸列ではなくて並列でした。
>>175
ファイルをダウンロードして保存していく処理です。
>>176
ありがとうございます。
やってみます。
- 178 ：デフォルトの名無しさん ：2019/11/04(月) 09:42:36.30 ID:2+WwS96M0.net
- FormのMainMenu内のMenuItemとしてPanelやUserControlを表示するにはどうすればよいでしょうか？
- 179 ：デフォルトの名無しさん ：2019/11/04(月) 10:13:49.85 ID:2+WwS96M0.net
- すみません打開しました。
private UserControl1 UserControl1 = new UserControl1();
var menuItem = new ToolStripControlHost(UserControl1);
((ToolStripDropDownMenu)toolStripDropDownButton1.DropDown).ShowCheckMargin = false;
((ToolStripDropDownMenu)toolStripDropDownButton1.DropDown).ShowImageMargin = false;
toolStripDropDownButton1.DropDown.AutoSize = false;
toolStripDropDownButton1.DropDown.Size = new Size(UserControl1.Width, UserControl1.Height);
toolStripDropDownButton1.DropDown.Items.Add(menuItem);
- 180 ：デフォルトの名無しさん ：2019/11/13(水) 09:04:11.57 ID:1AwZzcZD0.net
- メニュー項目をグレイ表示にしたりチェック記号など付けたいような場合、
MFCではOnUpdateXxxx()ハンドラでCCmdUIを使ったり、メニュー項目に
IDM_XXXXの様なID番号を付けておいて、そのID番号で操作することが
出来たのですが、C#で同様の事をしようとすると項目の表示順がそのまま
反映された0から割り振られた番号を使う必要があるようです。でもそれだと、
新しい項目を途中に追加した場合に番号がずれてしまいます。MFCと同様に
IDM_XXXX のようなID番号を付けたり、Updateハンドラで処理するような
方法はないのでしょうか？
- 181 ：デフォルトの名無しさん ：2019/11/13(水) 12:10:20.10 ID:dfp87pvz0.net
- MenuItemなりToolStripMenuItemなりのインスタンスを使えばいい
デザイナで配置してるならフィールドに置かれてる
変数名はデザイナでNameプロパティを変えれば追従する
- 182 ：デフォルトの名無しさん ：2019/11/13(水) 23:53:39.67 ID:tSkG/O4T0.net
- >>180
MenuItemなら分からんけどToolStripMenuItemならTagプロパティがある
ただその用途だと各Itemをフィールドの配列かListで別管理したほうが楽
- 183 ：デフォルトの名無しさん ：2019/11/14(木) 10:48:50.19 ID:23v5U+5B0.net
- >>181
有難うございます。
メニュー項目に対応するインスタンス変数が存在していることすら知りませんでした。
- 184 ：デフォルトの名無しさん ：2019/11/16(土) 00:42:57.25 ID:AbQTX8d40.net
- Formアプリケーションを作っているとき、
例えば、Form1.cs, Form1.Designer.cs
Form1.resx(Form1.ja.resxなどになる場合も有りますが)
が組みになって作成されます。
Form1.csは人間がコードを書くためのもの、
Form1.Designer.csはIDEのデザイナが作成するもの
のように役割が決まっているそうですが、これらを互いに
関連付けているのはファイル名や拡張子なのでしょうか。
それとも、どこかに関連付いていることが記述されている
ファイルがあるのでしょうか？？？
- 185 ：デフォルトの名無しさん ：2019/11/16(土) 00:44:19.89 ID:HfmqkgpW0.net
- csprojファイルに書いてある
- 186 ：デフォルトの名無しさん ：2019/11/16(土) 00:46:32.43 ID:AbQTX8d40.net
- >>184
お聞きしたいのは、
xxx.cs と xxx.Designer.cs のようなファイル名の「パターン」によって関連付けられて
いるのか、それとも、どこかのファイルに、書き方はわかりませんが、例えば、
Relation{ "xxx.cs", "xxx.Designer.cs" };
や
Form "xxx.cs" {
Designer : "xxx.Designer.cs"
};
のような感じで関連付けを書いてあるファイルがあるのか、ということです。
- 187 ：デフォルトの名無しさん ：2019/11/16(土) 01:19:44.10 ID:YMoVrrFx0.net
- >>186
だからcsprojファイルに書いてある
- 188 ：デフォルトの名無しさん ：2019/11/16(土) 01:20:36.88 ID:Jhdu8Hovd.net
- >>186
クラスがpartial。
VSから見たときの関連性と言う意味では多分ファイル名だけど、コンパイルする時としてはpartialで同じ名前のクラスは纏められる。
というか昔はファイルわかれてなくて、regionの中に居た気がする。
partialが使えるようになった時にファイル分かれた。
- 189 ：デフォルトの名無しさん ：2019/11/16(土) 01:24:27.50 ID:Jhdu8Hovd.net
- csprojで、DependentUponになってるけど、ファイル名変えたら変な事になった気がする。
変えても良いんだっけ？
- 190 ：デフォルトの名無しさん ：2019/11/16(土) 01:26:29.09 ID:YMoVrrFx0.net
- >>184
はたぶん自動的にサブタイプになる設定がどこかに定義されてるかを聞きたいんだろうな…
- 191 ：デフォルトの名無しさん ：2019/11/16(土) 09:28:48.15 ID:+CnVgCxY0.net
- >>187
こんな風になっています。例えば、クラス名が Form1 で、ファイル名も Form1.cs
になっていますが、もしクラス名とファイル名を異なるようにしてしまったり、
Form1Designer.cs のファイル名を変えて、WindowsFormsApp1.csproj の中の、
Compile Include を変えたりしてしまった場合、果たしてどうなるのでしょう。
【Form1.cs】
namespace WindowsFormsApp1
{
public partial class Form1 : Form
{
・・・
}
}
【Form1Designer.cs】
namespace WindowsFormsApp1
{
partial class Form1
{
・・・
}
}
- 192 ：デフォルトの名無しさん ：2019/11/16(土) 09:29:13.19 ID:+CnVgCxY0.net
- >>191
【WindowsFormsApp1.csproj】
<ItemGroup>
<Compile Include="Form1.cs">
<SubType>Form</SubType>
</Compile>
<Compile Include="Form1.Designer.cs">
<DependentUpon>Form1.cs</DependentUpon>
</Compile>
・・・
<EmbeddedResource Include="Form1.en.resx">
<DependentUpon>Form1.cs</DependentUpon>
</EmbeddedResource>
<EmbeddedResource Include="Form1.ja-JP.resx">
<DependentUpon>Form1.cs</DependentUpon>
</EmbeddedResource>
<EmbeddedResource Include="Form1.ja.resx">
<DependentUpon>Form1.cs</DependentUpon>
</EmbeddedResource>
<EmbeddedResource Include="Form1.resx">
<DependentUpon>Form1.cs</DependentUpon>
</EmbeddedResource>
・・・
</ItemGroup>
- 193 ：デフォルトの名無しさん ：2019/11/16(土) 09:45:51.65 ID:ILBbGfsX0.net
- >>184
Visual Studioの設定や機能の話は該当するＶＳのバージョンのスレでやってくれ
- 194 ：デフォルトの名無しさん ：2019/11/16(土) 11:16:34.71 ID:MdmPeVmZ0.net
- >>191
試してみれば？
- 195 ：デフォルトの名無しさん ：2019/11/16(土) 14:34:42.64 ID:H9Ba0iJt0.net
- VSが入れ子表示してるファイル名と、コンパイラがコンパイルするクラス名は別の話だからな
VSが入れ子表示する話やデザイナファイル作る話ならVSスレ行ってやってくれ
- 196 ：デフォルトの名無しさん ：2019/11/16(土) 15:38:12.07 ID:Sm3PGb9V0.net
- 緊急で質問です。
Windowsフォームのコンボボックスにて、フォーカスされた時の背景色を青ではなく薄水色にしたいのですが、やり方がわかりません。
ネットで調べてもほとんど引っかかりません。簡単なソースコードサンプル付きで教えてくださる優しい方がいらっしゃいましたら、よろしくお願い申し上げます。
- 197 ：デフォルトの名無しさん ：2019/11/16(土) 16:48:11.20 ID:gzUz93yQ0.net
- >>196
それは緊急ですね。
ネットで調べるとたくさん引っかかりますよ。
https://stackoverflow.com/a/13212571/
https://stackoverflow.com/a/11650321/
https://stackoverflow.com/a/24476009/
https://docs.microsoft.com/en-us/dotnet/api/system.windows.forms.combobox.drawitem
- 198 ：デフォルトの名無しさん ：2019/11/16(土) 17:41:51.10 ID:aUb/5lHla.net
- >>196
緊急とか書くと自分の都合しか考えない身勝手な奴だと思われるよw
いやマジで。
すでにからかわれてるけど。
やっつけならこれでいいのでは？
ちゃんとやるならCombobox継承してOnDrawItemをオーバーライドする
private void comboBox1_Enter(object sender, EventArgs e)
{
var bc = comboBox1.BackColor;
comboBox1.BackColor = Color.Azure;
EventHandler leave = null;
leave = (sencer, ev) =>
{
comboBox1.BackColor = bc;
comboBox1.Leave -= leave;
};
comboBox1.Leave += leave;
}
- 199 ：デフォルトの名無しさん ：2019/11/16(土) 18:34:21.65 ID:dnB+BkZr0.net
- >>191-192
プロジェクトファイルをバックアップしておいてから、
クラス名・ファイル名などを変えて、プロジェクトファイルがどう変わるか、
diff・VSCode などで、比べてみれば？
- 200 ：デフォルトの名無しさん ：2019/11/16(土) 19:58:19.51 ID:+CnVgCxY0.net
- >>199
ソリューションエクスプローラー上の、Form1.cs上で、右クリックして、
出てくるメニューから「名前を変更」を選んでファイル名を変更したところ、
Form1.Designer.csのファイル名も連動して変更される現象を発見しました。
- 201 ：デフォルトの名無しさん ：2019/11/16(土) 21:35:50.24 ID:+CnVgCxY0.net
- >>200
さらにこのとき、クラス名も Form1から新しいファイル名に対応したものへと
自動的に修正され、*.csproj 内の関連名も全て変更になります。
- 202 ：デフォルトの名無しさん ：2019/11/17(日) 07:31:12.67 ID:2EA7witB0.net
- これからGUIデスクトップアプリ作り始めるなら、.net framework 4.8と.net core 3.0 どっちがいいの？
.net core のほうはGUIデザイナがないのがなんか気になる。
今書いたGUIデザインソースが.net 5 でGUIデザイナが出てきた時にうまく認識されずに全部書き直しになるんじゃないか不安になる。
- 203 ：デフォルトの名無しさん ：2019/11/17(日) 07:37:16.91 ID:LRl+Pbw6M.net
- Blazorがいいよ
- 204 ：デフォルトの名無しさん ：2019/11/17(日) 07:58:55.17 ID:ADq5wcSz0.net
- Client-side Blazorすら正式版が出てないのに。
- 205 ：デフォルトの名無しさん ：2019/11/17(日) 08:27:12.76 ID:lClw7DuB0.net
- Unoがいいよ
- 206 ：デフォルトの名無しさん ：2019/11/17(日) 12:01:58.08 ID:romeOKJN0.net
- >>202
ソースは使い回せるから好きなほうでいいよ
デザイナほしいなら.Net Framework
- 207 ：デフォルトの名無しさん ：2019/11/18(月) 14:21:42.81 ID:cok7taLx0.net
- .NetCoreでMingw64のBashで表示できるプログラムって作れないのですか？
- 208 ：デフォルトの名無しさん ：2019/11/18(月) 20:06:09.61 ID:Vzii0sJA0.net
- >>207
そもそも、Windows上のbashはWinアプリなら全て実行できます。
- 209 ：デフォルトの名無しさん ：2019/11/20(水) 12:30:53.34 ID:HwawHrED0.net
- CefSharp使うと一瞬画面が消えるんですけどなんとかなりませんかね？
- 210 ：デフォルトの名無しさん ：2019/11/23(土) 09:13:16.39 ID:g35NHCcr0.net
- C#で作ったコマンドラインアプリで例外が原因でアプリが終了した場合の
終了コード（バッチだとERRORLEVEL%で見れる値）が仕様でどうなってるか教えて。
単純にMainでSystem.Exception投げるだけのプログラム組んだら-532462766だったけど、
typeof(System.Exception).GetHashCode()あたりかなと思ったけど違ったし……
- 211 ：デフォルトの名無しさん ：2019/11/23(土) 09:21:08.42 ID:Q44dea670.net
- returnで終了コード返すのはダメなの？
- 212 ：デフォルトの名無しさん ：2019/11/23(土) 09:29:14.61 ID:g35NHCcr0.net
- 実用上はtrycatchしてreturnすりゃ問題ないけど、これ何の値なのかなーと。
- 213 ：デフォルトの名無しさん ：2019/11/23(土) 11:13:28.16 ID:2xdzU1XAF.net
- 16進数に変換してググると何か分かるかもね
- 214 ：デフォルトの名無しさん ：2019/11/23(土) 11:38:50.28 ID:0TwI+VPl0.net
- /h -h 等でヘルプを出力がよくあるパターンだな
- 215 ：デフォルトの名無しさん ：2019/11/24(日) 00:34:51.49 ID:HUSWRqmS0.net
- >>210
16進数に直すと、 0xE0434352 で、16進数の最後の3つは、ASCII CODEの
"CCR"になっており、「時間の霧で意味が失われる」という意味の頭字語
になっていて、corexcep.h の中の EXCEPTION_COMPLUS で定義されている。
https://stackoverflow.com/questions/35294313/exit-code-when-unhandled-exception-terminates-execution
On Windows, a .NET process normally exits with the SEH exception code value,
the one that got the process to crash and terminate. Usually -532462766
(aka 0xE0434352) for a managed exception. Last 3 hex pairs spell "CCR",
an acronym whose meaning is lost in the fog of time, declared as
EXCEPTION_COMPLUS in corexcep.h. Sample question is here.
https://github.com/dotnet/coreclr/blob/master/src/inc/corexcep.h
#define EXCEPTION_MSVC 0xe06d7363 // 0xe0000000 | 'msc'
#define EXCEPTION_COMPLUS 0xe0434352 // 0xe0000000 | 'CCR'
#define EXCEPTION_HIJACK 0xe0434f4e // 0xe0000000 | 'COM'+1
- 216 ：デフォルトの名無しさん ：2019/11/24(日) 00:48:09.56 ID:HUSWRqmS0.net
- >>223
"CCR" は、「時間の霧で意味が失われる」という意味ではなく、
昔は何らかの英語の言葉の略語だったが、今となっては何の意味だったか
誰も思い出せなくなってしまったよく分からない略語、という意味らしい。
- 217 ：デフォルトの名無しさん ：2019/11/24(日) 19:54:50.84 ID:qE01BsLZ0.net
- >>215
おお、詳細な情報ありがとう。
こっちも仕様をあたってみたけどC#の言語仕様もCLIの方もそれらしい記述は見当たらなかった。
まぁ英語苦手だし見落としてる可能性もかなり高いけど。
- 218 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 696e-d0qP)：2019/12/03(火) 18:29:27 ID:rt0m4L9f0.net
- XML処理しなきゃいけなくなってコード組んだんだけどXDocument×LINQの組み合わせが楽すぎた
XML扱う上でC#は最強の言語なのではなかろうか。併用するライブラリの都合上C++/Pythonも考えたけど勝負にならんかったわ
他にXML使うのに便利な言語ってなんかある？
- 219 ：デフォルトの名無しさん ：2019/12/03(火) 19:11:05.07 ID:aZbE0bc+M.net
- powershell
- 220 ：デフォルトの名無しさん ：2019/12/03(火) 21:27:27.34 ID:nqX73ViMM.net
- xslt
- 221 ：デフォルトの名無しさん (JP 0H79-e23S)：2019/12/05(Thu) 14:46:16 ID:JfDO/4XBH.net
- 以前に、const での定義名は、defineで定義したものに上書きされることがあるので
全部大文字で名前を付けないでPascal形式で付けるのが正しいらしいって質問をしたものだけど
そもそもC#ってdefineで定数作れないな
それでもPascal形式で名前つけたほうが良い？
- 222 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 0588-FbR7)：2019/12/05(Thu) 15:24:41 ID:S5Q8fHSu0.net
- MS推奨はPascal
- 223 ：デフォルトの名無しさん (ﾄﾞｺｸﾞﾛ MM49-5nhq)：2019/12/05(Thu) 15:28:13 ID:dtUadt8oM.net
- >>221
Pascalにする慣習だしMSもそう推奨しているから従うだけ
命名規約はそれが存在し統一されていること自体に意味があるのであり、機能的な理由付けを求めることはナンセンス
- 224 ：デフォルトの名無しさん ：2019/12/05(木) 16:33:23.52 ID:Y6gi0TAn0.net
- 昔はXML最強だと思ってたけど
jsonやyamlの天才的な手抜きにに触れて考えが変わった
- 225 ：デフォルトの名無しさん ：2019/12/05(木) 17:22:34.08 ID:izIiWsXta.net
- >>221
constであることを意識させる必要がもしあるならFOO_BAR形式は決して悪くないと思う。
ただ、その必要性があるケースってよく考えるとあんまりないんだよね。
- 226 ：デフォルトの名無しさん ：2019/12/05(木) 18:16:38.66 ID:iMFkaL+I0.net
- ぶっちゃけMS自身もconstが全部大文字だったりPascalだったりしてる
細けェことは気にすんな
命名なんて気分だ気分
- 227 ：デフォルトの名無しさん ：2019/12/05(木) 19:17:29.95 ID:5HmbMnOR0.net
- C++→C#と来て久しぶりにC#に戻ったらC++の面倒くささに驚いた
- 228 ：デフォルトの名無しさん ：2019/12/05(木) 19:18:00.89 ID:5HmbMnOR0.net
- C++に戻ったらの間違い
- 229 ：デフォルトの名無しさん ：2019/12/05(木) 22:20:07.57 ID:P/hgT5Y1M.net
- >>224
JSONはいいかげんコメント書けるようにしろよ
- 230 ：デフォルトの名無しさん ：2019/12/05(木) 22:28:30.57 ID:lfPZrKZb0.net
- >>229
コメントというデータを仕込めばいいんじゃね？
- 231 ：デフォルトの名無しさん ：2019/12/05(木) 22:56:27.93 ID:Ne31Bdzq0.net
- ラベルダブルクリックでテキストがコピーされるのに初めて気づいた
何でこんな余計な機能つけるんだよ。せめてプロパティでオンオフできるようにしとけよ
- 232 ：デフォルトの名無しさん ：2019/12/05(木) 23:33:27.61 ID:LiE2fHBS0.net
- >>230
そういうバッドノウハウに頼りたくない
- 233 ：デフォルトの名無しさん (ﾗｸｯﾍﾟ MMa1-nv6m)：2019/12/06(金) 12:42:16 ID:OcIGrh02M.net
- JSONの"再発見"者ニキ「JSONにコメントを書けないようにしておいてよかった」
- 234 ：デフォルトの名無しさん (ﾜｯﾁｮｲ cd4b-fARI)：2019/12/06(金) 12:55:10 ID:q3Vb2TIN0.net
- >>232
じゃあ、RFC4627 に口出しできる立場になって、自分で提唱すれば？
- 235 ：デフォルトの名無しさん (ｱｳｱｳｳｰ Saa9-FVm2)：2019/12/06(金) 12:56:20 ID:PT33Vgnva.net
- 何がじゃあだよガキかw
- 236 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 2363-Uyjt)：2019/12/06(金) 13:58:14 ID:5jTZz7uG0.net
- どこがガキなのかわからん
- 237 ：デフォルトの名無しさん ：2019/12/06(金) 21:08:55.37 ID:G0zfLpZEM.net
- えっ？
いきなりRfCとか言い出す>>234なんてガキの思考そのままだろw
- 238 ：デフォルトの名無しさん ：2019/12/06(金) 22:18:00.52 ID:ttYkMtMH0.net
- なるほどガキらしい考えだ
ママに聞かせて褒めてもらいな
- 239 ：デフォルトの名無しさん (ﾜｯﾁｮｲ cd4b-fARI)：2019/12/07(土) 14:40:03 ID:9Gp2j7L60.net
- 規格が気に入らないなら、それを変更するように影響を与えないといつまでも変わらない。
規格が気に入らない。可能な代替案も気に入らない。って喚いてるだけじゃん。
どっちがガキだよlol
- 240 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 2361-GJme)：2019/12/07(土) 15:36:41 ID:4jkkIRaG0.net
- >>239
敵対する言語の信奉者や作者が批判してしている可能性もあるんだから、
委員会に提案しない事が後ろ向きとは限らない。
- 241 ：デフォルトの名無しさん ：2019/12/07(土) 17:37:24.28 ID:Ga9vuWSha.net
- >>239
そういうのを書生論って言うんじゃないかな？w
その実現可能性ってどの程度？
まあ、ガキだよねやっぱり。悪いけどさ。
そもそも>>229の人はそんな話（どうやったら変えられるか？）なんかしてないんじゃないのかな。
病気の人をからかう意図はないけど、アスペルガーとかじゃなかそんなの普通に分かるよね
- 242 ：デフォルトの名無しさん ：2019/12/07(土) 17:47:06.56 ID:uIc1VvAO0.net
- ふらっとだけじゃなくここでも人格批判かよ
板違いだから余所でやってくれ
- 243 ：デフォルトの名無しさん ：2019/12/07(土) 17:50:57.13 ID:MHWzy9730.net
- >>239
ほんそれ
叩いてる奴らはバカ類だからほっとけ
- 244 ：デフォルトの名無しさん ：2019/12/07(土) 18:02:30.43 ID:f2i8nuZX0.net
- >>241
> アスペルガーとかじゃなかそんなの普通に分かるよね
せめて日本語がまともに使えるようになってから出直してこいよ
- 245 ：デフォルトの名無しさん ：2019/12/07(土) 18:02:39.31 ID:4jkkIRaG0.net
- >>243
いや、C++を直して欲しくて書いているとは限らない。
良いアイデアを敵に与える必要はないので、提案などするひつ世はない。
- 246 ：デフォルトの名無しさん ：2019/12/07(土) 18:07:14.42 ID:4jkkIRaG0.net
- >>245
あれ、JSONの話だった。
- 247 ：デフォルトの名無しさん ：2019/12/07(土) 18:12:42.05 ID:L+Kcsfik0.net
- >>240
よくわからないんだけどC#と敵対してる言語ってなに？
- 248 ：デフォルトの名無しさん ：2019/12/07(土) 18:21:09.76 ID:erYV0nIUM.net
- 大多数のC#erが敵と感じることが多いのはVBじゃないかな
MS的には敵はGoやJavaと言いたいだろうけど、まだまだC#は(Unityを除けば)Windowsでしか使われておらず、プラットフォームの制約で仕方なく選ばれる言語の域を出ない
その上でVBを選ぶかC#を選ぶかは完全に好みの問題なわけで、
そこで好みを優先できる組織ならそもそもサーバーにWindowsなんか採用しないよね
- 249 ：デフォルトの名無しさん ：2019/12/07(土) 18:28:17.16 ID:4jkkIRaG0.net
- >>247
自分の好きな言語を広めたいと思っている人も居るわけですよ。
- 250 ：デフォルトの名無しさん ：2019/12/07(土) 18:37:40.00 ID:L+Kcsfik0.net
- >>249
答えになってないんだけど
君が「C#と敵対している」と考えてる言語って何？
- 251 ：デフォルトの名無しさん ：2019/12/07(土) 18:50:47.69 ID:4jkkIRaG0.net
- >>250
黙秘権を使います。
- 252 ：デフォルトの名無しさん ：2019/12/07(土) 20:35:07.03 ID:VnqK0uSL0.net
- >>248
もともとunsafeなんかはC#だけだったけど
最近のバージョンは他の部分でも差が付いてるので
好みの問題だけじゃなくなってきてる
- 253 ：デフォルトの名無しさん ：2019/12/07(土) 20:48:48.93 ID:KZIoY4Tw0.net
- さすがに今どきVB.NETは有り得ないんじゃね？
- 254 ：デフォルトの名無しさん ：2019/12/07(土) 20:53:05.32 ID:7QN5mOIt0.net
- ここ数年VBなんて見てないわ
他の選択肢が多すぎて選ぶ人なんて居ないだろう
- 255 ：デフォルトの名無しさん ：2019/12/07(土) 22:43:02.88 ID:quRr2R9X0.net
- 1. 設定値を入力する画面がある
2. 設定値を入力して登録ボタンを押すと、設定値保管用クラスの変数に値を渡す
3. 他クラスは画面の値でなく、設定用保管クラスの変数の値を参照する
みたいなクソ仕様のアプリを書いてしまいました。
なんで直接、設定値入力画面の入力値を参照しないのか・・・。
仕様を直したいんだけど、もうクソ長いコード書いてしまっていまさら直すのも数日かかりになりそう。。。
- 256 ：デフォルトの名無しさん ：2019/12/07(土) 22:44:22.12 ID:quRr2R9X0.net
- >>255
これやっぱり直すべきでしょうか・・・・。
工学系の院生の研究用アプリです。
- 257 ：デフォルトの名無しさん ：2019/12/07(土) 22:46:49.22 ID:1bDOsUysa.net
- 普通じゃね？シリアライズするなら当然そうしねーか？
- 258 ：デフォルトの名無しさん ：2019/12/07(土) 23:08:25.55 ID:zukzhMoh0.net
- C#関係ないようなｗ
設定値の復帰させるとかでも一括で管理する部分あった方が取り回し楽になるし何がクソなのかもわからない
>>256
むしろ該当部分組みなおすのに数日かかってしまう形になっているのが問題では
- 259 ：デフォルトの名無しさん ：2019/12/07(土) 23:09:21.20 ID:Ga9vuWSha.net
- >>255
言ってること誤解してるかもしれないけど、
UIの入力をダイレクトに設定に反映しないのはMSのお作法的には
むしろ正しいんじゃないの？
適用かOKをクリックするまで入力が設定に反映されず、キャンセルボタンを
クリックすると何もなかったことになる仕様なんだよねたぶん？
まあ、仕様が適切かどうかは要件次第だと思うんで、あんまり教条主義的に考えない方が...
要は使いやすければそれでいいんで
- 260 ：デフォルトの名無しさん ：2019/12/08(日) 00:00:10.40 ID:Oblj5J3Y0.net
- 大まかな設計は悪くないと思うけど、
2. 設定値を入力して登録ボタンを押すと、設定値保管用クラスの 「変数に値を渡す」
3. 他クラスは画面の値でなく、設定用保管クラスの「変数の値を参照する」 (画面の値でも同様によくない)
って仕組みは直した方がいいんじゃないかな
一箇所仕様を変えたら全部が狂うとか、変なことが起きてくるんじゃないの
- 261 ：デフォルトの名無しさん ：2019/12/08(日) 00:29:06.09 ID:pSs03yKS0.net
- >>260
まさにそこなんですよね。。。
他クラスで使用しているときに値を変更されないように2、3を実装したんですけど、単に画面を入力できないようにロックすればよかった。
2の変数の名前とか少し替えるとどこで参照先を全て直さなければいけない。
この仕様直したいんですけど、時間がかかるのと単純作業を繰り返すので、
考えただけで目眩がします。
- 262 ：デフォルトの名無しさん ：2019/12/08(日) 00:38:02.22 ID:3vBWNciC0.net
- え？何が悪いのかさっぱりわからん
〜すればってのも俺には的外れに見える
- 263 ：デフォルトの名無しさん ：2019/12/08(日) 00:50:00.57 ID:tOnI98EO0.net
- >>261
変数の名前ならVisual Studioの機能で簡単に一括変更できるぞ
https://docs.microsoft.com/ja-jp/visualstudio/ide/reference/rename?view=vs-2019
- 264 ：デフォルトの名無しさん ：2019/12/08(日) 01:02:05.03 ID:7KQ7NXxs0.net
- 変数名の変更はVSの機能で一発で済む
vsじゃなくても最近のIDEなら標準的な機能じゃないかな？
書いてある設計自体は普通でクソだとは思わん
設定値が1万個くらいあってそれを1個のclassに全部ぶち込んでるとかだと整理したほうがいいんじゃね？って思うけどそういうわけでもないんでしょ？
画面ロックすればよかったって言ってるってことはあとから値変えられて困ってるってこと？
登録ボタンなんて作らずに画面上の設定値が変更されたら即座に設定値管理用classに反映させればいいのでは？
- 265 ：デフォルトの名無しさん ：2019/12/08(日) 01:04:08.10 ID:PIvqmbCd0.net
- >>264
それやると設定値にチェックが必要なとこで詰むぞ
やめるべき
- 266 ：デフォルトの名無しさん ：2019/12/08(日) 01:06:23.59 ID:KIb7eBZ10.net
- >262
同じく、何がくそ実装なの分からない
普通はGUIの変数を直参照しちゃってるから>>255の2,3みたいに直したいって悩みそうなもんだけど
- 267 ：デフォルトの名無しさん ：2019/12/08(日) 01:06:29.61 ID:PIvqmbCd0.net
- 開始日、終了日の入力で
開始日から終了日の期間に制限がある場合とかバインドに弱い
開始値、終了値も同様
- 268 ：デフォルトの名無しさん ：2019/12/08(日) 01:13:11.42 ID:7KQ7NXxs0.net
- >>265
いや、何も詰まないけど？
反映するときにチェックして異常値であることがわかればいいじゃん
登録ボタンで登録時にチェックしてエラーとするのと何らかわらん
設定値保持classは常に正常な値のみを保持する
って要件ならそら無理よ
- 269 ：デフォルトの名無しさん ：2019/12/08(日) 04:54:32.09 ID:Oblj5J3Y0.net
- >>261
前の書き込みじゃわからなかったけど、主要な心配は、コードの保守性の問題じゃなくて処理中の入力に対する問題なの？
もし後者なら本当に作り直しレベルかも・・・・・
- 270 ：デフォルトの名無しさん ：2019/12/08(日) 06:45:15.65 ID:h14g0YSH0.net
- WPFとかだとそういう風に組むのが推奨されてるし
- 271 ：デフォルトの名無しさん ：2019/12/08(日) 08:21:03.71 ID:rNTMaYhL0.net
- >って要件ならそら無理よ
このことを「詰む」って言ってたんではないかと
- 272 ：デフォルトの名無しさん (ﾜｯﾁｮｲ a501-gDf/)：2019/12/08(日) 08:33:51 ID:YBiAuaAw0.net
- DocumetViewとかMVVMパターンでは普通の実装だね。
- 273 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 9bde-aps1)：2019/12/08(日) 10:03:29 ID:K3lJ24NK0.net
- >>268
だからいつ？
ちゃんと考えて
開始と終了の期間に制限があるんだよ
組んだことないの？
- 274 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 152f-V35x)：2019/12/08(日) 10:24:22 ID:pSs03yKS0.net
- >>266
>>269
1 画面に数値を保持して、開始ボタンを押すと画面入力はロックする
3 クラスは1の画面上の値を直接読みに行く
とすると2はいらなかったのかなと。
2があると、設定を増やしたり変数名を変更するたびに1→2→3全部直さなければいけず、
保守が面倒くさいので、後でソースを見た人にブチ切れられないかと・・・。
あと、画面上なら間違って他クラスから値を書き換えることはしないと思うのですが、
変数だと他クラスから不用意に値を書き換えてしまわないか不安で。。。
- 275 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 152f-V35x)：2019/12/08(日) 10:25:27 ID:pSs03yKS0.net
- 自分で途中からクソ仕様と思い始めてしまったんですが、これが標準なんですかね。
だとしたら安心して引き継げるのですが。
正直面倒くさくて直したくないorz
- 276 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 9bde-aps1)：2019/12/08(日) 10:29:01 ID:1rCojsjZ0.net
- >>274
画面に範囲guyのヤツブチ込んでも誰も死なんの？
コントロールだから絶対に想定guyのヤツは来ないはないよ
- 277 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 7501-V35x)：2019/12/08(日) 10:34:32 ID:JIo60cn60.net
- >>274
>変数名を変更するたびに
vsなら参照してるところもすべて書き換える機能あるよ
- 278 ：デフォルトの名無しさん ：2019/12/08(日) 10:48:39.51 ID:sqNFXMf8a.net
- >>275
引き継ぐならそのままにしてあげたほうが良い
わざわざ手間をかけて設計を壊して後任の恨みを買う必要はない
- 279 ：デフォルトの名無しさん ：2019/12/08(日) 10:56:36.45 ID:z9x/0bTQa.net
- >>274
ちょっとした吐き捨ての設定ならそれで問題ないかもしれないけど、入力の項目が多くなってアプリを開いてあの設定を保存して呼び出したいってなった時とかどうすんの？とか結局仕様と設計の問題じゃないか？
- 280 ：デフォルトの名無しさん ：2019/12/08(日) 10:57:28.44 ID:8fOog+TqM.net
- >>275
てか、WinFormなの？ それともWPF？
自分のこだわりがないならとりあえずフレームワークの流儀に倣ってりゃいいんじゃね
- 281 ：デフォルトの名無しさん ：2019/12/08(日) 11:04:44.31 ID:C3XpVZQF0.net
- 画面遷移されたら消えるの？
たまたま今回画面遷移せんの？
問題が起こりまくるから止めろと言っておく
コントロールの不正な入力を完璧にガードするのはよく知ってる奴でも結構難しいときあるし
- 282 ：デフォルトの名無しさん ：2019/12/08(日) 12:32:23.17 ID:7KQ7NXxs0.net
- >>273
ユーザーが設定値を変更したとき
そうやって突っ込むってことは
>設定値保持classは常に正常な値のみを保持する
って要件はないんだよね？
開始終了とか関係なくユーザーが設定した値保持するだけじゃん
mvvmとか見たこと無いの？
- 283 ：デフォルトの名無しさん ：2019/12/08(日) 12:50:54.37 ID:MsET5CX00.net
- >>282
開始に1980/01/01
終了に1980/02/01
が設定されてたとき
期間に3ヶ月って制限がかかってたときに
開始と終了に2019/09/01-2019/10/01を設定したいとするわな？
よし、じゃ、開始に2019の・・・エラー!（終了に1980/02/01が入ってるので）
じゃ、終了に2019の・・・エラー!（開始に1980/01/01が入ってるので）
詰んだじゃん
- 284 ：デフォルトの名無しさん ：2019/12/08(日) 12:55:17.97 ID:pSs03yKS0.net
- >>277
それやったんですけど、なんか変更されないところも出てきて・・・。
ここ以外で変なことやってるのかもしれません。
- 285 ：デフォルトの名無しさん ：2019/12/08(日) 12:56:57.51 ID:pSs03yKS0.net
- >>281
開始ボタンをおしても、設定入力画面は開いたままで画面遷移させてないんですよね。
- 286 ：デフォルトの名無しさん ：2019/12/08(日) 12:59:14.97 ID:pSs03yKS0.net
- みなさんのお話を聞いていると、
登録ボタンを押して、変数記録クラスに画面の値を記録させるというのはクソ仕様ではなかったんですね。
ホッとしました。
- 287 ：デフォルトの名無しさん ：2019/12/08(日) 13:00:29.22 ID:7KQ7NXxs0.net
- >>283
エラーになる設定に値を設定への操作を許可してりゃ詰んでないじゃんｗ
そもそもそういう操作を禁止するなんて話どこにあった？
ユーザーの操作は何も制限なんてする必要は無い
設定保持classが現在入力されている設定値が正常か否かだけを分かってればいい
- 288 ：デフォルトの名無しさん ：2019/12/08(日) 13:00:57.18 ID:pSs03yKS0.net
- 画面に入力された文字は変数記録クラスに記録させて、
変数記録クラスを参照していると、
「あれ、この変数って画面ではどこのことだっけ？」
とかなるのは自分の頭がクソ仕様ということか・・・。
- 289 ：デフォルトの名無しさん ：2019/12/08(日) 13:04:18.68 ID:7KQ7NXxs0.net
- この理論、パスワードは8文字以上でって制限だと
1文字目を打ったタイミングでエラー出して入力ボックス消すってことか？
そんでコピペ以外で8文字以上打つことができずに詰んだってか？
そんなびっくり仕様どこにあるの？
- 290 ：デフォルトの名無しさん ：2019/12/08(日) 13:04:22.11 ID:oZbmRsqQ0.net
- >>288
そこは間違いないな
- 291 ：デフォルトの名無しさん ：2019/12/08(日) 13:06:20.25 ID:BE6HVZz80.net
- だからワンクッション置かないと駄目だよねって話
- 292 ：デフォルトの名無しさん ：2019/12/08(日) 13:08:13.78 ID:KIb7eBZ10.net
- >>288
変数記録クラスで変数を入れておくのをプロパティにしておけば、VSの機能で参照先をすぐに探せる
- 293 ：デフォルトの名無しさん ：2019/12/08(日) 13:17:20.81 ID:WI1y2v9y0.net
- >>289
開始終了は入力中だけじゃなく
killfocusやvalidatedでもだめでしょ？
- 294 ：デフォルトの名無しさん ：2019/12/08(日) 13:26:39.13 ID:7KQ7NXxs0.net
- >>293
だからダメだったら何なの？
不正な値が入力されたらそうであることが参照するclassがわかればいいだけ
登録ボタン形式であっても登録時にチェックして正常異常を判定するのだから異常入力をユーザーに通知できるタイミングの違いでしか無い
何も詰まないのに詰むでしょ？考えて？組んだこと無いの？
って勝手に操作入力制限の要件足して突っかかってくるのやめてね
- 295 ：デフォルトの名無しさん ：2019/12/08(日) 13:42:37.78 ID:z1c2Df2S0.net
- >>294
元は
>>264
の
>登録ボタンなんて作らずに画面上の
>設定値が変更されたら即座に
>設定値管理用classに反映させればいいのでは？
って発言に対するレスな
- 296 ：デフォルトの名無しさん ：2019/12/08(日) 13:49:38.20 ID:B7mwO2xN0.net
- >>295
反映させ方にもいろいろあるから開始/終了の制限があっても別に詰まないよ
質問と関係ないからもうやめれ
- 297 ：デフォルトの名無しさん ：2019/12/08(日) 13:50:09.94 ID:7KQ7NXxs0.net
- >>295
そんなん分かってるよ
設定値管理用classが異常値を保持するだけで何も詰んでない
- 298 ：デフォルトの名無しさん ：2019/12/08(日) 13:53:27.09 ID:rNTMaYhL0.net
- >設定値が変更されたら即座に
>設定値管理用classに反映させればいいのでは？
これ、バリデーションとか無い場合の方がやっかいだよね。
ユーザーは10を入力したかったのに1で処理されちゃうとか。
- 299 ：デフォルトの名無しさん ：2019/12/08(日) 13:58:30.12 ID:7KQ7NXxs0.net
- 個人的に割とよくある設計だと思ってる
入力したタイミングからエラーチェックして早めにユーザーに通知できるメリットがでかい
webなんかではよく見る形式
で、そんなよくある設計を詰むよ、なんて言って初学者（かどうかわからんが）に対して無意味に敬遠させるべきでは無いと思う
- 300 ：デフォルトの名無しさん ：2019/12/08(日) 14:06:24.08 ID:90QfBCQ40.net
- >>296
え？コントロールの値を直接参照してるのにどうやるの？
無理ゲーじゃね？
- 301 ：デフォルトの名無しさん ：2019/12/08(日) 14:08:43.35 ID:90QfBCQ40.net
- >>299
ガチでどうやるの？
範囲指定があった時点でOKボタン的もんが必要でしょ？
- 302 ：デフォルトの名無しさん ：2019/12/08(日) 14:18:51.74 ID:WpCL9e8A0.net
- MVVMを持ち出してる割にVMとMがごっちゃになってるように見える
- 303 ：デフォルトの名無しさん ：2019/12/08(日) 14:19:22.37 ID:7KQ7NXxs0.net
- >>301
何を無理だと感じているのかさっぱりわからん
from/toが範囲外になったってユーザーがそう入力してるならその値を保持するだけ
で処理に進む段階で異常値があるなら進ませない
登録ボタン形式なら異常値があるなら受け付けない
処理に進むのを実行ボタンとすれば
前者なら異常値があれば実行ボタンを無効化しておき、設定値が全て正常になったタイミングで有効化する
みたいな要件が実現しやすい
- 304 ：デフォルトの名無しさん ：2019/12/08(日) 14:25:09.69 ID:90QfBCQ40.net
- >>303
即時反映の話はどこいったん？
- 305 ：デフォルトの名無しさん ：2019/12/08(日) 14:26:41.39 ID:90QfBCQ40.net
- さらに設定値を参照してる奴全員に異常値の対応をさせるってありえなくね？
- 306 ：デフォルトの名無しさん ：2019/12/08(日) 14:27:36.72 ID:7KQ7NXxs0.net
- >>304
その値を保持する
ってのが反映だ
根本から話がずれてる
- 307 ：デフォルトの名無しさん ：2019/12/08(日) 14:28:42.21 ID:7KQ7NXxs0.net
- >>305
そんな仕様どこに書いてあった？
- 308 ：デフォルトの名無しさん ：2019/12/08(日) 14:32:02.79 ID:90QfBCQ40.net
- なんかすでに議論に勝つためだけに頑張っちゃってる感じ？
- 309 ：デフォルトの名無しさん ：2019/12/08(日) 14:34:19.70 ID:rNTMaYhL0.net
- 登録ボタンと実行ボタンがある前提で登録ボタンの方は無くせる、と言っているのかな？
- 310 ：デフォルトの名無しさん ：2019/12/08(日) 14:41:07.50 ID:eGeBS+CxM.net
- >>301
入力中はアンダーラインを引いたりメッセージを出して通知はするが間違ってても即保存する
入力された不正な設定値を読み取る時に無視するあるいは警告を出して無視するはたまたエラーを出して失敗させる
後々設定をアプリ外から弄ることも視野に入れると読み取り時にデータの正確性を保証したほうがいい
- 311 ：デフォルトの名無しさん ：2019/12/08(日) 14:50:30.86 ID:7KQ7NXxs0.net
- UI→登録ボタンによるチェック処理→設定値保持class
UI→チェック機能を有した設定値保持class
こんだけ
前者はチェック処理で弾けば設定値保持classには異常値が入っていないことが担保できる
後者は設定値保持class自身が正常と判断してるかどうかで異常値があるかどうかを判断する
別に前者の設計が一概にダメとは思わないしこういうこともよくするが後者が詰むという理論は理解できん
- 312 ：デフォルトの名無しさん ：2019/12/08(日) 14:51:48.07 ID:B7mwO2xN0.net
- >>274
一般的には読みやすくメンテしやすくするため
画面からの入力を処理する役割と設定値を管理する役割は別のクラスに持たせる
ただ簡単なプログラムなら画面クラスに設定値管理の役割を持たせるのでも別に構わない
他クラスから不用意に値を書き換えられないようにするのはそいうふうに設定管理クラスを作ればいいだけ
レス見る限り他のクラスの変数を
プロパティやメソッド経由せずに直接設定したり直接参照してる風に読めるんだが
もしそうなら役割ごとにクラスを分離したのに密結合してるのが一番の問題
でもブチ切れるレベルの人ならササッと書き換えるから心配する必要ないと思う
- 313 ：デフォルトの名無しさん ：2019/12/08(日) 15:03:31.77 ID:Oblj5J3Y0.net
- >>274
いやいや、2みたいなものは要るし、3は一番ダメだよ
問題なのはフィールドを他クラスのオブジェクトから読み書きする点で、ここをプロパティーやフレームワークの内部コマンドに置き換えたりしないと徐々にコードが酷くなっていくよ
- 314 ：デフォルトの名無しさん ：2019/12/08(日) 17:55:31.29 ID:zhe6A2K90.net
- この一連の流れは相談か？
- 315 ：デフォルトの名無しさん ：2019/12/08(日) 18:19:08.18 ID:54HI4DkC0.net
- そうだんですよ川崎さん
- 316 ：デフォルトの名無しさん ：2019/12/08(日) 18:25:13.90 ID:q5OZjWUaa.net
- 正直最初の質問が結局何を質問してるんだか俺にはいまいちよく分からないんだけど、
こんな雲をつかむような話でよくレスが50も進むよねw
まず質問者が何を聞きたいと思ってるのかを明確にするのが先だと思うんだけど
- 317 ：デフォルトの名無しさん ：2019/12/08(日) 19:25:44.35 ID:h14g0YSH0.net
- >>255の質問内容はわかるだろ
既に>>270, >>272で答え出てるし本人ぽい人も>>286で一応納得してる
レスが伸びてるのは場外乱闘してる基地害が２匹いるっていういつのも流れだからスルーでいい
- 318 ：デフォルトの名無しさん ：2019/12/08(日) 19:40:58.07 ID:q5OZjWUaa.net
- >>317
漠然とは、ね。
逆にいうと漠然としか分からない
〜だろ？w
頭悪そう
- 319 ：デフォルトの名無しさん ：2019/12/08(日) 20:06:20.23 ID:h14g0YSH0.net
- いや、わからないならスルーしとけよ
別にお前がわかる必要はないんだしw
- 320 ：デフォルトの名無しさん ：2019/12/08(日) 20:19:46.26 ID:vQtEDwKW0.net
- また昨日の続きかよ
- 321 ：デフォルトの名無しさん ：2019/12/08(日) 20:37:00.33 ID:h14g0YSH0.net
- 自分がわからないのは質問者のせいだ
って思い込んでる人は一定数いるからw
- 322 ：デフォルトの名無しさん ：2019/12/11(水) 18:58:15.46 ID:neU6iLAlM.net
- 該当クラスがどこのネイムスペースから
なのかすぐわかる方法ってない？
- 323 ：デフォルトの名無しさん ：2019/12/11(水) 19:12:17.36 ID:A2ve7TTYa.net
- >>322
型名ならマウスオーバーでポップアップ表示されない？
変数ならF12で以下同文
- 324 ：デフォルトの名無しさん ：2019/12/11(水) 19:16:20.62 ID:neU6iLAlM.net
- >>323
メモ帳しか使えない
すぐわからない？
ideが前提なの？
javaだと省略しないのに
- 325 ：デフォルトの名無しさん ：2019/12/11(水) 19:22:09.23 ID:3diBwqZu0.net
- 名前空間を省略せずに書けばいいだろ
- 326 ：デフォルトの名無しさん ：2019/12/11(水) 19:27:51.94 ID:2za+15ZK0.net
- javaだってするだろ
- 327 ：デフォルトの名無しさん ：2019/12/11(水) 19:31:24.40 ID:tBBOlHQ00.net
- >>324
C#に限らず最近の言語はほぼIDEや高機能エディタ前提だと思うが
- 328 ：デフォルトの名無しさん ：2019/12/11(水) 20:19:46.44 ID:A2ve7TTYa.net
- >>324
ライブラリの型ならC#と一緒にググればすぐ出てくるでしょ
- 329 ：デフォルトの名無しさん ：2019/12/11(水) 20:25:15.92 ID:EPJ4Sm/w0.net
- vscodeすら入れられないの？
メモ帳縛りとかコンパイルもめんどいやん
てかコンパイラ単体で持ってきたの？
- 330 ：デフォルトの名無しさん ：2019/12/11(水) 23:25:24.84 ID:fjLZq11N0.net
- 昔はviとかで普通にコーディングしてたが
今更メモ帳でコーディングする気にはなれんな
今のIDEとかもう便利すぎる
- 331 ：デフォルトの名無しさん ：2019/12/12(木) 00:08:12.86 ID:n05Ewb3K0.net
- dotnet buildでいいからコンパイルは楽でしょ
- 332 ：デフォルトの名無しさん ：2019/12/12(木) 00:22:15.51 ID:AJjh9lU00.net
- 今時viだってコーディング支援あるしね
- 333 ：デフォルトの名無しさん ：2019/12/21(土) 08:44:14.52 ID:mOkYxWI2r.net
- インデントもわざわざ打たなきゃならんでしょメモ帳・・・
- 334 ：デフォルトの名無しさん ：2019/12/21(土) 09:28:59.77 ID:RVospelqd.net
- >>329
WindowsならC#コンパイラcsc.exeが標準で入ってる。
>>324
でもなあ、IDE無しでは効率悪いでしょ。
規模にもよると思うけどVisualStudio入れられないならC#諦める選択肢もある。
といって代わりに何を使うかで良いのがあるとも思えないけど。
- 335 ：デフォルトの名無しさん ：2019/12/21(土) 09:53:05.63 ID:elCUYmNmM.net
- クラウドIDE良いよ
インストール不自由でも使える
- 336 ：デフォルトの名無しさん ：2019/12/21(土) 11:11:56.97 ID:tKqa0Mcd0.net
- vim
https://youtu.be/X0vVVHGFotc?t=306
makeファイルとかの下りは今は不要
- 337 ：デフォルトの名無しさん ：2019/12/21(土) 12:14:55.25 ID:wj7YAMPY0.net
- メモ帳しか使えない環境だからいくら紹介しても無駄だぞ
- 338 ：デフォルトの名無しさん ：2019/12/22(日) 01:12:40.65 ID:BLYFt7Uup.net
- 最初にメモ帳でC#に特化したエディタ作る
以降はそれで開発
- 339 ：デフォルトの名無しさん ：2019/12/22(日) 02:09:51.62 ID:thbQEK090.net
- C言語はC言語で書かれてると聞いたことがあるような…
最初にどう始めたかは知らない
アセンブラか他言語で始めてCに移行だとは思うが
- 340 ：デフォルトの名無しさん (ﾜｯﾁｮｲ b754-+Tiu)：2019/12/22(日) 05:49:50 ID:By9IH60L0.net
- セルフホスティングやな
- 341 ：デフォルトの名無しさん ：2019/12/22(日) 12:27:43.38 ID:BM7u1zydM.net
- そんなことも知らないのかよ
cの場合は最初にクロスコンパイラを作るから、新しいプラットフォームでもアセンブラは不要。
て、さっきwikiで読んだ
- 342 ：デフォルトの名無しさん ：2019/12/22(日) 13:11:54.70 ID:0l5I7UXk0.net
- 原初の環境では機械語直入力だ
- 343 ：デフォルトの名無しさん ：2019/12/22(日) 14:27:23.59 ID:4GpMlcpo0.net
- >>341
そのクロスコンパイラとやらはなんの言語で書かれてるんだ？
- 344 ：デフォルトの名無しさん ：2019/12/22(日) 15:28:16.06 ID:la1jzM750.net
- もちろんCだよ。
gccに関して言えば、まず、Cで書かれた自分自身のサブセットを別のCコンパイラでコンパイルしてから、自分自身のサブセットで自分自身をコンパイルする。
だから今後Cコンパイラがアセンブラで書かれる必要はまったくない。書きたければ書くのは自由だが。
なお、最初のCコンパイラはBで書かれたものとDECマシン向けのアセンブラで書かれたものがあり、Bコンパイラはすべてアセンブラで書かれていた。
僕くらい博識になるとこんなの常識だね。明日には忘れるけど
- 345 ：デフォルトの名無しさん ：2019/12/22(日) 15:36:37.89 ID:ngCRczT7M.net
- まるでC博士だな
大したやつだ
- 346 ：デフォルトの名無しさん ：2019/12/22(日) 15:38:35.28 ID:sqLa+RyJa.net
- いきなりネイティブのコンパイラは無理っぽいわ。
- 347 ：：2019/12/22(日) 15:47:44.02 ID:EAnHyDWL0.net
- >>344
gcc は確か C++ で記述されていたはず、C++ のサブセットなんてどんなものなんですかね？
- 348 ：デフォルトの名無しさん ：2019/12/22(日) 16:11:14.32 ID:5lkZulIS0.net
- 元々はただのCだぞ
- 349 ：：2019/12/22(日) 16:23:54.21 ID:EAnHyDWL0.net
- >>348
ずいぶん昔に gcc は c++ になってしまいましたよ…
- 350 ：デフォルトの名無しさん ：2019/12/22(日) 16:45:16.31 ID:lRvby7lea.net
- 元々はって日本語わからんのかな
- 351 ：デフォルトの名無しさん ：2019/12/22(日) 16:46:38.86 ID:uiOI59Hv0.net
- 昔のc++はcのコードを一旦出力してcコンパイラでバイナリを作っていたな
- 352 ：デフォルトの名無しさん ：2019/12/22(日) 17:21:58.53 ID:4GpMlcpo0.net
- >>341
> アセンブラは不要。
と書きながら
>>344
> なお、最初のCコンパイラはBで書かれたものとDECマシン向けのアセンブラで書かれたものがあり、Bコンパイラはすべてアセンブラで書かれていた。
とか自称博識がアホすぎるw
- 353 ：：2019/12/22(日) 17:31:31.94 ID:EAnHyDWL0.net
- >>350
では質問を変えましょう
その昔の to C トランスレータの頃のC++は、控えめに言って C++98/03 の範囲の何パーセントくらいがカバーできていたのでしょうか？
- 354 ：デフォルトの名無しさん ：2019/12/22(日) 18:56:50.05 ID:5lkZulIS0.net
- かわいそうに、馬鹿なのだな
- 355 ：デフォルトの名無しさん ：2019/12/22(日) 19:39:34.09 ID:tqOBQt+/0.net
- >>354
コテでググったら各所で問題児扱いされている奴だったわ
- 356 ：デフォルトの名無しさん ：2019/12/22(日) 21:03:00.98 ID:0l5I7UXk0.net
- >>352
よーく読んでみ
- 357 ：デフォルトの名無しさん ：2019/12/22(日) 21:43:42.23 ID:la1jzM750.net
- >>352
バーンドブレードアタッチメントな僕の知識に反論しようとは笑止千万。
前者は今後出てくる新しいPFに関する記述で、後者は当初のコンパイラに関する記述なので、なんの矛盾もない。
- 358 ：デフォルトの名無しさん ：2019/12/22(日) 21:55:06.63 ID:4GpMlcpo0.net
- >>357
> 前者は今後出てくる新しいPFに関する記述で
誰もそんな話はしてない
Wikipediaレベルのチンケな知識自慢は要らんよw
- 359 ：デフォルトの名無しさん ：2019/12/23(月) 00:11:53.87 ID:GXjcw1770.net
- だめだこいつ…ｗ
- 360 ：デフォルトの名無しさん ：2019/12/23(月) 06:44:48.06 ID:AlxEeRKZM.net
- >>359
自己紹介乙ww
- 361 ：デフォルトの名無しさん：2019/12/24(火) 19:15:18.17 ID:fgilpQiTl
- XMLを知る前に、気づいたらJSONを使ってた。関数があるから便利だよな。
しかも今はJSON.NETがあるからデータ構造すら気にしなくていい。。
- 362 ：デフォルトの名無しさん：2019/12/24(火) 19:20:31.43 ID:fgilpQiTl
- >>141 扱うデータ量にもよりそう。
あんまりたいしたことがないデータ量なら for のほうがとても早いが、
あるオーダーから指数関数的に for のほうが遅いということもある。
for だって最適化されてるし、関数にはオーバヘッドがある。
- 363 ：デフォルトの名無しさん：2019/12/24(火) 19:22:22.08 ID:fgilpQiTl
- まあ一般的に業務ならデータ量は多いはずだから関数のほうが早いんだろうな。
趣味レベルだと扱う量がたいしたことないから、極端に言えばＳＱＬを使うよりも
テキストのデータベースのほうが遥かに早い。
データインサートのときは適当に自分なりの符号を作ってテキストを挿入し、
引くときは正規表現で引くみたいな。
- 364 ：デフォルトの名無しさん：2019/12/24(火) 19:34:26.35 ID:fgilpQiTl
- しかし言語系って同じ概念なのに用語がいっぱい作られていて一々用語の意味を
調べるたびに「一緒ジャン」ってなるな。
データ型名や関数名からそのまま新しい用語ができているって感じがする。。
- 365 ：デフォルトの名無しさん ：2019/12/25(水) 16:59:22.64 ID:Zg8ebJFL0.net
- 今日もつまらないことで5chは盛り上がっております
- 366 ：デフォルトの名無しさん ：2019/12/26(木) 11:49:58.62 ID:2UlJm9YS0.net
- using/disposeについて確認したいんだが、
あれって厳密には「リークする」ではなくて、
「解放のタイミングが不明で、場合によっては問題が発生することもあり得る」なだけだよな？
https://docs.microsoft.com/ja-jp/dotnet/standard/garbage-collection/using-objects
具体的にはGDI+オブジェクトのGraphicsやBrush等について、
MSDNのドキュメントもほぼusingなしで記述されているので気になっている。
https://docs.microsoft.com/ja-jp/dotnet/framework/winforms/advanced/how-to-draw-a-line-filled-with-a-texture
一応、using使えということになっていたはずだが？
そこで色々ググって見ると、どうやら以下のようだが、あってるか？
・try-catch で finally にdisposeが入ってなかったとき、（≒つまりusing使わなかったとき)にも、
例外が発生したその時のリソースも、参照が切れ次第、いつかはGCによって回収される。
・GDI+リソースはシステムリソースで、場合によっては枯渇するから、作法としては不要になり次第解放すべき。
・とはいえ32bit化でこの辺の問題は大幅に緩和され、GDI+はプロセス毎の上限は10,000になってる。
だから余程酷いことをしない限りこれに引っかかることはない。
結果、作法としては正しいがほぼ命中しない問題に関して一々using使うのもウザイ、
ということでMSDNのドキュメントがusing無しになってる、ということで合ってるかな？
(なお関係ないとは思うが俺が使っているのはVC++/CLIとForms)
- 367 ：デフォルトの名無しさん ：2019/12/26(木) 12:35:29.16 ID:WMR2NHe80.net
- サンプルプログラムに厳密性を求めるな ってだけ
- 368 ：デフォルトの名無しさん ：2019/12/26(木) 12:37:11.96 ID:Fsuom43iM.net
- サンプルだから本質には関係ないところをバッサリ省略してるだけでしょ
ガチな例外処理とか入れられても見辛いだけだし
それと同じ話
- 369 ：デフォルトの名無しさん ：2019/12/26(木) 13:02:58.04 ID:Wx+k6OqqM.net
- まあサンプルをコピペしちゃうレベルなら他にもっとまずいところはいくらでもあるだろうから、
少々Disposeが先延ばしになるくらいは無視しても問題ないかと
- 370 ：デフォルトの名無しさん ：2019/12/26(木) 13:36:36.96 ID:2UlJm9YS0.net
- >>255
周回遅れだが一応参戦。当該院生が冬休みでもう一度読んでいることを期待する。
他の人も言っているとおり、設計としては253で正しい。直す必要はない。
なおその点はForms->WPFで思想が修正された点であり、（つまりFormsが駄目だった点）
これも他の人が既に言っているとおり、「最新のフレームワークの流儀」で設計するのが妥当。
判断する能力がないなら、とにかく「最新の流儀」に乗っかるのが
無駄に嵌るのを未然に防ぐ適切な方策となるのでそうすべき。
構成としては、おそらく、
「設定値変更画面(V)」「設定値保管用クラス(M)」「他クラス（多分演算ルーチン）(EXE)」で、
これはMVCの通りであり、V-M, M-EXE 間は結合しているがV-EXEは結合していない。
これに対して、誰か（≒老害）に指摘されたのだと思うが、君が253の時点でいいと思っている構成は、
「設定値変更画面(V+M)」「他クラス（多分演算ルーチン）(EXE)」となっており、Mが分離していない。
（=EXE側がVを知っている必要がある）
この構成の利点は、
・コードが多少少なく済む
点であるが、結局使い勝手が悪いので、ずっと改善していくと最終的に253みたくMVCに分離することになる。
- 371 ：デフォルトの名無しさん ：2019/12/26(木) 13:37:07.04 ID:2UlJm9YS0.net
- >>261
といっても分かりにくいだろうから具体的に指摘すると、
君の問題は、間違った方策で解決しようとして、余計におかしくなっていることだ。
> 他クラスで使用しているときに値を変更されないように2、3を実装したんですけど、単に画面を入力できないようにロックすればよかった。
これは「画面をロック」ではなく、演算開始時に「設定値保管クラスのコピーを演算ルーチンに渡す」とすべき。
これにより、一つの実行画面から多数の演算ルーチンを並列に起動したり、
或いはGUI無しでコマンドラインから起動することも普通に可能となる。
（つまりプログラムとしての汎用性/柔軟性が上がっている）
「クラスのコピー」ってのはディープコピーだが、単純に値が入っているクラスなら、
Cなら構造体の代入、つまり
SomeClass myCopy = reference;
の1行で事足りる。或いは通常、関数呼び出しには構造体への「ポインタ」を用いているはずだが、そこを構造体の「値」に変えればいいだけ。
C#だとstructは値型だったと思うので、設定値保管用『struct』なら自動的に上記が常に行われる構造になるが、
余程小さくない限りそれでは使いにくい筈なので、設定値保管用『クラス』で正しく、何らかの方策でディープコピーをした方がいい。
インミュータブルに組んでいればシャローコピーでも行けるようには出来るはずだが。
- 372 ：デフォルトの名無しさん ：2019/12/26(木) 14:38:18.82 ID:2UlJm9YS0.net
- >>367-369
つかこれ、どれくらいgraphicsヘビーにすればヒットするんだ？
以下はヒットしているようだが、俺はヒットしない。
https://sorayukinoyume.hatenadiary.org/entry/20121029/1351525436
俺のは40k個Brushを作ってそのまま放置、それを1秒ごとに再描画、
みたいな感じだが、OutOfMemoryなんて起きない。
（ただし、カクつく事があったから今はDisposeを入れてしまったが)
プログラムは演算結果をGUIで表示するもので、演算ヘビーだが、
演算自体はC++ネイティブなのでGCは行われない。
（演算ルーチンではマネージドメモリを消費しない）
なお以下とかは正しいように思う。
https://uchukamen.com/Programming/GC/
https://ladybug.hatenadiary.org/entries/2004/01/10
https://ufcpp.net/study/csharp/rm_gc.html
https://divakk.co.jp/aoyagi/csharp_tips_using.html
https://www.codeproject.com/Articles/48701/Using-GDI-Objects-the-Right-Way
（なお最後はシステムで10,000が上限だと言っているが、これはプロセスの間違いだと思う。《他でそう書いてあったところもあった》
また、タスクマネージャーで見る限り、俺のPCでは全体で10,000は越えているし。
なお一番使っているのはJane2chの8,653だった。Jane糞だなオイ。
chromeは各プロセス毎に600-800位、俺のプログラムはどうやっても50-70を推移してる）
MSも馬鹿じゃないからサンプルコードはそれなりに正しいはず。
絶対にこう書け、なら必ずそう書く。そうでないのはその必要が「普通は」ないからだ。
逆に、普通にサンプルコードで問題が発生するようなら、クレーム来まくりで大変だから、当然のように修正される。
それが為されてないのは、それなりに使用に耐えるコードだからだ。
という感じなのだが、お前らこれヒットするのか？
VC++/CLIとC#だとGC周りがだいぶ違うって事か？
- 373 ：デフォルトの名無しさん ：2019/12/26(木) 14:50:50.75 ID:+pzqFzNua.net
- >>372
DC(Graphics)は不要になった時点でDisposeした方がいいと思うけど、
PebとかBrushとかFontとか、このあたりがIDisposable実装してるのは
たぶんWin9xを想定してるんだろうねw
.NET 1.1とかの時代に、Win2kやXPではそこまで神経質にならなくていいよ、
って記事を結構読んだ記憶がある
- 374 ：デフォルトの名無しさん ：2019/12/26(木) 14:53:40.92 ID:g3TV29VW0.net
- 多いから糞って単純な話でもないだろ。表示しているオブジェクトが多いなら仕方がない。
explorerもウィンドウを大量に開くとモリモリ消費する。
- 375 ：デフォルトの名無しさん ：2019/12/26(木) 15:25:02.44 ID:2UlJm9YS0.net
- >>374
いやJaneはガチでリークしてると思うぜ。
俺のPC内での今の順位
1. Jane2ch 8,677 ←増えてやがるし
2. explorer 1,340
3. chrome 826
以下chromeが20個ほど続く。
字しか表示しねえJaneでどうやって8,677個になるんだよ？
フォントや色でも精々100だろ。
そもそも複数ページ表示してるchrome越えてる時点でだいぶおかしい。
- 376 ：デフォルトの名無しさん ：2019/12/26(木) 15:25:33.99 ID:2UlJm9YS0.net
- >>373
そのわりにusingガーというのが多いのはなんでだ？
若干Java的オブジェクト指向（オブジェクト指向が唯一絶対神であり、それ以外は認めない）に近い偏見を感じる。
GCなんて手抜きの為の機構であり、逆に言えば、GC使っている以上、書かなくて済む事は書かない、というのが正しいだろ。
全部書け、ならC++を使って全部書き、GCなんて使っている軟派野郎は死ね、とあるべき。
C#でusingって、なんか違うくね？
まあ現実的にヒットするなら致し方ないとして、俺が試した限りでは、どうにもヒットしないように見える。
それとも
> DC(Graphics)は
これはdevice context だけは即時解放した方がいい、ということか？
具体的にはGetHdcメソッドを有する連中だが、見た目Graphicsだけかな。
だとすると俺がやってるBrushでは再現しないのも納得だが、
かといってGraphicsを10,000取得とかいう使い方もないとも思うが。
- 377 ：デフォルトの名無しさん ：2019/12/26(木) 15:49:32.19 ID:8rtfbEtYp.net
- 何をグダグタと気にしてるのかよーわからんな
どうせそのうち回収されるんだから無駄に残ってるのが気にならねえならどうでもいいだろ
精々Janeみたいに過剰に確保されてるのを観測されてクソクソ言われるのが自分のアプリになるだけだ
- 378 ：デフォルトの名無しさん ：2019/12/26(木) 16:01:00.94 ID:Wx+k6OqqM.net
- つか本来は実際に画面に表示されてる間だけアンマネージリソースを確保すればいいわけで、設計が手抜きなんだよ
まあ、そういう思想でスマートなリソース管理をしてるWPFはゴミのように遅いわけだがw
- 379 ：デフォルトの名無しさん ：2019/12/26(木) 16:08:06.67 ID:+pzqFzNua.net
- >>376
なんかちょっと被害妄想激しいよw
IDisposableを実装してたら絶対Disposeすべき、という教条主義を展開してる記事って
あんまり読んだ記憶ないけど、まあusingブロックは十分コンパクトに書けてかつ便利なので、
Disposeしなくてもいい、という確信が持てないなら素直にDisposeするのが普通に安全牌だよね。
※ 個別にDisposeを呼ぶんじゃなくてusingを使え、という趣旨の記事ならいくつか読んだことある
- 380 ：デフォルトの名無しさん ：2019/12/26(木) 16:15:52.27 ID:2UlJm9YS0.net
- >>377
俺自身は「usingを使うべき」とされる解説ページでお約束的に出される
・そこで例外が発生してdisposeされずに抜けてしまった場合、リークする
が間違い（というか誇大)だと見ているのだが、これが間違ってるかどうかをここで尋ねている。
俺の認識に間違いがないとすると、
俺が試した限りではヒットすることが難しいのに、何故ここまでusingにこだわるのか？というのが疑問になる。
勿論こだわるのもありだが、C#ってそういう言語でもないし。
なお俺のはdisposeしてなくて50-70だぞ。
そこで上記の通り、Brushを40k個作ってもだ。
(もっとも、多すぎてGCが常に速攻行われているだけかもしれないが)
JaneStyleは調べたところOpenJaneからの派生で、OpenJaneはDelphiで、これはGC無しらしい。
つまりモロにリークしてるだけだよ。
- 381 ：デフォルトの名無しさん ：2019/12/26(木) 16:30:20.52 ID:bzjIw0U90.net
- 尋ねてるって言うけど、君の求めてる通りの回答以外は認めないんでしょ
聞くだけ無駄じゃん
- 382 ：デフォルトの名無しさん ：2019/12/26(木) 16:40:38.25 ID:2UlJm9YS0.net
- >>379
> Disposeしなくてもいい、という確信が持てないなら素直にDisposeするのが普通に安全牌だよね。
つまりこれ。
実はDisposeしなくていいんじゃねえの？というのが俺の疑問。
ヒットしている人がいるから何か要件はあるのだろうけど、俺が試してる限りではヒットさせようがないように見える。
とはいえ、ヒットする可能性がある限り、解説ページ等では「Disposeしなくていい」とは書けない。
だけどほぼ必要がないことはMSも認めてるからサンプルページではusingなんて使っておらず、
usingについてのリンクすらない、というように見える。
(つまりサンプルページを確認しているレベルの奴がヒットさせようがなく、
余計な混乱を防ぐ為にも書かない方がいい、とMSが判断してる。
まあ>>367-369はモロにそう言ってるわけだが)
ただこの状況でも、自分だけが使うならともかく、他人も使うとなると、
using使わないわけには行かない、というのは認める。
だからなんだかなあ、みたいな感じになってる。
結局のところ、これは俺の環境のみならず、
.NETが動くありとあらゆる環境に於いて問題なく動くプログラムを作る為の作法であって、
MSがusing使えと言う以上、書くしかない、ということか。
それが俺のPCでは再現不能だとしても、それはたまたまでしかない、ということであって。
- 383 ：デフォルトの名無しさん ：2019/12/26(木) 16:47:16.53 ID:BHrZHcGr6.net
- c#のListをイテレーションするサンプルをウェブで探していたんだけど、インデックスでアクセスして回しているコードがよく見つかるんだけど、
Listのデータ構造はリストではないの？
- 384 ：デフォルトの名無しさん ：2019/12/26(木) 16:48:04.03 ID:+pzqFzNua.net
- >>382
上に書いたWin9x環境を特に想定した実装、というようなケースを除けば
そのクラスを作ったプログラマは「不要になったらDisposeを呼んで欲しい」と思っているから
IDisposableを実装している。
だからDisposeしなくてもいい、という確信が持てないなら（以下略
- 385 ：デフォルトの名無しさん ：2019/12/26(木) 16:55:18.99 ID:WMR2NHe80.net
- >>383
「リスト」だとデータ構造が説明できてないと思うのだが
List<T>は配列で実装してるよ
- 386 ：デフォルトの名無しさん ：2019/12/26(木) 16:59:42.72 ID:F8ujXl8x0.net
- GC任せではなく明示的にメモリを開放していかきゃ動作に支障をきたすような少メモリな環境だって世の中にはある
- 387 ：デフォルトの名無しさん ：2019/12/26(木) 17:03:28.05 ID:Wx+k6OqqM.net
- >>383
.NETではIListは順序が定義され効率的なランダムアクセスの可能なデータ構造
従って、リンクリストはIListを実装しない
- 388 ：デフォルトの名無しさん ：2019/12/26(木) 17:07:04.85 ID:2UlJm9YS0.net
- >>384
なるほど確かにその通りだ。
設計者が想定したとおりに使うのが安牌であり、
書いておけば済む物を、特段メリットもないのに書かずに済ませて後で嵌るのは生産性が悪い、というのはC#的には当たりだ。
呼ぶか呼ばないかは使用者が判断するものではなく、設計者がIDisposableを実装するかどうかで示し、それに従え、ということか。
まあ長期的に見てその思想が正しいんだろう。
なるほど納得した。
- 389 ：デフォルトの名無しさん ：2019/12/26(木) 17:10:19.42 ID:2UlJm9YS0.net
- >>383
つhttps://docs.microsoft.com/ja-jp/dotnet/api/system.collections.generic.linkedlist-1?view=netframework-4.8
- 390 ：デフォルトの名無しさん ：2019/12/26(木) 18:35:58.39 ID:EoULV8Z50.net
- disposeされなくてもデストラクタで解放されるが、
かなり高コストな処理が発生するそうな
https://ufcpp.net/study/csharp/rm_disposable.html#idisposable
- 391 ：デフォルトの名無しさん ：2019/12/26(木) 19:21:56.18 ID:2UlJm9YS0.net
- >>390
それは嘘。というか誇大広告。
オブジェクトの寿命が1GC分伸びるだけ。それが深刻になる状況なら、
ファイナライザリストをそもそも作らず、必ずusing/disposeしろ、という設計思想が妥当。…(A)
或いは、ファイナライザリスト内だけ2GC世代分GCするとか、そういうフレームワーク設計も可能。…(B)
いずれにしても、.NETはそうしてない＝それは大した問題ではない、とMSが判断している証拠。
といってもGCも進化しつつあるし、この辺もじきに整理されるのかもしれん。
C#8.0のusingはソースコードとしてはほぼ完成型だし、
> using var font1 = new Font("Arial", 10.0f);
> https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/keywords/using-statement
型によっては using var でしか宣言出来ない（＝静的に確保出来ない＝ローカルでしか持てない）ようにすれば、
上記(A)の思想を体現出来る。それが本筋かもね。
形式的にはVC++/CLIのpin_ptrと同じだから、実装する気になればMS的にはすぐだ。
https://docs.microsoft.com/ja-jp/cpp/extensions/pin-ptr-cpp-cli?view=vs-2019
制限はそこに書いてあるが、以下。
> 固定ポインターは、スタックの非静的ローカル変数としてのみ宣言できます。
> 固定ポインターは、以下として使用することはできません。
> 関数パラメーター
> 関数の戻り値の型
> クラスのメンバー
> キャストのターゲット型
「関数パラメータ」に使えない、と書いてあるが、これは言い方が悪くて、
「関数の仮引数の型には使えない」が正しく、実引数として渡す場合はキャストされるので普通に使える。
言葉だと分かりにくいが、
pin_ptr<double> ptr_d;
を void somefunc(double*) に渡すとdouble*に自動的にキャストされるので普通に使える。
これと同様の制限だと、「その関数を抜けた後も保持していて欲しい」オブジェクトには使えないが、
GDI+オブジェクトに関してはこの方向でもコーディングは可能のように思える。
- 392 ：デフォルトの名無しさん ：2019/12/26(木) 21:56:25.88 ID:Ag2MBuDI0.net
- >>391
> オブジェクトの寿命が1GC分伸びるだけ。それが深刻になる状況
じゅうぶん現実的な状況でなり得るよ。Gen1以上のGCを舐めてる
それが許容できるかは要件次第
ゲームプログラミングでなくとも極力排除すべき要素
そういえば「ガクガクするから結局Dispose呼び出した」とか自分で言ってたね
なんでガクガクしたの？
> 型によっては using var でしか宣言出来ない（＝静的に確保出来ない＝ローカルでしか持てない）ようにすれば、
論外。ネイティブリソースを持った時点でスタックにしか確保できない型しか作れない言語の出来上がり
ファイナライザを作らずDisposeを強制するというのはそういこと
大した問題じゃないから、ではなく潜在的に負荷を抱える可能性の排除とリソースリークへのセイフティを天秤にかけた結果だよ
> VC++/CLIのpin_ptr
それC#で言うunsafeなfixed相当。関係無い
- 393 ：デフォルトの名無しさん ：2019/12/26(木) 22:28:04.26 ID:9AkEaWNs0.net
- Disposeしないで挙動を調べた結果、問題ないんだったらそのリソースに関してはDisposeしなくていいってことがわかるだけじゃない？
それを一般化してusingなんか使う必要がないのだ/Disposeはファイナライズのときにされるので十分なのだってのはおかしいような。
一々いろんなIDisposableのオブジェクトの挙動を調べてたら検証時間がかかってしょうがないし、
今調べた挙動が将来的にずっと同じである保証もないから、Disposeしてね、と言われているものに関しては、
Disposeされるものだと思って設計変更される可能性がある、と考えて、
問題のないタイミングで行儀よくDisposeしてトラブルの種を潰すってだけの話だと思うんだけど
逆に、使い尽くしてDisposeしなくていいってわかってるんだったら
（例えば自作クラスで、なんかのハンドルを握ったままになったりしないという保証があるなら）
どうぞご自由に、って思うけどね
「自転車ってうちの近くの舗装の綺麗で平坦な道路では手放し運転できるのに、なんでハンドルなんかついてるんだ？いらなくね？」って言ってるようなものだと思うけどね。
- 394 ：デフォルトの名無しさん ：2019/12/26(木) 23:04:21.26 ID:qz8G02Zg0.net
- なるほど！と読んでたら最後の例えでよくわからんようになった…
- 395 ：デフォルトの名無しさん ：2019/12/26(木) 23:08:24.18 ID:2UlJm9YS0.net
- >>392
いや多分、みんな求め過ぎなんだよ。
C++erが特にそうだが、C++を何でも出来る言語にしようとしてる。
それと同じく、君もまた、C#を万能言語にしようとしてないか？
つまり、簡単に書け、かつ、最速な言語に、ということだ。
> それが許容できるかは要件次第
俺に言わせれば、ゲームプログラミング等のパフォーマンスクリティカルな状況でC#を使う選択自体が間違ってる。
実際、ゲームは今でもC++が主流で、それはパフォーマンスの問題からだろ。
そういえばUnityはC#だが、（俺はゲーマーでないから詳しくないが)
あれは紙芝居ゲーとかそういう全くパフォーマンスとかどうでもいい系向けではないのか？
グラゴリゴリのゲームをC#で書いて、C++に勝てるとでも思っているのか？
> なんでガクガクしたの？
知らん。ただ、Disposeしてなかったから試しにしてみたらとりあえず直った。
だからGCなのだろうとは思うが、それ以上は確認してない。
ただ、2-3画面毎だったから、Brushで言うと100k毎くらいだ。
- 396 ：デフォルトの名無しさん ：2019/12/26(木) 23:09:24.48 ID:2UlJm9YS0.net
- > 論外
いやお前の不勉強具合が論外だよ。少なくともRustはそっちを目指している。
もうちょっと単純簡潔な表現のページもあったはずだが見つからないので、グダグダしているが以下。
> 意味論への影響
> スタックアロケーションはRustの言語自体へ影響を与えており、したがって開発者のメンタルモデルにも影響しています。
> Rust言語がどのように自動メモリ管理を取り扱うかは、LIFOセマンティクスに従っています。
> ヒープアロケートされユニークに所有されたボックスのデアロケーションさえも、
> スタックベースのLIFOセマンティクスに従っていることは、この章を通して論じてきたとおりです。
> 非LIFOセマンティクスの柔軟性（すなわち表現能力）は一般的に、
> いつメモリが解放されるべきなのかをコンパイラがコンパイル時に自動的に推論できなくなることを意味するので、
> デアロケーションを制御するために、ときに言語自体の外部に由来するかもしれない、動的なプロトコルに頼らなければなりません。
> （Rc<T> や Arc<T> が使っている参照カウントはその一例です。）
>
> 突き詰めれば、ヒープアロケーションによって増大した表現能力は（例えばガベージコレクタという形の）著しい実行時サポートか、
> （Rustコンパイラが提供していないような検証を必要とする明示的なメモリ管理呼び出しという形の）
> 著しいプログラマの努力のいずれかのコストを引き起こすのです。
> https://doc.rust-jp.rs/the-rust-programming-language-ja/1.6/book/the-stack-and-the-heap.html
と公式は言ってはいるが、Rustの取っつきにくさはここにあって、
要するに既存言語のノリでやったら全然コンパイルが通らないらしい。（俺はやってなから知らんが）
ただし、スタックアロケーションの方が効率も管理も楽なので、スタックアロケーション出来るものはスタックに、という理屈は合ってる。
問題はそれだと柔軟性、つまりデタラメなコーディングが出来なくなる点で、
- 397 ：デフォルトの名無しさん ：2019/12/26(木) 23:10:55.58 ID:2UlJm9YS0.net
- > 天秤にかけた結果だよ
というのはその通りで、C#は色々なことを天秤にかけて「丁度いい言語」を目指している。
だから、「最速の言語」では今現在ないし、今後ともあり得ないことも自覚してないといけない。
繰り返すが、パフォーマンスクリティカルな状況でC#を使うこと自体が間違いだ。これは今後共だ。
> それC#で言うunsafeなfixed相当。関係無い
確認したが、fixed相当なのはその通り。それで、何故関係ないと言えるのか？
usingで書けるということは、同じ構文のfixedでも書けるということ。
pin_ptrは型なのでグダグダ制限が付いているが、usingやfixedは構文なのでそもそも制限する必要がないだけ。
まあここら辺の理屈はさておき、実際、GDI+リソースをクラスメンバとして持つ必要がどこにある？
例えばGraphicsをControl.CreateGraphicsから生成するのなら、Controlを持っておき、その都度生成することは出来る。
これにより、永続コンテンツ（クラスのメンバ）として持つのは回避出来る。
この制限を付ければ、Graphics自体が「生成されたスコープを抜ければ常に破棄される物」となり、
言い換えれば君の言っているとおり「スタックにしか確保出来ない型」になるが、
usingなんて付けなくてもリソースリークが発生することは原理的になくなるし、
ファイナライザという機構も不要になるので、GC自体も単純化し、高速化する。
とは言ってもここら辺はフレームワーク根幹の設計思想であって、今更グダグダ言っても始まらないが、
Rustで.NETをサポートしたらusingみたいな糞は入らないだろうよ。（原理的に不要）
どの言語スレもそうだが、若干みんな信者になってしまっていて、公平に見れてない。
C#8.0のusingは「書く」前提なら完成型だと思うが、「書かない」方向を目指すことも出来、実際、Rustはそっちを目指してる。
それを糞だと判断するのも自由だが、理解出来ない/知らないのは君の問題だよ。
俺に言わせりゃ、コールグラフなんて抜けるんだから、
usingなんて書かなくとも「このリソースが永続化することはない」というのはコンパイラ側が判断出来ることで、
なら自動的にusing扱いにして、そうじゃないところだけwarning出してくる、というのが理想だと思うが。
- 398 ：デフォルトの名無しさん ：2019/12/26(木) 23:23:27.97 ID:aYxazJyl0.net
- unityでも3Dゴリゴリのゲームは作るよ
というかスマホで3Dゲームの高クオリティ開発ならunity
1択なくらい。unrealはまだスマホ市場少ない
unityはスマホが多いがコンシューマもPCもそれなりにある
ゲーム以外のARVR分野もかなりunityは多い
言語パフォーマンスより開発パフォーマンスが優先された結果だと思う
だからといって処理速度をないがしろにできるわけじゃない
- 399 ：デフォルトの名無しさん ：2019/12/26(木) 23:25:15.01 ID:2UlJm9YS0.net
- >>393
いや長期的に見た生産性の為にusingを書いてトラブルの種を潰しておく、というのは納得した。
俺がいくら試しても、俺環境で俺の使い方での結果でしかないから、公式に従った方が得策だ。
ただし言語としてそれが最高か、と言われれば、俺はusingなんて書かなくてもなんとかしとけ、という思想。
つまり、
C#： using書け、ただし、書き忘れても大体何とかなるようには作ってある
Rust： そもそも変数はスタック上にしかアロケートしないので、usingとか原理的に不要
俺： 勝手にコンパイラが色々チェックして、可能なところは自動的にやって、駄目なところだけwarning出してこい
ということ。ただしこれは理想論であって、現実はそうではないのはもう認めてる。
ただそれにしても、「GDI+オブジェクトがスタック上にしか確保出来ない」がそんなに糞だとは思わない。
実際、俺はこれでほぼ組んでいるはずだし。
- 400 ：デフォルトの名無しさん ：2019/12/26(木) 23:41:44.91 ID:V9vPePAWa.net
- Rustは普通にヒープ使うぞ？
なんか勘違いしてるようだが、そもそもスタックだけで用が足りるんなら所有権だの何だのとRustの高度なリソース管理は要らん
C++のRAIIや、それこそC#で変数をデフォルトでusingにした程度で十分だ
- 401 ：デフォルトの名無しさん ：2019/12/26(木) 23:42:14.94 ID:2UlJm9YS0.net
- >>398
> 言語パフォーマンスより開発パフォーマンスが優先された結果だと思う
> だからといって処理速度をないがしろにできるわけじゃない
C#の開発パフォーマンスがいいのは認める。
とはいえ、原理的な速度というのはあって、
正直、C++erの「GC使わないけどスマポ使え」ってのはロジック的に間抜け（矛盾してる）と思うが、
Rustの「全部スタック動作と連動」というのは原理的に正しく、逆に言えば、この方法でないとCを越えられない。
だから、根幹の思想は何だかんだで重要で、GDI+に関してはusngではなく「スタック縛り」の方が妥当だったように思う。
ファイルリソースは永続化出来ないとイテレータが使えないのでusingじゃないと無理っぽいが、
GDI+リソースは特に永続化する必然性が無く、大量に生成し、破棄するものだからだ。
パフォーマンス上は断然「スタック縛り」が有利で、
それでコードが書けなくなる/書きづらくなる、ってこともないと思うのだが。
と言ってもMSも気づいているだろうし、当然考えてもいるだろうし、
Rustにも手を出してはいるから必要なら出してくるんだろうけど。
- 402 ：デフォルトの名無しさん ：2019/12/26(木) 23:44:51.57 ID:2UlJm9YS0.net
- >>400
他言語の「ヒープ」と同等の動作では全くない、ということ。
- 403 ：デフォルトの名無しさん ：2019/12/27(金) 01:44:02.82 ID:FV6GRoMta.net
- >>402
具体的にどう違うのか説明してね
Rustのメモリ管理は、端的に言えばスマポしか使えない縛りを入れたC++に過ぎないよ
- 404 ：デフォルトの名無しさん ：2019/12/27(金) 09:28:31.67 ID:9LlS+1cS0.net
- >>399
呼び出しの静的解析だけで、コンパイラ側が自動でusing付けるとか、現状の言語仕様でいけるもんなのかなあ。
行けそうなケースがあるのはわかるけど、すべてのケースで問題なく動作するというエビデンスはなんかある？
あと、俺に言わせりゃ静的解析で出来るだろとのことだけど、設計実装難易度も十分に低いと見積もってて、なんでやらないんだ、と言いたい、ってことなの？個人的には難易度は未知数だと思うんだけどなあ。
- 405 ：デフォルトの名無しさん ：2019/12/27(金) 10:30:46.74 ID:jG1yqawr0.net
- >>404
参照がスコープ外に持ち出されていないかどうかを判断する必要があるだろうけど、それには
rustのように関数呼び出しに情報を受け渡す拡張が必要になるだろうね。
どうせ文法を拡張するなら、C++/CLIのようにusingより簡単な記述でDispose()の必要性を
判断できるようにする方が現実的かも。
- 406 ：デフォルトの名無しさん ：2019/12/27(金) 11:10:40.91 ID:AkdF/Ds50.net
- >>404
> 設計実装難易度も十分に低いと見積もってて、なんでやらないんだ、と言いたい、ってことなの？
いや違う。ぶっちゃけ、信者的態度で言われたから言い返してるだけだな。
現実問題として、Rust公式でも述べているとおり、ヒープ+GCの使い勝手は素晴らしく良く、
「コードの書きやすさ」という意味においては現状最高だろう。
だからC#がこれを採用しているのも理に適ってる。
ただし問題は、それを信者的に素晴らしいと君らが捕らえている点で、
これはC#が魔法を使ったわけでもなんでもなく、
単純に、速度を捨てて書きやすさを取っているだけだと正しく認識しろと言っている。
だからパフォーマンスクリティカルだと分かっている状況でC#を使うのが間違いだし、
それはファイナライザが実装されているからGCが1世代分伸びるのも問題だ、というときも該当する。
そこまでのパフォーマンスを求めるときに使う言語ではないし、出来る言語でもない。これは今後共だ。
解決策は既に述べたとおりだが、ここに関してはMSが「間違えた」というのは厳しいが、でも、間違いだとは思う。
usingは「書く」前提ではC#8.0で完成しているが、
問題は、「それが書かなければならない型だ」とユーザーが認識しなければならない点で、
そもそも知らなければ抜けるし、そのためのファイナライザでシステム的に遅いGCになる事を許容しなければならない。
（というほど俺は遅くはならないと思うが、お前らはファイナライザが問題だと言うので）
なら、最初から「スタック縛り」にしてしまえば、SyntaxErrorで落とせるし、GC機構そのものが不要になる。
このときの問題点は多少コーディングの自由が奪われることだが、現実として、
PenやBrushをクラスメンバとして永続させる必要なんて無いし、
GraphicsやFontも生成元『マネージド』情報(既に述べたがControl等）を代わりに持つことによって回避出来る。
結果、馬鹿みたいに「GDI+オブジェクトはその都度生成して、その都度廃棄」なコードになってしまうが、
SyntaxErrorにならなければリソースリークは原理的になくなり、
GCも簡素化/高速化し、using周りの仕様も覚える必要がない、ということになる。
- 407 ：デフォルトの名無しさん ：2019/12/27(金) 11:11:26.51 ID:AkdF/Ds50.net
- 俺が思うC#の利点は、「無駄に覚えなければならない仕様」がほぼ無いことであり、
これは、C++が何でも出来る言語にしようとしている反面、
ほぼ使いもしない仕様を覚える必要がありすぎる状況になっているのと対極的ではある。
ただ、俺に言わせれば、usingも覚えるべき仕様ではない。
「GDI+リソースを持つクラスはスタック上にしか置けません」の仕様だと、何も覚えなくて済み、リーク周りの問題もない。
ただこれは完全に後出しで、MSが間違いを犯したわけではない。
彼等は単純に現状の仕様に乗るようにしてきただけであり、
未来の改訂で「スタック縛り&using廃止」になるのも十分ありうるし、俺はそれを望む。
ただMSはおそらくパフォーマンスよりも書きやすさに振ると思うので、微妙だとは思うが。
> 呼び出しの静的解析だけで、コンパイラ側が自動でusing付けるとか、現状の言語仕様でいけるもんなのかなあ。
要は
Brush xxxxx;
{
// ここで永続化されなければよい
}
なので、中身を辿りきれるかどうかに尽きる。
具体的には、ヒープ上のオブジェクトに保持されているとかが無ければいい。（といってもC#は全部ヒープだが）
解析に問題になるのは関数ポインタを動的に使われるケース（テーブルジャンプ等）だが、
そういうのはほぼやらないから現実的には大半の場合は解析可能だと思う。
> 行けそうなケースがあるのはわかるけど、すべてのケースで問題なく動作するというエビデンスはなんかある？
こんな物はそもそも必要ない。
解析可能なら自動でusing付けろ、解析無理(かつユーザーがusing付けてない)ならwarning出せ、のベストエフォートでいい。
現実的にこれで問題ない。
というかJavaScriptのJITが既にこれに近いことをやっていたはずで、
要は「この関数を抜けたら破棄されると静的に解析済みの変数は最初からスタックに配置する」で、
解析無理なら従来通りヒープに置いてＧＣ、可能な物は纏めてスタックに置いてGC回避で高速化、みたいなことになってたはず。
だから.NETもそれをやればいいだけ。
- 408 ：デフォルトの名無しさん ：2019/12/27(金) 11:48:38.34 ID:hRCuq6kQM.net
- 君が冒している最大の勘違いは、「C#開発者の皆が自分と同じくusingの不便を感じている」という前提を置いていることだ。
実際にはもうFormsの開発なんてC#ではマイナーな部類になりつつあり、
現在の主流であるWeb開発ではDisposeなんか滅多に使わない。
Webのパフォーマンス改善の観点で言えば、(君の愛する)スタックにしか置けない特殊な構造体の導入等により、
C#のGCに極力頼らない高度なメモリ管理は実は一部では既に実現されている。
usingはもはや滅多に使わない機能であり、それほど力を入れて改善されるべき対象ではないんだよ。
- 409 ：デフォルトの名無しさん ：2019/12/27(金) 11:56:34.65 ID:JsENnlV9p.net
- 信者的信者的ってなんのこと言ってんだコイツ？
ファイナライザ持ちがDispose呼ばないと昇格オブジェクトが増えてやばいって警告に
誇大広告だのほざいてるのは自分じゃねえか
自分のコードでDispose呼ばずにフルコレクトかましてガクガクさせながら「自分はそれほどでもないと思う」とかなんのギャグだよ
- 410 ：デフォルトの名無しさん ：2019/12/27(金) 11:59:55.99 ID:9LlS+1cS0.net
- >>407
JITだからできることでコンパイラじゃできなくない？
何が気になるかって言うと、コールスタックの解析とかをコンパイル時点でやり始めるってのは停止性問題を取り扱うみたいなむりがあるんじゃないのかってこと。
ごく簡単な例だったら問題ないだろうけど、そのごく簡単な例ってわずかじゃないのかな。
- 411 ：デフォルトの名無しさん ：2019/12/27(金) 12:08:44.93 ID:hRCuq6kQM.net
- それをコンパイラ(というか型システム)でやろうとした結果がRustだね。
ちなみに彼は知らないようだが、Rustのメモリ管理がスマートであると言われる所以は、
エスケープしていないオブジェクトの生存管理などではなく(そんなものはC++でとっくの昔に実現されている)、
エスケープした「ヒープ上の」オブジェクトも正しく追跡して破棄できること。
それがプログラマにどれだけの負担を強いているかは>>396の通り。
- 412 ：デフォルトの名無しさん ：2019/12/27(金) 12:34:15.59 ID:AkdF/Ds50.net
- >>408
Formsが過去の遺産で糞で既にVSからデフォで除外済みなのは知ってる。
ただし俺は移行するよりはそのままメンテする方を選んでいるだけ。
usingについては、C#8.0(2019/09リリース）で改訂されているのだからobsoleteとは言わんだろ。
まあそれはさておき、Web開発ってのは以下で、現状のC#の主力はWPFではなくこれだって事か？
https://docs.microsoft.com/ja-jp/visualstudio/ide/quickstart-aspnet-core?view=vs-2019
見た目サーバーアプリで、つまりPHPの代替のように見える。
なら実際の描画はやる必要がないから、そりゃGDI+オブジェクトを掴むことはあり得ないわな。
> Webのパフォーマンス改善の観点で言えば、(君の愛する)スタックにしか置けない特殊な構造体の導入等により、
> C#のGCに極力頼らない高度なメモリ管理は実は一部では既に実現されている。
調べてみたが、Span<T>, stackalloc, ref struct 等か。確かにこれらは悪くない。
こういう小回りも利くところがMS主導言語のいいところではある。
実際にコードを書く奴らが主導している匂いがする。
ただな、こういうマニュアル調整は本来C#が目指しているものではないだろ。
GCを使う＝変数等の寿命について一々考えたくない、であって、
実際、C++だと考えることが多すぎて、開発に手間がかかる＝開発効率が悪くなる。
だからそこをランタイムに丸投げして、ユーザーは本来書くべきコードだけに集中出来るのがよいのであって、
あれこれ弄れば速くなります、なら、最初からC++等使え、でしかない。
とはいえ、折衷策として出してきたのは悪くないが。
JavsScriptの良い点は、「何も考えなくてもJITが勝手に速くしてくれる」事であって、
俺はこの点が最高に気に入ってる。
ちゃんと弄れば速くなります、なんてのは、面倒＝開発効率が下がる。
ただしC#はスクリプト言語レベルの手抜きを目指しているわけでもないから、割と妥当なラインなのかもしれんが。
- 413 ：デフォルトの名無しさん ：2019/12/27(金) 12:41:35.60 ID:Xz3K8ooNd.net
- えらい散らかった論調だな。もう少し端的に話せんか？
- 414 ：デフォルトの名無しさん ：2019/12/27(金) 13:00:43.57 ID:AkdF/Ds50.net
- >>410
JITで出来ることとコンパイラで出来ることは違うが、今回に関しては同じだよ。
（関数単位でJITしてる限り同じ）
普通に考えれば分かると思うが、関数内の変数なんてその関数出たら破棄される物が大半で、
仮に内部でさらなる関数呼び出しに関連している物が全部追跡不可能だったとしても、十分効くんだよ。
完全にやり切ろうとするのはそりゃかなり無理だよ。でもそれは必要ないんだ。
- 415 ：デフォルトの名無しさん ：2019/12/27(金) 13:13:01.35 ID:ra/PE2rBa.net
- 極論 vs. 極論でなんともw
- 416 ：デフォルトの名無しさん ：2019/12/27(金) 13:18:13.87 ID:AkdF/Ds50.net
- >>411
> ちなみに彼は知らないようだが
実際知らんからRustの話は君に任せる。
俺はRustはどういうコンセプトでどういう状況かを遠くから眺めているだけで、
「このコードが動かないんです！」みたいな悲鳴をチラ見してるだけだからな。
ただ、その中に「ヒープ上のオブジェクトすらも勝手に解放されるのかー！！！」みたいな話もあった気がするが。
スマポ限定なだけだというのなら、あれは関数呼び出しによる所有権移転で解放されただけの話か。
まあそうかもしれん。
いずれにしても俺はRustのコードは書いてないし、直近で書く予定もないので、Rustについては君に任せる。
- 417 ：デフォルトの名無しさん ：2019/12/27(金) 13:29:20.92 ID:ra/PE2rBa.net
- どうせ過疎スレだし、BGMこれでガンガンやって欲しいw
https://youtu.be/BvmqYM1xpZA?t=28
- 418 ：デフォルトの名無しさん ：2019/12/27(金) 16:53:56.60 ID:SNZP60vo0.net
- トヨタの車をブレーキを踏まずに運転できる人なら、usingはいらないよ
- 419 ：デフォルトの名無しさん ：2019/12/27(金) 20:05:38.60 ID:vYkXGtn00.net
- うぜーから個人ブログでやれよ
- 420 ：デフォルトの名無しさん ：2019/12/27(金) 21:26:25.65 ID:rZaePzzs0.net
- 正直半分ぐらいしかわからないけど、たまには盛り上がるのもいいよ
- 421 ：デフォルトの名無しさん ：2019/12/27(金) 23:28:54.87 ID:SNZP60vo0.net
- 2週間に1度ぐらいのペースで、わけのわからん話題で盛り上がってる気はする
- 422 ：デフォルトの名無しさん ：2019/12/27(金) 23:31:26.75 ID:jbwOykBS0.net
- ふらっとじゃなくこっちで暴れる分には好きにしたらいい
こっちでNGしとけばふらっとで見なくて済むし
- 423 ：デフォルトの名無しさん ：2019/12/27(金) 23:40:23.09 ID:AkdF/Ds50.net
- >>420
半分しか分からないのは、オブジェクトの寿命を考えずにコーディングしているからだ。
ただしこれがGC言語の魅力でもあり、一々グダグダ考えていると魅力半減ではあるが、
そうは言っても、上達したいのなら、考える癖は付けた方がいい。
これについては、禿(ストロウストラップ＝C++創始者）の
「ドキュメントを作成すべきコードのサイズには下限があるが、
コーディングする前に考えるべきコードのサイズには下限がない」
が当たってる。なまじ出来るようになるとどうとでも組めるようになるが、それがいけない。
本来このコードはここにあるべきか？というのを考えながらコーディングした方がいい。
usingに関しては、そもそもGDI+オブジェクトが永続化されるのが間違いで、
それはVに状態を持つということだから、MVCから見てもアウトだとすぐ分かるだろ。
本来は、GDI+オブジェクトに関しては、
・usingの中でしか使えない
・スタック上にしか置けない
（まあこの2つは等価だが)みたいな制限を課されたとしても、まともな設計なら制限にすらならないんだよ。
で、戻るが、これが分からないのなら、それはオブジェクトの寿命を考えてないからだ、となる。
といっても分からないだろうから、具体的に説明すると、
例えばドベタな将棋ソフトを作るとしよう。
CPUと対戦するだけの将棋ソフトで、ドベタに、
ユーザーが入力（指す）→画面の更新→CPUは考える→指す(画面の更新)→アイドル（ユーザー入力待ち）、の無限ループだとしよう。
これでMVCなら、
M： 盤面と持ち駒情報
V： 画面表示
C： それらのグルー
であって、画面はその都度最新状態に更新されているのだから、
アイドル状態で残っているオブジェクトはどう考えてもMの「盤面と持ち駒情報」だけでいいだろ。
だからアイドル状態にてV用のGDI+オブジェクトが捕まれたままになっている時点で設計がおかしいんだよ。
この点、Janeは再起動してみたが相変わらずGDI+は8,657なので、明らかに糞設計だと断言出来る。
- 424 ：デフォルトの名無しさん ：2019/12/27(金) 23:41:02.61 ID:AkdF/Ds50.net
- 画面の更新は、当然関数であり、
画面の更新はこの中でしか行われないのだから、当然、この関数を出ればGDI+オブジェクトは破棄していい。
だから、全てのGDI+オブジェクトは、どこかで
void some_funciton_0(){
using (var someGDIobject = ... ){
some_function_1();
}
}
みたいにusingで囲めるポイントが必ず存在する。例えば、ど頭でCreateGraphicsするなら以下となる。
void redraw_board(){
using (var gr = someControl.CreateGraphics()) {
some_function();
}
}
これは寿命という意味では、関数の一番頭でCreateGraphics＝この関数と変数grの寿命を同期させているわけだが、
この関数以外に画面更新関数がなく、常に全面更新完了して抜けるのだから、
grはどう考えてもこの関数の外で使われることが無く、これで問題になりようがないだろ。
だから変数を寿命順に入れ子にし、結果的に関数コールも同様に並び、変数の寿命とスタックの動作が完全に一致する、というのがC流で、
動作としてはこれが一番無駄がないから、この設計で組まれた場合に速度ではどうやっても勝てない、ということになる。
別にこれが難しいとか制限が厳しいとかいうわけでもなく、要するに無駄なく普通に組めばこうなる。
だからまともな設計に於いて、GDI+オブジェクトに
・usingの中でしか使えない(＝スタック上にしか置けない)
という制限を課すのは、制限にすらならない。
これが問題になるようならそもそも設計がおかしい。
ただ、現実論として、度重なる仕様変更によりプログラムの設計というのはおかしくなって行くもので、
多少設計がおかしくてもなんとでもなる言語じゃないと困るのだが、
それにしてもGDI+オブジェクトは上記制限を課されても全く問題ないと思う。回避手段もあるし。
というかマジな話、MVCにしてればV用オブジェクト掴みっぱなしなんてあり得ないし。
- 425 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 412f-fJ/L)：2019/12/28(土) 04:09:04 ID:Cmc+tz5h0.net
- GDI+だけがアンマネージドリソースではないんだが
そんな狭い前提で話されてもなぁ
- 426 ：デフォルトの名無しさん ：2019/12/28(土) 09:58:00.22 ID:6W1egYcc0.net
- ちょっと言い方が本質的でなかったから言い直すと、
ある関数内で必要とされるリソースに対して、
・その関数突入時には掴んでおらず、
・その関数脱出時にはリリースしててよい（＝その関数の中でしか使わない）
場合は、必ずブロックスコープの入れ子で対応出来る。(A)
となる。Cはある意味これしか無く、これを「不自由だ」とする人達はGCに向かったが、
結局C的上記手法に回帰してる。これはC++もそうだし、C#もそうだ。
C#8.0のusing、何度も言っているが書く場合は完成型だが、意味的にはC++のデストラクタと同じでしかない。
なら36年前に開発済みの手法であり、C#1.0からこれでよかった。
それを19年かけて再開発して、何も知らない若者がありがたがるという、間抜けなことをやっている。
ここら辺がLinusがC++を嫌う理由で、C++も同様に仕様を引っかき回した挙げ句、C的手法に回帰してる。
なら最初からCで書け、Cで出来る範囲しかC++は認めない、というのも、酷い言い方だが確かにそうでもある。
同様に、C#も、usingの間抜けさに気づくのに8.0までかかったんだから、
C#12.0位で上記縛りを付けて廃止する方向になるのではないかな。
MとVを分離するのは現在既に常識だし、Vを分離している場合にはGDI+リソースについては上記(A)は必ず成立する。
ファイル等のその他アンマネージドリソースについては後回しになるだろう。
言語/プラットフォームとしての整合性/統一性が取れないが、C#は整合性より実質的利益を選択するはず。
- 427 ：デフォルトの名無しさん ：2019/12/28(土) 09:59:17.52 ID:6W1egYcc0.net
- お前らは多分気づいていないんだろうけど、C系言語は「関数を抜けたらローカル変数は全て破棄される」為、
動作効率はいいが、関数を頻繁に抜ける＝GUIとは絶望的に相性が悪い。
GUIの場合は各イベント関数がトップレベル関数(C#コンソールアプリでいうmain)になるから、
上記「入れ子」での変数処理にかなり無理が発生してしまう。（アーキテクチャ的に無理）
ここら辺は最初からGUI用に設計されているJavaScript等をやってみれば分かる。
JavsScriptの場合は全部の関数がクロージャ付きだから、クラスと関数の区別もなく、関数に変数が紐ついてる。
だから、C系言語だとグダグダになるGUIも、JavaScriptなら比較的綺麗に書ける。
C#はいい言語だし、1つ学ぶならC#という選択も悪くはないが、他言語をやりさえすればあっさり見えることはある。
JavaScriptは糞だ糞だと言われて久しく、AltJSもやたら作られたが、いまだに殺しきれないのは、
結局のところ根幹のアーキテクチャ「全関数がレキシカルスコープのクロージャ付き」がGUI向けに圧倒的にフィットするからだ。
同様に、C#含めてC系言語がやたらあるのに、Cを殺しきれないのは、結局のところ、Cの根幹のアーキテクチャ
「変数の寿命とスタックの動作を一致させ、最速を得る」が圧倒的に素晴らしいからだ。
「変数の寿命を考えて設計しろ」なんてのは今も昔もそう言われてないが、（ただCにはそれしかないから言わずもがなだったが）
C#もC系ではあるのでC的手法で設計した方がフィットするのは事実。
寿命なんて考えたこと無かった奴は考える癖を付けた方がいい。
そして可能であればJavaScript等の「コンセプトがそもそも違う」言語を触ってみた方がいい。
そうすれば、C系言語が何を捨てて何を取ったかも分かるようになる。
具体的には（歴史的にはおかしい言い方だが）、GUI対応を捨てて速度を取っている。
- 428 ：デフォルトの名無しさん ：2019/12/28(土) 09:59:55.78 ID:6W1egYcc0.net
- なお余談だが、そのGUIをグダグダにならないように設計として対処しよう、というのがMVCであり、
これはやった方がいいのは事実だが、酷い話、
JavaScriptほどGUIと相性がいいとMとVが混ざっていようがなんとでもなってしまうのも事実で、
これの最たる物がjQueryであり、jQuery自体ではなく使う奴の使い方の問題なのだが、レッテル貼られて丸ごと廃棄されようとしている。
ただここら辺も、やれば、C#なんてGUIにはまるで向いて無く、
だからMVCだバインディングだと手の込んだ仕掛けを作って誤魔化さないと駄目なのだ、というのが分かるようになる。
だからまあ、設計の善し悪しが分かるようになってきたら、他言語を触ってみればいい。
（分からないうちに触っても文法コレクターにしかなれず、意味無いから止めとけ）
- 429 ：デフォルトの名無しさん ：2019/12/28(土) 10:32:20.67 ID:Jn8dNYLra.net
- FormがBackgroundプロパティを持たないでどうやって背景色を指定するのかな？
再描画の際にしかBrushのGDI+オブジェクトは使用されないのだから常にBrushがGDI+リソースを持ち続ける必要がないという主張であるなら、パフォーマンスを度外視すればその通りかもしれん。
しかしBrushがGDI+リソースと一対一対応するのではなく必要なときにだけ内部的にGDI+リソースを作るような設計思想なら、
そもそもBrushのusingが一切必要ないようなアーキテクチャが十分に実現可能なんだよ。
言語をいじるまでもない簡単な話。
- 430 ：デフォルトの名無しさん ：2019/12/28(土) 11:00:39.51 ID:b3ohKRMf0.net
- 今日も知ったか君が暴れてるw
- 431 ：デフォルトの名無しさん ：2019/12/28(土) 11:09:23.84 ID:mOzjhcRm0.net
- 予防線張ることに必死過ぎて何言ってんのかわからなくなってる典型だなこりゃ
自分の発言を自分で否定しながらお花畑垂れ流してる底抜けのアホ
- 432 ：デフォルトの名無しさん ：2019/12/28(土) 11:11:57.13 ID:e/19aGJmM.net
- オブジェクト指向ではリソースは依存性として分離して注入するのが良い習慣とされる
なのでローカルスコープでいきなりリソース確保みたいなコードを書くことは稀だ
C#やJavaの世界ではリソースのライフタイムはDIコンテナが管理するものであってスタックに同期させるものではない
- 433 ：デフォルトの名無しさん ：2019/12/28(土) 11:16:46.70 ID:Jn8dNYLra.net
- >>432
彼の主張は置いといて、生成タイミングの制御のためにDIでファクトリーオブジェクトを注入するのはよくあるパターンだぞ
- 434 ：デフォルトの名無しさん ：2019/12/28(土) 11:45:36.16 ID:yuB2IAbM0.net
- cでもmallocしてりゃどこかで開放は要るだろ。
理屈すり替えて楽しいか？
- 435 ：デフォルトの名無しさん ：2019/12/28(土) 13:24:27.10 ID:6W1egYcc0.net
- >>429
> パフォーマンスを度外視すれば
GDI+オブジェクトの生成ってそんなに重いのか？
> そもそもBrushのusingが一切必要ないようなアーキテクチャが十分に実現可能なんだよ。
その通りだ。だから.NET自体がボロいんだよ。
元々はGDI+オブジェクトのリソースが限られていたから、win98までは文句を言わず俺が言っている
「使うときだけ生成、使い終わったらすぐ解放」
しかなかった。これを「面倒」と思ったのか単にボケているだけなのか、
リソースが大幅に増えたこともあって問題にもならなくなった為、掴みっぱなしも出来るようになった。
.NET自体はWin32APIを隠蔽する為の物で、これ自体は良く出来ている。
ただ、俺は、君の言うとおり、もう一枚多く隠蔽して、usingが一切不要のフレームワークにした方がいいと思うけど。
もしGDI+オブジェクト生成が問題になるほど重く、キャッシュしたいというのなら、直接自前でGDI+オブジェクトを掴む必要がある。
だから.NETは今のアーキテクチャなのだ、と捕らえることも出来るが、
実際はそうではなく、単に皮を被せただけで、その皮の厚さが不適当だっただけだと思うよ。
まあこれはすぐに修正出来る話でもあるけど。
- 436 ：デフォルトの名無しさん ：2019/12/28(土) 13:31:51.66 ID:6W1egYcc0.net
- >>432
> オブジェクト指向ではリソースは依存性として分離して注入するのが良い習慣とされる
そうだ。ただ、これがGUIとは絶望的に相性が悪いんだよ。
実際、Formsはこれで、各コントロールが値を保持してそれを参照する、というアーキテクチャだが、
事実としてこれは使いにくくて、WPFでばっさり修正されてるだろ。
(例としてはまんま>>255で、彼が253の時点でいいと思っているアーキテクチャがFormsのものだ。
だから俺は253はFormsしか知らない老害に文句を言われたのだと思っている）
一応Webは当初は（というか一応今も）Javaでもクライアントコードを書けることになっている。
ただ、JavaとJavaScriptだと書きやすさのイージーさの次元が違っていて、喧嘩にならないんだよ。
一応アプレットが遅いだの色々理由が付けられてるけど、
俺はJavaScriptの方が圧倒的に楽に書ける、というのが本質だと思うよ。
(仮に速くてもJavaは駆逐されてたと思う）
不幸なのはGUIが出てきた時の覇権言語がCであった為、
有無をいわさずGUIもCでやり、そしてそれを今でも引きずっている点だ。
そしてその後はOOPが覇権を取ったから、GUIもOOPだという事になるのだが、これがまた間違いで、
これを盛大にやらかしたのがFormsだ。
MVCのMなんて、OOP（特にJava)で禁忌とされるグローバルそのものだろ。
C系言語の変数管理そのものがGUI向きではないんだよ。
そしてOOPの変数局在化思想もOOP向きではない。結果、Formsは二重に間違いを犯してる。
- 437 ：デフォルトの名無しさん ：2019/12/28(土) 13:34:55.12 ID:6W1egYcc0.net
- >>436
最後訂正
x そしてOOPの変数局在化思想もOOP向きではない。
o そしてOOPの変数局在化思想もGUI向きではない。
まあ分かると思うけど紛らわしいので一応。
- 438 ：デフォルトの名無しさん ：2019/12/28(土) 14:09:15.47 ID:06FVqHz0a.net
- うーん、なんかさすがに「アインシュタインは間違っている！」と主張するトンデモ本作者的な主張は草不可避w
- 439 ：デフォルトの名無しさん ：2019/12/28(土) 14:31:37.94 ID:6W1egYcc0.net
- >>438
それが信者的態度だよ。
お前はC#以外の言語をいくつも知っていて、C#/.NETの良さ/悪さをちゃんと識別出来るのか？
ただしこれはC#だけではなく、どの言語スレも割とこの傾向の奴が多いのも事実だが。
ただその態度は目を曇らせるから止めた方がいい。
C#が覇権を取れておらず、今後とも取れそうにもないのにも理由があるし、
JavaScriptが糞糞言われてもやたら蔓延っているのにも理由がある。
お前が何を好きかはお前の自由だが、何故そうなっているのかが分からないようなら単なる馬鹿でしかない。
勿論馬鹿であり続けるのも君の自由だが。
> https://www.youtube.com/watch?v=Og847HVwRSI
> https://mevius.5ch.net/test/read.cgi/tech/1571315884/69
- 440 ：デフォルトの名無しさん ：2019/12/28(土) 14:54:05.52 ID:yrEHcKMIM.net
- そんなに良いものなら実装してC#チームにマージリクエスト出したら？
ここで演説しても全く時間の無駄だよ？
実装するのにスキル不足なら機能リクエストでもいい
C#はオープンソースなんだからさ
- 441 ：デフォルトの名無しさん ：2019/12/28(土) 15:20:44.51 ID:WD8h4qtV0.net
- 今でもJavaでもクライアントコードを書けることになっている、とか、どの世界の話だろう？
あと、自分は432じゃないけど、
> それが信者的態度だよ。
> お前はC#以外の言語をいくつも知っていて、C#/.NETの良さ/悪さをちゃんと識別出来るのか？
というぐらいなら、C#以外の言語使えばいいんじゃない？って思ってしまう。
実際自分はプラットフォームに合わせて、アプリケーションの使いかたに合わせて8言語ぐらいから選んで使ってるけど。
あと、C#が覇権を取れていないとは全く思わないけどな。Windowsで適当なアプリ作るなら普通みんなC#で書くんじゃないの？
UnityだってC#だし。
- 442 ：デフォルトの名無しさん ：2019/12/28(土) 16:14:20.14 ID:6W1egYcc0.net
- >>440
俺は.NETを使っているのであって、C#は使ってない。
ただ、usingをどうするかは思想の問題であって、技術的に不足しているわけではないので、提案しても通らないとは思う。
（作ってる側も知っててそうしているはず）
>>441
そう思うならそれでよし。
C#は良い言語だし健闘している方だが、Javaと食い合うなら死ぬのはC#だ。(俺はJavaが死んで欲しいのだが)
OracleはJavaを技術的に成長させることは出来なかったが、ある意味余計なこともしなかった為、
プラットフォームとしては既に膨れあがってしまった。
後はC#で成果が出た仕様を順に取り入れていけば、「C#には負けない」言語にはなる。（勝てもしないが）
同じような仕様で並立すると、死ぬのは小さい側のC#なので、当然C#は新規機能を追加して逃げ続けるしかない。
これはこれで恩恵はあり、そうこうしているうちに勢力逆転出来ればいいが、今のところその芽もないだろ。
(Unityがそうだというのならそれでいいが）
> Windowsで適当なアプリ作るなら普通みんなC#で書くんじゃないの？
俺は知らんが多分Python。大体ネット上ではブッ叩かれているが。
その動画見ても一応トップだし。
- 443 ：デフォルトの名無しさん ：2019/12/28(土) 16:38:51.11 ID:WVh0vSeH0.net
- ずーっと勝ちだの負けだのふわっふわなことこだわってるのなこのド近眼馬鹿
手前で他の言語持ち出してきて突っ込まれたら知らんから解説譲るとか逃げてるし
まさに無意味な頭でっかち文法コレクター（笑）を自ら体現してる
クスリでもキめてんのか？
- 444 ：デフォルトの名無しさん ：2019/12/28(土) 22:03:53.41 ID:WD8h4qtV0.net
- >>442
> 俺は知らんが多分Python。大体ネット上ではブッ叩かれているが。
いやいや…
実情を知らなすぎだろう？C#なら実行ファイルの入ったフォルダごと渡したら実行できるようになるけど、
Pythonだと環境を作ったりとか結構めんどくさいぞ。大体GUIを考えたらPythonとか最悪でしょ。
「お前はC#以外の言語をいくつも知っていて、C#/.NETの良さ/悪さをちゃんと識別出来るのか？ 」とか言ってる割にはトンチンカンすぎる。
一応言っとくと、C#しか書けないからこう言ってるわけじゃなくて、Pythonもガンガン使って仕事してるからね。
あと、JavaはもうほとんどSIer専用言語みたいになってるから、C#と直接比較するのもナンセンスでしょ。
スーパーコンピュータで科学技術計算する分野では今でもFORTRANが主役だけど、そこ以外で使わないだろ。それと一緒。
最強言語なんてのはない。色々なニーズに合わせて言語（プラットフォーム）を選んで何でも書けばいいんだよ。
手続き型言語だったら考え方は大して変わらないからね。
- 445 ：デフォルトの名無しさん ：2019/12/28(土) 22:29:59.46 ID:6W1egYcc0.net
- >>444
そりゃお前の現状認識がおかしいと思うぞ。
インストールすら大変なら、Pythonがここまで蔓延ることはない。
何故かよく出てくるFORTRANガーってのも、FORTRANなんて実際もう誰も使ってない（と聞いている）し、
今のFORTRANは昔のFORTRANとは別物（と聞いている）ので、FORTRANを持ち出すのもおかしい。
それはVBを持ち出してBASICがまだ使われている、と言っているに近い。（はず）
多分お前もFORTRAN信者に嘘を吹き込まれているだけだと思うが、
冷静に考えれば見抜けるはずだが、FOTRAN全盛時代の連中はもうリタイヤかその辺であって、コードなんて書いてない。
あれはスパコンのCOBOL扱いになってるはずだが。
（もしかしてベクトルはFORTRANしか受け付けないのかな？これはあり得るが）
まあいいが。
いずれにしてもお前らが何故そんなに信者化するのかはいつも疑問だ。
- 446 ：デフォルトの名無しさん ：2019/12/28(土) 22:34:45.14 ID:yuB2IAbM0.net
- 自分が作ったものだけ動かすなら楽だもの。Python。
envで環境作らないといかんくなったらめんどくさい。
お前あんまり知らねえだろ。
- 447 ：デフォルトの名無しさん ：2019/12/28(土) 23:12:31.42 ID:WD8h4qtV0.net
- >>445
開発用PCでプログラミングするだけで十分な場合と、デプロイが必要なアプリケーションを作るのは違うんだよ。
Pythonが流行ってるのはデプロイが必要なアプリケーションでなければ、かなり楽できるから。
デプロイするのは結構大変だよ。インターネット接続不可の環境でpipを使うのはめちゃくちゃ難しいし。
仕事でプログラム作ってアプリ納品したことないでしょ。その経験がなければプログラミングを語るなとは思わないけど、
納品という観点でみたらナンセンスすぎるんだよ。よくも上から目線で「お前の現状認識がおかしい」と言えるね。
あと、PythonでGUIアプリケーションを書くことに関してはスルーかな？
FORTRANの下りも、聞きかじった知識だけじゃん。
科学技術計算でよく使われるBLASっていう線形代数のライブラリがあるんだけど、githubで見る限り半分はFORTRANで書かれてるよ。
https://github.com/xianyi/OpenBLAS/
4,033 commitsとか書かれてるところの下の棒押してみ。
Fortran 49.3% Assembly 26.7% C 21.2% C++ 1.4% Makefile 0.8% CMake 0.4% Other 0.2%
って出てくるから。
あと、書かれてるコードも昔のFORTRANそのものでしかないコードだよ。
https://github.com/xianyi/OpenBLAS/blob/ce3651516f12079f3ca2418aa85b9ad571c3a391/lapack-netlib/SRC/dgebd2.f
これを今でも皆コンパイルして使ってるわけ。スパコンだけじゃなくて、PCでもね。
んで、プログラマーじゃなくて、研究者はいちいち他の言語とか覚えたくないから、今でもこういう乗りのFORTRANを使ってるわけ。
http://www.chem.konan-u.ac.jp/PCSI/DL_POLY/still_FORTRAN.pdf
どうしてろくに自分で調べもせずに聞きかじったそれっぽい言葉を信じちゃうのか。
「いずれにしてもお前が何故そんなに知ったかするのかはいつも疑問だ。」
- 448 ：デフォルトの名無しさん ：2019/12/28(土) 23:13:03.41 ID:H+9YQLdE0.net
- 自分とは違う意見=信者、と言うレッテル張り
- 449 ：デフォルトの名無しさん ：2019/12/29(日) 00:26:30.89 ID:EA/Onx+o0.net
- >>447
もう意味がないから終わりでいいが。
> インターネット接続不可の環境
今更ねえし。それがC#なら楽チン！（とも思えないが、仮にそうでも）それが売りになるとでも？
> あと、PythonでGUIアプリケーションを書くことに関してはスルーかな？
当たり前だがGUI用のツールキットも死ぬほどあったはずだよ。ググればいくらでも出てくるでしょ。
> 4,033 commitsとか書かれてるところの下の棒押してみ。
それで飛んでいった先が
> C 3950
> Fotrran 3720
なんだが。コミットが多いだけでコードの数はCの方が上だし。
それ以前に今時のML向けのCUDAやOpenCLじゃFOTRAN使えねえだろ、と思ったが、
CUDAにはFortran出てるのな。ちょっとびっくりだわ。
> これを今でも皆コンパイルして使ってるわけ。スパコンだけじゃなくて、PCでもね。
君本人がFORTRAN書いているのか？それならまあそれでいいが。
そのスライドなかなか面白かったけど、2010年代がねえだろ。そういうもんだよ。
京がCとFORTRANのユーザー割合を公開していた気がしたが、出てこないんだな。
> 研究者はいちいち他の言語とか覚えたくないから
これはその通りだけど、だからこそ、年代的にFOTRANはほぼ絶滅してて、
今時はPythonで書かせろゴラアで、NumPyだCythonだが出てきてるわけだろ。
もし君がFORTRANを実際に書いているのなら、それだから君の周りにFORTRAN使いが多いだけであって、
やっぱり君の現状認識は間違ってると思うぜ。
- 450 ：デフォルトの名無しさん ：2019/12/29(日) 00:34:45.31 ID:jh70IlFa0.net
- 結局このスレで長文垂れ流して何がしたかったのかは永遠の謎だった
- 451 ：デフォルトの名無しさん ：2019/12/29(日) 00:36:25.95 ID:EA/Onx+o0.net
- >>447
すまん、名前(TensorFlow)が出てこなかったので分かれてしまったがついでに。
GoogleのTensorFlowもPython,/C/Java,/Goであって、FORTRANは動かない。
CUDAは既に書いたようにFortranも出ているようだが、
元々はそもそも出す気もなく、ユーザーも「C++のサポートを」とは言っていたけどFORTRANについては言ってなかったと思うけど。
BLASのFORTRANをUpdateしている連中は、どこで何向けを流しているんだ？
現在のHPCはFORTRANなんて見てないと思うのだが。（上記CUDAやTensorFlowしかり）
- 452 ：デフォルトの名無しさん ：2019/12/29(日) 00:40:06.58 ID:9rgAI5qX0.net
- GUI Programming in Python
https://wiki.python.org/moin/GuiProgramming
- 453 ：デフォルトの名無しさん ：2019/12/29(日) 00:58:10.27 ID:s3t0CIvz0.net
- python製のwindowsアプリって何かある？
- 454 ：デフォルトの名無しさん ：2019/12/29(日) 01:04:54.28 ID:34CXn0hn0.net
- 凄えなGitHubの見方もまともにわからねえのかコイツ…
ここまで全方位に雑な上から目線キャラ初めて見たｗ
- 455 ：デフォルトの名無しさん ：2019/12/29(日) 01:13:01.51 ID:s3t0CIvz0.net
- 現時点でwinアプリ開発で採用される言語のトップにpythonなんか入るわけ無いと思うけど
普通にC++/C#/VB辺りじゃない？
VBは国内だけかな？
この次あたりはどれも似たようなもんでそこにpythonが入るとかならまぁわかる。
javaはwinアプリなんかで使われてるのかはわからんけど
- 456 ：デフォルトの名無しさん ：2019/12/29(日) 01:17:48.90 ID:s3t0CIvz0.net
- ある程度の知識が広く浅くあるタイプの人間で技術屋以外に対して上手く話をして言いくるめるのが得意そうな感じ
あんま知らんけどSIerってこんな感じの人間なのかな？って見える
- 457 ：デフォルトの名無しさん ：2019/12/29(日) 01:55:47.41 ID:Jtzyjysr0.net
- 言い訳と反論が得意なイメージ有るけど。
- 458 ：デフォルトの名無しさん ：2019/12/29(日) 11:03:14.73 ID:HK/YahvcM.net
- >>449
> 今更ねえし。それがC#なら楽チン！（とも思えないが、仮にそうでも）それが売りになるとでも？
いくらでもある。当然売りになる。というかセキュリティ要件で満たさなきゃいけない。
> 当たり前だがGUI用のツールキットも死ぬほどあったはずだよ。ググればいくらでも出てくるでしょ。
で、使おうとしてみたことあるの？Pythonしか書けないってんじゃなければWinFormsの方がましとすぐに気がつく。
あとgithubのグラフの読み方は間違ってる。コミット数じゃなくて、コードの総量。
> 京がCとFORTRANのユーザー割合を公開していた気がしたが、出てこないんだな。
さっきのPDFに書いてあるとおり、FORTRANが1位だよ。
- 459 ：デフォルトの名無しさん ：2019/12/29(日) 11:04:58.14 ID:HK/YahvcM.net
- >>449
> 今時はPythonで書かせろゴラアで、NumPyだCythonだが出てきてるわけだろ。
その辺は科学数値計算よりデータサイエンス系で盛り上がってるだけで、
色々余計なレイヤーがかぶさってるPythonが数値計算でnumpy、Cythonがあったとしても採用されにくいと
思うけどな。それこそメモリまわりの挙動とかで。
あと、tensorflowを例に挙げてHPCがどうこうと言ってたけど、ディープラーニングとかHPCの1ジャンルでしかないし、
ディープラーニングの分野ではFORTRANが使われてない、以上のことを示してないよ。
で、なんでそんなに他人の違う意見に対して「自分は正しい。お前の現状認識は間違ってる」と自信満々に言えるの？根拠は？
聞いてる限り聞きかじりの知識ばかりで実際に作らずに良し悪しを決めつけてるようにしか思えないんだが。
- 460 ：デフォルトの名無しさん ：2019/12/29(日) 11:46:41.74 ID:vuWWhjO70.net
- ここはC#スレだぞ
- 461 ：デフォルトの名無しさん ：2019/12/29(日) 13:00:01.09 ID:99B+H0jR0.net
- ワッチョイスレなんだから各自NGすればよろし
- 462 ：デフォルトの名無しさん ：2019/12/29(日) 13:26:29.34 ID:KIjz0jVz0.net
- 日経Linux 2020/1月号に、
米田聡の記事「AI で鳩を自動認識、ラズパイ4 で3倍速」が載っている
TensorFlow Lite を使う、Google のEdge TPU の2製品、
Coral USB Accelerator, Coral Dev Board
CUDA なら、CPU の1/50 ぐらいの時間になる
ここは、C# のスレなので、以降は他のスレで議論してください！
- 463 ：デフォルトの名無しさん ：2019/12/29(日) 14:36:52.40 ID:EA/Onx+o0.net
- >>458
概ね全面的に水掛け論だからまあもういいが、一応反論だけはしておく。
> いくらでもある。当然売りになる。というかセキュリティ要件で満たさなきゃいけない。
いや逆じゃね？ローカルにUSBメモリ刺してexe/dllを直インストールなんてセキュリティが厳しい要件で許可されるのか？
まあいいが。
> Pythonしか書けないってんじゃなければWinFormsの方がましとすぐに気がつく。
だから言ったとおり俺はPythonを使ってない。
> WinFormsの方がまし
ただ、これはない。Formsは壮絶にゴミだ。それはHTML/CSS/JavaScriptを使えばすぐ分かる。
同様にWPFもゴミだが、Formsよりは数倍ましだ。
そしてWPFがHTMLに寄せたのはMSもそっちの方が断然いいと判断したからだ。
ただ、まだCSSが当てられないのが相当痛い。だから次は丸々HTML/CSSに寄せるはず。
（というかWeb開発では事実上そうでしかないが)
そもそもPythonもそっちに動いているっぽいだろ。>>452の頭の2つ、
> Cross-Browser Frameworks
は多分それだよ。Pythonでローカルに鯖を立てて、それをブラウザで見るんだよ。(かそれに近い形式）
というか俺なら最初からそうする。
つまり計算用PythonはJSONインタフェースだけ付けて終わりで、後は全面的にHTMLの恩恵を受けられる。
HTMLの良さが分からないのは、君が知らないからでしかない。といっても別に難しいものではないから、やってみればいいんだよ。
やれば、悲しいくらいに簡単にGUIを作れて、Formsとか本当にゴミだと実感出来るようになる。
- 464 ：デフォルトの名無しさん ：2019/12/29(日) 14:37:27.40 ID:EA/Onx+o0.net
- > あとgithubのグラフの読み方は間違ってる。コミット数じゃなくて、コードの総量。
間違いは認めるとして、いずれにしてもナンセンスだからこれは止めよう。
BLASはAPIであって、当たり前だがOpenBLASは一つの実装でしかなく、
Cにもポートされているのだから当たり前のように同量のソースはあるし、
そもそもcommit回数を競ったところで意味がない。
BLASが使われるのがFORTRAN経由かC経由か、他の実装も含めての割合が問題であって、それはGitHub見てても分かりようがない。
君が示したのは、「今でもFORTRAN向けBLASの一つの実装がアップデートされている」という事実だけでしかない。
（それでも俺にとっては十分驚愕だが）
> さっきのPDFに書いてあるとおり、FORTRANが1位だよ。
本当にそうだったら「うええ、老害め」みたいに記憶に残ってるはずなんだがなあ。
と言っていても本当に水掛け論だから、こちらも調べたが出てこない。
ちなみに文部科学省のアンケートは出てきたが、これにはユーザー割合は載ってない。（ただし2006年の資料であり、相当古い）
https://www.mext.go.jp/b_menu/shingi/gijyutu/gijyutu2/022/shiryo/__icsFiles/afieldfile/2012/06/11/1321896_7.pdf
インストールされているのはFORTRAN100%、C92%なので、その当時はCが使えないスパコンってのも存在したのも事実のようだ。(P19)
> その他、スーパーコンピュータセンターからのコメントから、ＦＯＲＴＲＡＮ７７からＦｏｒｔｒａｎ９０への移行、
> あるいはＣ＋＋
への移行等、より記述性や生産性の高い言語への移行が進んできている印象を受けた。
君は移行すらしてない、という見解なんだろ。なんだかなあ。
> それこそメモリまわりの挙動とかで。
何が言いたいのか分からん。
Cのdllを呼んでるだけだぞ。C#でならunsafeでCのdllを呼んでるのと同じ。
全く問題ないし、関係ないよ。だからこれについてはC#でも何でもいいわけだが。
- 465 ：デフォルトの名無しさん ：2019/12/29(日) 14:38:02.85 ID:EA/Onx+o0.net
- > ディープラーニングとかHPCの1ジャンルでしかないし、
> ディープラーニングの分野ではFORTRANが使われてない、以上のことを示してないよ。
今寄ってたかってホットなのは明らかにここだし、これを外して何を言うんだ？
問題は、こういった新しい環境ではFORTRAN向けの環境整備なんてされてない、ってことなんだよ。
だから正確には、「新しいHPC環境ではFORTRANは使えない」だよ。
俺は君が
> スーパーコンピュータで科学技術計算する分野では今でもFORTRANが主役だけど(>>444)
という明らかな嘘を言ったことを咎めている。
「環境自体がない」んだからそんなわけがないだろ。
何も知らない若い奴らが信じてしまう可能性もあるのだから、明らかな嘘をついてミスリードするようなことはするな。
色々見解が違うのはいいとしても、これはねえよマジで。
- 466 ：デフォルトの名無しさん ：2019/12/29(日) 14:51:21.50 ID:mqdEA2UD0.net
- WPFはHTMLに寄せたんじゃねえよ。
XMLとしてvalidだろ。
- 467 ：デフォルトの名無しさん ：2019/12/29(日) 15:06:33.85 ID:EA/Onx+o0.net
- >>466
C#er的公式見解がそうなのは知ってる。
ただ、機構は丸パクしてるだろ。
HTML/CSS/sjavaScriptのよい点は
A. テキストで書くだけ。ボタンなら"<button>Click Me</button>"だけ。
B. CSSが当てられる。
C. イベントがバブルする。
D. JavaScriptから値を弄ってもイベントは発生しない。
E. イベントは非同期、つまり必ずキューイングされる。
で、WPFは（といっても俺は使ってないが）
A. はまあ許容範囲（もうちょっと簡単に書かせろよとは思うが）
B. 出来ないのが悲しい
C. 問題なし
D. E. 知らない。Formsはイベントが発生してしかも同期イベントなので地味にこれがものすごく使いにくくて糞。
直っていることを期待するが、そもそも俺はWPFを結果的にスキップしそうになってる。
だろ。AはXMLからとしても、Cはパクったろ。
そしてCは地味に素晴らしい。
といってもFormsから移行した奴らは活用してないかもしれんが。
- 468 ：456 ：2019/12/29(日) 15:10:58.86 ID:KIjz0jVz0.net
- VSCode で良い。
markdown も表示できるし
Python は、Jupyter Notebook でも良い。
Julia, Ruby でも使えるし
VSCodeは、Electron だから、Node.js + Chromium だろ。
Ruby の標準サーバーを立ててもよいし
- 469 ：デフォルトの名無しさん ：2019/12/29(日) 15:26:07.21 ID:J2Lmqp1KM.net
- >>468
ルビ糞は教祖様推奨のEmacsを使えカス
- 470 ：デフォルトの名無しさん ：2019/12/29(日) 15:26:34.81 ID:fYAoNqJEd.net
- コントロールに適用したいStyleがあるので、Generic.xaml を作成して、
App.xaml で ResourceDictionary.Merge Dictionaryしました。その中で自作のコンバータークラスを使いたくて定義したのですが、どうしても認識してくれません。ビルドは通るのですが、実行時に見つからないエラーがでます(xaml parse exeption)
同じ定義を App.xaml の中で、Generic.xamlをマージする前に書くと、何故か実行時にエラーも出ませんし、ちゃんと動きます。
Generic.xaml の中でコンバーターを定義することは出来ないのでしょうか
- 471 ：デフォルトの名無しさん ：2019/12/29(日) 15:30:19.53 ID:Lr7vQfGy0.net
- テキスト送信して相手にレンダリングさせるものと自身のウインドウ環境に直接レンダリングするものを本気で横ならびで比較する時代になったのね
- 472 ：デフォルトの名無しさん ：2019/12/29(日) 15:59:41.03 ID:EA/Onx+o0.net
- >>471
なったというか、いわゆる(短期的な)「生産性」ってのは、どうでもいいところで如何に手を抜くか、でもあるからね。
グラが勝負なら自前でレンダリングしかないが、
>>255とか俺とか、>>458もほぼ確実にそうだと思うが、
計算ソフトの初期値設定をするだけ、みたいなGUIに時間かけて凝っても意味無いんだよ。
そこは「計算」に凝るべきであって、とりあえず多少遅かろうが表示出来れば何でもいいんだよ。
というか、こういうのを分かっててお前らはC#を選んでいるんじゃないのか？
ならまあ、お前らが奇妙なほどに信者化するのも分からなくもないが。
ちなみにUnity、内部エンジンはC++で上位スクリプトだけC#か？なら確かに芽があるかもしれん。
しかしこの構成なら、じきに上位スクリプトもPythonで書かせろ、になるとも思うが。
- 473 ：デフォルトの名無しさん ：2019/12/29(日) 16:06:57.90 ID:mqdEA2UD0.net
- >>467
機構のどこが丸パクリなんだよ。
Cだけじゃねえか。
Formsでもイベントのさばき方次第だろ。全然Forms触ってねえだけじゃねえか。
で、イベントも普通はそう捌くんじゃなくて、バインディングするもんだよ。
何意味不明な事言ってんだよ。
- 474 ：デフォルトの名無しさん ：2019/12/29(日) 16:08:17.70 ID:ot6kdVlr0.net
- 語れば語るほど行毎に突っ込みどころ量産してるのが凄い…
釣りでガイジのフリやってるなら大したもんだわ
- 475 ：デフォルトの名無しさん ：2019/12/29(日) 16:11:04.28 ID:RdqvkJW90.net
- > ちなみにUnity、内部エンジンはC++で上位スクリプトだけC#か？なら確かに芽があるかもしれん。
> しかしこの構成なら、じきに上位スクリプトもPythonで書かせろ、になるとも思うが。
なんでこんな予測になるのか意味不明
unityから使用できるjavascriptが廃れた経緯があるのにまた変更なんかこないよ
ゲーム開発においてスクリプト言語が来る時代は来るかもしれんがそれはunityにはこんだろう
新しいエンジンが来たときにその時代に沿った新しい言語が採用される可能性はある
- 476 ：デフォルトの名無しさん ：2019/12/29(日) 16:14:19.03 ID:8r12tXQy0.net
- 実際にUnityで選択肢として使えたjsとpythonがC#に駆逐された経緯とか知ったらこのキチガイ脱糞しそう
- 477 ：デフォルトの名無しさん ：2019/12/29(日) 16:27:43.79 ID:EA/Onx+o0.net
- >>473
逆だろ。Bはこれからパクる、Cはパクリ、D/Eは直っていればパクリ、直ってなければ糞だ。
あとFormsはバインディングできない。（から自前でやるにはReflectionすることになり、これが糞）
ただバインディングについては、
バブルされたイベント拾ってそこでバリデーションして問題なければ反映、アウトなら戻す、
みたいな方が格好悪いが結果的に楽な気はする。
(既に言ったとおり俺自身がWPF使ってないから全てに於いてバインディングだけで上手く行くのかは分からない。
勿論全く問題ないならバインディングした方がいいけども)
>>475
>>476
おお、その釣り針は喜んで食いつくから、駆逐された経緯とか書いたページがあれば紹介してくれ。
つってもちょっと（席を）外すが。
- 478 ：デフォルトの名無しさん ：2019/12/29(日) 16:36:33.93 ID:RdqvkJW90.net
- 食いつかんで良いから自分の浅はかな知識で事を語っていることを認識し悔い改めていただきたい
知りたきゃご自身でお調べ下さい
- 479 ：デフォルトの名無しさん ：2019/12/29(日) 17:14:51.69 ID:mqdEA2UD0.net
- >>477
WPFがバインディングが基本だと言っとろうが。
FormsにもDataSourceと言う概念があって出来んもんでもないしリフレクションも必要ではない。
- 480 ：デフォルトの名無しさん ：2019/12/29(日) 18:30:55.82 ID:2GmPR76J0.net
- >>467
> B. CSSが当てられる。
> B. 出来ないのが悲しい
書くのが異様に面倒だけどスタイル定義はできるよ
てか、よく知らないならROMってれば？
- 481 ：デフォルトの名無しさん ：2019/12/29(日) 19:00:10.06 ID:EA/Onx+o0.net
- >>479
> DataSource
ああそれは確かに俺は触ってないわ。何かあったけど放置してた。
一応軽く見てみたが、ちょっと使ってみないと分からんね。
.NETは若干かっこよさを追求しすぎていて、既に言った
「フォームの値をプログラムから変更してもイベントが『同期』で発生する」
もそうだけど、格好良く自動連動を目指したのだろうけど、余計に使いにくくなってる。
同様に、余計なイベント接続が行われている可能性もあるから、実際に使えるかどうかは試してみないと分からん。
JavaScriptの場合はもっとドベタに
「プログラムから変更したらイベントは発生しないから、必要なら自分で呼べ」
でしかないから、本当にドベタにユーザーが挙動を定義出来る。
言ってしまえば、JavaScriptはライト層向けにできていて、
.NETはプロ向け（.NETのことを隅々までよく知っている前提）だと言えなくもないが、
ちょっとチューニングを失敗しているように思う。
結果、JavaScriptの方が取っつきやすいから、最近はどうでもいいUIはだいたいWebアプリになってるだろ。
>>480
これか？
https://www.atmarkit.co.jp/ait/articles/1009/07/news096_2.html
これは確かにCSSの一部だが、これでは全然足りない。
スタイルを適用したいのはコントロールそのものに、ではない。
CSSが美味しいのは、左右はもちろん上下ですら表示位置を簡単に入れ替えられること。
だから見た目全く違う物も同じHTML構造を取れ、結果、
同じ関数からお約束のHTMLを吐き出して後はCSSでも当てて、みたいな手抜きがあっさり出来る。
（見た目毎に出力関数を用意する必要がない）
CSSの表現能力についてはWeb系の馬鹿共がよく「CSSでここまで出来る！」みたいなページを作っているから見てみればいい。
- 482 ：デフォルトの名無しさん ：2019/12/29(日) 19:12:12.77 ID:RdqvkJW90.net
- 詳細を突っ込まれると
そうだね、けどこの面では…的な論理展開ばっかだけど自分で気にならないの？
これを繰り返してるうちに自身の主張が何かよくわからなくなって無意味に多方向にdisを撒き散らしてるだけになってる
- 483 ：デフォルトの名無しさん ：2019/12/29(日) 19:21:15.54 ID:2GmPR76J0.net
- >>481
> CSSが美味しいのは、左右はもちろん上下ですら表示位置を簡単に入れ替えられること。
それはコンセプトの違い
WPFはXAMLでコントロールの位置を変えればいいだけ
データとはバインディングで繋がってるから位置を変えてもDataSourceはいじる必要はない
- 484 ：デフォルトの名無しさん ：2019/12/29(日) 19:24:54.99 ID:mqdEA2UD0.net
- >>481
自動連携なんて目指してない。
変更したならイベントが起こって然るべきだからイベントが起こるんだよ。
- 485 ：デフォルトの名無しさん ：2019/12/29(日) 19:33:22.61 ID:EA/Onx+o0.net
- >>478
以下は読んだ。
https://blogs.unity3d.com/jp/2017/08/11/unityscripts-long-ride-off-into-the-sunset/
開発側の人的資源の問題と、C#のIDEが素晴らしいからだな。
まあ妥当といえば妥当。（というかそう読めるように書いてあるもんだが）
そもそもJavaScriptが動くとは知らなかったし、信者でも無いから、ダメージもないのだけど。
まあそれ以前に俺はここだからC#の話をしているだけであって、
JSはJSでそれなりに糞だから、JSスレでならJSの悪口言ってるよ。
C#のIDEが圧倒的にいいのは事実だよ。あれと同じ物を自前で用意するのは無理だ。
- 486 ：デフォルトの名無しさん ：2019/12/29(日) 19:53:49.10 ID:RdqvkJW90.net
- >>485
で、unityはそのうちpythonになるだろうという君の主張はどうなったの？
また同じ論理展開で主張が飛んでるよ？
そんなの知ったこっちゃないってのなら始めからズレた主張しないでね
- 487 ：デフォルトの名無しさん ：2019/12/29(日) 20:00:11.04 ID:EA/Onx+o0.net
- >>483
だからそれが駄目だと言ってるんだよ。
XAMLを変更＝HTMLを変更と同じで、それだと、全く同じ関数とか使えないんだよ。
XAMLを弄って変更した場合、文書階層が変わるから、バブルしてくるイベントも経路が変わってしまうだろ。
すると、イベント周りも修正が必要になってくるだろ。
CSSだけで位置変更出来れば、本当に表示位置だけを変えられる。
バブルしてくるイベントはHTML通りにバブルしてくるから、見た目重なってもいない要素からもバブルしてくるようにも出来るんだが、
それだからこそ、同じプログラムで対応出来るんだよ。
違うのは人間からの見た目だけであって、プログラム上からの見た目は同じだから。
と、説明しても意味分からんと思うけど、多分やれば分かるよ。
「こんな手抜きの仕方があるのかよ！」みたいな事が結構出来たりするから。
典型的な例だと、HTML/CSSでは display:none （表示させないだけ、Formsで言う Control.Visible = false)を多用する。
勿論上記の通りFormsでも出来るけど、文化的にほぼ使われてないでしょ。（と俺は思っている）
ここら辺の手抜きの仕方がWeb系の方がこなれてる。
俺もそうだったが、,.NET界隈も真面目にプログラミングやりすぎてるんだよ。
「常に見えない設定の物を表示ルーチンに渡すのは無駄だ」というのは当たり前だけど、
それで別関数になるくらいなら、display:noneで同じ関数使おうぜ、ということ。
CSSの表現能力が高いからこれがかなり有効なんだよ。
- 488 ：デフォルトの名無しさん ：2019/12/29(日) 20:05:42.44 ID:rG0bhEhQ0.net
- かまうほうも頭おかしいんだけど自覚ないの
- 489 ：デフォルトの名無しさん ：2019/12/29(日) 20:06:05.21 ID:EA/Onx+o0.net
- >>484
原理原則論としてはそうなのだろうけど、だから逆に使いにくくなってるんだよ。
多分これも、JavaScriptみたいに「自前でやらないと発火しない」フレームワークを使えば分かるよ。
君が既に両方使ったことがあって、
HTML/CSS/JavaScriptよりも.NETの方が使いやすいと判断しているのなら、それでいいが。
- 490 ：デフォルトの名無しさん ：2019/12/29(日) 20:06:32.69 ID:RdqvkJW90.net
- なんでxamlとhtmlの比較の典型例にformsがでてくんの？
xamlでもコントロールの非表示なんて日常茶飯事だと思うが
- 491 ：デフォルトの名無しさん ：2019/12/29(日) 20:08:02.86 ID:kYkJMpoK0.net
- cssを採用したjava fxってどうなったんだろうね？
- 492 ：デフォルトの名無しさん ：2019/12/29(日) 20:12:37.27 ID:EA/Onx+o0.net
- >>486
ん？Pythonについてなら君の言うとおり、
> ゲーム開発においてスクリプト言語が来る時代は来るかもしれんがそれはunityにはこんだろう
これについては納得したぞ。俺の負けでいい。
あのブログはもう2-3年前になるが、まあ、少なくともunityにはスクリプトは来ないね。
あれはC#と心中する、という決断だ。（逆に言えばC#は死なないとunityは判断してる）
- 493 ：デフォルトの名無しさん ：2019/12/29(日) 20:20:44.20 ID:PurJ6L2e0.net
- 差し支えなければどなたか>>470を…
- 494 ：デフォルトの名無しさん ：2019/12/29(日) 20:21:07.58 ID:2GmPR76J0.net
- >>487
> XAMLを弄って変更した場合、文書階層が変わるから、バブルしてくるイベントも経路が変わってしまうだろ。
WPFではイベントは直接使わないよ（使うこともできるけどあまりよろしくない）
モデル側でコマンドを定義してコントロールにバインドする
って言っても君にはちんぷんかんぷんかもね
まあ理解する気なさそうだから君はそのままでいいと思うよw
- 495 ：デフォルトの名無しさん ：2019/12/29(日) 20:21:43.91 ID:by75XqYfM.net
- >>492
俺は複数の分野を横断的に知ってて各方面の弱いところをよく知ってる、だからマウントとれる、
と思ってるのかもしれないけど、職業プログラマだったらそんなの実務レベルで当たり前で、
むしろある分野を専門的にやってる人には勝てないなと思ってるからそんな大げさな物言いはしないんだけどね。
（〇〇の分野だと□□という概念があるんだけど、△△だとそういう概念はある？ぐらいに控えめに話題にする）
「C#信者」、「FORTRAN信者」だの、「Web系の馬鹿共」だの、「HTMLの良さがわからないのは君が知らないからだ」だの、
「説明しても意味わからんと思うけど」だの、よくもまあ自分以外を下に見る発言が沢山出てくるもんだ。
皆、あんたが偉そうに発言する割には、中身が誰でも思いつくことでしかも間違いが多いからツッコミを入れてるだけだぞ。それを「こいつはわからないから反論してきてるんだ」と思うようじゃ単なる天狗で自分の成長につながらないよ。
このスレでたった2日やりとりしたぐらいで、経験知識不足で頓珍漢な理屈を並べてると思われちゃってるんだから。
最終的に、実世界で相手されなくなって5chに書き込むしかなくなる悲しい人生になるぞ。
> 「今でもFORTRAN向けBLASの一つの実装がアップデートされている」
正直笑ってしまった。わかってないようだがOpenBLASはFORTRANのコードをコンパイルしてCから呼び出すんだよ。
FORTRAN専用のコードじゃない。CやFORTRANで呼び出せる共通バイナリをFORTRANで書いてるの。
- 496 ：デフォルトの名無しさん ：2019/12/29(日) 20:23:58.98 ID:EA/Onx+o0.net
- >>490
そうなら第一段階は出来ていることになる。
でも本当にそうなら、もっとStyle側に押し込めればコードを減らせる＝XAMLのスタイルなんて非力すぎる、
というのも実感出来てるはずだけど。
>>491
俺についてはCSSを採用してることすら知らなかったな。
ただJavaのGUIはどうやっても死んでるだろ。
色々原因は言えると思うが、既に言ったとおり、Javaの変数管理がGUIに向いてないんだよ。
これはC#も同じで、よく騙して来れてる方だよ。
- 497 ：デフォルトの名無しさん ：2019/12/29(日) 20:25:19.89 ID:RdqvkJW90.net
- >>492
勝ちとか負けとかそんな話してないんですが…
俺が突っ込めるのは俺がわかる範囲だけだが、そういった浅い知識で何でも語る人間なら全ての話が適当なんだろうなとしか見えないね
- 498 ：デフォルトの名無しさん ：2019/12/29(日) 20:25:25.54 ID:2GmPR76J0.net
- >>490
たぶんID:EA/Onx+o0はWPFのことをFormsをXMLで記述できるようにしたもの程度の認識なんだろうと思う
- 499 ：デフォルトの名無しさん ：2019/12/29(日) 20:33:25.70 ID:EA/Onx+o0.net
- >>494
> モデル側でコマンドを定義してコントロールにバインドする
そんなことになってんのかよ。
んー、まあ何か理由はあるんだろうけど、格好良すぎて余計に分かりにくくなってる気はするが。
まあいずれにしても俺の勉強不足はそのとおり。俺はWPFはやってないし、今すぐやれる準備もしてないからね。
>>495
だからそもそもマウント取りに来ていると考えているのが間違いなんだよ。
なんで一々そんなことしないといけないんだよ。
> FORTRAN専用のコードじゃない。CやFORTRANで呼び出せる共通バイナリをFORTRANで書いてるの。
おーマジか。知らんかったわ。というかFORTRANのバイナリなんて呼び出そうともしたこと無いし。
してOpenBLAS以外はFORTRANで書かれているのか？
Cじゃねえの？という気はするし、それ以前にアセンブラで書く気はするが。（勿論Cのインラインアセンブラな）
- 500 ：デフォルトの名無しさん ：2019/12/29(日) 20:37:07.30 ID:EA/Onx+o0.net
- >>497
> 勝ちとか負けとかそんな話してないんですが…
メンドクセエ奴だな、じゃあどう言って欲しかったんだよ？
俺のことをどう見るかは君が決めることであって、俺がどうこう言っても意味無いだろ。
好きにすればいい。
- 501 ：デフォルトの名無しさん ：2019/12/29(日) 20:44:08.21 ID:RdqvkJW90.net
- >>500
適当な知識を撒き散らし嘘を広めるような言動をやめてほしかったんですよ
- 502 ：デフォルトの名無しさん ：2019/12/29(日) 20:44:40.41 ID:by75XqYfM.net
- >>499
初めの主張を否定されたら「知らんかったわ。だけどこれはどうなの？」とか言って話をずらすのは、
気付いてないのかもしれないが、マウントを取る行為そのもの。
会話をしている相手への礼儀に欠いている。
少なくともFORTRANが現状では死んだ言語だという主張は間違いなわけだ。あんたが呼び出そうとしたこともないかどうかで事実が変わる訳でもない。
やったことない領域は分からないんだと謙虚な態度で考えることがエンジニアリングにおいても人間関係においても大事。
伝聞からの外挿で精度の悪い話を吹聴しても勝てないんだよ。相手は大抵人間じゃないか自分より能力や経験値が高いから。
日常が精度の悪い話で勝てる状況なら、正直その環境を見直した方がいいと思うぞ。低レベルな環境で過ごしてて、知識や技術は身につかないのに歳だけ取るということになるからね。
エンジニアリングを生業にしてないのなら、まあ、趣味の範囲で好きに生きるといいと思うよ。
- 503 ：デフォルトの名無しさん ：2019/12/29(日) 20:52:25.70 ID:by75XqYfM.net
- >>502
マウント行為の重要なところが抜けてた。、他人を信者呼ばわりしたり、専門的にやってる人を「馬鹿共」と言ったり「分からないだろうけど」「知らないんだろうけれど」と決めつけたり、
なんの根拠もなしに他人を下に見て一方的な勝利宣言をするこれらの発言、マウント以外になんか理由があるのかい？
- 504 ：デフォルトの名無しさん ：2019/12/29(日) 20:52:59.69 ID:EA/Onx+o0.net
- >>501
嘘は広めてないだろ。
俺は俺の見解を述べてるだけで、間違いはその都度認めてるつもりだが。
俺は広報しているのではなく、会話をしているだけだ。
紛らわしいから白黒正せ、というのがあれば、一々挙げてくれたら回答するが。
既に言ったがunityにはPython(というかスクリプト)は来ないだろう、というのは君の見解の方が正しいだろう。
- 505 ：デフォルトの名無しさん ：2019/12/29(日) 21:03:21.41 ID:RdqvkJW90.net
- >>504
広めるような、ね。
知識が無いのに明言してんじゃん
知識ある人がちょっと突っ込むだけで破綻するのになんで適当なこと言ったの？
知らないなら質問するだけにするか始めから触れなきゃ良いだけなのに
俺は突っ込めんがfortranもwpfも同じ流れじゃん
突っ込めない人間から見れば真実に見えかねない
- 506 ：デフォルトの名無しさん ：2019/12/29(日) 21:08:15.64 ID:poQrkzj50.net
- ここの書き込み毎日凄いね。
ついてけね〜
C++のめんどくさいから来たから有用な書き込み求むわ。
- 507 ：デフォルトの名無しさん ：2019/12/29(日) 21:09:38.83 ID:YKlCMf1b0.net
- >>506
ここ質問スレのふらっとの隔離スレだから有用な書き込みなんか期待するのが間違い
- 508 ：デフォルトの名無しさん ：2019/12/29(日) 21:15:40.85 ID:EA/Onx+o0.net
- >>502
> 少なくともFORTRANが現状では死んだ言語だという主張は間違いなわけだ。
そんなことはない。というかマジでこれは止めろ。
現状のHPCはどう見てもAI/MLであって、そこが環境を用意していない以上、死んだも同然だ。
君はCOBOLを現役だ、と言っているに等しい。(いや、アセンブラが現役だ、の方が近いか？)
若い研究者が今からFORTRANに賭けたらいきなり死ぬんだから、こんな事を言ってはいけない。
君こそ、
> 手続き型言語だったら考え方は大して変わらないからね。
というのならさっさとCに乗り換えるべきで、今の若手にはCを強制すべきだ。
まあ君がFORTRAN使いでカチンと来ているのは分かったが、しかしさすがに今の若手に
> FORTRANが主役 (>>465)
はマジで止めろ。
というか君の発言は「FORTRAN信者」と言われても全く文句言えないレベルだと思うが。
>>503
して
> と、説明しても意味分からんと思うけど、多分やれば分かるよ。 (>>487)
は馬鹿にしてないだろ。こんな説明では説明がイマイチで分からないのは当然だけど、やれば分かる、と言っているだけだ。
まあそれ以外は馬鹿にしているのも多々あるが、それは本当に馬鹿にすべきだからだよ。
例えば、「Web系の馬鹿共」、実際に行ってCSSのページとか見てみればいい。
そこじゃねえんだよ、ってところで頑張ってて、肝心のそこだよ、ってところが抜けてるんだよ。
だから本当にWeb系は玉石混淆（といえばよく聞こえるが、ほぼゴミ）なんだよ。
これは事実だし、実際Web系は馬鹿にされまくってるだろ。PHPerとか特に。
それは馬鹿にされるだけの理由が確かにあるんだよ。(これも本当に、見れば分かるよ。
なお俺はPHPerは過小評価されすぎで、むしろJavaScripterの方が問題だと思っている）
ただし上手いところは本当に上手くCSSを使い、
え？この関数しかないの？こんなんで出来るの？スゲー、みたいな構造になってたりする。
そういうところは勿論馬鹿にしてないし、するはずもない。
要は、馬鹿だから馬鹿にする、というだけの話で、それ以上でもそれ以下でもないし、
それが俺は匿名掲示板のいいところだと思っている。
- 509 ：デフォルトの名無しさん ：2019/12/29(日) 21:23:23.75 ID:EA/Onx+o0.net
- >>505
> 突っ込めない人間から見れば真実に見えかねない
だから具体的にどれについてだ？
真実に見えかねないから全部訂正して回れ、というのなら、一々挙げろ。対応はする。
単に黙れ、というだけなら、お前が去れ。
ここは自由に意見を述べられる場所であって、それ以上でも以下でもない。
意見を自由に述べる以上、全部「正しい」なんて事にはならない。
というか、仮に全部「正しい」のであれば、そもそも議論が成立しない。
だから、俺の見解が間違っているというのなら、その意見を具体的に述べろと言っている。
そして必要なら俺は訂正する、とも言っている。
というのは>>504で述べたとおりの内容であって、お前が分からないようだから一端咀嚼したが、
無限ループするようならもう無視するから、その辺よろしく。
- 510 ：デフォルトの名無しさん ：2019/12/29(日) 21:36:21.89 ID:RdqvkJW90.net
- >>509
突っ込めない人間が居ない話題についてはどう訂正なんかするんだよって話だよ
君の無知からくる発言全てにその分野の知識ある人間からツッコミ入れさせるの？
始めから知らん内容を推測で発言すべきじゃないと言ってんの
間違ってるなら訂正してやるから教えろ
じゃなくて間違ってる可能性の高い内容を流布すんなって話
無闇に手を広げずに自分が話せる内容に留めておけ
知見を広げたいための会話ならそうなるようなレスをしろ
- 511 ：デフォルトの名無しさん ：2019/12/29(日) 21:52:09.23 ID:cgMj5yHh0.net
- もー放っておけよ
こんだけデタラメ積み重ねてりゃ内容わからん人間でも
他人をディベートごっこに巻き込んでるだけで
なにひとつ言ってることが信用できないと既に印象付いてるから大丈夫だよ
1を聞いて-10を語るキチガイ相手じゃまともな方が何も得るもの無さすぎてかわいそうだわ
- 512 ：デフォルトの名無しさん ：2019/12/29(日) 21:54:28.45 ID:axIq/xVYa.net
- これ数日前にusingウゼーとかゴネてた人？w
なんかすごい執念だね
でも結局何が言いたいんだろうw
- 513 ：デフォルトの名無しさん ：2019/12/29(日) 21:57:34.59 ID:4DsKC9Uu0.net
- 中身のない長文かけたら作文楽だったんだろうなあ
- 514 ：デフォルトの名無しさん ：2019/12/29(日) 21:59:52.09 ID:axIq/xVYa.net
- >>513
わかるw
作文教育なんてやめた方がいいねw
あんなの思ってもいないことを平気で書ける不誠実な人間を育てるだけだ
- 515 ：：2019/12/29(日) 22:20:16.44 ID:yqbBnK7b0.net
- >>514
そうそう、書くんだったら普通に英文和訳の方が力が伸びますね、そもそも嘘は書けないし
- 516 ：デフォルトの名無しさん ：2019/12/29(日) 23:12:04.78 ID:ecPco4090.net
- >>508
数値計算屋がFortranを捨てるべき３つの理由
(リンクがRock54で貼れないので、ググってくれ)
今でもこんな記事が書かれるほど、現場ではFORTRANが使われているということだろ。
自分はFORTRANはほとんど書いたことはないし、Cなんて当然のように使ってるし、人に教えるのならPythonだ。
(なぜ手続き型言語だとCなのかも謎だが)
FORTRAN使いとかいうのもお得意の決めつけなわけよ。
HPCはどう見てもAI/MLというのは、根拠がどこかにある話なのかな。よく知らないので否定しないので教えてくれ。HPCをどういう意味として使っているのかも教えてくれ。
- 517 ：デフォルトの名無しさん ：2019/12/29(日) 23:13:45.21 ID:ecPco4090.net
- >>508
「説明しても意味分からんと思うけど」
は、通常「説明しても（お前が馬鹿だから）意味が分からないと思うけど」と解釈される。馬鹿にする意図がないなら「この説明では伝わらないかもしれないが」のように書くべきだろう。
また、Web系が馬鹿にされるべき理由があろうとも、その理由が会話の内容と関係のないものなら無文脈に馬鹿にすべきじゃないだろう。
レッテル貼りして否定して回るのは紛れもないマウンティングなんだよ。
マウンティングする気がないのなら、発言の仕方に気をつけよう。端的に言ってあんたの発言は精度も態度も雑すぎて、聞き手に対して無礼極まりない。いくら内容が正しくても相手の機嫌を損ねてまともに聞いてもらえないぞ。
そんな奴は知に対して素直じゃない、とか思うかもしれないが、知に対して素直になりたいのなら、知以外の部分で余計なマイナスの修飾をすべきじゃない。
504とは違う意味になるが、「知見を広げたいための会話ならそうなるようなレスをしろ」というのはそのとおりだ。
中学生とかじゃなくてもういい大人なんだろうから、態度についてちょっとでも意見されたときに、脊髄反射的に否定するんじゃなくて、
一旦自分にそういうところは本当にあっただろうか、メタな視点で振り返ることができるようになろうよ。
それをした上で自分の行為はマウンティングじゃない、と客観的な言葉で説明できるのならそれはそれで良いからさ。
- 518 ：デフォルトの名無しさん ：2019/12/30(月) 01:03:51.03 ID:y1laSdPm0.net
- >>516
> HPCをどういう意味
HighPerformaceComputingだよ。普通に使われてる言葉だ。
> HPCはどう見てもAI/ML
むしろ今それ以外どこだと言うんだ？俺は君がここに疑問を持つことが疑問だが。
- 519 ：デフォルトの名無しさん ：2019/12/30(月) 01:04:22.43 ID:y1laSdPm0.net
- >>517
どうでもいいわ。ここはお前の日本語力の養成所ではない。
その後に「多分やれば分かるよ」と続けているのだから、
普通に読めばある程度相手の技術力に信頼を置いていることは明白だし、
仮にそれが君みたいに誤読してかってに切れられたとしてもマジで割とどうでもいい。
ついでに言うと、誤読でなく、実際に俺の人格が糞で切れていたとしても、どうでもいい。
マウンティングだと取りたければ取ればいい。
ただ、俺は君自身が「本当の議論」をしたことがないだけだと思う。
君が議論に人格を持ち込む奴なのは>>495が端的だし、それ以前から色々におわしていた。
君はリアルでもそういう議論『ごっこ』をして、反対意見を『年長者』という勢いで潰してきているのだろう。
が、そもそも俺は話者の人格なんて見てないし、興味もない。
そしていくら人格について言われても、意見を引っ込める気はない。
それとこれとは全く別だからだ。
俺はこのスタンスでずっと続けているが、繰り返すがそもそも俺は相手の人格になんて興味なく、
相手が技術的に糞だった場合はズタボロに言うものの、こちらが間違いなら普通に負けを認めてるから、
そもそも相手の技術力が高い場合にはさほど衝突しない。
だから俺はこれで全く問題ないし、ここではこのスタンスが最適だと経験的に結論づけてる。
当初は確かに俺も丁寧にやってたが、結局それだと馬鹿が図に乗るだけで収拾がつかなくなるだけだった。
馬鹿に優しいと、馬鹿にとっての楽園になってしまって、余計に馬鹿が集まる循環にしかならなかった。
だから馬鹿は叩かれるべきだし、当然俺が馬鹿だと思えば叩いて来ればいい。
そうして馬鹿はたたき出される、ということにしないと、匿名掲示板の健全さは保てない、と知った。
そしてお前らが技術的に叩けなくなったら「人格ガー」と言い出すのも理解している。
- 520 ：デフォルトの名無しさん ：2019/12/30(月) 01:05:20.88 ID:y1laSdPm0.net
- もう一度言う、「FORTRANが主流だ」(>>444)という嘘を平気でつくのは止めろ。
本当にそれは害悪だ。俺の人格云々ではなく、そっちの方が大問題だ。
これは見解の相違とかではなく、事実をねじ曲げてるレベルだからだ。
が、これ以上はどう見ても水掛け論だから、一応纏めておく。
君
・スーパーコンピュータで科学技術計算する分野では今でもFORTRANが主役(>>444)
理由はOpenBLASの実装がFORTRANで書かれているから(>>447)
俺
・FORTRANなんぞとっくに死んでる
理由は現在のHPCの主戦場であるAI/MLの中心に位置するCUDA/TensorFlow等に於いて
FORTRANはそもそもプロットフォームとして提供することすら議論されていない。
（ただしCUDAにはたまたま勝手ポートをした会社があり、それを買収して公式化されたので使えるが）
これをどちらが正しいと取るかは読者の判断だ。
技術的内容より人格だ、と思うのならそれでいいし、逆に、俺の人格は糞でも筋は通っている、と思うのも自由だ。
- 521 ：デフォルトの名無しさん ：2019/12/30(月) 01:06:18.52 ID:y1laSdPm0.net
- >>510
そもそもそのスタンスが間違ってるんだよ。
発言の自由があるということは、結果的に間違っている発言もある程度存在することを許容しないといけないし、
そもそもここは学校のように「正しい知識を教えてくれる場所」ではない。
勝手に各自が発言した内容を、自身で精査して、どれが正しそうかを君自身が掴み取らなければならない。
それに君が人格フィルターを使うのも自由だし、それ以外を使うのも自由だけど、
いずれにしても君自身が「精査」出来ないのなら、ここを使って「正しい」知識を得るのは無理だ。
俺は意図的に間違いを言っているつもりはない。
だから間違っていると思うなら突っ込んでくれればいいし、勿論ブッ叩いてくるのもありだし、放置ならそれでもいい。
ただ、「正しい発言しかするな」は「発言の自由」とは原理的に両立しないし、そもそも俺は一応「正しい」と思って発言している。
だから君の態度がナンセンスなんだよ。
あと、ここはディベートが出来る場所ではない。>>511
あくまでもパネルディスカッションであり、「この問題については俺はこう思う」以上のことは出来ない。
それで複数人から意見を聞いて、どれが正しいかを判断するのは読者自身だ。それは読者の責任であり、俺の責任ではない。
繰り返すが、俺は一応正しいと思って言っているし、同様に、間違いだと思うことには噛みついている。
それが俺の責任範囲であり、それ以上のことは出来ない。
各意見を並べた上で、どれを採るかを決めるのは、読者の判断であり、俺はそれに関与出来ない。
俺は人格者だからーみたいなことを言う気も毛頭無い。俺の発言を全て読んだ上で、君がどう判断するかは、君の自由だ。
この態度に徹しきれないのは、君たちが議論慣れしてないからだ。それは自覚した方がいい。
>>470,493
巻き込んで申し訳なかった。
ただ申し訳ないが、俺にはそれに答えられる知識がない。
タイミングが悪かったのはそちらの責任ではあるが、流し去ってしまったことについては謝っておく。
- 522 ：デフォルトの名無しさん ：2019/12/30(月) 01:20:14.54 ID:oG91u3Zf0.net
- >>521
515の2行目を読んでから514の1行目読んでみなよｗ
常に正しい情報しか発信しないが理想論でしか無いのは当然
だからといって間違った情報を流布していい免罪符にはならない
間違ってないことが望ましいしそうなるように努めるべき
君のレスはどれも適当に言いくるめようと自身に都合の良いような情報を作っているように見える
事実unityで適当こいたしwpf周りも相当怪しい
fortranは俺にはさっぱりだがこの流れなら君の意見に対する信頼度は皆無
君は自分が正しいと思っていると言うがもう少し自身のハードルをあげたほうが良い
usingの頃からあらゆる方面についてさんざんツッコミを受けているんだから
- 523 ：デフォルトの名無しさん ：2019/12/30(月) 02:05:00.30 ID:y1laSdPm0.net
- >>522
何度も言っているが、君がそう判断するならそれでいい。
ただ俺はusingについても特段間違ってないつもりだけどな。
君らが間違っていると思うのも自由だが。
一応纏めておくと、
1. usnig書け。usingを忘れるとリークする。最速。
2. usnig書け。ただし書き忘れてもFinalizerで救済する。
でもその分GCが複雑化して多少遅くなるから、要らないときにはSuppressFinalize呼んでね←今の.NET
3. using不要。ただしローカルにしか確保出来ない。最速。←俺はこれがいいと思う
4. usnig不要。メソッド内でGDI+リソースを確保/解放することにより完全に隠蔽。
確保/解放分各メソッドは遅くなるが、絶対安全ではあるのでFinalizer不要になりGCは高速化する。
結果的に速くなるか遅くなるかは未知数←423のツッコミ
俺は今でも3がいいと思うよ。ただ当たり前だが俺には決定権なんて無いから関係ないけど。
安全側に倒すのなら4だし、これも理屈的にはありだけど。
2なんて完全に泥縄的仕様で、美しくはないだろ。ただMSはこういうのも許容するところはあるが。
3はC的寿命設計が必要にはなるが、別段難しくないし、GCに慣れきってる奴でもやらせれば出来る範囲。
DIコンテナの先は知るか、でも、おそらく問題はない。
GDI+リソース周りはそのDIコンテナの先に入り、ユーザーが管理することにはならないはずだから。
4でFinalizerを外すにはfileリソース等含めて全面的にusingを撤廃する必要があり、多分すぐには無理。
各メソッドでGDI+だけ隠蔽するのは出来るが、それだと単純に遅くなるので、やるなら上記の通り足並み揃えて全面改訂だとは思う。
これでどう間違っているか言ってみ。
というか俺はお前が「俺が間違っている」ということにしたがっている理由が分からん。
俺が「全面的に間違っている」か「全面的に正しい」かで、この『人』は信じられる、この『人』は信じられない、にしたい？
ならそれは諦めろ。ここはこの『意見』は正しそう、この『意見』は間違ってそう、にしかならない。
unityについては公式見解を読む限り俺の「スクリプトが来る」予想は撤回であり、それ以上にも以下にもならんよ。
ただそれは君も分かっているとおり、unityには、でしかないよ。
- 524 ：デフォルトの名無しさん ：2019/12/30(月) 02:17:14.52 ID:y1laSdPm0.net
- >>522
> 515の2行目を読んでから514の1行目読んでみなよｗ
あ？ダブスタって話か？
なら俺は「分かり切っている嘘には噛みつく」という、君の言う
> 間違ってないことが望ましいしそうなるように努めるべき
をやってるだけだな。それでどっちが間違っているかを判断するのは君の責任だ。
さっぱりなら、「こういう事があった」ということだけ覚えていればいい。
そして後日、分かるようになったときに思い出したら、ああ、そういうことだったのか、でいい。
相手が言うことを止めることは無理だから、精々こちらは噛みつくことしか出来ない。
それで判断が保留されるのなら、それでも及第点ではある。
それが俺の精一杯だよ。
- 525 ：デフォルトの名無しさん (ｱｳｱｳｳｰ Sab5-655U)：2019/12/30(月) 02:59:24 ID:IsEWodDca.net
- >>523
割り込んで申し訳ないけどusingについては結構奇妙なこと言ってると思うよw
まず、コンピュータのリソースには希少どころか物理デバイスみたいに排他的にしか
利用できないものもあるので、解放されるタイミングをプログラマが制御できないのは困ると思うよ。
非同期メソッドがあるC#ならなおさら「メソッドのスコープを抜けたら解放」なんてそんないい加減な話困っちゃうでしょw
次に、希少なリソースを握ってるオブジェクトだからってそれを戻り値にできないような言語、
普通は使いたくないのでは？その制約はどういう利益のための代償ですか？w
こういうの「倒錯」って言うんだと思うよw
強迫神経症ともいうねw
そもそも大して冗長でもないusuingを目障りだ、という問題意識が恐らく盛大に間違っているんだと思うけどw
- 526 ：デフォルトの名無しさん ：2019/12/30(月) 05:35:58.11 ID:TxCLIlob0.net
- Qiitaでやれ
- 527 ：デフォルトの名無しさん ：2019/12/30(月) 07:15:03.12 ID:tsk9MmEe0.net
- >>518
AI/MLはHPC分野で新たにシェアが伸びた分野ではあると思うが、
今までの数値シミュレーションだって当然需要がなくなるわけもなく、HPC分野の大きな一ジャンルだろう。
"High Performance Computing (HPC) on Azure"というページをググって見てくれ。AI/MLとは別に項目になっているのだから、
AI/MLに食われるような存在ではないということだろう。
そして、根拠を示してくれと言ったのだがそこはスルーなのな。
その根拠を示さない限りは、
>>520の言説の仮定の一つとなっている、「HPCは科学技術計算ではなくAI/MLである」の正しさが検証できず、
HPCでFORTRANなんか使われてない、は示せない。AI/MLではFORTRANなんか使われてない、としか言ってないだろう。
事実を捻じ曲げている、というのなら、明確な根拠をどうぞ。
>>519
あんたの大層な論の細部がめちゃくちゃだからツッコミを入れると、「信者」だの「知らないだけ」だの言って
ズレた反応を示しながら相手の発言と自分の知識の間違ったところのすり合わせをしないから「人格に問題がある」って言ってるんだよ。
端的に言うと、「馬鹿って言ってるけどお前のほうが〇〇の理由で馬鹿だぞ」と言われたときに、「〇〇は果たして間違っていただろうか？」と考えず、
「いや、やっぱりお前のほうが馬鹿」ってのを繰り返してるんだよ。思い込みを指摘されて、根拠はあるの？と言われてもまだ思い込みで返してくる。
少なくとも調べなおそうよ。
もう、技術的にあんたの経験不足、知識不足を指摘するのは諦めてるんだけど、あんたは人を馬鹿にできるほど経験も知識もない。
WindowsのGUIアプリはなんでもかんでもブラウザベースでOK、とか、インターネットにつながってない環境は考慮する必要ない、とか、
そりゃそういう世界もあって良いけど、そうじゃない世界もあって、そこでは通用しない考え方なんだよ。
自分の考えが通用しないからって、「そんな世界はない」と言ってるようだけれども、事実そんな世界はあるんだよ。
仕事でそんな世界にアプリを納品する必要があったら、ブラウザベースじゃないGUIアプリを作るとか、
インターネットに繋がってなくても当然のように使える開発プラットフォームを使うとか、別の方法をとるまでだ。
ちなみにSIerではないからね。設計から実装まで任されててもたまにそういうところはある。
そんなときにあんただったらどうするんだい？「こんな馬鹿な環境では仕事してらんないから辞めてやる！」のか？
- 528 ：デフォルトの名無しさん ：2019/12/30(月) 09:16:55.19 ID:bS1/9EJkM.net
- 年末に何やってんだ君たち暇なの？
家族や友人とは交流しないの？
- 529 ：デフォルトの名無しさん ：2019/12/30(月) 09:58:05.51 ID:EEF4A29R0.net
- 中途半端な知識で何とか丸め込もう、話を付け替えて何とかしようとするから長文になる
わかってる人は、核心付くだけで済むから短文で済む
長くコンピュータに関わってたら、それぞれ皆わかってる程度の内容を書き連ねて暇だね〜
えっ！？ 君園児？ それなら凄いわ
- 530 ：デフォルトの名無しさん ：2019/12/30(月) 10:14:08.57 ID:enwINxmVa.net
- 何でもブラウザでできる時代になる論は20年前にも10年前にあったw
これ数年前にも書いたけど、そういうドリーマーにGMailやOutllook.comのUIが
どう見えているのか興味はあるねw
何年たってもどっか使いづらいままだよねw
UIの使い辛さ以上の利便性があるから使われているだけのことで
- 531 ：デフォルトの名無しさん ：2019/12/30(月) 10:31:39.03 ID:duSdEw3c0.net
- outlookのWebUIは最近の365だと割とまともじゃないか？
使えない機能が多いのは確かに考えもんだけど。
- 532 ：デフォルトの名無しさん ：2019/12/30(月) 10:36:33.41 ID:5236BLqUa.net
- 今のOutlookのUIってクライアント版もかなりWeb寄りになってるから、その気になればWebベースでも十分再現できそう
プログラマにとって最も馴染みの深いツールの一つであるテキストエディタがVSCodeでWebベースになった時点で、もう言い訳はきかんよ
- 533 ：デフォルトの名無しさん ：2019/12/30(月) 17:39:30.58 ID:sCWLu8Vm0.net
- using はユージングって読む人が多いけど、ついウシングって読んでしまう。VBのときのストラコンブとかと同じような感覚で
- 534 ：デフォルトの名無しさん ：2019/12/30(月) 17:49:06.40 ID:ATxCdpD+0.net
- その読み方はした事ないけど自分の中で使っちゃうやつってのはあるね
charは脳内だといつもチャー読みだわ
- 535 ：デフォルトの名無しさん ：2019/12/30(月) 19:59:49.22 ID:87J66wvt0.net
- 気絶するほど悩ましいな
- 536 ：デフォルトの名無しさん ：2019/12/30(月) 20:29:05.94 ID:5ZlpxjqAd.net
- char は敢えてシャアと読むべきだね
https://marycore.jp/programmer/char-aznable-type/
- 537 ：デフォルトの名無しさん ：2019/12/30(月) 20:43:25.72 ID:y1laSdPm0.net
- >>527
いやもうお前はいいよ。
前半はどういう論理でどう白黒つけたいのかさっぱり分からんし、後半は要するに俺への文句だろ。
君の中では俺は糞という結論が出ているのだし、それでいい。
それを周りの人がどう取るかも含めて読者の自由だ。
俺は技術論しかする気ないんだよ。
一応OpenBLAS見てみたんだが、やっぱFORTRANが生きているとは言い難いぞ。
アーキ毎に高速化されてる奴はkernelの中に入っているが、アセンブラとCしかない。
高速化されてない奴は確かにFORTRANの実装を呼んでるっぽいので、
実際に呼ばれるFORTRAN/C/アセンブラの割合がどれくらいかと、
最近他にFORTRANで改訂された物がどれくらいあるかだね。
つってもBLASの作りだと、単なる(FORTRANで書かれた）アセンブラライブラリでしかない。
現役だというのならまずその上位コードがFORTRANで書かれてないといけない。
- 538 ：デフォルトの名無しさん ：2019/12/30(月) 20:43:49.47 ID:y1laSdPm0.net
- なお論調がまた勘違いして読み間違っているようだからもう一度はっきり言っておくと、
俺は君の意見なんて全く認めてないし、FORTRANは死んでると今も認識してる。
そしてお前は本当に議論が出来ないようだが、お前が今やるべきは、
A. 俺の『意見』を否定することにより、俺の『意見』を無効化する
B. 俺の『人格』を否定することにより、ここの人格重視の馬鹿C#er共と一緒に喚き立てて俺の発言全てを無効化したことにする
ではなくて、
C. 君の意見を補強する材料を提示して、俺の意見を木っ端微塵にする
なんだよ。お前みたいな議論が出来ない馬鹿はAやBにこだわるのが常だけど、
それだと、-1が0にしかならず、結果、その議論は何も得る物が無く、結論も出ない。
そうではなく、やるべきはCであって、+10とかぶっちぎってしまうことであり、
それが出来れば俺が-20とか出さないと勝てなくなるんだよ。
議論は足の引っ張り合いではなく、突っ張りあいをやるべきなんだよ。
お前は最新のプラットフォームで相手にもされてないのがどれだけのことなのか理解出来ないのか？
そしてこれを越える材料を持って来いと言ってるんだよ。
なおお前が実際にFORTRANでスパコン使いまくってる、というのなら俺にブチ切れるのも分かるが、
そうでないと言うのだから、ここにこだわる理由も分からんがな。
そして材料が無いなら、蒸し返そうが何しようがそれ以上話は進みようがないだろ。
「FORTRANが主役」「FORTRANはもう死んでる」で読者に判断を委ねるで済ませられない理由は？
> 別に項目になっているのだから、
> AI/MLに食われるような存在ではないということだろう。
お前はそもそも「スパコン」が何か理解出来てないようだが、何故ここまでこだわる？
- 539 ：：2019/12/30(月) 20:47:34.21 ID:tdJlCQBf0.net
- 「FORTRAN」「求人」でたくさん引っかかるのですが
本当に FORTRAN は死んだのでしょうか？
- 540 ：デフォルトの名無しさん ：2019/12/30(月) 20:57:59.29 ID:y1laSdPm0.net
- >>539
お前にレスするのは不本意だが、なかなか良いツッコミだ。
が、俺は
> あれはスパコンのCOBOL扱いになってるはずだが。
> （もしかしてベクトルはFORTRANしか受け付けないのかな？これはあり得るが） (>>445)
と既に言ってるだろ。
COBOLなら求人があるのは分かるよな？そういうことだ。
http://labs.timedia.co.jp/2017/06/gnufortran.html
- 541 ：デフォルトの名無しさん ：2019/12/30(月) 21:35:10.50 ID:EmtYQ5a60.net
- 最新、トップシェア以外のものは死んでるという前提の理論はいらん
- 542 ：デフォルトの名無しさん ：2019/12/30(月) 21:44:50.82 ID:XBOZEUQCp.net
- いやスパコン言ってるなら既に出されてる京のpdfを否定する資料をまず出せば？
相手にされてないってものCUDA Fortranで自分で否定してるし
なんか対等にやりあってる風を装ってるけど
既に木っ端微塵されたところから全然建て直しできてねえぞ？
- 543 ：デフォルトの名無しさん ：2019/12/30(月) 22:05:30.33 ID:uKQ1L5j80.net
- >>533
ウンチングが正解
これ以外で読んだやつを信用してはならない
- 544 ：デフォルトの名無しさん ：2019/12/30(月) 22:13:55.24 ID:y1laSdPm0.net
- まあFORTRANの話はいずれにしてもスレチだし、俺も終わりでいい。
ただお前らが思っている世界とスパコン界隈は全然状況が違うが、
それにしても興味もないだろうし、お前らに俺が間違っているとされても俺は問題ないので。
ただ、俺の話を少しでも信じる気があれば、
「FORTRANなんて既に死んでる」と言っていた奴が居たことを頭に留めておいて欲しい。
そしてもしなにか機会が発生したら、その時に俺が言っていたことを吟味してくれればいい。
それだけで、だいぶ違うはずだから。
- 545 ：デフォルトの名無しさん ：2019/12/30(月) 22:16:46.91 ID:y1laSdPm0.net
- >>525
そう思うならそれでよし。
君は今の.NETの実装、つまり俺の纏めた 2 が妥当だと思ってるんだろ？
ならそう言えばいいだけ。
余分な人格評価とかすると（一般的には)君の評判自体も落ちると思うぜ。
そこも含めて自由にすればいいとも思うが。
> そもそも大して冗長でもないusuingを目障りだ、という問題意識が恐らく盛大に間違っている
これはちょっと違ってな、というか俺も以前は今の君のように何も考えずに「書くものだ」で書いてたんだけど、
それだと「書ける人」にしかならないんだよ。
ただの1行、ただの1ステートメントですら、
「本当にこれ必要なのか？無くすことは出来ないのか？」と考えないと、本当に余分のないコードにはならない。
ジョブスがやってた、「ボタンは一つにしろ」と同じだよ。
コードは、書くよりも、削る方が難しいし、削るときに腕前は上達する。
というのは以下のどこかにあったはずだが、出てこない。が、まあ、実感としてこれは当たってる。
https://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/
ググってたら出てきたからついでに
何事においても、完璧に到達するのは、 付け加えるものが何もなくなったときではなく、 削るものが何もなくなったときである。 （アントワーヌ・ド・サン＝テグジュペリ）
- 546 ：デフォルトの名無しさん ：2019/12/30(月) 22:21:24.79 ID:y1laSdPm0.net
- >>530
どっちが優れていたとしても、優れていた方がパクられて、最終的に同じUIになるのは確実だろ。
区別する意味ないと思うが。
ただ俺が言っているのは、君が勝手に想像しているそれではない。
俺は単に、
・HTMLの方がUIが作りやすい
と言っている。
例えば00年代初頭にはJavaでクライアントアプリを作って配布することもあった(と聞く)勤怠アプリ、
今ではWebアプリ一択だろ。これには、君らは
1. デプロイの手間がない
2. 鯖にデータが勝手に溜まる
だけだと思っているのだろうけど、俺は、
3. GUIを作るのが楽
がでかいと思っている。
そしてそれがデスクトップに出てきたのがelectronだ。当然1,2の利点はなく、3だけで勝負してる。
ならなんでUIが糞なのさ、というのは言ってしまえばWeb系のデザイナのセンスが糞だからだろ。
フラットデザインが糞なのは、マルチデバイス優先で手抜きされてるからのようだが。
> しかし、もっとも大きな理由は「マルチデバイスへの対応に最適だから」と言えます。
https://webbu.jp/flatdesign-2762
- 547 ：デフォルトの名無しさん ：2019/12/30(月) 22:44:33.73 ID:XBOZEUQCp.net
- 散々中立ぶっててこの未練がましさはさすがに草
無能さをさも自分がニュートラルであると振る舞って誤魔化す手合いだな
もうちっとまともな化けの皮を被れ
- 548 ：デフォルトの名無しさん ：2019/12/30(月) 23:05:34.31 ID:EEF4A29R0.net
- コンピュータ関係者向けの漫談ぶっこんで、盛大に白けて終わったな
- 549 ：デフォルトの名無しさん ：2019/12/30(月) 23:16:18.62 ID:y1laSdPm0.net
- >>547
メンドクセエ奴だな。
TensorFlowは既に言ったろ。>>451
ついでにTPUも確認してみた。>>462
TensorFlow: Python,/C/Java,/Go
TPU: Python/JavaScript/C++/Java/Go/Swift、これらは公式サポート
C#/Haskell/Julia/Ruby/Rust/Scala、これらはコミュニティサポート
喜べ、C#はTPUを使える。TensorFlowSharpとTensorFlow.NETだとさ。
https://www.tensorflow.org/versions/r1.14/api_docs/
- 550 ：デフォルトの名無しさん ：2019/12/30(月) 23:20:33.54 ID:CqEb/nEc0.net
- ヤーッホーフォートランランラン
ヤーッホーフォートランランラン
て歌ってたな。
30年前だけど。
- 551 ：デフォルトの名無しさん ：2019/12/30(月) 23:50:47.66 ID:XBOZEUQCp.net
- やっぱり終わらない笑
そしてまた持論の範囲を狭めて説得力ごと削ってゆくスタイルはもはや芸人である
- 552 ：デフォルトの名無しさん ：2019/12/31(火) 02:01:20.46 ID:YC1setdFM.net
- ガイジの群れ
- 553 ：デフォルトの名無しさん ：2019/12/31(火) 02:52:44.77 ID:R+4lw4Fp0.net
- おまえらいい加減にしないとpythonいっちゃうぞ？
- 554 ：：2019/12/31(火) 15:54:10.80 ID:uegmaB/s0.net
- >>540
褒めていただき光栄です！
＞お前にレスするのは不本意だが、
そういわずに、私もよいコメントを出そうと常に思っていますので今後ともよろしくお願いいたします
- 555 ：デフォルトの名無しさん ：2019/12/31(火) 19:20:27.09 ID:uqnsAvu+0.net
- >>530
補足。
WPFは糞だが、これは『現在の』HTMLと比べるからであって、
WPFが登場/仕様検討された頃のHTMLと比べればましだと思うよ。
だからMSが間違ったとか技術不足ではなくて、単に、進化の速度が遅いだけ。
それはMSも分かっていて.NETもアーリーリリースに切り替えたけど、それにはお前らは不満たらたらなんだろ？
なおWebの状況は「仕様に採用された！やったぜ！」とか騒いでいたから
（数ヶ月後に）使おうと思ったら未実装で使えないとか、
或いは新規機能もバグってて使い物にならないとか、普通にある。たぶん.NETの方がまだましなんじゃないかな。
ただ、何だかんだで仕様が決まってさえすれば次第に実装はされるから、結果的な進化速度は早くなる。
おかげでWeb系は「この機能は使っていい、これは駄目」みたいな全く無駄な努力を常に強いられる糞環境なものも事実だけど。
でもこの構造だと一度抜かされたら二度と追いつけないんだよ。で、今もうそうなってると思うよ。
そしてWeb系もそんなに勤勉なわけでもないから、WPFを勉強してまでデスクトップアプリを作ろうとはしない。
それは君らがHTMLを勉強してまでWebアプリを作ろうとはしないのと同じように。
だから結果的に分断されていたわけだが、垣根はなくなりつつあるし、そこまで余裕かませる理由が分からんけどね。
C#でちゃんと『プログラミングが出来る』のなら、JavaScriptの修得自体は容易なのは事実だけど、
『.NETを知っているだけ』ならほぼゼロからやり直しだよ。
とはいえ個人的には、既に言ったがPHPerは馬鹿にされすぎてるが実はそこそこ実力はあり、
調子に乗りすぎてるのはJavaScripterで「お前らがやってるのはプログラミングではなく塗り絵だ」のレベルが多いから、
C#erが大量流入して皆殺しにして欲しいのだけど。
- 556 ：デフォルトの名無しさん ：2019/12/31(火) 19:21:12.67 ID:uqnsAvu+0.net
- ただ逆に言えば、そんな馬鹿ばっかでも何とかなってしまうのがWeb系『フレームワーク』の実力で、
それは構造的に三層WebでMVC縛りだとか、
CSSの自由度が高くてVとCもほぼ分離出来るとか、
元々GUI向きなJavaScriptを使っているとか、そういうところなんだよ。(これらは既に言ったが)
最後のところはC#を使っている限り埋まらない。
今まで規模が3倍強のJavaに飲み込まれず、むしろ善戦してること自体が驚異的ではあるのだけど、
JavaScriptとは「異種格闘技」を強いられてしまうし、HTMLフレームワークは実はPHP+JavaScriptで4倍規模だから、
それも跳ね返していけるか、となると、正直きついだろうというのが俺の予想だね。
Web系なんてC#やJavaで「ちゃんと」設計出来てる人から見たら全てゴミだけど、
そのゴミでも何とかなっているというのがミソで、
MSはちょっと技術力が高すぎて、ユーザーに精度（技術力）を求めすぎているんだよ。
フレームワークを細かく整備していけば、勿論最終的な生産性は上がるのだけど、
当たり前だがそのフレームワークについて正確に知っていること,、正しく使うこと、という精度を要求してしまう。
結果、デタラメに仕様追加され、デタラメなコードになっていたときの劣化具合が余計に激しくなってしまう。
そこはMSが想定する「常識レベル」の技術者なら上手くリファクタ出来るレベルに留めているはずなのだけど、
それが(MS自体に馬鹿が少ないから）結果的に高めになってる。
ここら辺のズレが致命傷になると思う。(要は、.NETはニワカが使うには難しすぎる）
逆にWeb系は「生き残ってる物が正義」みたいな状況になってるから、結果的にずれることがない。
PHPなんて中級者に成りたて＝とりあえず一通りは出来るようになった！
みたいな馬鹿が書いたような仕様ばかりなので、いらつくしムカつくんだけど、
当然だが、そのレベルの人達にはそれが本当に心地よいんだよ。
だからそのレベルホイホイになっているところはあって、結果的に新規参入者が絶えない。
これも広い意味で言えばPHPの実力なんだよ。
ただし言語としてはかなり最悪の部類であるのも事実だが。
- 557 ：デフォルトの名無しさん ：2019/12/31(火) 19:40:51.62 ID:uqnsAvu+0.net
- >>554
君は多分狙いすぎてるんだよ。
投稿自体の切れ味は割といいと思うんだけど、『常に』ムカつくタイミングで出てくるから、
イラッとするし、そういうことを狙っている（そういうことしかしない）のだと取られてしまう。
また、大体は議論が紛糾している時であって、
レス付けたら余計に話がおかしくなるから無視するしかない、
みたいなタイミングで『しか』出て来ないのもどうにかしろとは思うよ。
話をしたいのなら、普通に話に混ざった方がいい。
いや俺はツッコミ専門だ、話なんてする気無い、というのならそれも自由だが、それだと今後とも嫌われると思うよ。
ただ俺は君の空気を読まないスタンスは素晴らしいと思う。
そもそもここではネットならではの議論をすべきであって、それは
「ここで突っ込んだら相手の面子丸つぶれだな…でも明らかに間違いだしな…」みたいなところで躊躇する必要がまるでないことであって、
馬鹿がよくやってる罵倒合戦ではないんだよ。
君はこれは完全に出来てて議論慣れしてるところはいいと思うよ。
ただ繰り返すが、話をする気があるのなら、出てくるタイミングが酷すぎる。
- 558 ：デフォルトの名無しさん ：2019/12/31(火) 21:01:44.58 ID:3He7PpF20.net
- 長ったらしい説明は要点がボケる傾向にある。
- 559 ：デフォルトの名無しさん ：2019/12/31(火) 21:07:56.98 ID:KGMG1qTB0.net
- もうあんたら、学歴ジャンケンでどっちが頭がいいのか決着をつけたらどうだ？
それかQiitaに行けよ
- 560 ：デフォルトの名無しさん ：2019/12/31(火) 21:25:28.17 ID:YPeginhU0.net
- 長文連投キチガイの法則はデスノートなみに正確だということ
- 561 ：デフォルトの名無しさん ：2019/12/31(火) 23:51:30.11 ID:uRSSI5660.net
- 今年最後にあぼーんで埋まってゆく…
- 562 ：デフォルトの名無しさん ：2020/01/01(水) 00:38:31.16 ID:NLfsRE4W0.net
- そういえば、なぜJavaScriptに初心者が魅了されるのかというと、
コンパイラがなくてもすぐに始められるために、初めて触る言語が
それであることが多く、それに慣れてしまっているからではないかと思う。
しかし、Promise(とasync)の辺りとか、イベントのキャプチャーフレーズ、
ターゲットフレーズ、バブリングフェーズの違いや preventDefault や
stopPropagation を正しく理解するのはかなり難しい。
PromiseとResponceに、ServiceWorkerと responseWith、waitUntil
などの辺りなどは、ちゃんとした仕様が書いてあるサイトを見つけるのすら
難しい。
- 563 ：デフォルトの名無しさん ：2020/01/01(水) 00:43:43.30 ID:NLfsRE4W0.net
- >>555
なぜ、HTMLアプリが増大しているかの理由については以下も参考になる。
OSとみなした場合に、WindowsやAndoridに比べてシェアが圧倒的に大きいからと考えられるそうだ：
【Wasm】ブラウザをOSとみなすとシェアはTOP
https://medaka.5ch.net/test/read.cgi/prog/1576520355/
- 564 ：デフォルトの名無しさん ：2020/01/01(水) 13:50:13.63 ID:6pvjYbyn0.net
- >>562
それもあるが、敷居が低いのは「インタプリタがある」からだよ。PHPもこれがデカい。
C#もあるにはあるようだけど、構造的に本物と全く同一動作というわけには行かないだろうから、ここも本質的に敷居が高くなってる。
https://ufcpp.net/study/csharp/cheatsheet/apscripting/
だたまあ、ある程度慣れれば「インタプリタでのデバッグなんて効率悪すぎ」で使わないのも事実だが。
この意味だとC#やJavaはプロ仕様で、いわゆるスクリプト言語は「アマ向け」なんだけど、
国民総プログラマ時代（俺はこれには大反対だけど）には敷居が低い言語の方が向いているんだよ。
JavaScriptは以前は環境が要らない、というのが大きかったけど、
スマホだと開発者ツールがついてないから以前のようにF12を押すだけ、とは行かない。
一応C#はコンパイラはWindows同梱だし(csc.exe)、ここについては形式的には完了してる。
ただ、HTMLは見た目のインパクトが大きい。例えば、
<img src="xxxx" style="position:fixed">
だけで画像がポップアップする。これは俺には「たったこれだけ？」と衝撃だった。
同様に、他言語/環境から入ったらその簡単さに衝撃を受ける。それくらい簡単さが違う。
- 565 ：デフォルトの名無しさん ：2020/01/01(水) 13:50:36.93 ID:6pvjYbyn0.net
- Promiseは俺に言わせれば完全な糞仕様で、あれは入れるべきではなかった。
C#でasync/awaitだけで問題ないのが分かっていたのに、止めることも出来ず、
今でも「あれがないとasyncが理解出来ない(ｷﾘｯ」と嘯いて正当化してるわけだが。
JavaScriptは本当に仕様委員会自体が糞で、仕様に政治を持ち込んだりもしてる。（httpSでしか使えない新仕様とかある）
完全に自殺中だ、というのが俺の見方だ。
ただそもそもPromise自体は「非同期を無理に同期的に組む」時に必要なものであって、組み方で回避出来る。
JavaScripterは非同期を極めているつもりの奴が多いが、
JSのは上手く色々省けるようにした「なんちゃって非同期」でしかなく、（これ自体は素晴らしいことだし、大成功だが）
連中はガチの非同期を知らないから、ここら辺を何度説明しても理解出来ない。
まあいずれにしても、ヘルズバーグも「でもPromiseはねーわ」だったし、俺はC#の判断の方が断然正しいと思う。
イベントバブルについては、理解すること自体は簡単だが、
それを上手く利用した構造を作ることは「ちゃんと設計する能力」が必要になる。（そんなに難しくもないと思うが、慣れは必要）
ただ、そこを何も考えない作りの時に威力を発揮するのがjQueryであり、
要はForms同様各GUIコンポーネントにイベントを一々付けていくわけであるが、
これをやってて、そしてまた、それでも問題ない事が多いのもまた事実だよ。
なおこれはWebページのみならず、一般のGUIもそう。
だから.NETはちょっと格好いいところを目指しすぎてて敷居が上がっている、とは思う。
といってもこれはWPFでも技術的には出来ることではあるから、コミュニティ的なもの、
つまりいまだにjQueryみたいな糞を使っていても大して文句を言われない、というところの違いかも。
JavaScriptは一部から生理的に拒絶されていたりするのでelectronも直接の驚異にはならないかもしれない。
パンドラの箱が開くのは、PythonがJS並の速度を持ったときだとは思う。
- 566 ：デフォルトの名無しさん ：2020/01/01(水) 20:06:48.58 ID:qG+Zau3f0.net
- >>470
コンバーターって、ValueConverterのことだよね？
StaticResourceとして定義すれば行けるはずだけど。
xamlを貼ってみると、回答しやすいんではないかな。みんな。
- 567 ：デフォルトの名無しさん ：2020/01/02(木) 12:00:38.14 ID:TpBXcd1kM.net
- >>565
無茶苦茶だな
C#のasync/awaitはTaskがベースでpromiseとほぼ同じだ
そしてJavaScriptにもMS主導でasync/awaitが導入済み
- 568 ：デフォルトの名無しさん ：2020/01/02(木) 19:11:21.24 ID:FzsUW8F+0.net
- >>567
そりゃTaskも最早ゴミだからだよ。
実際「asyncと書いておけば、後は小さいオッサンが何とかしてくれる」程度の理解で問題ないように出来てるだろ。
C#1.0からasyncだったら神だったろうよ。
そして俺はお前らの「今はもう要らない」仕様についても崇拝を続ける姿勢を信者だと揶揄してるんだよ。
ただJavaSriptのasync/awaitはMS主導なのか？だったらPromiseにこだわるのは政治か。
JavaScriptの仕様委員会は本当にどうしようもないな。
- 569 ：デフォルトの名無しさん ：2020/01/02(木) 19:24:07.49 ID:TpBXcd1kM.net
- >>568
アホか
C#のasync/awaitがTaskのシンタックスシュガーであるのと同様に、
JavaScriptのasync/awaitもPromiseのシンタックスシュガーに他ならない
そして、あなたが敵視している「JavaScriptの仕様委員会」において仕様策定をリードしているのは紛れもなくMSであり、
あなたの敬愛するヘルスバーグもいわばJavaScriptのパイロット版ともいえるTypeScriptの開発を通じて関わっている
- 570 ：デフォルトの名無しさん ：2020/01/02(木) 19:34:18.12 ID:haQBNDzzM.net
- 古い技術より新しい技術のほうが優れてるから最初からそっちだったらいいのに、なんて言うのは誰でもできるわな
それと非同期処理はasync/awaitが覇権を握ったけど並列処理でまだまだTaskが現役だぞ
- 571 ：デフォルトの名無しさん ：2020/01/02(木) 19:52:10.23 ID:9KDR5rd70.net
- Taskイラネって、WaitAllみたいなユースケースは頭にないんだろうな
障害児はプログラミングなんかしなくていいんだぜ
迷惑だからな
新海面処分場に自主的に向かってくれや生ゴミ
- 572 ：デフォルトの名無しさん ：2020/01/02(木) 20:25:41.97 ID:HeIctSc70.net
- >>566
ありがとう。いま帰省してて手元にコード書ける環境がないので、戻ったら再度やってみるよ
流石にアイフォーンでxaml書くのはしんどいす
- 573 ：デフォルトの名無しさん ：2020/01/02(木) 20:32:51.61 ID:cbHiY2pH0.net
- プログラミングしてないから、Taskが必要なケースも知らないんじゃない？
- 574 ：デフォルトの名無しさん ：2020/01/02(木) 20:58:20.51 ID:FzsUW8F+0.net
- >>569
そりゃお前のスタンスがおかしい。敵視とかそういう問題ではない。
俺はゴミをゴミだと言ってるだけ。いい仕様を制定出来てれば褒めてるよ。
逆にお前らはポジショントークしかしてないだろ。
つまりC#を使ってるから（どんな糞仕様であっても）C#は素晴らしい、でしかない。それを信者だと言ってるんだよ。
比較的C#はマシなのは事実だが、全部素晴らしいわけもない。
>>571
それもPromise擁護のお約束だが、
asyncで済む場合にほぼ全員がasyncを選択する時点でPromiseはゴミでしかないよ。
だからPromiseにはそれ以外の機能もあるもん！というわけだが、
実際Promiseが無くても書けるし、難しくもないし、必要な時もそうないだろ。
○と○をくっつけたらチョー便利！なんてのはよく初心者がやってるが、それと同レベルだよ。
- 575 ：デフォルトの名無しさん ：2020/01/02(木) 20:58:47.18 ID:FzsUW8F+0.net
- >>570
その通りだ。だから俺の方がヘルスバーグより賢いなんて言う気もないし、実際言ってもないだろ。
ただ、だからといって、古い技術の方がよかった、なんて事にもならないんだよ。
ゴミはゴミだと正しく認識するべき。
> 並列処理
元々の問題はC#が即時関数（ラムダ）を軽視してたことだろう。
とはいえC#は対応も他言語(C++/Java)と比べて早かったのも事実だが。
確かに並列に関しては今後とも残るかもしれん。
ただC#がTaskを用意したのは「UIコンポーネントはUIスレッドで」という.NETフレームワークの思想の為であり、
俺はこれがそもそも疑問なんだがな。GUIはタスクランチャーだと割り切り、
・GUIからの呼び出しは「新規スレッド」か「UIスレッド」か選べるようにする。
・UIコンポーネントはどのスレッドからでもいじれるようにする。
・そこで競合するなら自前で同期化機構を書け
でよかったと思うし、実際これで当初「Task素晴らしい！」みたいなことを言われていたのは大体解決出来るだろ。
要は「重いジョブ」「そのGUI出力」を同じ関数内に記述したいけど、それは「.NETフレームワーク的には出来ない」だけであって、
自分でおかしな縛りを導入して、それに対する解を用意してって、マッチポンプでしかないだろ。
ただまあ、馬鹿が多いようなので無駄に噛みつかれないようにもう一度言っておくと、
確かに並列用途にはTaskは残るかもしれんね。
だからといってPromiseがいいって事にもならんが。
- 576 ：デフォルトの名無しさん ：2020/01/02(木) 21:08:54.36 ID:+muZM7K/0.net
- 高卒の天才みたいな人はいらないよ
- 577 ：デフォルトの名無しさん ：2020/01/02(木) 21:28:42.78 ID:eV/mpEQr0.net
- C＃ならではのアプリよろしく。
- 578 ：デフォルトの名無しさん ：2020/01/02(木) 21:31:55.72 ID:qr+4fHWP0.net
- もしかして「シンタックスシュガー」が理解できてないとか。
- 579 ：デフォルトの名無しさん ：2020/01/02(木) 21:36:12.24 ID:cbHiY2pH0.net
- > ・UIコンポーネントはどのスレッドからでもいじれるようにする。
この時点でマルチスレッドプログラミングまともにしたことない感が…
- 580 ：：2020/01/02(木) 21:47:43.46 ID:VmmTWzwp0.net
- >>575
＞・UIコンポーネントはどのスレッドからでもいじれるようにする。
それは土台無理というものですよ…
- 581 ：デフォルトの名無しさん ：2020/01/02(木) 21:59:18.76 ID:PZFQVuh5M.net
- 別にUIコンポーネントのためにTaskを用意したわけではないが
- 582 ：デフォルトの名無しさん ：2020/01/02(木) 22:26:33.22 ID:qsQZs66Y0.net
- Task登場前に比べれば段違いで楽になったわけやしな
その後直ぐにasync出たのも時代的に仕方なかったわけで
- 583 ：デフォルトの名無しさん ：2020/01/02(木) 23:06:36.82 ID:ZgXvL7GY0.net
- 俺がasync/awaitを使うとだいたいハングアップするんだけど
みんなどういう場面で使ってるの？
- 584 ：デフォルトの名無しさん ：2020/01/02(木) 23:07:01.36 ID:FzsUW8F+0.net
- >>579,580
だからそれが俺には謎なんだよ。やれば出来る範囲としか思えない。
実際、お前らが今バインディングしている先も、一々排他チェックなんてしてないだろ。
そもそもGUIではレーシング時には「前の値」でも「後の値」でもどっちでもいいケースでほぼ全部で、
問題のあるところだけmutex等の遅い同期化機構でも全く問題ないんだよ。
MSはGUIがプチフリするのが許せなくて、30秒以上（だったかな？）のジョブをUIスレッドでやったら警告を出し、
他スレに強制移転させたわけだが、その時に仕様的にはそのままGUI出力出来なかったというのが元の問題だろ。
しかし button_onClickに最初から他スレで問題ないし、
そもそもお前らみたいに「DIコンテナが正義」ならどうせStringBuilder/TextBox等に直書きなんてあり得ないのだから、
必要ならDIコンテナ先で排他/同期で全く問題ないし、これの方が実際生産性も高いだろ。
ただこれは俺にとってはかねてからの疑問で、これを5chで言うのも初めてではない。
他言語、例えばJavaScriptも形式は違うが一応「UIはシングルスレッド」になっているので、何かあったのだとは思う。
色々聞いた限り、Javaで昔マルチスレッドなGUIがあって、盛大にそこでやらかしたから、
それ以降はシングルスレッドなのだ、との説を聞いたのだけど、これについて知っている奴はいるか？
ただそれにしても、その時はマルチスレッドにみんな慣れていなかったからであって、今なら普通にこなせるとも思うが。
>>581
ではなんだよ？
並列処理、というのは後付だと思うが。
- 585 ：デフォルトの名無しさん ：2020/01/02(木) 23:48:39.72 ID:PZFQVuh5M.net
- >>584
マルチスレッドとマルチスレッド以外のあらゆる非同期、並列処理を統一的に扱うための抽象化だよ
歴史的な経緯で非同期、並列処理のやり方がマチマチでわかりにくかったからTaskにまとめた
これにより雑魚プログラマでも簡単に安全にイイカンジに最適化された非同期、並列処理を実装できるようになった
さらに統一的な抽象を得たことによって言語レベルでasync awaitを導入する基礎ができた
UIスレッドなんてのはオマケもいいとこだ
- 586 ：デフォルトの名無しさん ：2020/01/02(木) 23:59:29.88 ID:cbHiY2pH0.net
- >>584
mutexを緻密にやればrace conditionが発生するし、
雑にやればパフォーマンスの低下を引き起こすと思うけど
UIの実装なんてあんまり真剣に考えたくないところなんだから、
別スレッドからUIスレッドへ実行すべきブロックをキューに追加するぐらいが丁度いいと思うが。
逆に、「やれば出来る範囲」と言うけど、実際にUIスレッドをスレッドセーフにしてまともなGUIフレームワークになっているものってあるの？
- 587 ：デフォルトの名無しさん ：2020/01/03(金) 00:04:21.64 ID:jYqYJjY40.net
- すまん、race conditionではなくデッドロックだ
- 588 ：デフォルトの名無しさん ：2020/01/03(金) 00:13:26.64 ID:hATKQL5q0.net
- マルチスレッドに分散処理させてた結果を最終的に本体スレッドで受け取る時に、queueで待機させて結局同期的にDBに書き込んでるんだけど、意味あるのかな？
- 589 ：デフォルトの名無しさん ：2020/01/03(金) 00:17:52.23 ID:O846x913a.net
- >>588
その分散処理とやらがボトルネックになっているなら意味があるかもしれない
多くの場合はDBの方がボトルネックになるから、DBへの書き込みをバッチ化するとかの方が遥かに効果がある
- 590 ：デフォルトの名無しさん ：2020/01/03(金) 00:48:08.71 ID:fU3ErGER0.net
- >>585
俺はそうは思わんね。
> あらゆる非同期、並列処理を統一的に扱うための抽象化
これは単なる「関数」で超大昔に終わってる。
つまり、非同期でも、並列でも、エントリポイントは「関数」であり、つまり渡す物も「関数」であり、
その上の階層で非同期か並列かを選べるのだから、「関数」で抽象化は完成してる。
実際、ちゃんと組んであれば、内部の関数はマルチスレッド/シングルスレッド/同期/非同期のどれで用いるにしても、
一字も変更する必要がなく、変更されるのは最上位での呼び出し方だけだろ。
これが「抽象化」が「関数」で完全に済んでいる証拠。
（というよりは、こうなる為のお作法として「グローバル禁止」等があるわけだが）
async/Taskがいいのは「その場に書ける」「戻り値を取れる」からであり、
抽象化してるとするなら、「同期」と「非同期」を抽象化してる。
（ただしキーワードが必要なので厳密には抽象化出来ているわけではないが）
だから、簡単で直感的な「同期」記述とほぼ同じ記述で「非同期」が出来るから美味しいだけであって、
それ以上でもそれ以下でもない。
そしてC#に非同期が必須みたいになったのはフレームワークの仕様の問題であり、これは回避出来たと思ってる。
- 591 ：デフォルトの名無しさん ：2020/01/03(金) 00:57:27.50 ID:jYqYJjY40.net
- >>590
GUIなんて「グローバル変数」の典型例だと思うけど、
設計モチベーションの一つとして、GUIを便利に書く言語となってほしいってのがおそらく合ったと思うけおd、
それでも「回避できた」可能性はあるの？
- 592 ：デフォルトの名無しさん ：2020/01/03(金) 01:06:44.31 ID:fU3ErGER0.net
- >>586
> UIの実装なんてあんまり真剣に考えたくないところなんだから、
これはその通りだ。
> 別スレッドからUIスレッドへ実行すべきブロックをキューに追加するぐらいが丁度いいと思うが。
そしてこれがInvokeというわけか？
まあ.NET的にはそうなのかもしれん。
> 実際にUIスレッドをスレッドセーフにしてまともなGUIフレームワークになっているものってあるの？
知らん。だから聞いている。
無いのは、無い理由があるとは思うのだけど。(そしてそれが、昔Javaで…だと聞いているだけ)
- 593 ：デフォルトの名無しさん ：2020/01/03(金) 01:12:48.79 ID:T8mFSGHc0.net
- JavaScriptのPromiseが難しいのは、then のブロック内の最後の行で実行した関数の戻り値が勝手に次のプロミスにチェーンしていくみたいなところ。
ここが難しいのは、JavaScriptには明確な型が無いので公式サイトのサンプルを見ても、関数の戻り値がどんな内容（型）のデータを返しているのか分かりにくいところ。
それぞれの関数のドキュメントを調べてもそれが結局分からない。
同じ関数でも時と場合によって返すデータの型(?)が変わってしまうようなケースすらあるかも知れないし。
いまのところまだ理解できないのは、fetch でResponseオブジェクトを返すような処理。
ドキュメントの説明で、関数のプロトタイプ宣言の様な部分でも型がちゃんと書いてないので理解が難しい。
- 594 ：デフォルトの名無しさん ：2020/01/03(金) 01:16:10.63 ID:T8mFSGHc0.net
- >>593
みなさん、これをすらすらと理解できますでしょうか？
自分はなかなか理解できません。
https://developer.mozilla.org/ja/docs/Web/API/Fetch_API/Using_Fetch#Response_objects
- 595 ：デフォルトの名無しさん ：2020/01/03(金) 01:34:14.56 ID:fU3ErGER0.net
- >>591
回避出来たも何も、それ以前にする必要がないんだよ、割と。
例えば>>255,261、画面のGUIコンポーネントを直接参照して動作時は画面ロックの方がよかった、というわけだが、
実際これでも「自家用アプリに簡単にGUIを付けたいだけ」なら全く問題ない。
そして、演算実行中は放置だから、他スレッドとも競合なんてしないんだよ。
格好良くいえば、「運用で回避する」ということになる。
勿論プログラムとしては色々ヤバイが、必要なら真面目に同期取ればいいだけ。
手抜きなら「動作中は触るな」で十分、というわけだ。
クラッシュするのは例えばログ出力用TextBoxに複数から同時に書き込まれた時だが、
そもそもそれは複数出力元がある=複数の計算ルーチンが同時に起動する事が必要で、
全くのGUI初心者が最初に組むアプリではないんだよ。
それを非同期で別スレ起動してInvokeしろとか、かなり敷居を上げてしまってるだろ。
（もっとも、警告を無視してUIスレッドで計算して、当然GUIはフリーズ、みたいなことも出来たが）
- 596 ：デフォルトの名無しさん ：2020/01/03(金) 01:47:00.56 ID:VBfxgT36M.net
- >>590
超大昔に終わってないから出来損ないのインターフェイスや実装がポンポン出てきて混乱したんだよ
でマイクロソフトが主導してC#における標準的な抽象としてTaskを導入した
プログラマはみんなそれを受け入れてTaskを使うようになった
- 597 ：デフォルトの名無しさん ：2020/01/03(金) 01:53:44.42 ID:T8mFSGHc0.net
- >>594
追記：
thenブロック内部の関数の戻り値が Response「型」の場合でも、
直後のthenブロック内部の関数の引数が必ずしもResponse「型」ではないこともあるようで、その場合は、型の「自動変換」が行われているのではないかと思えるんです。
C++の場合だとプロトタイプ宣言などの関数宣言があるのでそれが分かり易いのですが、JavaScriptだと本当に型変換が行われているかどうかも不明確で理解が難しくなっています。
仮引数の型に可能性の幅が出てくる可能性があり、結局どのような「型」になっているか分からないので、どのクラス(?)のドキュメントを読んでいいのかも分からないので理解に時間が掛かります。
候補となりそうなクラスや関数の解説文を手当たり次第に読んでみて辻褄の合うようなものを自分なりに見つけてこないといけないようです。
C/C++ではなかった苦労がそこにあります。
- 598 ：デフォルトの名無しさん ：2020/01/03(金) 02:26:10.78 ID:cSDCrnP10.net
- >>594
https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch#Return_value
↑fetchの仕様を見れば戻り値は
「A Promise that resolves to a Response object」と明記されてるよ
MDNも日本語訳は内容が古いからまずは英語で見たほうがいい
const response = await fetch(…);
- 599 ：デフォルトの名無しさん ：2020/01/03(金) 02:31:11.54 ID:cSDCrnP10.net
- >>597
>直後のthenブロック内部の関数の引数が必ずしもResponse「型」ではないこともあるようで
んんん？？
thenは2つコールバック関数を引数にとって
一つはresolveした場合、もう一つはrejectされた場合。
fetchが返すpromiseがresolveした場合は必ずResponseオブジェクトじゃないの？
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/then
- 600 ：：2020/01/03(金) 03:19:39.56 ID:RUwUdhzc0.net
- >>584
＞Javaで昔マルチスレッドなGUIがあって、盛大にそこでやらかしたから、
Java ライブラリの GUI（基本は awt） ってそんなんだったかな…近々 awt を頭から見直そうと思っていますのでそのときに考えて見ます
- 601 ：デフォルトの名無しさん ：2020/01/03(金) 10:59:52.40 ID:3J/SmROP0.net
- javaのフィールドに倣ってプロパティの接頭語にアンダースコアを付けるべきか悩んでいるのですがベテランの皆様はどう思われますか？
- 602 ：デフォルトの名無しさん ：2020/01/03(金) 11:03:04.63 ID:VBfxgT36M.net
- 好きにすればいいよ
どっちでも文法的に正しいし、どっちがより良いかは証明不可能
- 603 ：：2020/01/03(金) 12:23:01.84 ID:RUwUdhzc0.net
- >>601
それはハンガリアン（の一種）といって悪い作法だと思います
- 604 ：デフォルトの名無しさん ：2020/01/03(金) 14:09:52.04 ID:T8mFSGHc0.net
- >>598
A Promise that resolves to a Response object.
この言い回しが分かりにくて
「Responseオブジェクトを解決するところの1つのPromise」
とはコードで書くとどういうPromiseの事を言っているのか分かりません。
- 605 ：デフォルトの名無しさん ：2020/01/03(金) 14:15:20.54 ID:T8mFSGHc0.net
- >>604
リンク先にあった、以下のコードを見ればどういうことなのかは大体理解はできそうですが。
「Xを解決するところの1つのPromise」
というものの正確な定義はどこにあるのでしょうか。
let myRequest = new Request('flowers.jpg');
fetch(myRequest)
.then(function(response) {
if (!response.ok) {
throw new Error('HTTP error, status = ' + response.status);
}
return response.blob();
})
- 606 ：デフォルトの名無しさん ：2020/01/03(金) 15:32:49.36 ID:fU3ErGER0.net
- >>596
FrameworkOnFrameworkが日常的になっている時点で、
機能的に足りない＝そのFrameworkが糞、なのは明らかだろ。
>>600
AWS等について確認したが、どうやら
> スレッドとAWT/Swing
> https://www.ibm.com/developerworks/jp/java/library/j-thread/index.html
> https://www.ibm.com/developerworks/jp/java/library/j-king/
・AWSは多分何のプロテクションもない
・SwingはinvokeLater()とinvokeAndWait()(多分BeginInvokeとInvoke相当）が用意されている
・これらで手こずったので、.NETは最初から「UIスレッド縛り」を付けた
ように見える。結果的には妥当な判断なのかもしれん。
(AWSやSwingは俺が569で言った構成に《.NETよりは》近い）
- 607 ：デフォルトの名無しさん ：2020/01/03(金) 15:33:08.37 ID:fU3ErGER0.net
- これらやその他の記事を読む限り、
Javaはどうもマルチスレッド周りの問題をまともに解決しに行ったように見える。
時代的に「最先端言語」としての矜持があったのかもしれん。
結果、爆死して今に至るのかも。
例によってデッドロック周りがやたら記述されているが、これに関しては、
折角ポインタを廃止して消し去った、「悪いプログラム片が少し混入しただけでアプリ全体がアウト」
になるCの問題点がそのまま復活してしまうから、Javaとしては絶対に許せない。
かといって、上手い解決策も見つけられてない。
ただ、デッドロックは多分今の若者が教育されているほどには驚異にはならない。
あれはアホみたいに「一つ確保して、その場ですぐ返す」構造にすればそもそも回避出来る。
つまりロック周り自体ではなくて、その上位構造から単純化してしまって解決する方がいいのだけど、
それをしようとはしていない。
逆にそれをしたのが.NETで、言うなれば全部のUIコンポーネントで一つのmutex、
それをUIスレッドが握りつぶす（他に渡さない）から他が触れず、Invokeするしかなくなる。
OOP初心者が訳の分からないクラス構成にすることはよくあるが、同様に、
Javaでマルチスレッド初心者が訳の分からないロック機構（しかもバグってる）を作りまくったのかもしれん。
.NETはそれよりは、仕様的に回りくどい構造になるがアホでも組める方を選んだのだろう。
とはいえそれもFrameworkOnFrameworkしたくなってしまうほど糞で、実際それをやらかし、
Task/asyncで収まった、というのが現在か。(話を総合すると）
歴史の流れとしては極めて妥当なのかもしれん。
- 608 ：デフォルトの名無しさん ：2020/01/03(金) 15:58:36.89 ID:NacIP61HM.net
- >>606
君いわく超大昔にとっくに解決したはずのものが現実には多くの糞を生んだ
しかし新たに設けた抽象化であるTaskがそれれらの大部分を解決したということだな
君の言う関数という抽象化は非同期処理の現実には大して役に立たなかった
事実は事実として受け止めたほうがいいよ
- 609 ：デフォルトの名無しさん ：2020/01/03(金) 17:14:48.26 ID:fU3ErGER0.net
- >>608
まあ俺のスタンスは変わらんけどな。一応纏めておくと、以下。
・Taskはゴミ。今となっては（非同期には）要らない。
・asyncは「抽象化」ではなく非同期の「記法」。
・asyncにより非同期の煩雑さは解決された。
簡単に記述出来る「記法」が足りなかったのに、非同期強制部分が.NETにあった為に多くの糞を生んだ。
元々はラムダや匿名関数周りが弱かったからであり、これらが最初からあればもうだいぶましだった。
実際、JavaScriptのイベントモデルだと、Taskなんて無くてもC#程酷いことにはならない。
そう出来なかったのはC#の問題であり、（といっても既に解決済みだが）
逆にWeb系は馬鹿でも出来るようになっているからこそ馬鹿が調子こいてる。（簡単なこと自体は素晴らしいことだが）
君がこれらを認めないのは君の自由。
- 610 ：デフォルトの名無しさん ：2020/01/03(金) 17:23:20.75 ID:RiNqytdzM.net
- 多くのケースでasyncawaitでコーディングしたほうが簡単だがTaskが要らないわけではない
並列処理では相変わらずTaskが活躍している
またasyncawaitを実装するためにはTaskという抽象が必要だった
関数で抽象は完結してるなどとトンチンカンなことを主張して思考停止していたらasyncawaitの発明には到達できなかった
- 611 ：デフォルトの名無しさん ：2020/01/03(金) 17:35:57.54 ID:VSKvK8ih0.net
- 並列処理はうまく書けないからasync/awaitは中途半端な糞！にならないのが不思議だなあ
てかこのひと年末からずっと何かにつけて「ほにゃららは糞！おまえらは信者！」から入るのに
ひたすら教えられてるだけなのが面白いね
- 612 ：デフォルトの名無しさん ：2020/01/03(金) 17:56:04.43 ID:cSDCrnP10.net
- >>604
スレチな気もするが一応回答しとく
Promiseってのは処理が終わってるかもしれないし
まだ終わってないかもしれないという文脈付きで値を運ぶ入れ物
処理が終わってる場合は、成功してるケースもあれば失敗してるケースもある
つまり下記3つのうちいずれか1つの状態にある
1. Pending:まだ終わってない/結果待ち
2. Fulfilled: 成功で処理完了済み(=Resolved)
3. Rejected: 失敗で処理完了済み
「戻り値が A Promise that resolves to a Response object」というのは
戻り値はPromise(=文脈付きで値を運ぶ入れ物)で
成功で処理が完了済みの状態になった場合
入れ物の中身は「a Response object」になるPromiseですよって意味
- 613 ：デフォルトの名無しさん ：2020/01/03(金) 18:03:40.42 ID:cSDCrnP10.net
- >>605
>.then(function(response) {
.thenの第一引数はresolveした場合のコールバック関数で
そのコールバック関数に渡される引数が
Promiseが成功で処理完了済み状態になった場合に入れ物の中に格納してる値
fetchの場合はそれが「a Response object」
function(response){…}というコールバック関数の引数(response)に
Promiseという入れ物に格納されたa Response objectが入る
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Promise/then
- 614 ：デフォルトの名無しさん ：2020/01/03(金) 19:11:10.09 ID:fU3ErGER0.net
- >>611
そうとしか取れないのはお前が馬鹿な信者だからだ。
俺はそもそもasyncが悪いなんて言う気もない。いい物はいいと認めるだけ。
お前みたいな馬鹿信者は俺という『人』を全否定したいから、全部否定するとか、
お前みたいな馬鹿でも明らかに分かるほど間違った態度を取ってくれないと困るようだが。
> 並列処理
そりゃ重要度が違うからな。実際、お前ら並列処理なんて書いてないだろ。
スパコンのこと何にも知らないようだし。（これ自体はC#的には問題ないが）
C#/.NETが扱うのは、そもそも並列が効くような案件でもないし。
対して非同期は.NET的には日常的に必要な物になってしまってるだろ。
ただまあ、お前らがTaskにこだわるのなら、第一級関数ってのも意味があるのかもね。
Task自体はラムダをオブジェクト化したようなものであり、関数型で言う第一級関数的なものだ。
JavaScriptならFunctionにメソッド生やして全部Task的にすることも可能だ。（やったら別の意味で殺されるはずだが）
俺には第一級関数の有り難み自体はよく分からないのだけど。
- 615 ：デフォルトの名無しさん ：2020/01/03(金) 19:31:35.35 ID:rBRy8LznM.net
- > C#/.NETが扱うのは、そもそも並列が効くような案件でもないし。
やっぱり使ったことない人だったか
- 616 ：デフォルトの名無しさん ：2020/01/03(金) 19:35:32.04 ID:FQOC+LzKd.net
- 通信やファイル等々は並列化前提くらい当たり前に使う部分
そもそもまともに開発したことないんでしょ、彼は
- 617 ：デフォルトの名無しさん ：2020/01/03(金) 19:40:22.89 ID:VSKvK8ih0.net
- >>614
> 馬鹿でも明らかに分かるほど間違った態度を取ってくれないと困るようだが。
馬鹿がasyncマンセーTaskは糞なんて明らかに分かるほど間違った態度を取ってるから別に困って無いよ？
> そりゃ重要度が違うからな。実際、お前ら並列処理なんて書いてないだろ。
まあ日常的に並列処理を書いて無いならasync信者になるのも止む無しだね
粒度の粗いAPIを呼び出しているだけで済むプログラマ人生なのが良くわかる
まさに「馬鹿でも出来るようになっているからこそ馬鹿が調子こいてる。」
- 618 ：デフォルトの名無しさん ：2020/01/03(金) 20:21:02.89 ID:jYqYJjY40.net
- 並列実行をHPC系の計算でしか使わないと思ってるのかなあ
スマホゲームにだって使われている、カジュアルに使えなくちゃ今時大変な機能だと思うけど
- 619 ：デフォルトの名無しさん ：2020/01/03(金) 23:02:49.12 ID:O+Z2CAJQ0.net
- c#の並列処理ってコントロールが糞だから仕方なくって場面ばっかりだけどね
そもそも並列処理って実現方法に2つあって
並列で動く2つの処理を
処理Aと処理Bとしたときに
[方法1]
言語の並列機構に任せて
処理Aと処理Bをそれぞれ独立で実行する
もちろん処理過程や処理結果も表示通知する機能が存在する
[方法2]
処理Aと処理Bをブツ切りにした
処理A1~N、処理B1~Nをループで
処理A1
処理B1
表示
処理A2
処理B2
表示
・
・
・
という具合で実行
色々触ってきたけど[方法1]で
実行できた言語って一度もネーな（笑）
- 620 ：デフォルトの名無しさん ：2020/01/03(金) 23:20:55.60 ID:mMttcVtS0.net
- そうだね、パソコンがなんでもやってくれると君みたいな頭でもプログラムが書けるね
- 621 ：デフォルトの名無しさん ：2020/01/03(金) 23:21:49.89 ID:cSDCrnP10.net
- とりあえず並列処理と並行処理は区別しよう
- 622 ：デフォルトの名無しさん ：2020/01/03(金) 23:46:23.43 ID:fU3ErGER0.net
- >>616
既に突っ込まれてはいるが、それは一応「並列(Parallelism)」ではなく、「平行(Concurrency)」という。
が、まあ、これはさておき、君の使い方はやはり平行でなく非同期(Asynchronous)だと思うよ。
実際、例えば、「asyncブロック」というのが次に来たとして、仕様は、
・これまでの記述の複数のasync文を async { } で囲うことが出来ます。
・asyncブロック内のasync文は同時にディスパッチされます。
・全てのasync文が完了次第、asyncブロックを抜けます。
という、async { } で囲うだけ！簡単！楽チン！な物が提供されたら、
今お前らが使っているであろうTask<TResult>は不要になるだろ。
ディスパッチャを自前で書く気がなければTaskは基本的に要らないと思うけど。
本来「平行」の場合は表ジョブと裏ジョブの同期は割と厳密に取る。
手が空き次第捌け、順番はどうでもいい、は非同期の使い方で、大概はほぼこれだろ。
- 623 ：デフォルトの名無しさん ：2020/01/03(金) 23:48:32.86 ID:fU3ErGER0.net
- × 平行
○ 並行
- 624 ：デフォルトの名無しさん ：2020/01/04(土) 00:04:34.11 ID:kFIotbKU0.net
- >>616
>>622
と思ったんだが訂正。
確かに今の仕様のasyncだとまだTaskは廃棄出来ないかも。
現在は明示的に発行と結果回収を別の行に書いてるんだな。それでawaitで引っかけてると。
俺はこれ、遅延評価で勝手に引っかかってるだけだと勘違いしてたわ。
すまんね。
- 625 ：デフォルトの名無しさん ：2020/01/04(土) 00:09:37.91 ID:OgXWl81Pa.net
- やっぱり使ったことない人だったか
- 626 ：デフォルトの名無しさん ：2020/01/04(土) 00:48:40.79 ID:4F9nlIzrM.net
- 通信やファイル処理はCPUとは別のデバイスが同時に処理するから並列処理
ネットワークやディスクにアクセス中にスレッド消費されたら使い物にならん
- 627 ：デフォルトの名無しさん ：2020/01/04(土) 01:17:00.82 ID:ebUznjxj0.net
- 誤った指摘をしている人がいますが、>>616は、相当ミスらない限り並列処理かつ非同期処理です
並行処理である保証は全くありません
- 628 ：デフォルトの名無しさん ：2020/01/04(土) 02:02:38.56 ID:X7t3Qsuc0.net
- 並列は、CPU に使う用語
並行は、処理に使う用語
- 629 ：デフォルトの名無しさん ：2020/01/04(土) 02:34:27.40 ID:WRfbnwnP0.net
- こんだけ暴れておいてこの結末ｗ
- 630 ：デフォルトの名無しさん ：2020/01/04(土) 02:47:20.03 ID:oEJCGEWJ0.net
- >>626,627
ファイルや通信のI/O処理中にCPUでは別の処理をするってのは
典型的な並行処理の例で一般的には並列処理とは呼ばないぞ
ファイルがパーティション分割されてて
100パーティション同時に書き込みを行うような処理なら並列処理
基礎的なことなのでもうちょい勉強してくれ
- 631 ：デフォルトの名無しさん ：2020/01/04(土) 03:01:30.66 ID:ebUznjxj0.net
- >>630
>>627は冗談で言ってるんだとは思いますし、何が一般的かは知りませんが、私はこの並行処理の記述に従って理解しています
https://docs.microsoft.com/en-us/dotnet/standard/parallel-programming/
なお、私の知る限りでは他分野でも同じです
- 632 ：デフォルトの名無しさん ：2020/01/04(土) 07:26:04.88 ID:SQI5AQb9M.net
- >>630
並行処理ってのは、単一の主体が短いタイムスパンで複数の処理を切り替えて処理することによって、まるで並列処理をしているように見せかける技術のことな
言うまでもないが、並列処理は複数の主体が、見せかけじゃなく同時に別の処理をしてる場合な
例えばこうだ
var t1 = CalcSomething();
var t2 = DownloadFile();
var t3 = ReadFile();
1つの物理装置が、少しCPU処理→少しファイル処理→少しネットワーク処理、と繰り返して3つの処理を同時に処理してるように見せてるなら並行処理だ
でも実際には、別々の物理装置によって計算、ネットワークアクセス、ファイルアクセスを同時に処理するので、これは並行処理ではなく並列処理だ
基本的なことなので、勉強してくれまじで
- 633 ：デフォルトの名無しさん ：2020/01/04(土) 07:33:09.39 ID:wUfYsbyMd.net
- C#で並列処理を勉強しようとしたら大抵初めに出てくるParallel.Forすら知らないんでしょ
だから英単語出してきてまでそれは平行だ！とか指摘しちゃう
英単語わかってるなら並列だってわかるはずのにｗ
もう以前からびっくりするくらい知識が浅い
- 634 ：デフォルトの名無しさん ：2020/01/04(土) 07:49:31.73 ID:wUfYsbyMd.net
- あとマルチproccessとマルチthreadも同じやね
using System.Threadingも書いたことなんだろう
C#に無知でこれらを知らないは別に良いけど一般的なソフトウェア開発で並列処理なんて書かないとかいう指摘も的外れ
C#に関することに無知なのは触ってなけりゃ普通のことだろうけど今や当たり前に行われる並列処理をスパコンのものでお前らにはわからんだろうな、とか言っちゃうのは技術者としてどうかと思う
- 635 ：デフォルトの名無しさん ：2020/01/04(土) 08:29:25.67 ID:zoxkJgWd0.net
- プログラム内の厳密な並列ってなくね？
おそらく無理じゃね
同じメモリ空間をCPUが同時にアクセスできないよね？
paralle.forとか俺はこんないい加減な前準備でできると思ってないけどね
どういう仕組みか知らんけどｗ
多分なんちゃってだろ
やった感じ直列で処理したほうが早い感じになってうんこだったよ
ちなみにフルHDの画像処理を上から三等分にしてparalle.forでやってみたがクソ遅い上に並列にやってない気がしたけど
みんなはこんなもん使えてるの？
ところでスレッドってスレッドスイッチするし積まれたタスクを順番に処理してるだけだよな？
その切替タイミングはプログラム内のsleepやDoEventsだよね？
- 636 ：デフォルトの名無しさん ：2020/01/04(土) 08:50:02.37 ID:oslWCP6e0.net
- 変なの増えた
- 637 ：デフォルトの名無しさん ：2020/01/04(土) 09:09:30.45 ID:H9Ya7buR0.net
- >>635
> その切替タイミングはプログラム内のsleepやDoEventsだよね？
いつの時代の老害だよ…
- 638 ：デフォルトの名無しさん ：2020/01/04(土) 09:10:51.45 ID:SF9EFyjm0.net
- >>635
パイプラインとかキャッシュとかレジスタとかマルチスレッドとか、CPUの技術を少しは勉強したほうがいい
- 639 ：デフォルトの名無しさん ：2020/01/04(土) 09:16:33.71 ID:zoxkJgWd0.net
- >>637
え？じゃあどこ？
- 640 ：デフォルトの名無しさん ：2020/01/04(土) 09:23:34.37 ID:zoxkJgWd0.net
- >>638
それを実際に言語の機能に適用してるかどうかは別だよね？
なんか超遅かったよ
もし並列に動いてるなら画像処理は単純に三分の一で終わったはずだよね？
ところがむしろ3倍以上かかってるんだな
なんか前準備に色々条件があるのか？
こんなもん役に立たないのか？
該当する処理が本当に適用できるのかはチェックが必要だと思うな
- 641 ：デフォルトの名無しさん ：2020/01/04(土) 09:34:32.95 ID:ljwPgx+b0.net
- スレッド切り替えと言うが、今日日マルチコアだぞ。
Parallel.Forも一つだけど、PLINQなんかも実は色々効いてくる。
まあ、Taskは便利よ。
スレッドプールを有効利用するのは手でやると事故るので、Taskに任せるほうがよかろう。
その上でUIスレッドに返したければUIスレッドに返すコード書けば良いだけなんだし。
逆に言うと、UIスレッドからTaskをawaitしたときに元のスレッドに戻って来てる事自体が例外的な処理に近い。
- 642 ：デフォルトの名無しさん ：2020/01/04(土) 09:44:36.22 ID:wUfYsbyMd.net
- parallelにしてもちゃんと理解してないと遅くなることだってありうるよ
並列化できない処理をparallelしたって切り替え処理とかが無駄に働いて逆に遅くなることもある
コードでも上げてみりゃどこが間違ってるか指摘できる人もいるんじゃない？
- 643 ：デフォルトの名無しさん ：2020/01/04(土) 09:49:49.34 ID:zoxkJgWd0.net
- >>642
コードを見ないとわからない？
IDEが教えてくれる？
なんにせよ使えないよそんなの
- 644 ：デフォルトの名無しさん ：2020/01/04(土) 09:54:48.34 ID:zoxkJgWd0.net
- >>641
それ並列でやった処理結果まとめられないじゃん
やりにくいし
結局処理単位は自分でブツ切りにしないと途中経過出力できないし
実質この手の機能ってc++の頃から別に便利でもなんでもないゴミクズ機能で停滞してるよね？
- 645 ：デフォルトの名無しさん ：2020/01/04(土) 09:57:09.90 ID:H9Ya7buR0.net
- >>639
プリエンプティブ でググってこい
- 646 ：デフォルトの名無しさん ：2020/01/04(土) 09:59:40.19 ID:wUfYsbyMd.net
- >>643
いや、あんたが何かを勘違いしてるかもしれないことをコードレビューしてあげようかって言ってあげてんのｗ
詳細な実装は開示しないけど俺が試したら遅くなった！parallelなんかまともに使えない！って主張なの？
世界中のプログラマが有益に利用してるんだから間違って利用しちゃってるなら正せばいいだけじゃん
ググりゃ腐るほど日本語でも記事はヒットするんだし
- 647 ：デフォルトの名無しさん ：2020/01/04(土) 10:01:55.73 ID:wUfYsbyMd.net
- 3分割したら3倍異常遅くなるって例えば各スレッドでファイルを読み込んでるだけじゃねーの？
そんなやり方したらそりゃ遅くなるよね
- 648 ：デフォルトの名無しさん ：2020/01/04(土) 10:02:04.61 ID:zoxkJgWd0.net
- >>646
フルHD画像処理を上から三等分でparalle.forって言ってんだからやって動くサンプル出してこいよ
おそらくdobon辺りに貼るだけでparalle.forかけて画像処理ループさせるだけだ
10分だぞ
やりたきゃ頑張れ
- 649 ：デフォルトの名無しさん ：2020/01/04(土) 10:14:00.73 ID:WRfbnwnP0.net
- GAIJI vs GAIJI
- 650 ：デフォルトの名無しさん ：2020/01/04(土) 10:18:25.47 ID:dtJSIh3jp.net
- ヤベエ逸材多過ぎだろこのスレｗ
今までどこに潜んでたんだコイツら
- 651 ：デフォルトの名無しさん ：2020/01/04(土) 10:31:54.67 ID:ljwPgx+b0.net
- >>644
纏められるよ。
PLINQ使ってみ。
途中経過が必要ってこと自体、多分並列化出来てないから考え方がおかしいよ。
並列にやってるんだから途中経過なんて足し込まないと出せない事はやるべきじゃないでしょ。
足しこみは並列にできないんだから、そこで足並み揃えちゃったらそりゃ並列に動かんよ。
- 652 ：デフォルトの名無しさん ：2020/01/04(土) 10:57:29.93 ID:kFIotbKU0.net
- まあとりあえず、「並列」「並行」については最近は混同されてるし、実際混同しても問題ない領域が多いし、
文系馬鹿C#erが主流なこのスレでその厳密性を求める意味はない。
ただまあ、ファイルとCPUでは速度差がありすぎるから、
まともなスケジューラーなら並列に書いてても並行になってしまうとも思うが。
しかしMSはそこも含めて隠蔽しようって事なんだろ。これ自体はいい。
> Parallel.For
これはちょっと筋が悪い。現在の主流はMap/Reduceなんだから、そっちに合わせた方がよかった。
お前らが速くなるならないでグダグダ言っているのも、結局はこれで、Map/Reduceが効く場合は速くなり、
そうでない場合は速くならず、場合によっては遅くなる、というだけ。別に不思議なことではない。
ただまあ、君らも分かっているとおり、レンダリングの場合は分割は効果があるから、
・書き方が悪い
・今はそこまでParallel.Forの出来がよくない
のどちらかで、まあそれを揉めているわけだが、今の状況はさておき、
最終的にはこのコードで簡単楽チンに数倍速を得よう、ってのは間違ってはいない。
問題はやはりMap/Reduceでないことで、結局、「関数」で処理を抽象化出来ているから
関数を直接扱う「関数型」の方がI/Fは綺麗に並んでしまう。
そこをForにこだわったのは間違いだと思うよ。
- 653 ：デフォルトの名無しさん ：2020/01/04(土) 11:03:02.06 ID:DH3JGq6p0.net
- とりまコード見ないとなんとも
なんかで排他制御でも効いてるんだろうけど
- 654 ：デフォルトの名無しさん ：2020/01/04(土) 11:03:38.49 ID:oEJCGEWJ0.net
- >>631
そのリンク先に並行処理についての記述は一切無いぞ
>>632
並行処理をせまく理解しすぎ
並行処理と並列処理は観点の違う概念であって相互排他的なわけではない
並行処理はある瞬間を切り取ると”必ずしも”同時に複数の処理が実行されているわけではないだけで同時に実行されてる場合もある
君の例は1つの物理装置で処理されてようが別々の物理装置によって同時に処理されてようが関係なく並行処理(Concurrent Processing)の例
それを並列処理とは呼ばない
- 655 ：デフォルトの名無しさん ：2020/01/04(土) 11:11:54.60 ID:8gIJKMuI0.net
- そもそもawait/asyncは、非同期処理を同期処理のようにかける仕組みであって
マルチタスクそのものじゃなくて周辺技術だよな
- 656 ：デフォルトの名無しさん ：2020/01/04(土) 11:53:37.81 ID:SQI5AQb9M.net
- >>654
いや、そっちが理解間違ってるよ
並列処理は複数の装置で複数の処理を同時に実行すること
並行処理は単一の装置に複数の処理をスケジューリングして、順番に実行することによって巨視的に並列処理のように見せかけること
複数の装置にスケジューリングすることを並行処理と呼んでる場合もあるが、それは正確には並列処理と並列処理のハイブリッドだな
君が言ってる同時に処理される場合もある、というのはこのことだろうな
- 657 ：デフォルトの名無しさん ：2020/01/04(土) 12:07:21.44 ID:hpecUN4N0.net
- >>656
どっちが正しいと断言するつもりはないけど、この並列処理と並行処理の定義はどこから持ってきたものなの？
- 658 ：デフォルトの名無しさん ：2020/01/04(土) 12:08:56.85 ID:ljwPgx+b0.net
- >>652
自動的に適切な単位に分割されたMapとReduceがPLINQで実現できると思うんだが。
- 659 ：デフォルトの名無しさん ：2020/01/04(土) 12:27:07.45 ID:LH34clIMM.net
- >>657
放置しときなよ
用語知ってる俺スゲー君同士の戦いなんてどうでもいいし
- 660 ：デフォルトの名無しさん ：2020/01/04(土) 13:10:03.26 ID:9r4/dVyW0.net
- この年末からのつまんねえ言葉遊びの流れほんとクソ
- 661 ：デフォルトの名無しさん ：2020/01/04(土) 15:56:23.34 ID:zGBEMeLs0.net
- 装置どうこうで並列や並行いってるやつらは
まずマルチコアなCPUを装置としてどう見てるのか書け
話はそれからだ
- 662 ：デフォルトの名無しさん ：2020/01/04(土) 19:35:04.89 ID:kFIotbKU0.net
- >>658
実際効果が出ているのならそれでいいと思うよ。
MapかForについては、どっちから攻めるかの違いだけではあるから。
ただ、分割をC#側が担うのは明らかに間違ってるでしょ。
DBならSQL投げてその先はDB側で動的に何とかしろ、が正しく、
当たり前だがDBの構成なんてC#コーディング時に関知しようもないし。
といってもMSがこの辺を知らなかったはずもない。
何か作戦があるんだとは思うよ。
PLINQについては確かに「並列」だが、なかなかな事を書いている。
> 既定では、PLINQ はホスト コンピューター上のすべてのプロセッサを使用します。
> https://docs.microsoft.com/ja-jp/dotnet/standard/parallel-programming/introduction-to-plinq
> 結果の順序は毎回異なることがあります。
> この動作は、オペレーティング システムによるスレッドのスケジュール方法に依存するため、アプリケーションでは制御できません。
> https://docs.microsoft.com/ja-jp/dotnet/standard/parallel-programming/order-preservation-in-plinq
これはMSが悪いわけではなくて、当然そうにしかならないのだけど、
当たり前だがPLINQに丸投げすれば全てよし、みたいなものではない。（ただ、そこを目指してはいるのは正しい）
まずは書けないと話にならないので、MSとしてはプログラミングモデルを提供してきた、というところか。
- 663 ：デフォルトの名無しさん ：2020/01/04(土) 19:37:21.95 ID:kFIotbKU0.net
- asyncも、ググれば分かると思うが、実はasync/awaitの片方はキーワードとしては要らない。
その場合には実行/フェンスについて、実行は今まで通り記述した時点で開始、
フェンスは結果を使うところで暗黙的に、ということになる。（つまり今ならawaitが要らない）
これはこの界隈ではすごく一般的な考え方で、
例えばアセンブラでDIVやSQRT命令みたいにレイテンシが長い命令を配置したとき、
結果レジスタを使わない場合はどんどん流し、結果レジスタを使う場合だけそこで一旦停止して結果待ち、という事を30年前からやっている。
だから「非同期」というよりは「並列化＋パイプライン(可変長レイテンシ）」として考える方がいいのかもしれないけど、
いずれにしても今は「明示的にawaitを書く」というある意味MSらしくない、
どちらかというとWeb系的ドベタ仕様で、だからこそ君らもTaskマンセーな訳だが、
こう説明されれば「あ、確かにawaitいらねえな」とはすぐに分かるだろ。
多分君らが非同期にだいぶ慣れた頃にawaitは廃止されると思うよ。
そして「非同期」と「同期」は一文字も変わらない同じ関数で実行可能となり、完全な抽象化が実現出来ることになる。
ただし、今の仕様が悪いか、と言われれば、必ずしもそうでもない。
俺がさんざん言っているとおり、MSは若干エレガントなところを狙いすぎていて、
ライト層がちょっと置いてきぼりになってる感がある。（Web系に比べて）
そしてさんざん君らがTaskマンセーしているとおり、ベタな仕様には分かりやすいという大きな利点がある。
ただそれにしても、繰り返すが、CPUのパイプライン構造を知っていれば、あ、確かに間抜けな仕様だな、とはすぐに分かるだろ。
俺が信者だと揶揄しているのはそこら辺であってさ。
- 664 ：デフォルトの名無しさん ：2020/01/04(土) 19:51:30.64 ID:dJY1KQxf0.net
- 別スレ立てたら?
- 665 ：デフォルトの名無しさん ：2020/01/04(土) 19:54:05.88 ID:kFIotbKU0.net
- もしかしたら伝わらないか？とも思うので一応。
俺はawaitを廃止して、以下の
> 次に、ベーコンと卵の await ステートメントを、メソッドの最後の朝食提供前に移動します。
> https://docs.microsoft.com/ja-jp/dotnet/csharp/programming-guide/concepts/async/index
の下のコードを以下に出来る、といっている。
Coffee cup = PourCoffee();
Console.WriteLine("coffee is ready");
Egg eggs = FryEggs(2);
Bacon bacon = FryBacon(3);
Toast toast = ToastBread(2);
ApplyButter(toast); // ここでtoastが完了してないときだけは結果待ちで止まる
ApplyJam(toast);
Console.WriteLine("toast is ready");
Juice oj = PourOJ();
Console.WriteLine("oj is ready");
Console.WriteLine("eggs are ready");
Console.WriteLine("bacon is ready");
Console.WriteLine("Breakfast is ready!");
まあみりゃ分かるとおり、await文部分を前に持っていっただけではあるが。
今の仕様だと、この書き方では肝心の非同期部分が1つずつステップ実行されてしまう、という事になっている。
- 666 ：デフォルトの名無しさん ：2020/01/04(土) 20:06:59.76 ID:tMXF89W90.net
- >>665
そのコードじゃ非同期処理が完了してなくても"〜 are ready"って表示されるだろ。
- 667 ：デフォルトの名無しさん ：2020/01/04(土) 20:09:00.48 ID:DH3JGq6p0.net
- c++スレにいた長文マンかなこいつ
- 668 ：デフォルトの名無しさん ：2020/01/04(土) 20:44:38.22 ID:kFIotbKU0.net
- >>666
まあそこはツッコミ来るかとは思っていたが…。
ぶっちゃけ、その通りだ。そしてそれで問題ないんだよ。
結果を確認しに行けば確かに出来ている（ようにしか見えない）からね。
時間軸上で遅延が発生するだけで、論理的な動作としては全く問題ない。
これは例えばJavaScriptでは大昔から実装済みで、getElementsByClassNameがそうなってる。
https://developer.mozilla.org/ja/docs/Web/API/Document/getElementsByClassName
これで問題が発生しているケースなんてない。
馬鹿が「getElementsByClassNameは圧倒的に速い」みたいなブログを書いている、というのは結構あったが。
ただ、まあ、何らかのフェンス構文自体が必要なのは認める。
しかし、当然だがフェンス自体は不要なら書かないものだし、
普通に「返り値を使う」いわゆるお行儀のいいプログラミングをしている限り、実際に不要だ。
だからじきに、みんなが「await って実は要らなくね？毎回お約束的に書かされるだけだろ。」
と思いだした頃に、廃止されるんじゃないかな。
そしたらその階層を取り扱う必要もなくなり、Taskも廃止できる。
- 669 ：デフォルトの名無しさん ：2020/01/04(土) 20:59:50.92 ID:W0mLC2oD0.net
- >>663 >>668
awaitの結果を必ずしも使うとは限らないのに、本気で言ってるの？
async Task<void>のメソッドなんていくらでも作ることあるだろ。
そりゃ、async Task<bool>にでもしてtrueでも返すようにして、if文で判定するとかはできるけど、そんなの正直言ってasync/awaitからの退化だよ。
C#では非同期実行の方が基本的にはあえてさせることなんだから、awaitなくしたとして
コードを読んでてもわからないところが非同期になっていたら結構困ると思うけどなぁ。
なんでもかんでもどうやらある程度経験が豊富そうなJSを基準に考えちゃうみたいだけど、非同期が当たり前のJSとはとりまく環境が違うと思うよ。
- 670 ：デフォルトの名無しさん ：2020/01/04(土) 21:49:39.49 ID:kexvLmFr0.net
- await不要って園児並みに相当バカ
無くなったら何が困るかの簡単なことに気づかないとか、普通の人でもわかることだよw
- 671 ：デフォルトの名無しさん ：2020/01/04(土) 21:59:07.73 ID:xLbjEwkrM.net
- そろそろ冬休み終わるから謎の長文更新も途切れるかね？
- 672 ：デフォルトの名無しさん ：2020/01/04(土) 22:10:43.14 ID:hpecUN4N0.net
- 冬休み関係ない人かもしれない
- 673 ：デフォルトの名無しさん ：2020/01/04(土) 22:16:18.30 ID:SQI5AQb9M.net
- 前にも言ったがそんなに素晴らしいものなら、C#の言語チームに提案してこい
誰にも相手にされんだろうが、ここでグダグダと怪文書を書き込み続けるよりは生産的だろ
- 674 ：デフォルトの名無しさん ：2020/01/04(土) 23:11:07.21 ID:kFIotbKU0.net
- >>669
> コードを読んでてもわからないところが非同期になっていたら結構困ると思うけどなぁ。
これはその通り。だから俺の理想は以下のコードになるけど、
これはおそらくプログラミング理論的には>>665より汚いコードだとされる。(抽象度が落ちてる）
Coffee cup = PourCoffee();
Console.WriteLine("coffee is ready");
Egg eggs = async FryEggs(2);
Bacon bacon = async FryBacon(3);
Toast toast = async ToastBread(2);
ApplyButter(toast); // ここでtoastが完了してないときだけは結果待ちで止まる
ApplyJam(toast);
Console.WriteLine("toast is ready");
Juice oj = PourOJ();
Console.WriteLine("oj is ready");
async_fence(); // これ以前のasync関数はこれ以降は完了していることが保証される
Console.WriteLine("eggs are ready");
Console.WriteLine("bacon is ready");
Console.WriteLine("Breakfast is ready!");
現行からの変更点としては、
・キーワードawaitをasyncに変更、書く場所は同じ、ただしwaitせず実行して貫通
・キーワードasyncは呼び出し側に明示的に付け、定義側には要らない
・必要ならasync_fence()でフェンス、無ければ実行結果が使われるときに自動的にフェンスされる
・Egg/Bacon/ToastはTaskではなく値、よってキャンセル等は面倒だがどうせしないからよし
ただこれだと async を async()として関数化してリッパーにすれば現行のC++等で実装出来そうな気がしてきた。
これは勝手にやってみるかも。
> 非同期が当たり前のJSとはとりまく環境が違うと思うよ。
コミュニティとしては君らの方が慣れてないだけで、プログラミングとしては大して変わらんよ。
JSもI/O以外は全部同期だし、非同期部分は限定されてる。(なおgetElementsByClassNameは非同期ではなく遅延評価)
- 675 ：デフォルトの名無しさん ：2020/01/04(土) 23:27:22.94 ID:Zo3qJxMY0.net
- 仕様を劣化させてるだけじゃん…
- 676 ：デフォルトの名無しさん ：2020/01/04(土) 23:40:07.01 ID:y+CTQpVr0.net
- >>674
暇だからリファクタリングしてあげた
var cup = PourCoffee();
Console.WriteLine("coffee is ready");
var eggs = FryEggsAsync(2);
var bacon = FryBaconAsync(3);
var toast = await ToastBreadAsync(2);
ApplyButter(toast);
ApplyJam(toast);
Console.WriteLine("toast is ready");
Juice oj = PourOJ();
Console.WriteLine("oj is ready");
await eggs;
await bacon;
Console.WriteLine("eggs are ready");
Console.WriteLine("bacon is ready");
Console.WriteLine("Breakfast is ready!");
コイツの管理者はコードレビュー大変そう
- 677 ：デフォルトの名無しさん ：2020/01/04(土) 23:47:15.01 ID:+Qzz4bCZ0.net
- 毎日毎日赤っ恥書きながらも上から目線を崩さない姿勢はだんだん可愛く見えてきたなｗ
- 678 ：デフォルトの名無しさん ：2020/01/04(土) 23:59:24.33 ID:kFIotbKU0.net
- >>676
それはawaitで書けばほぼ現行通りだろ、というわけか。
まあその通りだが、呼び出し側に async が付いているのがミソなんだよ。
今はそれが Task<TResult> だから明示的だが、var になると明示的でなくなる。これがよくない。
また現行の await は事実上フェンスとして使われているから、
君が書き直したその通りなのだけど、俺は既に言ったが、
「フェンスは出来るだけ使わない」（というよりこれは常識とされる）ので、ここが気に入らない。
書かずに済むのだから書かすなよ、だ。
そして現行の関数宣言部、 async を付けるわけだが、これは意味的に要らん。
(現行の仕様でも特に要らないはず）
ジョブの最上位関数はマルチスレッド/シングルスレッド./同期/非同期関係なく同一に書ける。
それをどう呼び出すかで同期/非同期等切り分けるべきであり、
定義側にわざわざ async と非同期専用みたいに書くのが気に入らない。
同期で呼び出したら同期で動作するだけの関数なのに、だ。
- 679 ：デフォルトの名無しさん ：2020/01/05(日) 00:05:02.27 ID:UANz5iul0.net
- >>676
ああ、だから俺は、違いは
同期：
var eggs = FryEggsAsync(2);
非同期：
var eggs = async FryEggsAsync(2);
だけにして欲しいな、ということ。
現行のコードに async を挿入するだけでコアが余っていれば非同期でその関数が実行され、高速化する、ということ。
- 680 ：デフォルトの名無しさん ：2020/01/05(日) 00:17:31.34 ID:3JPcR/pBM.net
- 言語の感想文はブログで書け
薄っぺらい知識なのを宣伝してるだけだぞw
- 681 ：デフォルトの名無しさん ：2020/01/05(日) 00:37:05.87 ID:T90rRrA70.net
- >>678
あなたの考える仕様はvarの比ではなく、暗黙的でわかりにくい
普通に変数にアクセスしているだけなのに、非同期処理と待ちが入るなんてはっきり言って迷惑
それと呼び出し先を非同期/同期の両方に対応させる設計は良い習慣ではない
・CPUバウンドなら同期的
・IOバウンドなら非同期的
大まかにこの基準で切り分けて、それをシグネチャで明示したほうがいい
- 682 ：デフォルトの名無しさん ：2020/01/05(日) 02:47:09.06 ID:hKu0nmGg0.net
- C#の仕様策定プロセスはオープンなんだからこんなところでウダウダ言ってないでgithubで提案してみれば？
ツッコミ入って「C#コミュニティはクソ！」って言い出す未来しか見えないけどさ
- 683 ：デフォルトの名無しさん ：2020/01/05(日) 04:32:02.28 ID:Bbmuqtw40.net
- まさかと思うけど、asyncなメソッドはawaitしないと呼び出せないとか思ってるんじゃないか
- 684 ：デフォルトの名無しさん ：2020/01/05(日) 09:05:43.12 ID:UANz5iul0.net
- >>681
varがわかりにくいというのはお前の慣れの問題。
> 待ちが入る
待っているのは同期設計だ。
毎行で「前行の終了を待つ」からブロッキングと呼ばれる。
> それと呼び出し先を非同期/同期の両方に対応させる設計は良い習慣ではない
そんなわけあるか。もう一度言うが、非同期ってのは呼び出し方法であって、ジョブそのもの（関数）の性質ではない。
例えば、MatrixMulという重たい計算があったとする。
すると、日常的にC#で並列をこなすお前らは、これを高速化する為に、Task<TResult>に分割するわけだろ。
その場合、MatrixMulは「同期関数」だが「非同期」で実行される。
「非同期」ってのは関数の性質ではなく、呼び出し方であって、逆に、「非同期関数」を「同期」で呼び出すことも当然出来る。
だから被呼び出し関数に async を付けること自体がナンセンスなんだよ。
付けるとしたら、呼び出し部分か型で、
var eggs = async FryEggs(2);
AsyncTask<Egg> = FryEggs(2);
であって、お前の流儀は
Task<Egg> = FryEggsAsync(2);
なんだろうけど、これはナンセンスなんだよ。ハンガリアンならぬ、アシンカリアンでしかない。
だから、今の仕様は
A. 非同期に慣れてないC#erへの補助輪
B. ヘルスバーグが中二病全開
C. 実はコンパイラの都合で、async付けてくれればパッチ当てがメチャ楽だったから適当こいて付けさせた
のどれかで、俺はBだと思うけど。
なお気持ち悪さではSQLをべた書きするLinqの方が上だと思う。
でも linq を使った関数に一々 linq を付けることもないし、
同様に parallel を使ったら parallel を付けて回る、ということもないんだろ。
await 使ったら async 付ける、ってのは全くナンセンスだよ。
非同期は、今後は、今のお前らが思っているほどは特別なものではなくなるんだよ。これはもう確定してるだろ。
- 685 ：デフォルトの名無しさん ：2020/01/05(日) 09:35:53.95 ID:kO8WyPRk0.net
- >>684
async/await考えた人が元々asyncは必ずしも必要ないと言ってるのに、何をさも自分が考えたように言ってるんだ？
awaitいらねーとか真正アスペかよ
- 686 ：デフォルトの名無しさん ：2020/01/05(日) 10:52:51.13 ID:T90rRrA70.net
- >>684
自分はvarがわかりにくいとは思ってない
>var になると明示的でなくなる。これがよくない。
あなたがvarをよく思ってなさそうなので、あなたの考えた謎仕様のほうがそれより遥かにわかりにくいですよ、と言っただけ
>そんなわけあるか。もう一度言うが、非同期ってのは呼び出し方法であって、ジョブそのもの（関数）の性質ではない。
これも間違い
例えば、ネットワークやファイルなどIOバウンドな処理は、CPUとは異なるデバイスで処理されるので、原理的に非同期にするしかない
呼び出し先の性質によって非同期が確定する典型例
CPUバウンドの場合、呼び出し先で非同期をサポートすることも可能だが、基本的にそうする必要は無い
スレッディングのコストは無料じゃないのだから、呼び出し先はすべて同期的に実装して切り替えオーバーヘッドを減らしたほうが、全体的なパフォーマンスが向上する
UIと止めずに応答性を高めたいだとか、非同期にする明確な理由が出来たらそこで初めてTask.Runすればいい
上で基本的にと書いたのは、CPUを食い尽くしてでもいいから時間的に早く処理を終わらせたい、という理由で並列化する場合があるからだ
この場合は、プログラムを並列処理用に最適化して設計するのが定石だ
なので、この場合に関しては逆に非効率的な同期版をサポートする理由がなくなる
asyncが構文として不要なのはわかってるが、そんなつまらない話はあなた以外はだれもしてない
- 687 ：デフォルトの名無しさん ：2020/01/05(日) 11:21:56.38 ID:dqyEtfEv0.net
- なんで比較にLINQが出てくるのかめちゃくちゃ謎
SQLっぽい書き方のLINQしか知らないのかな？
メソッド拡張の方のLINQはmap/filter/reduceと書き方がちょっと違うだけの単なるメソッドを呼び出し
してるだけなんだけど。
- 688 ：デフォルトの名無しさん ：2020/01/05(日) 11:33:14.86 ID:kO8WyPRk0.net
- >>686
657 デフォルトの名無しさん (ﾜｯﾁｮｲ 797b-s4wZ) sage 2020/01/04(土) 19:37:21.95 ID:kFIotbKU0
こう説明されれば「あ、確かにawaitいらねえな」とはすぐに分かるだろ。
多分君らが非同期にだいぶ慣れた頃にawaitは廃止されると思うよ。
>>686
asyncが構文として不要なのはわかってるが、…
asyncもawaitも不要なんですね、真正アスペ君w
たったこれだけのシンプルな間違いさえわからない、自分で理解できてない
これが真正アスペでないと誰が言えようかw
- 689 ：デフォルトの名無しさん ：2020/01/05(日) 12:17:09.89 ID:As/vHaVrM.net
- awaitは必要だぞ
- 690 ：デフォルトの名無しさん ：2020/01/05(日) 14:01:08.94 ID:UANz5iul0.net
- >>686
なるほどお前が全然分かって無いというのは分かった。
根本的に勘違いしていると思うのだけど、ジョブの中身を同期専用/非同期専用で設計することはない。(というか、できない？)
既に言ったが、MatrixMul、要は行列の掛け算が100ジョブあったら、4CPUならそれを4個ずつ積むだけだ。
このとき吐けた順にガンガン積んで処理していきたいなら、
「非同期」にして最初から全部キューイングしてディスパッチャに任せるだけ。
ジョブ自体が「非同期」ではなく、ジョブの処理の仕方が「非同期」なんだよ。
MatrixMulを非同期専用に書き換える、なんて事はない。というか、出来ない。
> 例えば、ネットワークやファイルなどIOバウンドな処理は、CPUとは異なるデバイスで処理されるので、原理的に非同期にするしかない
これもない。というか、C#にしても、他の言語にしても、ファイルオープンは通常は同期だ。
ここはJavaScriptのスレではないのだが、それを間違えたか？
これについては「JavaScript 10k （またはc10k)」でググってくれた方がいいと思う。
Sleepがない方がパフォーマンスが出る！というのがJavaScriptの宗教だから、蕩々と説明してあるはず。
ただしJavaScriptもメジャーになってしまったし、おそらく以前ほど叩かれなくもなっているので、最近はこの話題も聞かないが。
I/Oを非同期として分離する必要があるのは、JavaScriptがSleep無しのシングルスレッドアーキテクチャだからであって、
Sleepありのマルチスレッドアーキテクチャならその必要はないし、C#含めて通常の言語は全部これだよ。
- 691 ：デフォルトの名無しさん ：2020/01/05(日) 14:56:44.29 ID:MI3jwdk/a.net
- なんか言い争ってる両者ともそもそも同期非同期の意味が分かってない予感w
- 692 ：デフォルトの名無しさん ：2020/01/05(日) 14:57:08.99 ID:T90rRrA70.net
- >>690
>要は行列の掛け算が100ジョブあったら〜
これは呼び出し先を同期的に実装して、呼び出し元で非同期実行してるパターン
>>686で言うと
>CPUバウンドの場合〜
の段落のこと
このパターンでは呼び出し先は同期版だけサポートすればよく、非同期版までサポートする必要はない
無意味に同期/非同期の両方をサポートしなくていい
>C#にしても、他の言語にしても、ファイルオープンは通常は同期だ。
違う
ファイルIOは背後で非同期的に処理されているが、APIの中でブロックしているから同期的に見えているだけ
昔は言語側の非同期サポートが洗練されていなかったため、妥協してこういう書き方に落ち着いた
C#ではTaskとawaitが導入されて、非同期処理の記述が大きく改善されたため、
原理的に非同期なものは余計なことをしないで、非同期なものとして作れば良い、ということになった
このパターンでは呼び出し先は非同期版だけサポートすればよく、同期版までサポートする必要はない
処理の性質によって同期版か非同期版のどちらかだけを作ればよろしい
- 693 ：デフォルトの名無しさん ：2020/01/05(日) 15:01:43.69 ID:jkDw/EWEM.net
- こんなくだらん喧嘩の起きる余地がないGoが流行るのも納得
- 694 ：デフォルトの名無しさん ：2020/01/05(日) 15:26:07.93 ID:UANz5iul0.net
- >>692
> 無意味に同期/非同期の両方をサポートしなくていい
無意味も何も、普通に作ったら両対応にしかならないと思うぞ。
逆に、そうならないのなら、コーディングを見直した方がいい。
後半については、多分お前の「非同期」は一般の意味とは違うと思うが、
同期APIと非同期APIの両方が用意されている場合、今後は非同期APIだけ使え、というのはお前の自由だ.。
ただ現実として世の大勢は同期APIで、そしてこれで全く問題ない場合が多く、そうはならないと思うけど。
（例えばファイルなら中身がないと次の処理が出来ず、話を進めようがない事が多い）
なお非同期縛りが心地よいのならJavaScriptを勧める。あれは宗教的にそうなってる。
今はAPIの中身についての話なんてしてない。それがお前流の逃げならそれでもいいが、
ここは「C#でどう書くか」の階層の話をするところであって、APIの中身ガーとか言うのなら最低限先にそう言っておくべきだろ。
ただ俺はそれについてつき合う気はないが。（他の人が食いつくのは自由）
- 695 ：デフォルトの名無しさん ：2020/01/05(日) 15:40:34.39 ID:eKdfVC3B0.net
- そもC#はSTAとMTAの両方、なんなら混在する環境に対応しなければならないので
どっちかで綺麗に書けるかけるからこうすべきだってお花畑はなかなか通用しないのよね
結局C#においてはasync/awaitもTaskの中で頻発する特定のパターンを楽にしてくれるだけ
>今後は非同期APIだけ使え
新規のAPIではMSはそういう方針だねえ（winrt）
- 696 ：デフォルトの名無しさん ：2020/01/05(日) 18:06:33.11 ID:VTWLVkpA0.net
- WPFではファイル操作関数を同期的に呼び出せたが、UWPだと許されない。
ちっちゃいファイルの読込みでGUIの遅延も体感できないぐらいだけどダメなんだ。
ちょっとしたプログラム書く時に面倒だね。
- 697 ：デフォルトの名無しさん ：2020/01/05(日) 18:11:57.59 ID:qdBxOc2v0.net
- >>696
async/awaitあるから普通は問題無くかけるけど、コンストラクターでファイル弄るときは面倒なんだよな
- 698 ：デフォルトの名無しさん ：2020/01/05(日) 18:23:07.47 ID:VTWLVkpA0.net
- >>696だけど、ちょっと間違った。
同期的には書けるけど、プライマリスレッド(GUI)からだとダメなんだ。
- 699 ：デフォルトの名無しさん ：2020/01/05(日) 19:12:31.63 ID:jkDw/EWEM.net
- GUIアプリならネイティブスレッドのコストは問題にならないから、
GUIをフリーズさせたくないならイベントハンドラでスレッド起こしてあとは全部同期で書くのが一番シンプルで分かりやすい
最近のC#のasync信仰はWebで膨大なリクエストを捌くときの話で、WinのGUIアプリには全くと言い切っていいほど関係ないよ
- 700 ：デフォルトの名無しさん ：2020/01/05(日) 19:23:11.93 ID:kO8WyPRk0.net
- >>699
guiのイベントでawaitじゃあかんの？
- 701 ：デフォルトの名無しさん ：2020/01/05(日) 19:34:01.01 ID:jkDw/EWEM.net
- >>700
もちろんawaitはするよ。
await Task.Run(() => {
//あとは全部同期処理
})
イベントハンドラでこう書くだけ。
コントロールを触るときにInvokeが必要なことさえ忘れなければこれでいい。
ちなみにGoはこの考え方を更に突き詰めて、スレッドを独自の軽量な仕組みに置き換えることでWebも全部同期で書けるようにしてるね。
- 702 ：デフォルトの名無しさん ：2020/01/05(日) 19:38:18.63 ID:AZQzKocv0.net
- invokeしても死ぬときあんじゃん？
→運が悪かったと諦める
→解決するまでひたすら回避策を突っ込んでいく
→マイクロソフトに電話かける
→上記を制限時間いっぱいまで全部やってみる
- 703 ：デフォルトの名無しさん ：2020/01/05(日) 20:03:16.92 ID:qqN6BGPlM.net
- ファイルオープンは同期的とかいう謎の断定の声もあるけど、
UWPだとオープンも非同期なんだね。
https://docs.microsoft.com/ja-jp/windows/uwp/files/quickstart-reading-and-writing-files
アクセスするストレージへがローカルストレージだけじゃなくてクラウドストレージなのも一般的になってきたから、
ファイルを開くために必要な一連の操作もタイムアウトして失敗する可能性を考えなくちゃならなくなったということなのかな。
- 704 ：デフォルトの名無しさん ：2020/01/05(日) 20:08:14.69 ID:kO8WyPRk0.net
- >>701
なんだ… それなら
〉最近のC#のasync信仰はWebで膨大なリクエストを捌くときの話で、WinのGUIアプリには全くと言い切っていいほど関係ないよ
とちゃうやん
頭ではわかっているのに言い方が間違ってる（言い方が悪い）人時々いるよな
- 705 ：デフォルトの名無しさん ：2020/01/05(日) 20:47:26.26 ID:VTWLVkpA0.net
- >>701
GUIスレッドでawaitしたらブロッキングしてダメじゃん。
結局、同期呼び出しとおんなじになるよ。
- 706 ：デフォルトの名無しさん ：2020/01/05(日) 20:59:12.88 ID:dqyEtfEv0.net
- >>705
UIスレッドでawaitしてもブロッキングにはならないと思うけど。
await以降のコードがawaitしている処理が終わったら実行されるだけで、
処理中は一旦asyncのメソッドを抜けてイベントループに戻るよ
- 707 ：デフォルトの名無しさん ：2020/01/05(日) 21:07:50.78 ID:3XFOch5ma.net
- >>704
695の場合、どうせ後続に何も書かないんだからawaitはあってもなくても一緒じゃね
警告を抑制する以上の意味はないだろう
- 708 ：デフォルトの名無しさん ：2020/01/05(日) 21:15:43.37 ID:GaCs2bDS0.net
- >>705
awaitを誤解してる
Task.Wait()みたいにブロッキングはしない
awaitより後ろの処理が自動的に継続タスクになるから同期処理っぽく見えるだけ
- 709 ：デフォルトの名無しさん ：2020/01/05(日) 22:16:53.04 ID:kO8WyPRk0.net
- >>707
実行ボタンの場合、何も書かないほうが稀だと思うけど
- 710 ：デフォルトの名無しさん ：2020/01/05(日) 22:31:27.48 ID:3XFOch5ma.net
- >>709
処理結果の反映にInvoke使うんなら不要でしょ
- 711 ：デフォルトの名無しさん ：2020/01/05(日) 22:43:52.66 ID:kO8WyPRk0.net
- >>710
ボタンの連打対策が必要とか、普通にプログラム書いてる人ならわかると思うんだけど
- 712 ：デフォルトの名無しさん ：2020/01/05(日) 22:53:53.05 ID:3XFOch5ma.net
- >>711
だからInvokeでできるよそれ
Runから戻る必要はない
- 713 ：デフォルトの名無しさん ：2020/01/05(日) 23:03:25.02 ID:3XFOch5ma.net
- もしかして705はBeginInvokeと勘違いしてるんだろうか
InvokeはUIスレッド上で実際に処理が完了するまで呼出元のスレッドをブロックするから、連打対策のような用途にも使えるんだよ
なぜかコピペサイトではBeginInvokeだけ紹介されてることが多くて、意外とInvokeの方は知られてなかったりするんだよね
よく理解しないで使ってデッドロックさせるアホがいるからかな
- 714 ：デフォルトの名無しさん ：2020/01/05(日) 23:09:20.18 ID:MI3jwdk/a.net
- 何を争ってるのかよく分からんけど、連打対策になるって主張もよく分かんないねw
- 715 ：デフォルトの名無しさん ：2020/01/05(日) 23:12:07.22 ID:3XFOch5ma.net
- いや、そもそも処理終了後にEnabledを戻すだけならBeginInvokeでもいいか
細かいことを言えばInvoke/BeginInvokeだと一度メッセージループに処理が返ってしまい連打を防ぎきれない可能性があるから
無効化の方はRunの前にやっておく方がベターだけど、いずれにせよ後続処理はRunの中からInvoke/BeginInvokeで問題ないね
(というか振る舞いは等価)
- 716 ：デフォルトの名無しさん ：2020/01/05(日) 23:13:02.39 ID:XwlRh/tg0.net
- 継続ブロックがUIスレッドに戻ってくるからInvoke不要ってのがasyncイベントハンドラの価値じゃねえのん
逆にメリットそれだけだからTaskに包んで書こうが構わんやろって向きもあるんだろうけど
マそもそも同期コンテキストの前提がおけないライブラリ内のコードでは
継続ブロックがどのスレッドで動き出すかわからないなんてことも普通にあるので
ConfigureAwaitとか必要悪ともお付き合いせにゃならんのが辛いところネー
- 717 ：デフォルトの名無しさん ：2020/01/05(日) 23:19:25.32 ID:dqyEtfEv0.net
- >>712
それはTaskだけでなんでも出来るからawaitなんかいらないよ言ってることにならない？
もちろんInvoke使えばできるだろうけど、アニメーションなんかが絡むとコールバックだらけになりそうな気がする。
Task.Runの中のInvokeにはプログレスバーを進める、テキストエリアにテキストログを出す、
みたいなあまり本質的でないUIの変更にとどめておいて、本格的な処理結果の表示はawait以降に書く、なんてのも
コードの読みやすさの確保のためには有効な手順じゃないかな。自分はそうしてる。
- 718 ：デフォルトの名無しさん ：2020/01/06(月) 00:46:28.60 ID:3wPOSvMe0.net
- >>715
実際にそんなソース書くようなやつはセンス無いから、営業や総務に異動させるわ
- 719 ：デフォルトの名無しさん ：2020/01/06(月) 18:16:42.26 ID:Qm/elW020.net
- ファイルサーバにC#のサービスを常駐させてクライアントからリクエスト受けたらdosコマンドを実行したいのですがどういう技術で実現出来るでしょうか？
単純にサービスだとリクエストをどう受ければ良いのだろうと悩んでおります
- 720 ：デフォルトの名無しさん ：2020/01/06(月) 18:26:36.55 ID:+ezJCAApM.net
- そんなもんApacheでも立ててCGIでええやろ
C#なんぞ要らん
- 721 ：デフォルトの名無しさん ：2020/01/06(月) 18:33:44.24 ID:Qm/elW020.net
- 昔なんですけどwebサーバ立てないでリクエスト受け付けるサービス作ってた人が居たんです
そんなこと出来るんだと思った数年後の現在調べてみても何の技術か解らず
C#で作られていたのは覚えてるのですが
- 722 ：デフォルトの名無しさん ：2020/01/06(月) 18:38:57.81 ID:X36Zclkj0.net
- サービス作った人にやり方を聞けばいいのでは
- 723 ：デフォルトの名無しさん ：2020/01/06(月) 18:42:12.36 ID:HrPzlOWn0.net
- >>719
https://dobon.net/vb/dotnet/internet/tcpclientserver.html
ソケットで受けてProcess.Startとかすればいけると思うけどあまりお勧めしない
- 724 ：デフォルトの名無しさん ：2020/01/06(月) 18:48:18.84 ID:sG64rza2M.net
- System.Net.HttpListenerのこと言ってる？
- 725 ：デフォルトの名無しさん ：2020/01/06(月) 21:20:55.59 ID:/c/Em2OW0.net
- >>721
TcpListener/TcpClientでSocketをそのまま使うかWCFかな
- 726 ：デフォルトの名無しさん ：2020/01/06(月) 21:47:44.44 ID:78RinjQr0.net
- >>719
どうやって実現するかを考える前に
解決したい問題を定義することからはじめたほうがいい
そうしないと適切な選択肢を発見できない可能性が高いから
このケースで問題の定義ってのは
「どういう処理を、どういう理由で、どういう制約の中で実行したいのか」
- 727 ：デフォルトの名無しさん ：2020/01/07(火) 00:56:13.00 ID:ueOqy5pf0.net
- >>721
そりゃ、Ruby でも、socket モジュールで、TCP サーバーを作れるけど、そんな面倒な事はしない。
Sinatra を使えば、ルーティングまで出来るし、
他にも、PowerShell から、1-liner で、
Rubyで作られた、遅い標準ウェブサーバーの、WEBrick も起動できる
ruby -run -e httpd . -p 8080
そのフォルダに、index.html があれば、
何も考えなくても、これでブラウザからアクセスできる
http://localhost:8080
- 728 ：デフォルトの名無しさん ：2020/01/07(火) 01:21:55.02 ID:j8v37+r+0.net
- IIS Expressは?
- 729 ：デフォルトの名無しさん ：2020/01/07(火) 01:28:51.16 ID:ROWMtFOx0.net
- C#で作られたらしいのになぜか他言語推しするやつｗ
- 730 ：デフォルトの名無しさん ：2020/01/07(火) 07:07:29.19 ID:HzCvb3eG0.net
- WCFという言葉を聞いた事があるのでそれかと思います
調べてみます
ありがとうございます
- 731 ：デフォルトの名無しさん ：2020/01/07(火) 07:12:14.82 ID:HzCvb3eG0.net
- >>723
古い技術だから推奨されないのでしょうか
後学のためにお伺いしたいです
- 732 ：デフォルトの名無しさん ：2020/01/07(火) 16:22:44.68 ID:W35nJ2lzM.net
- .NET 5で何か変わると思う？
- 733 ：デフォルトの名無しさん ：2020/01/07(火) 17:03:30.97 ID:muv+YNpYM.net
- .NET5は4.x以前とは全くの別物であり、何もかも変わると思っておけばいい
業務ドカタは永遠に4.8から移行しないだろうから、Web系との間で深刻な分断が生じることになる
- 734 ：デフォルトの名無しさん ：2020/01/07(火) 18:26:40.26 ID:RhWBTAz60.net
- 未だにwin7な企業もわんさかいるし4.8は向こう5年くらいは現役になっちゃうだろうねー
- 735 ：デフォルトの名無しさん ：2020/01/07(火) 18:51:41.45 ID:4CH2lMXx0.net
- ぇー
4.8から5に移植する必要がでてくるの？
- 736 ：デフォルトの名無しさん ：2020/01/07(火) 19:12:37.85 ID:ROWMtFOx0.net
- そんな変わらんから
- 737 ：デフォルトの名無しさん ：2020/01/07(火) 20:12:30.06 ID:muv+YNpYM.net
- >>736
WebFormsが使えないから、既存の.NETアプリの半分くらいは完全に死亡するよ
- 738 ：デフォルトの名無しさん ：2020/01/07(火) 20:26:57.89 ID:muv+YNpYM.net
- あとヤバいのはWCF&.NET Remoting死亡あたりだな
経験上、Classic ASP.NETは使ってるつもりがなくてもユーティリティ類を使ってしまってるケースが結構多くて、大規模なアプリはだいたい死ぬ
- 739 ：デフォルトの名無しさん (ﾄﾞｺｸﾞﾛ MM75-VrsN)：2020/01/07(火) 20:32:52 ID:muv+YNpYM.net
- あと厄介なのがNuGetの依存関係ね
SDKのバージョンを上げるとだいたいNuGetパッケージのバージョンアップ祭りになるんで、だいたいどっかの破壊的変更を踏んで逝く
- 740 ：デフォルトの名無しさん：2020/01/07(火) 20:57:26.52 ID:ku8MCgKr7
- 市場も飽和しきってMSも他人にサードパティ製品で儲けさせず、自分んとこで出すために今後、ころころ変えていきそうだな。
- 741 ：デフォルトの名無しさん ：2020/01/07(火) 22:31:07.85 ID:o9NgJRxS0.net
- >>734
まだVB6アプリが現役なんだぜ
FW4.8は2050年くらいまで持つんじゃね？ｗ
- 742 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 0642-UAPS)：2020/01/07(火) 23:04:37 ID:wcxyvOp00.net
- >>741
VB6はC#より早いしWinFormsと見た目もそれほど変わらんからな
- 743 ：デフォルトの名無しさん ：2020/01/07(火) 23:20:19.80 ID:b0Bey+qG0.net
- VS2010以降の操作性に慣れたらVB6には戻りたくないわ
- 744 ：デフォルトの名無しさん ：2020/01/07(火) 23:26:15.05 ID:8JDfUSzea.net
- .NET CoreはLTSでも3年でサポートが切れる
もし.NET5も同じならドカタITでは互換性以前に検討にも値しないレベル
- 745 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 7fad-wbog)：2020/01/08(水) 00:38:18 ID:HFuLNThA0.net
- Java8的な感じで残りそうな気もする
4.8で打ち止めなら枯れて安定してるし
- 746 ：デフォルトの名無しさん ：2020/01/08(水) 17:07:05.84 ID:Jh9kZvPt0.net
- WinFormのTextboxやRichTextBoxを使用して、
エスケープシーケンスの様に文字単位で色を変えることは可能でしょうか？
String str = "例文：\red赤\r\n \green緑\r\n \black黒\r\n"; // \red \green \blackは仮想のエスケープシーケンス
TextBox.Text = str;
例えば上記で、赤・緑・黒の色がそれぞれ変えるのは可能でしょうか？
それともエスケープシーケンスは改行やTABにだけ対応していて、
色までは対応していなくて不可能でしょうか？
- 747 ：デフォルトの名無しさん ：2020/01/08(水) 17:42:23.45 ID:S7vQ7ZowM.net
- \redって赤と復帰文字+edの区別つかないじゃん
それはともかくRichTextBoxとRTFを使えばまあ似たようなことはできる
RTFを一から書くのは拷問だけど
- 748 ：デフォルトの名無しさん ：2020/01/08(水) 18:32:11.60 ID:6iphn5xQa.net
- >>746
ちょっと何言ってるのかよく分からないけど、
C#のコードでエスケープシーケンスを含む文字列リテラルを書いた時、
それがそのままバイナリになると勘違いしてない？
あれ、コンパイラが対応する文字に置き換えてるんだよw
- 749 ：デフォルトの名無しさん ：2020/01/11(土) 10:46:33.04 ID:IVNUyUW+0.net
- C#でできることってすべてF#で（多少複雑になったとしても）実現できますか？
同じ共通言語基盤上にあってもC#だけで可能なことってあるんでしょうか。
（もちろん、どちらも計算完備なのでC#でできることは
それこそBASICでもできるでしょうが、そういう意味ではなくて
.NET上での共通性の話です）
- 750 ：デフォルトの名無しさん ：2020/01/11(土) 12:49:57.55 ID:Uc6AtsCZM.net
- >>749
もちろん
チーム全員が関数型言語に習熟しているならあえてC#を選択する理由はないよ
- 751 ：デフォルトの名無しさん ：2020/01/11(土) 16:36:56.68 ID:IVNUyUW+0.net
- >>750
ありがとうございます。
（ちなみにですが、関数型っていうか対話的に実行できる仕組みが欲しかったんですよね）
- 752 ：デフォルトの名無しさん (ﾜｯﾁｮｲ ff7c-DGfv)：2020/01/14(火) 09:13:37 ID:/tPlPF6x0.net
- https://www.atmarkit.co.jp/ait/articles/1710/03/news018.html
一応C#も対話的に実行できる
- 753 ：デフォルトの名無しさん (ﾌﾞｰｲﾓ MM0f-rUPC)：2020/01/14(火) 09:19:18 ID:HiotJy5MM.net
- >>752
へーこれってどんな仕組み？コンパイル必要としてないの？
- 754 ：742 ：2020/01/15(水) 18:27:50.06 ID:YlxQUfnE0.net
- >>752
知りませんでした！
折角教えてくださった>>750様には申し訳ないのですが
C#インタラクティブを使ったほうが私めの望みを満してくれるので
そちらにします。
- 755 ：デフォルトの名無しさん ：2020/01/15(水) 21:17:39.40 ID:jOuGOKj7M.net
- なんだと…ｺﾞｺﾞｺﾞｺﾞ
- 756 ：デフォルトの名無しさん (ﾜｯﾁｮｲ d197-sxSO)：2020/01/15(水) 23:02:14 ID:k9iUnicj0.net
- C# Interactive, 64bitで実行できるようになるのはいつなのかねえ。便利なんだけどたまに困る。
xamarin workbookとかも代替であるんだろうけど。
- 757 ：デフォルトの名無しさん ：2020/01/16(木) 00:16:18.83 ID:CC5bpFwG0.net
- 誰だってわかりやすくて書きやすい言語でプログラミングしたいに決まってんじゃん
C#はまだわかるけど難解ぶってるオナニー言語は滅んだ方がいいね
- 758 ：デフォルトの名無しさん ：2020/01/17(金) 01:22:15.96 ID:atTN5w3j0.net
- まあ、たしかに defun(((((( なんか嫌だもんな。
- 759 ：デフォルトの名無しさん ：2020/01/24(金) 22:14:55.39 ID:k9osu5pp0.net
- forおじさんなるキーワードを知ったんだけど今forは使っちゃいかんの？
c#には直接関係ないけどさ
- 760 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 5f6a-bOFn)：2020/01/24(金) 22:23:17 ID:ckgx8D9Z0.net
- 他にbetterな方法がある場合でも、とにかくforをつかえってのを揶揄してるだけでしょ
- 761 ：デフォルトの名無しさん (ﾌﾞｰｲﾓ MMcf-PIvP)：2020/01/24(金) 22:59:35 ID:1f1Z8E2rM.net
- マーティンも今どきforは臭いからパイプライン使えみたいなこと言ってたな
- 762 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 6a02-ZTBJ)：2020/02/04(火) 07:23:29 ID:2P9jYwzY0.net
- ifとforで何重にもネストさせるやつ未だにいるからな
レビューで暴言吐きそうになって困るからやめてほしい
- 763 ：デフォルトの名無しさん ：2020/02/04(火) 08:13:40.65 ID:oN9vo+PdH.net
- >>762
for回さなくていいって記事読んだとき「なんじゃこりゃ〜」って叫んだわ
あ、おわかりのとおりわたし爺ですw
- 764 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 3628-A+Jj)：2020/02/04(火) 12:44:04 ID:M0ahQJ780.net
- 見た目だけじゃなくて処理効率も変わるのかな？
C#みたいな言語だとforだろうがmapだろうがコンパイラがよしなに最適化してくれそう（適当）
- 765 ：デフォルトの名無しさん (ｵｯﾍﾟｹ Srbd-Y6bJ)：2020/02/04(火) 19:03:41 ID:XAK/YcTOr.net
- 実際意味は違うので用途次第ということ
- 766 ：デフォルトの名無しさん (ﾜｯﾁｮｲ a902-nz5b)：2020/02/04(火) 22:00:23 ID:kfb5o96m0.net
- 期待通りの順番で処理してもらえるのか？
不安なんでfor使ったりすることあるね。
- 767 ：デフォルトの名無しさん (ﾌﾞｰｲﾓ MM8e-YgEg)：2020/02/04(火) 22:07:47 ID:Z8KA+tSJM.net
- 順番が気になる処理はなるべく書かない
- 768 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 6663-3Mgd)：2020/02/04(火) 22:56:53 ID:ozqUNPd80.net
- 馬鹿の一つ覚え
- 769 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 9f6a-56gX)：2020/02/05(水) 00:50:35 ID:+dC8QpOa0.net
- >>761
すまん、ジジイなんで勉強したいからソース教えてほしい
- 770 ：デフォルトの名無しさん (ﾜｯﾁｮｲ d724-56gX)：2020/02/05(水) 13:31:41 ID:OSDzuje90.net
- >>764
linqとforeach、forだと処理効率かなり違う
だからといってlinqで書けるものをforで書く程ではないが
- 771 ：デフォルトの名無しさん (ﾜﾝﾐﾝｸﾞｸ MM7f-gP8z)：2020/02/05(水) 14:05:00 ID:AaNsO0iwM.net
- 可読性より性能重視でfor使いまくることあるです
- 772 ：デフォルトの名無しさん (ﾌﾞｰｲﾓ MMcf-gAEv)：2020/02/05(水) 14:14:25 ID:N1rQ6Y7rM.net
- 性能が必要なら言語かえますし
- 773 ：デフォルトの名無しさん (JP 0H4f-w9wO)：2020/02/05(水) 18:36:26 ID:NPiSCXLeH.net
- アセンブラ最速（要最適化）
- 774 ：デフォルトの名無しさん ：2020/02/05(水) 21:42:19.79 ID:qmME163kr.net
- レベル高いのはlinqやforをちゃんと使い分けれる人
レベルが低い人はどちらかしか使わない人
- 775 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 3715-VkLk)：2020/02/05(水) 23:51:29 ID:JHMrCxaG0.net
- Linqってnullがあった時面倒な印象がある
実装当時はselectみたいな予約語を中途半端に実装したってどっかで見た記憶があるけど増えたのかね？
- 776 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 5797-IOUD)：2020/02/06(Thu) 11:04:45 ID:y+neP3Z40.net
- もちろんLINQでもforでも書けるけど、LINQで遅そうな処理で、それが作っている
ソフトの決定的なパフォーマンス問題につながりそうなら、forで書いてみて
ベンチマークしてどっちを採用するか決めるかな。
forの方がありとあらゆる言語で書ける書き方だから当然書けるけど、
LINQの方はPythonの内包表記やmap/filter/reduceの書き方に近くいから
こっちも当然書けるし、短いし一時変数用意しなくていいから基本LINQ使っちゃうよね。
- 777 ：デフォルトの名無しさん (ﾌﾞｰｲﾓ MMbf-gAEv)：2020/02/06(Thu) 12:27:26 ID:BIpKXfQOM.net
- forでないと書けないってコードが汚いだけの場合が殆どだからまずそっちをリファクタリングする
すると自然とLINQで書けるようになる
LINQで遅いのは件数が多すぎるかキャッシュを使ってない場合なので実はforに変えただけじゃたかが知れてる
- 778 ：デフォルトの名無しさん (ｵｯﾍﾟｹ Sr0b-RXZG)：2020/02/06(Thu) 18:42:57 ID:ePr9F6TEr.net
- あまり大したことに使ってなさそう
- 779 ：デフォルトの名無しさん (ｵｯﾍﾟｹ Sr0b-RXZG)：2020/02/06(Thu) 18:45:07 ID:ePr9F6TEr.net
- ＞ forでないと書けないってコードが汚いだけの場合が殆ど
そうは思わないけどｗ
- 780 ：デフォルトの名無しさん (ｵｯﾍﾟｹ Sr0b-RXZG)：2020/02/06(Thu) 18:54:05 ID:ePr9F6TEr.net
- >>776
これも一見もっともそうなことを書いてるけどよく見ると変だよね
forでも書いてるならベンチ取る必要ない
- 781 ：デフォルトの名無しさん (ｵｯﾍﾟｹ Sr0b-RXZG)：2020/02/06(Thu) 18:55:11 ID:ePr9F6TEr.net
- linqでしか書けない人は最下層
forでしか書けない人はそのやや上
- 782 ：デフォルトの名無しさん (ﾌﾞｰｲﾓ MMbf-gAEv)：2020/02/06(Thu) 19:33:48 ID:BIpKXfQOM.net
- forでしか書かない人は使い物にならないおじいさん
無理してでもLINQでしか書かないのはまだまだ研鑽が足りない
意識しなくても自然とLINQになってるのが達人プログラマ
- 783 ：デフォルトの名無しさん (ﾜｯﾁｮｲ d701-3aYi)：2020/02/06(Thu) 20:55:07 ID:WBT6cCNm0.net
- POSTとかGETのレスポンス速度って、自分の回線速度と相手側のサーバー速度依存ですか？
プログラムの処理でコンマ数秒でも早くする方法ってあったりします？
- 784 ：デフォルトの名無しさん (ｵｯﾍﾟｹ Sr0b-RXZG)：2020/02/06(Thu) 21:12:13 ID:ePr9F6TEr.net
- 普通はないよ
アメリカとかにPOSTして帰って来てるんだとしたらそもそも物理的な距離も問題になる
- 785 ：デフォルトの名無しさん (ｵｯﾍﾟｹ Sr0b-RXZG)：2020/02/06(Thu) 21:16:32 ID:ePr9F6TEr.net
- どうでもいいけど回線速度と言うのも変な表現だな
帯域依存だな
最初のレスポンス自体が帰ってくる速度は同じだけど取れる帯域が広いと早くダウンロードが終わる
- 786 ：デフォルトの名無しさん (ﾜｯﾁｮｲ d72f-ndoi)：2020/02/06(Thu) 22:57:37 ID:O+zcmlkO0.net
- ダウンロードの時間じゃなくてレスポンスの話だろ
帯域よりレイテンシのほうが問題だと思うが
- 787 ：デフォルトの名無しさん (JP 0H4f-w9wO)：2020/02/07(金) 08:11:56 ID:EMrYQo7/H.net
- 相手側のサーバーまで全部依存ですよね
ちなみに、普通にwebとかで見えてるサーバーは、必ずping返してくれるの？
- 788 ：デフォルトの名無しさん (ｵｯﾍﾟｹ Sr0b-glrA)：2020/02/07(金) 12:33:07 ID:etaMDs5Yr.net
- ping返さないサーバはいくらでもある
- 789 ：デフォルトの名無しさん (ｱｳｳｨﾌ FF9b-VM48)：2020/02/07(金) 17:30:10 ID:PWhN+bN7F.net
- >>783
htmlに埋め込まれてるアンカーを
バックグラウンドで先読みするタイプのブラウザがあった
評判は悪いみたいだが
- 790 ：デフォルトの名無しさん (ｱｳｱｳｶｰ Sa6b-Za6j)：2020/02/07(金) 20:27:13 ID:q5ptBTCZa.net
- フォームデータなのに？
- 791 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 571d-uqPE)：2020/02/07(金) 23:07:36 ID:GxNDg+Fe0.net
- 【与沢翼】労働収入を高くしても無駄！税金でほとんど持っていかれますよ。
金持ちになるにはたった２つしか方法がない
https://www.youtube.com/watch?v=A-5lQ2rDmc0
【与沢翼】サラリーマンとして生きるのはリスクでしかない。従業員は創業者に
利用されているだけだということに気づきなさい
https://www.youtube.com/watch?v=uPoTvbr5VDk&t=78s
【与沢翼】「世の中は罠だらけ。これに気づかない人はカモにされ続ける。」【思考の革命】
https://www.youtube.com/watch?v=qUk7HFabMeQ&t=70s
【与沢翼】現状に対する疑問を持てない人はずっと辛い労働をして生きてください。
今自分達が不自由であるということに気づかない人はどうぞご勝手に
https://www.youtube.com/watch?v=YGykF9IHv-w&t=41s
【与沢翼】時間を売るような働き方をしてはいけない。自分の24時間をどれだけ
増やせるかという発想で仕事しなさい。最終決定権がない仕事はビジネスとは呼べませんよ
https://www.youtube.com/watch?v=g0WXpcqg4oA&t=51s
- 792 ：デフォルトの名無しさん (ﾜｯﾁｮｲ d735-oJhu)：2020/02/08(土) 18:20:20 ID:0YppiA+B0.net
- OS:Rasbian Stretch
ランタイム:Mono JIT compiler version 4.6.2 (Debian 4.6.2.7+dfsg-1)
ソース:https://i.imgur.com/cFLOcYN.png
パッケージ:https://i.imgur.com/bWRI0Zg.png
エラー:Method 'System.Net.ServicePointManager.CloseConnectionGroups' not found.
Windowsでは正常に動作します。
エラーの原因と解決策を教えてください。
- 793 ：デフォルトの名無しさん (ﾜｯﾁｮｲ d735-oJhu)：2020/02/08(土) 18:23:37 ID:0YppiA+B0.net
- AngleSharpを入れるとこのエラーがでます。
AngleSharpを入れるとバイナリのフォルダにSystem.***という大量のDLLができます。
- 794 ：デフォルトの名無しさん (ﾜｯﾁｮｲ d735-oJhu)：2020/02/08(土) 18:24:23 ID:0YppiA+B0.net
- ターゲットは.NET Framework4.6.1です
- 795 ：デフォルトの名無しさん (ｵｯﾍﾟｹ Sr0b-RXZG)：2020/02/08(土) 19:17:58 ID:1TiVu9qyr.net
- >>794
Linux用には.Net Framework 4.6.1はないんじゃない？
.net coreと.net frameworkは別物
- 796 ：デフォルトの名無しさん (ﾜｯﾁｮｲ d735-oJhu)：2020/02/08(土) 19:25:53 ID:0YppiA+B0.net
- >>795
回答ありがとうございます。
Mono4.6.2と.NET Framework4.6.1は互換性ありませんか
- 797 ：デフォルトの名無しさん ：2020/02/08(土) 19:31:11.67 ID:0YppiA+B0.net
- AngleSharpを入れるとそれを使用しなくても関係ないところでエラーが出る理由がわかりませんね
- 798 ：デフォルトの名無しさん ：2020/02/08(土) 19:41:46.38 ID:1TiVu9qyr.net
- バージョンがあってないからだろ
初心者向けのふらっとスレに行け
まず
.Netにはいろいろ種類があると言うことをしり特性を知れ
次に.net standardが何か調べろ
そして使いたいフレームワークが.net standardで何に当たるか調べろ
次にServicePointManager クラスが自分の使いたいフレームワークで使えるかどうかMSのサイトをみて調べろ
- 799 ：デフォルトの名無しさん (ﾜｯﾁｮｲ d735-oJhu)：2020/02/08(土) 19:54:30 ID:0YppiA+B0.net
- こちらの質問は却下します
- 800 ：デフォルトの名無しさん (ｵｯﾍﾟｹ Sr0b-RXZG)：2020/02/08(土) 19:59:03 ID:1TiVu9qyr.net
- standardというパワー綴り
- 801 ：デフォルトの名無しさん (ﾜｯﾁｮｲ de89-GUQA)：2020/02/13(Thu) 11:12:59 ID:cLFC91tC0.net
- startupでデフォルトのDB接続先でapp.CreatePerOwinContextを登録してるのだが
途中でDB接続先を変更出来たりしないですか？
コントローラーのOnActionExecutingでfilterContext.HttpContext.GetOwinContext().Set(wkUserManager);
で変更したんだが、他画面にいくとリセットされてるというか元が変わってないというか
- 802 ：デフォルトの名無しさん ：2020/02/13(木) 19:44:16.71 ID:o7NRbkWy0.net
- ライブラリの話が出ているので自分も質問させて頂きたいんですが、SevenZipSharp(by squid-box)使ってる方いないでしょうか？
分割されたRAR5.0を解凍する際にファイルが壊れてる的なエラーが出て解凍できないことがあるのはバグでしょうか？（純正7Zipアプリでなら正常に解凍できるため実際には壊れていない）
どうやら1GB程以上の大きい分割ファイルだとそうなることが多いようで、数百MB程度の分割ファイルなら問題なく解凍は出来ます
単体のRARであれば1GB以上の巨大圧縮も解凍できるためメモリ周りのエラーと言う事でもなさそうなのですが
- 803 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 477b-yNzz)：2020/02/15(土) 13:09:48 ID:M9LrwgB50.net
- TabControl上の『選択されていないTabPage上の』ボタンをプログラムからクリックしたいんだが、どうすればいいのだ？
試したことは以下。
((Button^)ctrl)->PerformClick(); // ボタンが見えてないと（ボタンのあるTabPageが選択されていないと）ClickEventが発生しない（以下※１）
((Button^)ctrl)->OnClick(gcnew EventArgs()); // protected なメソッドなので呼べない
((Button^)ctrl)->Click->DynamicInvoke(gcnew array<Object^>(2){ctrl,gcnew EventArgs()}); // C3918、データメンバではないため、マルチキャストデリゲートに直接アクセス出来ない
((Button^)ctrl)->Click(ctrl, gcnew EventArgs()); // C3718, Clickにraiseメソッドがないから駄目
環境
.NET Framework3.5(Form), VC++/CLI, VS2008EE
目的
GUIの画面をバッチ処理しようとしていて、
ボタンの名前をスクリプトに書いておけば順にクリックしてくれる、みたいなものを作っている。
見えていればPerformClickは動作するので、今はその都度SelectedTabを切り替えて逃げているが、
バッチ中に一々画面が変わるので出来ればそのままで処理したい。
- 804 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 477b-yNzz)：2020/02/15(土) 13:10:05 ID:M9LrwgB50.net
- ※１
書いてあることとはこちらの状況と合致しているわけでもないが、とにかく見えてないとPerformClickは動作しない。
> TabControl.TabPages コレクションに少なくとも1つの TabPage が含まれている場合
> (Click、DoubleClick、MouseDown、MouseUp、MouseHover、MouseEnter、MouseLeave、MouseMove)、
> TabControl クラスでは、次のイベントは発生しません。 コレクションに少なくとも1つの TabPage が存在し、
> ユーザーがタブコントロールのヘッダー (TabPage 名が表示される) と対話する場合、
> TabControl は適切なイベントを発生させます。
> ただし、ユーザーの操作がタブページのクライアント領域内にある場合、TabPage は適切なイベントを発生させます。
> https://docs.microsoft.com/ja-jp/dotnet/api/system.windows.forms.control.click?view=netframework-4.8
自動翻訳がイマイチなので英語も。
> The following events are not raised for the TabControl class unless there is at least one TabPage in the TabControl.
> TabPages collection: Click, DoubleClick, MouseDown, MouseUp, MouseHover, MouseEnter, MouseLeave and MouseMove.
> If there is at least one TabPage in the collection, and the user interacts with the tab control's header (where the TabPage names appear), the TabControl raises the appropriate event.
> However, if the user interaction is within the client area of the tab page, the TabPage raises the appropriate event.
> https://docs.microsoft.com/en-us/dotnet/api/system.windows.forms.control.click?view=netframework-4.8
- 805 ：デフォルトの名無しさん ：2020/02/15(土) 14:11:22.37 ID:D6Qol+wpa.net
- >>803
表示されているかどうかの問題ではないと思う。
TabPageのコンテナ（およびその上のコントロール）はそのページが初めて
表示されるまで「作成」(CreateControl)されない仕様だった気が。
知らんけど
- 806 ：デフォルトの名無しさん ：2020/02/15(土) 14:34:26.54 ID:M9LrwgB50.net
- >>805
過去一度でも表示されたことがあるか、なら、確実に一度は表示されている。（初期画面のタブなので)
そして一応、直前に表示した状況でも試してみたが、やはりPerformClickは反応しない。
(「スクリプト実行ボタン」と「スクリプトから押したいボタン」が同一TabControlの別ページにあるので、
タブを切り替えた直後に実行ボタンを押してみたが、駄目だった）
ただしその挙動は少し覚えがあるというか、
大量にコントロールを並べていて描画がもたつく場合、タブを切り替える毎に再描画している雰囲気はあるから、
それに近い可能性（見えてないタブのコントロールを剥がすとか）もありえるとは思う。
- 807 ：デフォルトの名無しさん ：2020/02/15(土) 15:26:28.37 ID:cTwFsuY/0.net
- リファレンスには書いてないっぽいけど
ControlのCanSelectがtrueじゃないとPerformClick()はイベントを発生させない
https://referencesource.microsoft.com/#system.windows.forms/winforms/managed/system/winforms/Button.cs,346
ボタン側を拡張したりボタンが呼び出してるメソッドを直接呼べない状況なら
素直にTabをSelectする以外にないんじゃないかな
- 808 ：デフォルトの名無しさん (ﾜｯﾁｮｲ d201-b83C)：2020/02/15(土) 15:33:35 ID:cTwFsuY/0.net
- InvokeOnClick()呼べる？
こっちなら何もチェックしてないっぽいけど
- 809 ：デフォルトの名無しさん (ﾌﾞｰｲﾓ MM0e-BzDP)：2020/02/15(土) 15:39:09 ID:px7CuDIEM.net
- 別にボタン押すとこまで律儀に再現しなくても良いよ
イベントハンドラかその中で呼んでるサービスを直接呼び出せばいい
- 810 ：デフォルトの名無しさん ：2020/02/15(土) 15:48:29.89 ID:D6Qol+wpa.net
- >>806
なるほど確かに初回表示済みかどうかにかかわらず表示されてない時はダネだねw
これなら問題なかった
static class Extensions
{
public static void RaiseClick(this Control control)
{
var t = control.GetType();
var m = t.GetMethod("OnClick", BindingFlags.NonPublic | BindingFlags.Instance);
m.Invoke(control, new[] { EventArgs.Empty });
}
}
- 811 ：デフォルトの名無しさん ：2020/02/15(土) 15:58:13.85 ID:M9LrwgB50.net
- >>807
おお、ありがとう。
ググりまくりはしたが、ソースコードをチェックするという発想はなかった。
> このプロパティは、System.Windows.Forms.ControlStyles の Selectable 値が trueに設定されていて、
> 別のコントロールに含まれていて、コントロール自体が表示され、
> 有効になっていて、すべての親コントロールが表示され、有効になっている場合に true を返します。
> https://docs.microsoft.com/ja-jp/dotnet/api/system.windows.forms.control.canselect?view=netframework-4.8#System_Windows_Forms_Control_CanSelect
なんだかよく分からんが、かなり条件が深いのは分かった。
CanSelectはリードオンリーだから、素直に表示させるのが一番マシなようだ。
>>808
InvokeOnClickもprotectedなので駄目のようだ。(C3767)
ただ、なんでCanSelectなんだよ？とは思ったので、なるほどInvokeOnClickか!とも一瞬思ったが。
何がしたいんだよこの仕様(CanSelect必須）は。
GUIが有効か見ているわけだが、それをプログラムからの操作に噛ませる意味はないはず。
- 812 ：デフォルトの名無しさん ：2020/02/15(土) 16:08:02.82 ID:M9LrwgB50.net
- >>810
ありがとう。
ただ、リフレクションは嵌る原因になるので出来る限り回避している。理由は以下。
・C#ならさておき、VC++だとググッてもヒットしない。
・ならば勿論C#を参考にするわけだが、本来同じCLRでMSILなので全く同一の筈なのだが、
何故か一部異なっていたりして、そこで嵌る。（というか嵌ったことがある）
勿論使ってはいるが。
ただ、確かに今回はリフレクションでも対応出来る状況なので、最終的には使うかもしれないけど。
- 813 ：デフォルトの名無しさん ：2020/02/15(土) 16:16:32.88 ID:ZLgOs4gBa.net
- バッチ処理なのになんでFormsなんだ？
- 814 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 639e-oFCC)：2020/02/15(土) 16:45:32 ID:9gQJd/YW0.net
- IEコンポーネントの代替品って何？ ChromiumベースEdge のものは既に用意されてるの？
- 815 ：デフォルトの名無しさん ：2020/02/15(土) 17:23:14.18 ID:D6Qol+wpa.net
- >>812
ならこれでも出来た。
何か気づいてない弊害があったらごめんね
public static void RaiseClick(this Button button)
{
var parent = button.Parent;
if(parent is TabPage)
{
button.Parent = null;
button.PerformClick();
button.Parent = parent;
}
}
個人的にはこういうバットノウハウ感全開のコードは嫌いw
- 816 ：デフォルトの名無しさん ：2020/02/15(土) 17:54:52.64 ID:M9LrwgB50.net
- >>815
さすがに動的に剥がすのは色々副作用が発生しそうで怖い。
今のところ以下のコードでやっている。このままか、>>810にするかのどちらかだと思う。
if (ctrl->Parent->GetType()->Name=="TabPage") ((TabControl^)ctrl->Parent->Parent)->SelectedTab = (TabPage^)ctrl->Parent;
((Button^)ctrl)->PerformClick();
キャストが入ってうざくなっているが、要はボタンの親のタブページをその都度選択(表示)させている。
これで動いている。ただしタブが勝手に切り替わるので知らなければギョッとする。
直後に戻せばいいだけかもしれないが、それはそれで無駄にイベントが発生するし、とりあえず放置だ。
仕様だと分かったので諦めはつく。
しばらくこれで試して、問題がなければこのまま、といったところ。
現状TabControl内のTabControlなんて無いから、おそらくこの方法で問題ないと思っている。
(TabControlが入れ子になっている場合、おそらくリフレクションしかない）
- 817 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 9294-E40k)：2020/02/15(土) 17:56:21 ID:KAWVCWpT0.net
- ボタンのコードを呼び出すのは駄目なの？
- 818 ：デフォルトの名無しさん ：2020/02/15(土) 18:28:50.09 ID:M9LrwgB50.net
- >>816訂正
× TabControlが入れ子になっている場合
○ TabControl内にGroupBox等があり、そこにボタンがある場合
809のコードだと直接の親しか見てないので、
TabControl内のボタンは階層的に直接TabPageに貼られている必要がある。
そうでなければ親を再帰で辿るか、リフレクションするか、だろう。
- 819 ：デフォルトの名無しさん (ｵｯﾍﾟｹ Src7-oFCC)：2020/02/15(土) 19:38:08 ID:VwQX+D5fr.net
- 馬鹿がこんがらがってるイメージ
ボタンクリックのイベントハンドラを表示
private void button1_Click(object sender, EventArgs e)
{
//
}
始めの｛と終わりの｝の間をすべて選択する
右クリック クイックアクションとリファクタリングを選択
メソッドの抽出を選択
適用をクリック
- 820 ：デフォルトの名無しさん ：2020/02/15(土) 19:45:46.32 ID:nU62WrWUM.net
- >>819
だよなあ
おそらく「ボタンを押すこと」が目的化してしまってる
クライアントの要件は多分そういうことじゃない
- 821 ：デフォルトの名無しさん ：2020/02/15(土) 20:31:48.09 ID:D6Qol+wpa.net
- >>819
その程度の話なら既に指摘されてるよw
イベントハンドラは動的に変更されるかもしれないし、
ラムダ式や引数で与えられるデリゲートかもしれない。
だから普通質問者さんの問題意識は理解できると思うよw
イキってる君以外の人にはw
- 822 ：デフォルトの名無しさん ：2020/02/15(土) 22:59:55.86 ID:ZLgOs4gBa.net
- >>821
その動的に変わるかもしれない処理とやらを抽出するだけだろ?
Form: btnFoo.Click += this.Model.Foo;
Model: void Foo() => _foo?.Invoke(); // _fooは動的に変化するかもしれない
スクリプト(オレオレマクロの文法がわからんから例としてpowershell)
$form = $AppHost.Container.Resolve("MyForm")
$form.Model.Foo()
画面を見なくていいならより直接的に
$model = $AppHost.Container.Resolve("MyFormModel")
$model.Foo()
- 823 ：デフォルトの名無しさん (ｱｳｱｳｳｰ Sac3-+wK4)：2020/02/16(日) 00:18:48 ID:s243OsDZa.net
- なんかもうバカの壁だねw
ボタンのクリックをシミュレートしたいというのは十分理解できる話だし、
それをなるべくそのまま表現できるようなコードを書きたい、という動機も
普通に理解できる話だと思うんだけど。
>>822的な発想の問題点は、
(1) プログラマの意図と実際のコードに乖離がある
(2) だから呼び出しているメソッドが今本当にButtonのイベントハンドラに登録されているものと
同一であるか、という検証の必要性が発生する。
(3) ButtonのPerformClickの「仕様バグ」を回避するため、
という非本質的な目的のためにコードの設計に手を入れるのは本末転倒
なにが「だろ？」なんだろうね
スギちゃんかよだっせーwww
- 824 ：デフォルトの名無しさん (ｱｳｱｳｳｰ Sac3-+wK4)：2020/02/16(日) 00:20:18 ID:s243OsDZa.net
- >>820の人も思いっきり倒錯してるねw
- 825 ：デフォルトの名無しさん (ﾌﾞｰｲﾓ MM0e-BzDP)：2020/02/16(日) 00:28:16 ID:lYNu13iwM.net
- >>823
それより前の問題としてプログラマの意図がまず間違ってんだよ
魚をさばくのにノコギリでやろうとしてる状態
そこを正してからじゃないと話にならない
正さずにむりやり進めようとしてるからボタンクリックエミュレートなどという頭の悪い発想に固執する
挙げ句の果に画面上で見えてないと処理が走らない（涙）なんてバカバカしい罠にどハマリしちゃってるわけだ
はっきり言ってリフレクションはハマりやすいからダメだなんて言ってる場合じゃないよ
- 826 ：デフォルトの名無しさん ：2020/02/16(日) 00:38:37.35 ID:lYNu13iwM.net
- だいたいクライアントのやりたいことは自社アプケーションのオートメーションサポートだろうよ
それを素人の思いつきレベルの発想でUIのオートメーションに目的をすり替えたのが運の尽きだわな
レイヤの考え方が全くわかってないアマチュアの設計だからすんなりうまく行くはずがないんだ
見えてないと発火しないこと以外にいったいどんな罠が潜んでるかわかったもんじゃない
俺が提案した方法ならUIインフラに依存しなくなるから実行時の安定性と罠が少ないぶん高い生産性が期待できる
- 827 ：デフォルトの名無しさん ：2020/02/16(日) 01:57:42.29 ID:iNVxJNOu0.net
- アセンブリが自分や所属チーム/組織のコントロール下にないんじゃないのかな
違う理由かもしれないがそれと同じような制約下での話だと思われる
- 828 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 8361-IGGe)：2020/02/16(日) 03:27:20 ID:QSu9wuIh0.net
- >>803
>GUIの画面をバッチ処理しようとしていて
UiPathとかAutoIt使いな。
- 829 ：デフォルトの名無しさん ：2020/02/16(日) 09:58:00.38 ID:as0AlWv60.net
- >>827
そういうときはUIAutomationかWinAppDriverを使うといいよ
どうせこのあと要求がどんどん増えてボタンクリックだけじゃ済まなくなるんでしょ
あとで苦労するハックはやめてマイクロソフトが整備してる道具を使おう
- 830 ：デフォルトの名無しさん ：2020/02/16(日) 11:26:32.12 ID:j/dbz9ZG0.net
- >>826
まあその「俺のプログラムが一番だ」という姿勢は俺は嫌いではないし、
むしろプログラマは全員持つべきだとも思うけども、
動的結合の価値（意味）が分からないのなら、まずはそこを理解した方がいい。
現在、Clickイベントをエミュレーション出来ないGUIフレームワークなんて、存在してない。
リフレクションも割と一般的になりつつある。(常用するのはどうかとも思うが)
だから、使いどころはあるんだよ。
静的結合だけでやれ、みたいなのは言ってしまえばC++がそうだが、それでもRTTIは検討されている。
動的結合の価値は>>823も書いてくれているが、同様に以下でも触れられている。(これらだけでもないが）
https://www.atmarkit.co.jp/fdotnet/dotnettips/270performclick/performclick.html
言ってしまえば「実行速度を捨てて保守性を採る」わけであり、これが適切かどうかは状況によるので、
PerformClickやリフレクション等を使うこと自体が間違いだ、というのはさすがに行きすぎてる。
(なお既に言ったが、速度至上主義のC++は割とそういう思想だし、これも間違いでもないが）
ただそれはさておき、PowerShellは使ったこと無いから調べてみたが、確かに面白いものではある。
ポイントは、.NETオブジェクトをインスタンス化出来ることと、それらをパイプで流せる点か。
>>822を見る限り、C#等CLRな物ならリフレクションで内部の関数をぶち抜いて、自在に呼べるのか！
(名前があやふやだが確か）COMでも似たようなことをしていたMSならあり得るか！とも思ったが、
そうではなくて、自分で.NETクラスをインスタンス化して呼べるだけか？
まあそれでもリフレクションを使えば何でもありにはなるし、
.NETを使うだけで本式のバッチスクリプト環境が自動的に提供されてしまう、というのは画期的ではある。
ここら辺はMSの上手いところだとは思う。
- 831 ：デフォルトの名無しさん ：2020/02/16(日) 11:28:34.74 ID:j/dbz9ZG0.net
- >>823
俺も「仕様バグ」に近いものだとは思うが、おそらくMSはそう認識してないと思う。
理由は、.NETは比較的「仕様バグ」は少ない環境であり、これは、
・MSがガッツリ保守している
・バイナリ側がランタイムのバージョンを指定出来るので、改訂しやすい
為、「仕様バグ」を後方互換性の為に残す必然性がほぼ無いからだ。
少なくともobsolete(非推奨)にすることは簡単に出来るのだが、してない。
多分何か理由があるのだろうけど、俺には分からない。
なお後知恵だがDobonには書いてある。
> ただし、コントロールのCanSelectプロパティがfalseの時は、PerformClickメソッドは何もしません。
> 例えば、コントロールのVisibleプロパティがfalseの時、CanSelectプロパティはfalseとなります。
> https://dobon.net/vb/dotnet/control/performclick.html
Dobonは、というよりMSDN以外は基本的に見ないことにしていたのだが、妙な嵌り方をした場合は役に立つのかも。
なお他にも
> クリックの動作と同じ動きをするため、EnabledプロパティやVisubleプロパティが"False"の場合、
> PerformClickメソッドを呼び出しても何も実行されません。
> https://www.ipentec.com/document/csharp-simulate-click-event
- 832 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 1ede-sep5)：2020/02/16(日) 11:51:40 ID:4ZDOKfwJ0.net
- >>830
なにこの
メソッドにすりゃいーじゃん
以上の意味を見いだせない機能
- 833 ：デフォルトの名無しさん ：2020/02/16(日) 12:09:21.49 ID:qmeSH89zM.net
- >>830
そのリンクの先はかなりクソコードだから鵜呑みにしないほうがいいぞ
まあ2005年の錆びついたものだしもともと低スキル向けの記事だからしょうがないけど
この記事の悪しき前提はViewに処理をベタ書きしちゃってることな
本来ならViewとModelを分離してView上のメニューとボタンからModelの同じメソッドをコールするのが正しい設計な
ViewとModelを分離してModelがViewに依存しなくなればModelをUIインフラから切り離して独立させることができる
そうすればオレオレスクリプトでオートメーションをサポートするといった要求にも容易に応えることができるようになる
UI操作をエミュレートするなどという泥臭いハックに頼らなくて済むのだ
- 834 ：デフォルトの名無しさん ：2020/02/16(日) 13:03:06.69 ID:j/dbz9ZG0.net
- >>833
このページのコードと用例が糞なのは事実として、エミュレーションが適切な場合もあるってことだよ。
だから現在の全てのGUIフレームワークはエミュレーション出来るようになってるし、
リフレクションも装備しつつある。
MとVを厳密に分離してVはMのラッパ扱いに留めろ、というのは現在の思想としては正しいとして、
2005頃には今ほど言われていなかった、というより、そのころの失敗を経て現在の思想があるわけだから、
このページに対してそれを言ってもしょうがない。
ただそれにしても、現在もまだエミュレーションの価値はあると思うよ。
今回の点に関しての不満なら、俺は
MS:「OnClickがprotectedで呼べないからPerformClickを用意しました」
俺:「なら最初からOnClickをpublicにしとけよ」
であって、private至上主義という勘違いオブジェクト指向の面影を.NETもまた引きずっている点についてだね。
- 835 ：デフォルトの名無しさん ：2020/02/16(日) 13:23:09.50 ID:If0Pwz/d0.net
- >>834
ウンコをいじる正当性を探すな
- 836 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 477b-yNzz)：2020/02/16(日) 14:00:28 ID:j/dbz9ZG0.net
- エミュレーションの有用性が分からないのは根本的に経験が足りない。
何故現在の全てのGUIフレームワークがその機能を持っているのか、その意味をよく考えた方がいい。
そしてそのレベルの奴がコードの善し悪しを議論するのは5年早い。
ただ、このレベルの初心者と話をしても意味がないから俺はやる気無い。
お前らが正しいのなら、MSは数年以内に.NETからエミュレーション機能、
つまりPerformClick/OnClick/リフレクション等を全削除することになるが、
俺はこれはあり得ないとしか思えない。
正否は結果で判断でいい。
ここで低レベルな水掛け論をやる意味はない。
- 837 ：デフォルトの名無しさん ：2020/02/16(日) 14:16:23.77 ID:If0Pwz/d0.net
- こんなクダンネーモン作ってる暇があるならメッセージボックスが後ろに回らないように修正しろ
- 838 ：デフォルトの名無しさん ：2020/02/16(日) 14:20:38.32 ID:WhOeRDRvd.net
- >>814
nugetにあるよ。
- 839 ：デフォルトの名無しさん ：2020/02/16(日) 14:36:14.03 ID:t/nUwzcTM.net
- >>834>>836
UI操作をエミュレートする需要があることは間違いではない
がしかしそれはUIコンポーネント実装のためだったりテストフレームワークのためだったりソースにアクセスできないGUIアプリケーションのオートメーションのためだったりであって
自社アプリにオートメーションサポートを実装するための基盤ではない
それをサポートを実現するまっとうな設計はUI層に依存しないAPIやCLIの提供であってUI操作とは全く逆の考え方だ
お前はノコギリにだって役目と需要があると言ってる
しかしノコギリは魚をさばくのには適さない
無論無理をすればノコギリで魚をさばくことはできるがそれはバカのやることだ
- 840 ：デフォルトの名無しさん (ﾜｯﾁｮｲ af97-hMlH)：2020/02/16(日) 15:56:01 ID:4YtH0n6X0.net
- 年末年始年始に非同期処理で騒いでた人かな
- 841 ：デフォルトの名無しさん (ｱｳｱｳｳｰ Sac3-+wK4)：2020/02/16(日) 18:17:51 ID:vSVyAtifa.net
- >>839
あんたも相当しつこいねw
俺は質問者さんと別人だけど、ボタンやメニューのクリックをシミュレートしたい
場面というのは実際問題しばしば存在するよ
例えばクリックすると何か処理が走るボタンが複数あるとする。
この時、これを全部クリックしたのと同じ機能を果たすボタンが欲しい、
なんていうのは割とありがちな話。
あと、クリックで同じ機能を果たすボタンとメニューが存在する、なんてしょっちゅうある。
この場合はメニューの方のクリックをシミュレートするのが普通だと思うから
件の話を正当化する材料にはならないけどね。
- 842 ：デフォルトの名無しさん ：2020/02/16(日) 18:27:35.97 ID:Oyf7AnZI0.net
- >>841
えー、それにこれ使っちゃうのはキチガイだろ
チェック関連全部走ってから
本処理行くだろ
- 843 ：デフォルトの名無しさん ：2020/02/16(日) 18:32:01.24 ID:j/dbz9ZG0.net
- >>839
「UIに依存する」のではなく、「UIの代替を提供する」のであって、
UIが変更された場合にはUIと同じく変更されるのが正しいんだよ。この点が違う。
そしてソース変更無しで自動追従させる手法がエミュレーションになる。
「UIに依存する」というのは、UIとは本来関係ない事をUIを通してやってしまっていることにより、
UIが変更された場合に動かなくなって困る（動作が変わってしまう）ことを言ってるだろ。
そうじゃない。今回はそこは動作が変わるのが正しいんだよ。
それはさておき、PowerShellって流行ってるのか？
思想が面白いのは認めるが、これはつまり「.NETアプリをライブラリとして公開する」訳であり、
ガチのプログラマに対してソース公開して、後はお前が頑張れ、と言っているに近い。
勿論これで行ける奴はいいが、実際のところ、使う側はアプリを使いたいのであって、
ソースを読みたいわけでもなく、プログラミングしたいわけでもない。
そしてアプリと完全に密結合してしまうから、そもそも同レベルのプログラマじゃないとソースは読めない。
だから現実的に、アプリ+PowerShellで何とかしろ、と言われても、プログラマでも困ると思うが。
ただし再三言っているが、思想が面白いのは認める。
これにより、全ての.NETアプリはPowerShellライブラリとして動作し、
また、ガチのスクリプト環境が手に入るわけだ。これ自体は（有用性はともかく）面白い。
- 844 ：デフォルトの名無しさん ：2020/02/16(日) 19:25:18.98 ID:tfQsIfqsM.net
- >>841
どちらもボタンクリックをエミュレートする必要はない
上の例はクリックで実行される処理を順に実行するだけ
下の例はメニューとボタンから同じ処理を呼ぶだけ
- 845 ：デフォルトの名無しさん ：2020/02/16(日) 19:46:27.53 ID:tfQsIfqsM.net
- >>843
つまりお前が言いたいのは
スクリプティング機能の定石に反する糞仕様こそを求めているので今回に限り馬鹿なことをするのが正しい
ということか
PowerShellは流行ってるというかWindowsのシステム管理ではほぼ必須
OSにプレインストールされてるから開発環境用意するまでもないちょっとしたツールを作るのにも便利
今まさに話してるDSLを手軽に実装するための基盤としてもしばしば使われる
LinuxやMacで仕事してるなら触る機会ないだろうけどWindowsで開発してるなら触る機会は無数にあるはず
- 846 ：デフォルトの名無しさん ：2020/02/16(日) 20:13:22.98 ID:lt2wlhEH0.net
- >>803
おいもうそろそろこの話題締めて他所にいってくれや。
- 847 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 167b-4wVb)：2020/02/16(日) 20:16:51 ID:ZkXecQUS0.net
- ふらっと荒らしてこっち荒らして、いつも同じメンバーだろこれ
- 848 ：デフォルトの名無しさん (ｵｯﾍﾟｹ Src7-oFCC)：2020/02/16(日) 20:22:19 ID:+zL5Le7jr.net
- もともと完全にちゃんとＧＵＩ操作したいなんて書いてないだろさ
途中から見てる人が勝手に条件を足してるだけで本来あるべき姿とかい離してる
途中で無駄にリフレクションが出てくるあたり初心者の匂いが出てる
ボタン押すにはタブを切り替えなくてはならないのに
画面が変わらないままでボタン押したいって言ってるから別にＧＵＩ操作自体を再現したいわけじゃない
- 849 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 477b-yNzz)：2020/02/16(日) 20:24:37 ID:j/dbz9ZG0.net
- >>845
違う。定石に反しているのは君の方で、つまりはカッコイイソリューションを目指しすぎている。
馬鹿みたいなソリューションの方が、現実的に使いやすいことは多々ある。
多分、ちょっと若すぎて元気がありすぎるのだと思う。
これ自体は悪いことではなく、むしろ上達には必須の性格で、良いことだとは思うが、
世の中のアプリがどうなっているか、もう少し周りを見た方がいい。
GUIの自動化で一番簡単なソリューションは、GUIを記録してしまうことだ。…(A)
俺が昔使ったアプリだと、「ログ画面」にGUI操作と等価のコマンドが一々流れる、というのがあった。
そして自動化したい場合は、このログ画面内の該当部分をコピペしたファイルを読ませるだけ、というものだ。
当然、見れば分かる程度であり、例えばファイルを読み込んだらそのファイルパスがまんま表示されている。
なら、そこを変更するだけで同じ処理を他ファイルに適用出来るよね、というわけだ。
冷静に考えれば分かるが、Unixのshもこれと同様だ。（というより上記方式がshのパクリだが）
shもhistoryで出てくる履歴をコピペすればバッチファイルになるようになっている。
そして必要なら該当部分を変数化してループを回せ、ということでしかない。
俺は使ったことないけど、Webブラウザの自動化ツールとして有名なSeleniumも以下見る限り似たようなもんだ。
https://www.valtes.co.jp/qbookplus/509
だから、初段階のスクリプト環境はこの程度でいいし、実際、この程度でも相当有益なんだよ。
そしてそれを手っ取り早く実装する方法がGUIのエミュレーション(PerformClick等）になる。
だから、
> 自社アプリにオートメーションサポートを実装するための基盤ではない
これはちょっと意識が高すぎる。（気持ちは分からなくもないが)
PowerShellでオートメーション、というのはその先の先の先位で、
初期段階に於いては超オーバースペックでしかない。
そして殆どのアプリでは最終的にも必要としない。
- 850 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 477b-yNzz)：2020/02/16(日) 20:25:18 ID:j/dbz9ZG0.net
- 例えば上記アプリ(A)方式だと、ループ機能すらないのだから、
アプリ(A)だけで100個のファイルに同じ処理を適用しようとすると困る。
そこでループ機能を、とか言い出すと色々他が必要になって結局PowerShell、という思想もありだが、
そうではなく、Perl等でファイル名だけ変更するスクリプトを作り、
それでループを回して作ったドベタに展開された糞長いバッチファイルをアプリ(A)に流し込む、
というのもありなんだよ。
全ての処理を自アプリでやろうとするから無理が発生する。
unixはこれと逆で、他コマンドで出来ることは自コマンドでするな、で上手く行ってるだろ。
ソースコードについてもそうだが、アプリについてもKISS原則は重要なんだよ。
そして話を戻すと、UIの自動化のド定番は「実際に行われたUIを記録してそのまま流すこと」であり、
「PowerShell等のガチスクリプト環境と連携すること」ではない。
だからクリックエミュレーション等も今のところは今後とも必要な機能でしかない。
が、まあ、PowerShellを推す気持ちも分からなくはない。
おそらくIEだとPowerShellで自動化出来ると推測されるので、
IEが天下取っていたときに自動化の流れが来てたら少しは違ったかもしれん。
- 851 ：デフォルトの名無しさん ：2020/02/16(日) 20:55:58.19 ID:tfQsIfqsM.net
- >>849
無知すぎて呆れる
世の中のサービスやアプリをちゃんと見てみろ
APIやCLIをサポートすることは多々あってもGUI操作をサポートしてるものなどごく少数派だ
UIとは読んで字のごとくユーザーのためのインターフェースであって自動化のためのインターフェースではない
APIとはアプリケーションプログラムのためのインターフェースであり自動化をサポートするならこちらを提供するのが当然の選択だ
APIやCLIのサポートが定石であってGUI操作は邪教徒の好む黒魔術でしかない
お前の常識は多分10年か20年前の辺境の集落での常識だ
現代のグローバルスタンダードに追いつく努力をしてくれ
- 852 ：デフォルトの名無しさん ：2020/02/16(日) 21:13:00.97 ID:as0AlWv60.net
- >GUIの自動化で一番簡単なソリューションは、GUIを記録してしまうことだ。…(A)
>俺が昔使ったアプリだと、「ログ画面」にGUI操作と等価のコマンドが一々流れる、というのがあった。
>そして自動化したい場合は、このログ画面内の該当部分をコピペしたファイルを読ませるだけ、というものだ。
>当然、見れば分かる程度であり、例えばファイルを読み込んだらそのファイルパスがまんま表示されている。
>なら、そこを変更するだけで同じ処理を他ファイルに適用出来るよね、というわけだ。
これ、昔作ったことが有るけど、最も上手くいった方法はMVCを徹底して、Cの入り口でコマンドオブジェクトをシリアライズして記録するパターンだったな
やってみればわかると思うけど、画面コントロールの操作ログを正確に記録するのも、再生するのも、一筋縄ではいかない
- 853 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 639e-oFCC)：2020/02/16(日) 21:16:30 ID:yo/bSae/0.net
- COMで解決された問題を20年以上経って議論してる・・・
- 854 ：デフォルトの名無しさん ：2020/02/16(日) 21:58:35.37 ID:5ncsgUM20.net
- この話題をすり替えつつ自分の正当性をゴリ押しするスタイル、最近見ましたよね
明後日くらいには全然違う話題になってるぞきっとｗ
- 855 ：デフォルトの名無しさん ：2020/02/16(日) 22:11:19.84 ID:x7wMnJYb0.net
- 荒らしてるの毎回同じ人だよね
書き方に癖があるからすぐわかる
- 856 ：デフォルトの名無しさん ：2020/02/16(日) 22:21:29.37 ID:Z1hWCcVDa.net
- >>844
繰り返しになるけどね、そういう「プログラマの意図と実際のコードに乖離がある」
ことをやると別の仕事が増えるでしょ。
ボタンABCDEが全部クリックされたのと確実に同じことが起るって誰が確認して保証するの？
ボタンABCDEのクリックイベントの処理を後で変更した時、またそれをやりなおすの？
その確認作業を忘れたらどうするの？
こういう後の保守のことを考えないプログラマは愚鈍で無能。
倒錯してるよ君。
「する必要はない」のは、「クリックで実行される処理を順に実行する」なんて保守性を下げる
アホな手段を採用すること。
なぜ素直にボタンクリックをシミュレートしようとしないの。
- 857 ：デフォルトの名無しさん (ﾌﾞｰｲﾓ MM0e-BzDP)：2020/02/16(日) 22:40:57 ID:q02FpFyRM.net
- >>856
プログラマの真の意図は
ボタンを押したら複数の一連の処理をまとめて実行したい
メニューとボタンで同じ処理を実行したい
だろ
君が好きなボタンをエミュレートする方法は上記のプログラマの意図を実現する遠回りなやり方の1つだ
誰が確認するの？確認忘れたらどうすんの？なんて質問は自分は仕事でコード書いたことありませんと言っているようなものだから控えたほうがいい
テストを自動化するか人がやるか誰がやるかはチーム次第だがいずれにせよテストをしないわけがないではないか
そしてテストをするのはボタンをエミュレートする方式だろうが他のどうな方法だろうが同じことだ
まるで暗にエミュレートならテストを省略していいような言い方をするとああこいつはアマチュアなんだなとバレてしまうぞ
ちなみにテストの心配をするならなおさらUIに依存しない方式で書いたほうがいい
そうすればテストの自動化が容易になるから君が気にしてるテスト工数の増加やリグレッションの発生確率も最小化することができる
UIのエミュレートが正しく行われたことをテストするのはUI非依存のテストと比べると面倒な作業だよ
まあこんへんはアマチュアにはわかりにくいメリットかもしれないね
- 858 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 122c-LiuO)：2020/02/16(日) 22:47:15 ID:5EL9p8ON0.net
- Seleniumデザインパターン&ベストプラクティス、2015、オライリー
この本は、Ruby, Selenium WebDriver でのテスト手法を書いた本
例えば、Ruby, Selenium WebDriverで、
Yahoo への自動ログインするスクリプトは、下を参照
【VBScript】WSHについて話し合うスレ【JScript】
https://mevius.5ch.net/test/read.cgi/tech/1578522041/27
- 859 ：デフォルトの名無しさん ：2020/02/16(日) 22:59:33.28 ID:jBsklMHb0.net
- そしてさも当然ように混じり込むいつものRubyキチ
- 860 ：デフォルトの名無しさん ：2020/02/16(日) 23:43:22.86 ID:j/dbz9ZG0.net
- >>851
だから君は意識が高すぎるんだよ。
誰もAPIを欲してないし、スクリプトを書きたいとも思ってない。
GUIを自動化したいだけ。
そして君だって、1つや2つのファイル名の変更は、普通にエクスプローラで行うだろ。
勿論APIは整備されていて、コマンドプロンプトでren fileA fileB と打つだけなのに。
GUIの方が簡単だから、GUIで済む場合はGUIを選択する、これが普通だ。
勿論100個と言われたら考えるが、10個程度なら普通はそこでAPI調べてDSLとはならない。
理由は、10個程度なら我慢出来る範囲で、DSLを書く方が時間がかかるからだ。
そしてこの原因は、DSLの方言が酷く、オレオレアプリのDSLなんて書いてもすぐには動かないからだ。
だから「今やった操作をする為のスクリプト」が吐かれ、それをコピペすればすぐ動く、というのは優れたAPIではあるんだよ。
ただ、根本的な原因は既に言ったが『方言が酷すぎる』事だから、それをPowerShellで統一する、という野望は、
方向性として合ってるから悪くもない。
でもそれが達成出来てるとは全く思わないけど。
Unixの「テキストファイル/テキスト操作ツール群/ファイル操作」で統一しているシステムが出来が良すぎて、
結局WindowsもWSLやDockerを導入してる有り様だろ。
話を戻すと、PowerShell+APIでPerformClickが不要になる、なんて事にはなってないし、今後ともならないよ。
GUIの方が直感的で簡単だから世の中GUIな訳で、その操作を自動化するのならエミュレーションは一つの正しい解だ。
ただ、PowerShellの野望は面白いと思うし、なったらなったで俺は普通にそっちに乗っても問題ないけど。
そしてPowerShellが本当に面白いのは、.NETアプリならリフレクション使って何とでも出来ることだろ。
プロセスへのアタッチ機能も有るようだし、APIなんて無くてもやりたい放題だ。
これが、そそる、というのは分かる。
- 861 ：デフォルトの名無しさん ：2020/02/17(月) 00:04:24.35 ID:afVseoTo0.net
- >>852
それがすんなり行くかどうかはアプリの作りによる。
例えば、VSのコンパイル機能は csc.exe へのフロントエンドでしか無く、コマンドラインオプションを作るだけの物ではあるだろ。
こういう場合は至って簡単で、そのまま吐くだけで済む。
上手く行かなかったとしたら、前回の内部状態と混線したのだろうけど、ぱっとは思いつかないね。
普通にアプリを作ってしまえば当然再現性はあり、
どのボタンを押したかをそのまま記録/再生すれば当然同じ結果は生成される。
それらを「人間が見て分かるそれなりのコマンド名」に落とし込むのは大変だろうけど、ぶっちゃけ、
CONTROL Button インスタンス名 Click
程度のDSLならその心配もない。
これ以上に格好良くしようとすると、色々大変なのは分かるが、正直、この程度でもDSLとしては十分だから問題はない。
(ちなみに一応言っておくと、Buttonのみならず、他全て、例えばradioButtonやNumericUpDown、TextBox等、
内部状態を変更するGUIコンポーネントについては全てこの方式で記録/再生してる。
そりゃ再生出来るに決まってるだろ、というのは分かると思う）
- 862 ：デフォルトの名無しさん ：2020/02/17(月) 00:55:46.18 ID:b+8cPYAUM.net
- >>860
いやいや誰もUI操作を自動化したいとは思ってない
UI操作の背後で行われてる処理を使ってマクロを組みたいんだよ
ユーザーは無知だからUI操作をエミュレートする方法しか思いつかないんだろうけど開発者はそれじゃいけない
俺は名前変えるときでもコマンド打つけどねgit mv a bってさ
つうかそういう話じゃないよ
普段GUIで作業してようがなにしようがオートメーションしたいならGUI操作じゃなくAPIが整備されてたほうが嬉しい
それが当たり前の感覚であってAPIよりGUI操作のほうがいいなんてのは変人の考え方だ
UI操作するオレオレDSLなんてまあバグだらけだろうな
UI操作の不安定さなんてテスト自動化してる人なら誰でも身を持って経験してるからエンドユーザに提供するマクロ機能としてUI操作を強要するとかありえん
UI操作に加えてDSLまで独自開発なんてしてたらバグだらけのうえに開発機能までショボくて使い物にならんだろうな
PSみたいな既存言語に乗せればインタプリタの開発はマイクロソフトとコミュニティがやってくれる
デバッガなど含めた開発環境もノーコストで手にはいる
ユーザーは快適な環境でマクロを弄ることができるわけだ
オレオレマクロのユーザーは不憫だな
PerformClickはUIコンポーネントの開発者などが使うかもしれんから不要にはならないだろう
だがオートメーションサポートするのに依然としてPerformClickは必要ないな
UI非依存のAPIを提供するだけでいいのだからUIを操作する意味がない
人間が操作するときに直感的でわかりやすいといっても自動化に適するわけでもあるまい
自動化したいなら人間ではなくプログラムから見て呼び出しやすい構造を提供する必要がある
それはアプリケーションプログラミングインターフェースのことであってUI操作ではない
PSの面白いところはリフレクションとか意味わからんこと言うな
PS普通に使っててもリフレクション使ったコードなんて滅多に書かねえよ
- 863 ：デフォルトの名無しさん ：2020/02/17(月) 01:21:39.40 ID:HQMlSi3n0.net
- 処理の冒頭だけで途中でメッセージボックスが表示されてさらにユーザの追加入力が必要な処理はこれ使えねぇだろ
まさにゴミだろキングオブゴミだろ
- 864 ：デフォルトの名無しさん ：2020/02/17(月) 11:36:19.89 ID:7RiN2OZY0.net
- ThreadPool を使って、非同期に処理を実行しています。
特定のタイミングで ThreadPool に溜まっている処理を全て削除したいのですが、どのようにすればよいでしょうか。
// Threadの登録
ThreadPool.QueueUserWorkItem(new WaitCallback(ThreadMethod));
// ThreadMethod の処理が終わる前に abort させたい
スレ違いなら、誘導してもらえると助かります。
- 865 ：デフォルトの名無しさん (ﾜｯﾁｮｲ f2cf-OxJ8)：2020/02/17(月) 12:34:12 ID:7ui4xGiq0.net
- 古すぎるコード
- 866 ：デフォルトの名無しさん ：2020/02/17(月) 13:00:54.86 ID:uup53KRg0.net
- >>864
CancellationToken(CancellationTokenSource.Token)
- 867 ：デフォルトの名無しさん ：2020/02/17(月) 13:25:50.80 ID:YCC5nnQ0a.net
- >>857
なんか話が噛み合ってないね。
ボタンABCDEを全部クリックしたのと同じことが起るボタンが欲しい、という要件が発生した時、
その責務をモデルに持たせるべきか、むしろUIレベルでやってしまった方がよいかは微妙で
ケースバイケースだと思う。
俺は後者の場合の話をしています。
これまでの流れからそれは自明だと思うけど。
どうでもいいけどこういうのってemulat"なの？
simulateでしょ？俺の認識がおかしいのかな。
emulateって言葉はこの世界ではハードウェアの機能をソフトで代替するって
ニュアンスが強いと思うんだけどどうかな
- 868 ：デフォルトの名無しさん ：2020/02/17(月) 13:37:48.80 ID:YCC5nnQ0a.net
- まああれだ、ボタンクリックをシミュレートするなんてなんかダサい、という
中二病的な発想は（同意はできないけど）理解はできないでもない
そういう人は「プログラマの意図と実際のコードに乖離がある」 ことの方には気持ち悪さを感じないんだねw
っていうか理解できないのか。>>857の人もそうだと思うけど。
だから、プログラマの意図というか要件は「ボタンABCDE全部が押されたのと同じことを起こすボタンが欲しい」
なんだけど。
- 869 ：デフォルトの名無しさん ：2020/02/17(月) 14:03:27.84 ID:/fXse39B0.net
- 俺なら「ボタンが同時に押されないように作る若しくは押されても一つだけ有効にする」で組む方を優先するわ
- 870 ：デフォルトの名無しさん ：2020/02/17(月) 18:09:56.85 ID:qOh2XpnLM.net
- >>867
微妙、ではなくモデルに持たせるのが正解
>>868
中2とか意味わからん理由ではなく実益をとっただけ
理解しやすさ、テスタビリティ、変更への耐久性、等を考えればボタンクリックは、無い
プログラマ意図をコードに反映することは良い習慣だが
判断を誤ったプログラマの意図をコードに反映させることを正当化してはいけない
まずは判断を正してから意図をコードに落とし込もうね
- 871 ：デフォルトの名無しさん ：2020/02/17(月) 18:50:47.45 ID:q0kZWH/L0.net
- ﾜｯﾁｮｲ 477b-yNzz
ﾌﾞｰｲﾓ MM0e-BzDP
ｱｳｱｳｳｰ Sac3-+wK4
いつまで続ける気だよ役立たずどころかクソ迷惑
- 872 ：デフォルトの名無しさん ：2020/02/17(月) 19:14:45.43 ID:vEzx9LASM.net
- >>871
C#のスレでFormsについて話し合うことの何が問題なんだ？
もともとはVC++だったけどこの話題はC#でも通じる話だからここで話してもなんの問題もないはずだ
- 873 ：デフォルトの名無しさん ：2020/02/17(月) 19:45:45.35 ID:afVseoTo0.net
- >>862
まあ君がどうしてもPowerShell推しなのはわかった。
> UI操作するオレオレDSLなんてまあバグだらけだろうな
それはオレオレDSLに無理に高度な機能を持たせすぎてるから。
つるんと書かれたDSLをただ上から順番に実行するだけ、しかもエミュレーションの時に、
何行のコードを追加し、何行の既存コードを変更する必要があると思ってるんだ？
面倒だから答えを言ってしまうが、追加が30-50行程度、既存変更は0行、つまり変更無しだ。
エミュレーションが開発的に強烈なのはこの、完全に外付け出来る点だ。
>>856,857の争点もここで、俺は849と思想が同じく、「そもそもテスト項目を増やすな」でしかない。
だからバグっててもDSLモジュール内で閉じてて精々DSL機能が使えなくなるだけで、
追加テストはエミュレーション部分のみ、というのは十分魅力的なんだよ。
そして君はAPIAPI言っているけど、PowerShellには特にAPIを用意する必要があるわけではないだろ。
publicにしてある関数を勝手に呼ぶだけ、精々ドキュメントを整備するくらいだ。
当然リフレクションを使えば内部関数等は全部抜けるので、呼ぶだけならいくらでも出来る。
リバースコンパイラを使えば分かるが、リフレクションでも割と読めるコードが得られる。
後は好きなだけハッキングしろ、でしかない。（これを、そそる、と言っている)
- 874 ：デフォルトの名無しさん ：2020/02/17(月) 19:46:35.47 ID:afVseoTo0.net
- あと、PowerShellにこだわりすぎて、強力なDSLなんてPowerShellでしか得られないと思ってないか？
気づいていないんだろうけど、「テキストファイルで操作する」というのはUnixのAPIであって、
そこに揃えるだけでUnix周りのツールが全て使えるようになるんだよ。
具体的に言うと、DSLソースをファイルではなく標準入力とすれば、
(一応言っておくがC#等GUIアプリもコマンドラインから起動すれば普通にパイプできる)
その前段のツールが標準出力に「CONTROL Button instancename Click」と吐きさえすれば自動化できるのだから、
PowerShellみたいな糞文法につき合う必要もなく、言語も選べる。当然、C#やPythonも使える。
これも一応具体的に言っておくと python myscript.py | my.NETapp.exe な。
だから高級なDSLが欲しいにしても、フルスペックのDSLを自前で持つ必要なんてまるでなくて、
自アプリ内はアホみたいに「食わされたコマンドを処理して終わり」なDSL実行部分だけで十分なんだよ。
それで後はAWK/Perl/Python/Ruby等、好きな言語使って勝手にやってくれ、になる。
つまり30-50行程度追加し、既存部分にバグが発生することもなく、
AWK/Perl/Python/Ruby等好きな言語を使って自動化出来るのがエミュレーションの利点であり、
Unixインタフェースに揃える美味さだ。だからみんなここから離れられない。
- 875 ：デフォルトの名無しさん ：2020/02/17(月) 19:47:56.86 ID:afVseoTo0.net
- >>867
一応調べてみたが、この場合は微妙だし、どっちでも良いと思う。
> https://hinative.com/ja/questions/11390949
> https://xcelgo.com/emulation-vs-simulation/
要は、中身まで模倣するのがemulationで、外面だけ合わせるのがsimulation。
よって実行速度は通常simulator>>>emulatorになる。
void Button_Clicked(Object^ sender, EventArgs^ e) {
some_func();
}
で some_func を直接呼ぶならsimulation、
Button_Clicked を呼んでもまあsimulation、
OnClick や PerformClick を呼ぶならemulation、というのが俺の見解。
emulation扱いの2つはClickイベントを発生させる＝UIスレッドのイベントキューに積むだけであり、
ハードウェアマウスのイベントと見分けが付かないから。
（内部的にハードウェアマウスのクリックを模倣している）
対して上記simulation扱いの２つは、
simulatorが「このボタンをクリックしたら結果的にこの関数を実行する」と知っていて、
外面動作を合わせる為にそこを呼んでいる。
当然emulationの実行速度はsimulationと比べて遅い。
だから、最初からsome_func()呼べよ、という若さは分かるが、そこをケチっても実質的意味はない。
ここら辺は年を取れば老獪になるというか、手の抜きどころが分かるようになる。
emulation方式だと当然、UIスレッドがハングアップしていたら永久に処理されないし、
未処理のイベントがあればその後に処理されることになる。
ここら辺は完全にハードウェアマウスの動作と同じになる。
simulation方式だと、すぐに呼ばれる為、
非UIスレッドでDSLを処理した場合、未処理のUIイベントがあると処理順序が逆転してしまう。
だから、DSL実行環境とGUIの実行環境が同一の場合はDSL処理はUIスレッドでやるしかない。
だったら最初からPerformClickでやればそういう心配すらないだろ、ということになる。
- 876 ：デフォルトの名無しさん ：2020/02/17(月) 19:49:07.54 ID:afVseoTo0.net
- 余談だが>>857のUIテストが安定しないのはこの辺が大きい。
要は、GUIなんて所詮人間相手前提で組んであるのであって、
CPUの速度でイベントを積まれた場合にも正しく動くレベルまでのテストは為されていない事も多い。
技術的に見ればアプリが糞で組み方が悪いだけだが、そこまで保証する意味もないのも事実。
結果、「人間がやると動くが、CPUでやると動かない」なんてのは割とよく遭遇することになる。
だからまあ、「UIテストは安定しないから出来るだけ回避」も一つの戦術だが、
「UIテストも安定するようにちゃんと設計する」も一つの戦術なんだけどね。
「安定しない」のはあんまり正当化していい話でもないし、
ちゃんと設計されているアプリしか触ったことのない人にとってはポカーンな話でもあるとは思うよ。
ちなみに、文句を言っている連中に合わせるとしたら、以下のようなDSLにすればいい。
CONTROL Button instancename Click // PerformClickを呼ぶ
some_func() // some_func()を直接呼ぶ
これで、好きな方使えで済む話で、実際も、これに近い。
（当然だがDSL用のコマンドは別に持ってて、全部大文字なのはそれらと被らない為の方策）
- 877 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 1fad-z23p)：2020/02/17(月) 19:55:08 ID:Nkb49BjE0.net
- 議論が発散しててよくわかんないな。
何が何なの？全員、アブストを書いたらどうだ？
- 878 ：デフォルトの名無しさん (ﾌﾞｰｲﾓ MM32-BzDP)：2020/02/17(月) 19:56:33 ID:iNM+ZupGM.net
- >>873
論点をずらそうとしてるね
クソみたいなUI操作オレオレマクロよりUI非依存のPSのが低コストで品質がいいねというだけの話だろ
例としてPSを出したが別になんだっていいよ
最も大きな問題はインタプリタの方ではなくUI操作でオートメーションサポートするというバカバカしい発想の方な
オートメーションをサポートするならUI非依存のAPIを整備しろ
それが正しい道だ
- 879 ：デフォルトの名無しさん ：2020/02/17(月) 20:21:59.64 ID:YeNwIpPfd.net
- 話がまとまってないのに余談とか言っちゃって相手もそれに乗っかちゃって…
これを繰り返すからいつまで経っても収束しないし元の議題が何だったかわかりづらくなる
- 880 ：デフォルトの名無しさん ：2020/02/17(月) 20:24:09.75 ID:afVseoTo0.net
- >>867
>>875訂正、結果的に>>876は間違いなのでよろしく
俺の見解では全部simulationになる。
確認してみたら、PerformClickは同期イベントだった。
呼び出し履歴見る限り、Button.PerformClick->Button.Onclick->Control.OnClick->イベントハンドラ なので、
OnClickもほぼ確実に同期だと思われる。
だから呼称は全て simulation の方が妥当となる。
イベントキューとかは全く関係なくなるので、該当部分の869の話は間違いということでよろしく。
同期イベントなのは.NETの癌だと思っていたが、
この点に関しては同期イベントの方がプログラミングしやすい、というのは事実だな。
(俺の想定の非同期イベントだと俺のコードは動かないはずなのに気づき、確認したところ、同期だったorz)
- 881 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 477b-yNzz)：2020/02/17(月) 20:40:15 ID:afVseoTo0.net
- >>878
> 論点をずらそうとしてるね
お前がだろ。
> UI操作でオートメーションサポートするというバカバカしい発想の方な
GUIの自動化ならGUIのエミュレーションが俺的に第一選択肢だ。
これについては既に>>849で言ったとおり、君が気に入らないのはどうぞご自由にだが、
最近話題のSeleniumでも同様なのだから、君が思うほど糞でもないんだよ。
もっとも汎用的で、もっともカッコ悪いが、どんな馬鹿でも使えるソリューションだ。
そして、やる気になればPerlやPythonと組み合わせて自由自在でもある。
ソースコード戦略にも、テストにも問題がない。ならこれで決まりでいい。
- 882 ：デフォルトの名無しさん ：2020/02/17(月) 21:41:26.92 ID:zVw4OscHM.net
- >>881
Selenium系はAPIを提供してないサイトのオートメーションをユーザーが苦労して泣く泣く自動化したい場合やテスト自動化で使うツールな
俺らが今議論してるのはユーザー目線じゃなくて提供者側なんだよ
提供者側がAPI実装を放棄してGUI操作をサポートするなど馬鹿なことだ
ユーザーに苦労を押しつけてはいけない
- 883 ：デフォルトの名無しさん ：2020/02/17(月) 21:45:10.71 ID:HH3Dtgxka.net
- >>870
複数のボタンを全部クリックした時の動作、なんていう下らない機能を
モデルに持たせることが正当化されるケースってむしろあんまりないと思うよw
ぱっと思いつくのは、ボタンABCDEをクリックした時の処理に共通する部分
（例えばファイルのopen/closeのような前処理後処理）があって、まとめてやる場合には
大幅な最適化が可能な場合。
この人本当にプログラマかな。
- 884 ：デフォルトの名無しさん ：2020/02/17(月) 21:49:38.11 ID:HH3Dtgxka.net
- >>877
白鳥はすべて白い（PerformClickなんて100%ｲﾗﾈ）という人がいるので、
いやいや世界には黒い白鳥もいるんだよ、とまあそういう話
- 885 ：デフォルトの名無しさん ：2020/02/17(月) 22:01:31.09 ID:zVw4OscHM.net
- >>883
その糞設計だと要件変化ですぐにコードが汚染されるだろうなぁ
処理は今までどおり実行したいが特定のボタンだけ画面から削除したくなったせいで謎のHiddenボタンを置いたり
処理の結果で後続の処理を分岐したくなったせいで不自然な制御フラグフィールドが乱立したり
画面のデザイン変えただけなのになぜか処理の実行順序が変わったり
少し想像しただけでトラブルの兆しがするするでてくる
こういう発想はアマチュアらしくて微笑ましいけど業務で見かけたら説教しなきゃいけないぐらいだ
- 886 ：デフォルトの名無しさん ：2020/02/17(月) 22:05:59.99 ID:dzSo2/zk0.net
- >>870
各ボタンに割り当ててるコマンドをcomposite Commandで繋いで終わりじゃない？
- 887 ：デフォルトの名無しさん ：2020/02/17(月) 22:08:44.55 ID:HH3Dtgxka.net
- >>885
よく分からない妄想ワロタw
意味が分からないよ
＞要件変化ですぐにコードが汚染される
まさにその通りw
君の設計方針だと必然的にそうなる。
- 888 ：デフォルトの名無しさん ：2020/02/17(月) 22:09:55.34 ID:HH3Dtgxka.net
- どーでもいい非必然的な機能をモデルに持たせることは、
UIにベタベタ処理を実装するのと同じ糞設計ですw
- 889 ：デフォルトの名無しさん (ｱｳｱｳｳｰ Sac3-+wK4)：2020/02/17(月) 22:28:58 ID:HH3Dtgxka.net
- 一応言い訳しておくけど、>>883に書いたみたいに最適化の恩恵なんかなくても
複数の処理をまとめて一度にやるメソッドをモデルが持つことが自然なケースはもちろん存在すると思う。
っでも俺が言っているのは「黒い白鳥もいる」だからね。
「白鳥は全部白いは間違っている」と言ってるだけだから
- 890 ：デフォルトの名無しさん ：2020/02/17(月) 22:56:12.88 ID:zVw4OscHM.net
- >>887
お前のやり方はではすぐにコードが汚くなるって言ってんの
俺のやり方はメンテナンスしやすいモデルを採用してるからコードの品質が維持される
- 891 ：デフォルトの名無しさん ：2020/02/17(月) 23:01:51.58 ID:zVw4OscHM.net
- >>889
まとめて処理をする機能が要件にあるならそれをモデルに実装するのが王道で自然な方法
お前はそれをボタンクリックなどという大道芸的な方法で実装しようとしてる異端
- 892 ：デフォルトの名無しさん (ﾌﾞｰｲﾓ MM0e-BzDP)：2020/02/17(月) 23:03:21 ID:zVw4OscHM.net
- >>888
そうだ
だからまとめて処理をするという最小限の機能をモデルに実装せよと言ってる
ボタンクリックなどという余計なお遊びは入れなくていい
- 893 ：デフォルトの名無しさん ：2020/02/17(月) 23:09:15.69 ID:HQMlSi3n0.net
- こない未来を予測してる奴はバカ
絶対失敗する
しかも、最悪の形で
- 894 ：デフォルトの名無しさん (ﾌﾞｰｲﾓ MM0e-BzDP)：2020/02/17(月) 23:18:49 ID:43uLIzGsM.net
- >>893
来るかもしれない未来を考えないのも同じぐらい馬鹿だな
そして未来がわからんなら余計な拡張性を導入するのではなくコードを容易に改修できるようにシンプルに保つことが重要
つまりシンプルなモデルにやりたいことを素直に書けばそれでいい
それで済むものをわざわざボタンクリックなんていうやらなくていい遠回りな方法で実装するのは後で困る馬鹿の典型例
- 895 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 477b-yNzz)：2020/02/18(火) 00:50:17 ID:/0BlMKgF0.net
- >>882
だから君はちょっと意識が高すぎるんだよ。
自動化したいユーザーは、今やったのと同じ操作を100個のファイルに適用したいとかだ。
「ログに出てるコマンドをコピペすれば今やった操作を自動化出来ます」との情報を得て、ログを見たら、
CONTROL TextBox filename my000.jpg
CONTROL Button file_load Click
CONTROL Button filter_A Click
CONTROL Button file_save Click
となってたら、まともなプログラマなら適当にスクリプト書いて10分後には完了してる。
そこを「APIを調べてPowerShellでスクリプトを書いてください」だと困る奴の方が多いと思うが。
何でオレオレアプリのAPIをユーザーが一々調べないといけないんだよ？調べるだけで10分かかる。
方法は何でもよく、勿論APIでもいいんだけど、ユーザーは手っ取り早く今の処理を100個のファイルに展開したいだけ。
それには歴史的にも今も「テキストファイル内にコマンド羅列(＝つまりスクリプト)」という方法が用いられている。
これが一番分かりやすいからだよ。
PowerShellの「.NETアプリをインスタンス化して内部関数を直接呼ぶ」というのは発想としては面白いけど、
それが分かりやすいわけでもなく、汎用性があるわけでもなく、使いやすいわけでもない。
まあもうこれは堂々巡りだから終わりでいいが、
君の意見が正しければ、今後は全てのアプリでAPIが公開されていき、MS謹製のUIAutomationなんてゴミになることになる。
俺はそんなことにはならないと思うけど。
- 896 ：デフォルトの名無しさん (ﾜｯﾁｮｲ b7a7-sep5)：2020/02/18(火) 00:57:57 ID:GPdxsdEp0.net
- >>895
だからよ
1処理用の処理を連続で100回動かしたら確認ダイアログが100回出るだろーが
バカかテメーは
- 897 ：デフォルトの名無しさん ：2020/02/18(火) 06:52:39.11 ID:fxDAJd/Ea.net
- 言い合いになるなら
構わなきゃいいのになあw
- 898 ：デフォルトの名無しさん ：2020/02/18(火) 07:50:57.99 ID:LkwV7cyFM.net
- >>895
意識は高くない普通の感覚だよ
当たり前のことを当たり前にやるだけだ
モデルに処理を書いてビューに紐付けるってごくごく自然なコードだろ
しかもそれすればほとんどタダでオートメーションサポート機能が手にはいるんだぞ
ボタンクリックとかわざわざ苦労してトラブルを持ち込んでくる意味わからねえわ
マゾなのか
- 899 ：デフォルトの名無しさん (JP 0H6e-1vH+)：2020/02/18(火) 07:59:37 ID:ZOlvaa/TH.net
- >>896
その程度の回避策が思いつかないようなバカがいるとは
- 900 ：デフォルトの名無しさん ：2020/02/18(火) 08:20:17.01 ID:LkwV7cyFM.net
- >>895
ちなみにこのマクロでわかりやすいと思うのはお前だけだぞ
普通の人だったら
オートメーションなのなんでコントロールを操らないといけないんだ意味わからん
ボタンとかテキストとか書かれても何やってるか意味わからん
各行の関連性が意味わからん
操作してるインスタンスはどのフォームだよ意味わからん
などなど大混乱してしまう
ユーザーが見てわかりやすいレコードログってのは↓こういうものな
$model = $MyAppHost.Resolve("MyModel")
$model.FileName = "..."
$model.LoadFile()
$model.FilterA()
$model.SaveFile()
この処理をたとえばカレントディレクトリ全体に適用したいなーってユーザーが思ったらls | foreachでパイプするだけ
お前の大好きなコード生成みたいなバカバカしい無駄な苦労をしなくて済む
- 901 ：デフォルトの名無しさん ：2020/02/18(火) 08:23:55.17 ID:didWPBin0.net
- >>899
そこ工夫が必要ならこんなくだらんメソッド呼ばんわｗ
- 902 ：デフォルトの名無しさん (ﾌﾞｰｲﾓ MM32-BzDP)：2020/02/18(火) 08:43:22 ID:LkwV7cyFM.net
- >>895
例えばさぁ
お前のオレオレうんこマクロでファイルが存在しなかった場合のハンドリング処理はどうやって書くつもりなんだ？
ファイルの形式が間違ってた場合は？
セーブに失敗したときどうする？
指定したディレクトリツリーのファイルすべて処理したいときはどう書くんだ？
- 903 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 167b-4wVb)：2020/02/18(火) 21:08:13 ID:U5rnBvKT0.net
- 直のWINAPI（というか多分アンマネージ）が混ざる動作だとDebugとReleaseで動き変わること割りとあってめんどくさいな
- 904 ：デフォルトの名無しさん (ﾄﾞｺｸﾞﾛ MM47-P13C)：2020/02/19(水) 07:47:22 ID:bztKe272M.net
- >>903
単なるお前のバグだろ
- 905 ：デフォルトの名無しさん (ﾜｲｰﾜ2 FFdf-IPX/)：2020/02/19(水) 11:28:45 ID:cGULNOoWF.net
- WINAPIのはDebugだと0埋めされるんだろ
そりゃ動作変わるって(バグがあればω)
- 906 ：デフォルトの名無しさん ：2020/02/19(水) 14:38:26.03 ID:xNHctau2M.net
- 0じゃなく埋められる数値は何種類かある
デバッグリリースで挙動変わるのはほぼ確実にメモリ周りでなんかやらかしてるね
- 907 ：デフォルトの名無しさん (ﾜｯﾁｮｲ c37b-1Vd5)：2020/02/19(水) 21:10:46 ID:1xSUjqPH0.net
- >>900
俺はPowerShell知らんから推測文法で勝手に書くと
function apply_filterA(filename){ // (A)
echo CONTROL TextBox filename $finename
echo CONTROL Button file_load Click
echo CONTROL Button filter_A Click
echo CONTROL Button file_save Click
}
ls | foreach apply_filter
とかか？ まあ雰囲気は分かるだろ。どうしてもオブジェクト文法で書きたければ、property使える言語なら
ref class OreOreWrapper { // (B)
property String^ Filename {
void set(String^ filename){echo("CONTROL TextBox filename "+finename);}
}
} model;
とかかな。
俺が用意するのは公式UIAutomationでしか無い。
君は逆に何故UIAutomationがああなのか、また、
何故PowerShellなんて全く流行ってないのか、理解した方がいい。
既に言ったがコード戦略的には他にも色々理由はあるのだけど、それ以前に、
そもそも外面仕様的にも、.NET縛りになる糞APIを提供する意味なんて上記の通り、まるでないだろ。
Unixフォーマット(テキストと標準入出力)に揃えるのは、異様なほど自由度を提供する物なんだよ。
だからみんなそこから離れられない。
- 908 ：デフォルトの名無しさん (ﾜｯﾁｮｲ c37b-1Vd5)：2020/02/19(水) 21:11:45 ID:1xSUjqPH0.net
- 君が間違えているのは、君が出来ているつもりになっている「レイヤー設計」だ。(>>826)
君の中ではPowerShell(中レベル)/アプリの2層しかないから
中レベルAPIをアプリ自体に求め、それで汎用性が全くなくなっている。
そうではなく、各言語向け中→低レベル変換ライブラリ（上記A,B等）を噛ませば、
各言語(中レベル)/各言語向けレベル変換ライブラリ/アプリ(低レベル）となり、
全ての言語で中レベルでも低レベルでも書ける状況になるだろ。
俺の好きなフォーマットで書かせろ、というのはいいが、それはAPIに直接求めるものではない。
どうせどんなAPI/フォーマットを提供したところで、全員が満足する事なんて無いんだ。
なら、上記のように、単純な関数化/ラップでそれぞれのオレオレ超最高フォーマットが手に入るのなら、
それは素晴らしいAPIってことになるんだよ。
そして本件なんて、文句を言った方が恥ずかしくなるレベルなのは君でも分かるだろ。
- 909 ：デフォルトの名無しさん ：2020/02/19(水) 22:47:18.69 ID:Z9/2no0YM.net
- >>907
まる一日以上かけてそれかよ
そんな汚いわかりにくいコードをありがたがるのはお前だけだぞ
さて>>902に答えるのに何日かかるかなｗ
- 910 ：デフォルトの名無しさん ：2020/02/19(水) 22:52:36.17 ID:Z9/2no0YM.net
- >>908
ホント残念なやつだな
アプリの中にさらに層が別れてるに決まってんだろ
それぞれの層をスクリプティング用に公開することもほぼノーコストでできる
薄汚いオレオレラッパーを大量生産する苦痛とは無縁だ
そんなこた言わなくてもわかることなんだがわからなかったか
- 911 ：デフォルトの名無しさん (ﾌﾞｰｲﾓ MMff-o/5i)：2020/02/19(水) 23:21:51 ID:Z9/2no0YM.net
- >>907
つうかな自由とハックを混同するな
そういうのは黒魔術的な方向に進化してあっという間にカオス化して行く
そんなものはだれもありがたがらない
製造元が頭の悪いマクロしか提供していないから泣く泣くラップ作業に着手するってんならまあ話はわかるが進んでやりたいことじゃねえわな
- 912 ：デフォルトの名無しさん (ﾜｯﾁｮｲ c37b-1Vd5)：2020/02/19(水) 23:22:37 ID:1xSUjqPH0.net
- >>909
まあもう一々答える気はないんだけどな。
本当に問題になることを突かれた場合は改善に繋がるから有用なのだけど、
君のレベルではそれは無理だし、実際に今回も恥ずかしいことになってるだろ。
多分君が根本的に間違っているのは、バグをバグと認識できてないことだ。
既に言ったがUIを噛ませて動作が不安定になるのは、明確にバグなんだよ。
それはCPUが余りまくっている暇人環境なら再現しにくいだけで、
他アプリでCPUを取られている場合においてはユーザー環境でも普通に再現する。
つまりCPUロードが高い状況では不安定になるわけで、これは普通にバグだよ。
だから君はまずそのバグを直さないといけない。
そうすると>>857の認識をだいぶ修正出来るだろうさ。
- 913 ：デフォルトの名無しさん (ﾌﾞｰｲﾓ MMff-o/5i)：2020/02/19(水) 23:24:13 ID:Z9/2no0YM.net
- >>912
答えられませんわかりませんって素直に言ったら？
潔さも時にはたいせつだよ
- 914 ：デフォルトの名無しさん ：2020/02/19(水) 23:31:23.42 ID:Z9/2no0YM.net
- >>912
つか不安定ってとこを拠り所にしてるようだが
仮に完全に安定しててもUI操作ベース貧弱文法のオレオレマクロなんて積極的に使う理由にならんからな
UI非依存のAPIを優先して他に何もなくてどうしてもUI操作せざるを得ないとなったらそこで初めて使うか別のツールに移行するか検討すんだよ
そこんとこはやく理解したほうがいいぞ
同僚や取引先にボタン押すオレオレマクロ機能をドヤ顔で提案して赤っ恥をかく前に気づいたほうがいい
これ本当に君が心配だから言ってる
- 915 ：デフォルトの名無しさん ：2020/02/19(水) 23:36:36.72 ID:Z9/2no0YM.net
- しかもな
もし仮に百万歩譲ってUI操作をサポートしなきゃならんとなったとしてもだ
そんなものはUIA、WinAppDriver、Seleniumに任せときゃいいんだよ
時間と金をかけて赤っ恥マクロを製造する必要はない
もうすでにゴミマクロの億万倍便利なライブラリがあるんだからそれつかいなよ
エンドユーザだってそっち使うよ当たり前だろ
- 916 ：デフォルトの名無しさん ：2020/02/20(木) 00:55:48.08 ID:FY8QkcoV0.net
- >>912
正常系だけ動けばいいマクロだったら人間用のUIを触るでもなんとかなるよ。
異常系もハンドリングしなければならないなら、何が出てくるかの一覧もないような、ダイアログに書かれてることを理解しなくちゃいけないんだから、網羅するのはめちゃくちゃ大変だと思わないかな。
人間用には問題を自然言語で全体的な説明する必要があって、
外部プログラム用には事前定義されたメッセージで問題を端的かつ詳細に伝える必要があって、
両者はプロトコルが大きく異なるんだから、人間用に外部プログラム用の伝え方をしたり、もしくはその逆ってのはどう考えても筋が悪い。
外部プログラムに人間シミュレーターをやらせたり、
人間に外部プログラムシミュレーターをやらせたら、
余計なレイヤーが必要になってバグの温床になるだろ。
「バグはバグだろ」とか言ってたって品質は改善しないので、そもそもバグが生まれにくい構造にしておくのが当たり前。
設計からやったことないのかな？
- 917 ：デフォルトの名無しさん ：2020/02/21(金) 23:28:13.08 ID:UQ40Zz5M0.net
- >>916
ではまず、
・君的超最高な異常系ハンドリング方式、>>900と同様にコードで、と
・現状やたらあるタスクランナー等のどれ一つにもそれが採用されてない理由
を聞こうか。
- 918 ：デフォルトの名無しさん ：2020/02/22(土) 00:53:29.41 ID:eCNgUA1qa.net
- こういう返しをしてくるということは数日かけても本当に思いつかなかったんだなｗｗｗ
- 919 ：デフォルトの名無しさん ：2020/02/22(土) 08:29:38.27 ID:lw7HhssO0.net
- >>917
あなたは話を逸らす傾向にあるから、その前に、まず、
「自分のオレオレマクロでは正常系での動作しか考えられていなくて、
正常系で動かないのであれば、バグはバグなんだから修正する必要があると言っていた。
だが、異常系への対応までは考慮することができていなかった」
ということを暗に表明していることを認めてもらえるかな？
異論があるならどこが違うのか指摘してくれ。
- 920 ：デフォルトの名無しさん (ﾜｯﾁｮｲ ff63-ufZq)：2020/02/22(土) 10:09:00 ID:hsz3eTB90.net
- ガイジの相手をしているところが間違っているね
- 921 ：デフォルトの名無しさん (ｱｳｳｨﾌ FFe7-IPX/)：2020/02/22(土) 14:22:35 ID:2qBDSHyDF.net
- 正常系と異常系がごちゃまぜで
どこが危なくてどこが危なくないのか全く区別がつかない
- 922 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 937b-UH+R)：2020/02/22(土) 14:33:37 ID:4D2R9AsT0.net
- 毎度毎度スレ違いどころか明後日の方向レスの応酬やっている連中は病院行け
- 923 ：デフォルトの名無しさん (ﾜｯﾁｮｲ ff2c-lQWV)：2020/02/22(土) 14:53:22 ID:qQaAG+8d0.net
- 漏れは、スクレイピングに、Ruby, Selenium WebDriver, Nokogiri を使う。
ブラウザの自動操作もできるし
ただ、各サイトの解析が大変。
特に、Ajax で動的に読み込むものは、読み込み前には存在しないから
- 924 ：デフォルトの名無しさん ：2020/02/23(日) 21:04:42.65 ID:9ZBd+yN40.net
- ところでこれ、既存の他アプリを操作するって話なの？
自分の既存アプリを多アプリが操作するって話なの？
多アプリで操作されるアプリを設計するって話なの？
- 925 ：デフォルトの名無しさん：2020/02/26(水) 02:43:03.63 ID:XCO7XOGOv
- .NETってリバースされやすいけど、かといってそのためにC++で書くのも嫌（＋技術力が低いから出来ない）だから、
ゴマかすために部分的にC++で書いて、そのDLLを参照させてる・・・
って人いませんか。もちろん趣味の範囲の話です。
- 926 ：デフォルトの名無しさん：2020/02/26(水) 02:44:43.07 ID:XCO7XOGOv
- 部分的にってのは語弊がありました。ごまかすために無駄なコードをC＋＋で書いて、
それを参照するってことです。
- 927 ：デフォルトの名無しさん：2020/02/26(水) 03:01:38.84 ID:XCO7XOGOv
- .NET 便利です。通信、非同期など、こんなのをネイティブ言語で自分で実装しようとしたら
難しいし、へたすれば逆に性能が悪いです。.NETを使ったほうが良いにきまっています。
一方で別に.NET言語でなくても書ける部分はC++で書いて参照するってことです。
- 928 ：デフォルトの名無しさん (ｱｳｱｳｳｰ Sa0f-ymO9)：2020/03/09(月) 14:45:58 ID:aNmrWQjka.net
- こんな感じで
TestDataGridView.Columns.Add("Number", "No.");
TestDataGridView.Columns.Add("Item", "項目");
for (int i = 0; i < Max; i++) {
TestDataGridView.Rows.Add(1);
TestDataGridView["Number", i].Value = (i + 1).ToString();
TestDataGridView["Item", i].Value = "";
}
初期化して、TestDataGridView["Item", i].Valueに何らかを代入して作業を終えて
中身を消そうと
for (int i = 0; i < Max; i++) {
TestDataGridView["Item", i].Value = "";
}
を実行するとGCがバカバカ発生して滅茶遅いのですが、なんでですか？
- 929 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 4f7c-MjGO)：2020/03/09(月) 15:04:37 ID:306ybdW+0.net
- GCがバカバカ発生したってのはどうやって確認したの？
遅い理由がGCにあるってどうやって確認したの？
- 930 ：デフォルトの名無しさん (ｱｳｱｳｳｰ Sa0f-ymO9)：2020/03/09(月) 15:07:43 ID:aNmrWQjka.net
- >>929
デバッグで起動して、右側の診断ツールのプロセスメモリのグラフに黄色のマークがどんどん現れたのです。
- 931 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 9f24-CBSz)：2020/03/09(月) 15:52:53 ID:GI3THqg50.net
- WinformsならSuspendLayout & ResumeRayout(true)で囲ってみては？
DataGridViewってItemsSourceに代入するとき以外は代入するたびに表示の更新されるよね、確か
- 932 ：デフォルトの名無しさん ：2020/03/09(月) 16:45:24.00 ID:aNmrWQjka.net
- >>931
やってみましたが変わらずです。
11列×256行で最初の2列はそのままで以降の列に計測値と計算値を代入して、次の測定でクリアするのですが、一回目は瞬時クリアで２回目以降は20秒くらい待たされます。
自動調節などは入れていません。
今まで同様なソフト作っていて初めての事です。
- 933 ：デフォルトの名無しさん ：2020/03/09(月) 17:12:18.14 ID:cFIy8do/d.net
- プロファイラでどこが時間くってるか見てみれば？
- 934 ：デフォルトの名無しさん ：2020/03/09(月) 18:10:16.08 ID:T4gz2l9RF.net
- 何らかの代入してる方に問題ありそう
- 935 ：デフォルトの名無しさん ：2020/03/09(月) 18:28:22.35 ID:UntOhQUT0.net
- >>932
ミニマムコード作って動かしてみれば
それでそんな動作になるのなら諦めるか改めてそのコード示して質問するか
一回目と2回目の動きが変わるとかGCが頻繁に動くとかちょっとありえないし
- 936 ：デフォルトの名無しさん ：2020/03/09(月) 18:28:52.87 ID:GI3THqg50.net
- >>932
ちゃんと
TestDataGridView.SuspendLayout();
TestDataGridView.ResumeRayout(true);
って書いた？
これはコントロール毎にしか聞かないから、Form1のサスペンド呼び出しても子コントロールには効かない
- 937 ：デフォルトの名無しさん ：2020/03/09(月) 19:15:42.50 ID:GI3THqg50.net
- TestDataGridView.SuspendLayout();
//ここにTestDataGridViewの処理を書く
TestDataGridView.ResumeRayout(true);
いずれにしても20秒も掛かるとなると他に原因ありそうだな
一応自分はFlowLayoutPanelに自作コントロールをListViewのように並べるというソフト作ってた時、
1000個以上のアイテムを一気に追加すると数秒ラグってたのがこの手法によってほぼ一瞬で表示されるようにはなったが
- 938 ：デフォルトの名無しさん ：2020/03/09(月) 19:28:18.48 ID:JH2CO7i+d.net
- デバッガ表示見てるんだからプロファイラで問題箇所特定が一番早くて確実
その上で最小再現コード作ったり他の設定いじったり試行錯誤してみればいい
なんで便利な標準ツールを使わずに他の手法を進めるのか理解できない
- 939 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 9f94-ymO9)：2020/03/09(月) 21:38:17 ID:aWxXRkAf0.net
- >>936
for文の前後に入れました。
- 940 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 9f94-ymO9)：2020/03/09(月) 21:39:54 ID:aWxXRkAf0.net
- >>938
すまん、使いこなせないのだ。
- 941 ：デフォルトの名無しさん ：2020/03/09(月) 21:50:06.25 ID:aWxXRkAf0.net
- >>939
Resumeの()にはtrueじゃなくて空でした。
駄目？
- 942 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 0ff8-7NIE)：2020/03/09(月) 22:06:22 ID:eHGFA/ZF0.net
- trueを渡せば停止中にキューに溜まってたものを一括でレイアウトするから低負荷にレイアウトが出来るって仕組みだったはず
なのでtrue引数入れないとパフォーマンス上の恩恵は得られない
- 943 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 8b63-UVo+)：2020/03/10(火) 00:40:45 ID:rLdwFfVF0.net
- >>940
vs プロファイラでググればすぐ出てくる
どの関数がどれくらい処理時間くってるか全部出してくれる
何なら関数内のどの行がどれだけ処理時間かかってるかまでわかる
この点だけを調べるならマジで簡単だから一度試してみるといいよ
- 944 ：デフォルトの名無しさん ：2020/03/10(火) 12:16:47.67 ID:FjsT0ZiBa.net
- true入れましたが駄目でした。
プロファイラ使ってみました。
１回目の状態です。
http://imgur.com/QRNwSP5.png
瞬時です。
２回目です。
http://imgur.com/cfzhpIi.png
時間かかってます。
セルに代入している時にGCが一杯発生してます。
http://imgur.com/IEzLFZa.png
使い方間違っているのかな？
- 945 ：デフォルトの名無しさん ：2020/03/10(火) 18:15:47.21 ID:X+eVfRrsF.net
- static な Main() の中で
await を使うと Main() に async が必要と言われ
Main() に async を付けると怒られました＞＜
- 946 ：デフォルトの名無しさん ：2020/03/10(火) 20:13:50.16 ID:bus7JDt50.net
- C#7.1(だっけ？)以降なら書けるから更新する
もしくはstatic async Task AsyncMain()みたいなのを挟む
- 947 ：デフォルトの名無しさん ：2020/03/10(火) 20:16:20.56 ID:M4Rwf6kV0.net
- >>944
直接dataGridView触るとやたら遅くなるケースがあるから
データの追加削除等全部mainlistの方でやって、
こんな感じで更新する形に落ち着いたような 全然覚えてないような・・・
SortableBindingList<Model.hoge> sortableList = new SortableBindingList<Model.hoge>(Model.mainlist);
dataGridView1.DataSource = sortableList
C#も話題もよく分かってないから 見当違いだったらすまんね！
- 948 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 9f94-ymO9)：2020/03/10(火) 21:16:42 ID:aFJ9tE+S0.net
- >>947
ありがとう。
直接アクセスすると良くなさそうなんでlistでバインディング出来るか試そうとしてました。
明日、トライします。
MFCで少し書いていましたがC#だとめちゃくちゃ短いソースになるんで勉強します！
ハード周りはC++のDLLでやれそうで明るい未来になりそうです。
- 949 ：デフォルトの名無しさん ：2020/03/10(火) 21:22:21.07 ID:vi5fh4S80.net
- DataGridViwのなんかのイベントで重い処理やってんじゃないのか
- 950 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 4feb-xiWk)：2020/03/10(火) 21:50:05 ID:M4Rwf6kV0.net
- >>948
SortableBindingListに関しては下記のページより、
https://docs.microsoft.com/ja-jp/previous-versions/dotnet/articles/ms993236(v=msdn.10)?redirectedfrom=MSDN
ぐぐって何番目かに出てくる、動物病院のページが参考になったよ 先生凄い
dataGridViewって利用者多いと思うんだけど、どれがスマートな利用方法かは調べにくいよね 頑張って！
>>949
詳しい解説や dataGridViewこう使うのが一番賢いぜ！って内容凄く聞いてみたい
- 951 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 7957-LOeD)：2020/03/11(水) 01:54:34 ID:zwwCe0yv0.net
- https://dobon.net/vb/dotnet/datagridview/
- 952 ：デフォルトの名無しさん ：2020/03/12(木) 22:19:30.41 ID:hbFLurwA0.net
- がんばって
- 953 ：デフォルトの名無しさん (ｱｳｱｳｸｰ MM05-RK3s)：2020/03/18(水) 17:22:22 ID:rMJu+eWXM.net
- autoScrollをtrueにしたPanel内で例えばcomboboxにフォーカスすると、スクロールバーが自動で上まで移動してしまいます。
それを解決するにはScrollToControlメソッドをoverrideしたPanelを作成すれば良いというところまではわかったのですが、
SplitContainer内のPanelの場合はどのようにすれば良いのかがわかりません。あまり頭が良くないので具体的なコードで教えていただけると助かります。
- 954 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 597b-EBql)：2020/03/18(水) 18:35:28 ID:Mnonc2v70.net
- >>953
SplitContainerのSplitterPanelはsealed classになっているからそっちで何とかしようとするとめんどくさそう
SplitterPanelの上にSizeとAnchor合わせた「ScrollToControlメソッドをoverrideしたPanel」を重ねるのが楽じゃない？
- 955 ：デフォルトの名無しさん (ｱｳｱｳｳｰ Sa5d-TlPw)：2020/03/18(水) 18:37:11 ID:i82q/1/Aa.net
- >>953
正攻法でやるの面倒そうだから、その魔改造したPanelをSplitterPanelに入れて
Dock = Fillにしたら？
それにしても糞UIだねそれw
見えないComboBoxにフォーカスが当たっててマウスホイールに触っちゃったりしたら
いろいろイライラが募りそうw
- 956 ：デフォルトの名無しさん (ｱｳｱｳｸｰ MM05-RK3s)：2020/03/19(Thu) 11:38:19 ID:iNMTXluDM.net
- >>955-955
ありがとうございます。無事に実装できました。
- 957 ：デフォルトの名無しさん ：2020/03/26(木) 14:02:01.81 ID:WnIwPUvR0.net
- これ同一人物で精神分裂病だろ
- 958 ：デフォルトの名無しさん ：2020/03/26(木) 19:03:41.94 ID:hr2wCIjAM.net
- 怖いことを言わないで
- 959 ：デフォルトの名無しさん ：2020/03/27(金) 12:50:41.91 ID:GP64i6UA0.net
- 実行モジュールをWindowsサーバーに常駐させてクライアントPCからのリクエストでサーバー上でコマンドを実行する
という仕組みに最適な.NETプロジェクトって何だと思いますか？
IIS建ててWebサービスかなと思うのですが1つのサービスのためにIIS建てるのは何か大袈裟だなと思いまして
よりモダンでイケてる仕組みがあったらお聞かせ頂きたいと
- 960 ：デフォルトの名無しさん (ﾄﾞｺｸﾞﾛ MM1d-eCbu)：2020/03/27(金) 13:21:30 ID:US1WE8+5M.net
- 常駐のための設定とか信頼性とか監視とか考えたら結局IISの方が手っ取り早くて楽
モダンでイケてるとか言い出したら今時WinサーバーかよとかオンプレかよとかAWSやGCPでKubernetes使えとかそういうそもそも論にしかならないのでナンセンス
- 961 ：デフォルトの名無しさん ：2020/03/27(金) 13:27:10.68 ID:vRdj9EFz0.net
- 検索してやったぞ
https://qiita.com/0829/items/5518256b348521ac358c
自分なら環境が許せはコンソールアプリ常駐で（リクエスト）ファイル監視で作るかな
- 962 ：デフォルトの名無しさん ：2020/03/27(金) 13:51:20.69 ID:qYMoCqhd0.net
- 名前付きパイプとかは？
- 963 ：デフォルトの名無しさん ：2020/03/27(金) 14:14:26.54 ID:Y964uCoh0.net
- Windows限定で良いなら MSMQ とかは？
- 964 ：デフォルトの名無しさん ：2020/03/27(金) 15:13:13.57 ID:paZiMxhtd.net
- >>959
embedIOで雑なHTTPサーバ作る。超楽。
- 965 ：デフォルトの名無しさん ：2020/03/27(金) 15:21:11.20 ID:9RtDMjhbF.net
- >>959
windows 用の sshd をサービスに登録して起動
リモート側から putty とか plink とかで操作
- 966 ：デフォルトの名無しさん (ﾜｲｰﾜ2 FF1a-nBi6)：2020/03/27(金) 15:23:45 ID:9RtDMjhbF.net
- windows 限定でセキュリティ気にしないなら psexec
- 967 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 6e7c-yUDG)：2020/03/27(金) 15:31:45 ID:ITHcMNsn0.net
- インターネットに公開するのかイントラネット内だけの話なのかで大分変わりそうだが
- 968 ：デフォルトの名無しさん ：2020/03/27(金) 17:16:14.97 ID:cwhPeqJj0.net
- Ruby なら、コマンドプロンプト・PowerShell から、1-liner で、
Rubyで作られた遅いウェブサーバー、WEBrick が起動する
ruby -run -e httpd . -p 8080
そのフォルダに、index.html があれば、これでブラウザからアクセスできる
http://localhost:8080
- 969 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 8101-C6bq)：2020/03/27(金) 17:36:28 ID:GP64i6UA0.net
- 知らない技術が出てきて勉強になります
C#でさささと書ければ良いので色々試させて頂きます
- 970 ：デフォルトの名無しさん ：2020/03/27(金) 17:39:24.99 ID:aLfv28Wa0.net
- 要件まとめずに実装方法から入ってあとで後悔するパターンだね
個人用途ならいいんだけど
- 971 ：デフォルトの名無しさん ：2020/03/27(金) 17:40:11.90 ID:GP64i6UA0.net
- >>967
イントラのお気楽サーバーです
AD立ててるので操作ログにログインIDを記録することでセキュリティに替えたいと思います
中国軍のハッキング等は想定しておりません
- 972 ：デフォルトの名無しさん ：2020/03/27(金) 17:49:36.14 ID:GP64i6UA0.net
- >>970
一部のチーム員が使うサーバ管理ツールです
すでにある実行ファイルを任意のタイミングで実行するのみのもの
DB使ったフラグのやり取りしてもと思ったのですが、実行ファイルをポーリングさせてリクエスト監視するのは効率悪いなと断念しました
- 973 ：デフォルトの名無しさん ：2020/03/27(金) 18:53:19.57 ID:aLfv28Wa0.net
- 利用者がWindowsのサーバー管理をしてるんなら
Powershellが第一候補なんじゃないかな
認証やロギングの要件わからないけど
Invoke-Commandだけでも結構なことができるよ
- 974 ：デフォルトの名無しさん ：2020/03/27(金) 19:24:21.17 ID:dVgXV7dy0.net
- >>959
そんな時こそD-COMだよ！
- 975 ：デフォルトの名無しさん ：2020/03/28(土) 10:22:41.18 ID:PEtLg9Oh0.net
- staticな拡張メソッドが作れれば割と便利な気がしないこともない
- 976 ：デフォルトの名無しさん ：2020/03/29(日) 17:16:53.96 ID:eP0h1Frc0.net
- >>959
普通に考えてまずWindowsサービスだろ
プロトコル等に規制がないならIISでもいいけど
- 977 ：デフォルトの名無しさん (ﾄﾞｺｸﾞﾛ MM9a-eCbu)：2020/03/29(日) 20:16:57 ID:8urZoGoxM.net
- >>976
それは回答になってないだろ
winサービスを自前で作るんならクライアントから要求を受ける仕組みもセットで示さないと
まあその場合大抵はTCP系だろうが、だったら素直に最初からIISの方が手っ取り早い
- 978 ：デフォルトの名無しさん (ﾜｯﾁｮｲ f1ad-cy2b)：2020/03/29(日) 22:37:41 ID:Qec2KlTa0.net
- 何言ってんだこの馬鹿
- 979 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 926a-Cd0d)：2020/03/29(日) 22:55:05 ID:mCKUE4Oo0.net
- 誰に言ってんだｗ
- 980 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 8101-C6bq)：2020/03/31(火) 07:19:23 ID:gCUhLr340.net
- >>976
windowsサービスも考えたのですがクライアントとのやり取りをどうしようと
データベースでやり取りすればと思いましたがサービス側が周期的にデータベースへアクセスは辛いかなと
- 981 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 9201-aXsr)：2020/03/31(火) 09:05:17 ID:WgVk0vye0.net
- >>959
.NETでないとダメなの？
> 実行モジュールをWindowsサーバーに常駐させてクライアントPCからのリクエストでサーバー上でコマンドを実行する
要件がこれだけならサーバーにOpenSSH入れてクライアントからログインしてコマンド投げるコード書けばいいだけかと
- 982 ：デフォルトの名無しさん ：2020/03/31(火) 11:55:30.26 ID:zne18ccq0.net
- >>981
それ実行モジュールが常駐してないじゃん
>>980
クライアントとのやり取りで悩むレベルならIIS一択
- 983 ：デフォルトの名無しさん ：2020/03/31(火) 12:32:35.41 ID:MF8ritPeM.net
- >>982
> それ実行モジュールが常駐してないじゃん
サービスも知らんのか？
- 984 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 5d60-bVUD)：2020/04/01(水) 18:52:20 ID:yix2qnAq0.net
- C#はどうなるの？
- 985 ：デフォルトの名無しさん ：2020/04/01(水) 18:57:27.33 ID:86v82W0VF.net
- https://docs.microsoft.com/ja-jp/dotnet/framework/windows-services/walkthrough-creating-a-windows-service-application-in-the-component-designer
http://kenzauros.com/blog/add-own-installer-and-auto-start-to-windows-service-with-csharp/
https://symfoware.blog.えふしー2.com/blog-えんとり-1133.html
https://symfoware.blog.えふしー2.com/blog-えんとり-1132.html
- 986 ：デフォルトの名無しさん ：2020/04/01(水) 22:59:28.02 ID:r1g6bMKoM.net
- >>984
なくなるよ
- 987 ：デフォルトの名無しさん ：2020/04/01(水) 23:58:48.00 ID:ec43qMfS0.net
- 次世代言語C7に駆逐されることになってる
- 988 ：デフォルトの名無しさん ：2020/04/02(木) 00:44:38.21 ID:+8nGzjLo0.net
- エイプリルフールとかつまらん
- 989 ：デフォルトの名無しさん ：2020/04/02(木) 05:56:15.64 ID:JxZO1Jli0.net
- どんな言語も永遠ではない
- 990 ：デフォルトの名無しさん ：2020/04/02(木) 08:26:22.53 ID:mZYQaqTk0.net
- >>987
CR7な
- 991 ：デフォルトの名無しさん (ﾜｯﾁｮｲ 857b-jIYQ)：2020/04/04(土) 17:48:48 ID:+BZEhhGG0.net
- 次スレは新しく立てずにこっちで
C#, C♯, C＃相談室 Part94
https://mevius.5ch.net/test/read.cgi/tech/1553075856/
即死判定無いし削除依頼は機能してないからゴミスレがどんどん増える
- 992 ：デフォルトの名無しさん ：2020/04/18(土) 16:53:08.80 ID:+KNBZdEV0.net
- スーパーマン・・・(´･ω･｀)
- 993 ：デフォルトの名無しさん (ｱｳｱｳｳｰ Sa1b-7wDT)：2020/04/20(月) 16:09:08 ID:mmgnUp0pa.net
- c#からsql serverにアクセスして、SQLを文字列で作成して問い合わせるときに、「@」が付いている箇所があるんですが、何かわかりますか？
調べるとdeclareで変数を宣言するときに使うみたいなのですが、declare文もないので分からない状況です。
- 994 ：デフォルトの名無しさん (ﾜｯﾁｮｲ d733-YvxL)：2020/04/20(月) 16:18:49 ID:nx4AJKqq0.net
- >>993
パラメーター？
- 995 ：デフォルトの名無しさん (ｱｳｱｳｳｰ Sa1b-7wDT)：2020/04/20(月) 16:29:05 ID:mmgnUp0pa.net
- >>994
おそらくそうです
- 996 ：デフォルトの名無しさん (ﾜｯﾁｮｲ b74b-LSCM)：2020/04/20(月) 16:35:08 ID:q7S5vlT10.net
- var foo = @"ABC\DEF";
とかなら、'\'等をエスケープシーケンスとして使用せず、そのままの文字として使用する場合に使います。
よくあるのがフルパスでファイルやフォルダを指定するときですね。
SQL文自体に@があるならパラメータでしょう。
- 997 ：デフォルトの名無しさん (ｱｳｱｳｳｰ Sa1b-7wDT)：2020/04/20(月) 16:41:59 ID:mmgnUp0pa.net
- >>996
パラメーターってdeclareで宣言しなくても使用できるものなんですか？
パラメーター自体まだわかってはいなんですが…
- 998 ：デフォルトの名無しさん (ﾜｯﾁｮｲ b74b-LSCM)：2020/04/20(月) 16:54:38 ID:q7S5vlT10.net
- パラメータはインジェクション対策によく使われます。
この辺りを説明すると長くなるので、SQL インジェクションなどのキーワードで検索してみてください。
パラメータをSQL文（declare等）で定義する事はありません。
- 999 ：デフォルトの名無しさん (ｱｳｱｳｳｰ Sa1b-7wDT)：2020/04/20(月) 17:27:24 ID:mmgnUp0pa.net
- >>998
調べてみます。ありがとうございます。
- 1000 ：デフォルトの名無しさん (ﾄﾞｺｸﾞﾛ MMdf-Wm+M)：2020/04/20(月) 18:16:45 ID:5/um/alTM.net
- >>997
とりあえずよくわかってないならその部分のコードを晒した方がいい
>>996が言うように@は複数の意味で使われるからすれ違うと頓珍漢なことになるから
- 1001 ：デフォルトの名無しさん (ｱｳｱｳｳｰ Sa1b-7wDT)：2020/04/20(月) 19:37:03 ID:mmgnUp0pa.net
- >>1000
すみません、会社のコードなので晒せないんです。
とりあえず皆さんから出てきたキーワードでもっと調べてみます。
- 1002 ：デフォルトの名無しさん ：2020/04/20(月) 20:31:50.14 ID:3RmvNNii0.net
- 会社のコードなのにまず社内で聞かないでここで聞くとかもう
- 1003 ：デフォルトの名無しさん (ｱｳｱｳｳｰ Sa1b-7wDT)：2020/04/20(月) 21:49:20 ID:mmgnUp0pa.net
- >>1002
返す言葉もございません
- 1004 ：デフォルトの名無しさん ：2020/04/21(火) 02:26:03.39 ID:1MDMdwK80.net
- まあなんだ、埋めてみよか
- 1005 ：デフォルトの名無しさん ：2020/04/21(火) 10:29:34.91 ID:Sho77XeS0.net
- 埋めついでに
全部そのまま晒すのではなくて、コードの一部とを変数名等を変えて（hogeとか、barとか）やれば問題ないよ。
それもダメとかいう会社は、そもそも5chアクセスなんて許してくれないだろw
- 1006 ：デフォルトの名無しさん (ｱｳｱｳｴｰ Sadf-xa8R)：2020/04/21(火) 12:58:40 ID:dT9nwdnwa.net
- そんな書き換えで晒すとか
人生棒に振るからやめとけ
- 1007 ：デフォルトの名無しさん ：2020/04/21(火) 14:00:27.73 ID:dg2zqYC90.net
- 単純化しただけで人生棒にふるってどういうことよ
イミフすぎるぞ
- 1008 ：デフォルトの名無しさん ：2020/04/21(火) 14:04:03.43 ID:atc0jbknM.net
- SqlClientとかがどんなsql吐いてるか一回ぐらい確認したほうがいいよ
- 1009 ：デフォルトの名無しさん ：2020/04/21(火) 14:11:12.72 ID:HBEA6Nica.net
- 993です。
SqlClientも見てみるようやってみます。
後は社内のわかる人にタイミング見つけて聞いてみます。
- 1010 ：デフォルトの名無しさん ：2020/04/21(火) 14:19:24.31 ID:9fcQjJm80.net
- ↓ここの例にある@id, @descがSqlParameter
https://docs.microsoft.com/en-us/dotnet/api/system.data.sqlclient.sqlcommand.prepare?view=netframework-4.8
- 1011 ：2ch.net投稿限界：Over 1000 Thread
- 2ch.netからのレス数が1000に到達しました。
総レス数 1011
418 KB
掲示板に戻る
全部
前100
次100
最新50
read.cgi ver 2014.07.20.01.SC 2014/07/20 D ★