ふらっと C#,C♯,C＃（初心者用） Part145

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん (ﾜｯﾁｮｲ 1e7b-qjLW)
垢版 |
2019/10/07(月) 20:16:17.93ID:9eyAES450
!extend:checked:vvvvv:1000:512
次スレを立てる時は↑を2行冒頭に書くこと（1行分は消えて表示されない為）

「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。
他のスレッドでは書き込めないような低レベルな質問、質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。
内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。
なお、テンプレが読めない回答者、議論をしたいだけの人は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスや酔っぱらいレスはやめてください
>>980を踏んだ人は新スレを建てて下さい。>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。

■前スレ
ふらっと C#,C♯,C＃（初心者用） Part144
https://mevius.5ch.net/test/read.cgi/tech/1563258983/
■関連スレ
C#, C♯, C＃相談室 Part95
https://mevius.5ch.net/test/read.cgi/tech/1508168482/
■コードを貼る場合は↓を使いましょう。
http://ideone.com/
https://dotnetfiddle.net/

■情報源
https://docs.microsoft.com/ja-jp/dotnet/standard/class-libraries
https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/index
https://docs.microsoft.com/en-us/dotnet/standard/class-libraries
http://referencesource.microsoft.com/
・Insider.NET > .NET TIPS - ＠IT
https://www.atmarkit.co.jp/ait/subtop/features/dotnet/dotnettips_index.html
・DOBON.NET　.NET Tips
https://dobon.net/vb/dotnet/index.html
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured
2019/11/15(金) 23:45:14.55ID:ksKmrlqp0
三項演算子で比較するよりビットシフトのほうが圧倒的に早いから
cpuが得意とする処理と人間が理解しやすい処理は一致しない
どうしても納得行かないならILを見て各ステップでどういう命令がされるか確認するしか無いかな？
2019/11/16(土) 00:11:47.33ID:m6RZqer/0
>>709
ありがとうございます。とりあえずILについて調べて、
下のようなページを表示させるところまで行き着きました。
https://sharplab.io/#v2:C4LglgNgPgAgzAAhgJgQYQQbwLACgEFICMAbAmAHbAICqFYwAysAKYAORAFJdQB4CUCALwA+BLwQihCAAwIA/AiIIQsgNx5CxMj1r0mrNsm5Vxg0Qk4SRYuEUEBqJWoR4AvkA===

これから書いてある内容の理解に挑戦してみようと思います。
2019/11/16(土) 00:31:35.36ID:4hbhG1OZ0
そのILをぱっと見る限り、実行されるアセンブラまで調べに行く必要あるのかも
命令数は変わらんし
そこまで行ったらもう環境依存な気もする
てか最適化ありなら最適化されたIL見ないとだめかな
2019/11/16(土) 00:37:54.66ID:NxgYCWhy0
>>708
大昔にアセンブリやっていた経験からの推測だけど...

①の >= は左辺引く右辺の減算をして符号判定をしており、右辺の 0 を引くという演算が最適化ありでも外れず無駄な演算をしている可能性がまず一つ。でもこれは②に対して圧倒的に不利になる要素ではない。

もう一つのよりありそうな可能性は、三項演算子がコンパイルで if ステートメントになり、分岐先ブロックでパイプライン先読み実行していたステップが、分岐先読みの失敗により、ロールバックするコストが高くついているのではないかと。
確率 50% の分岐なら、2回に1回はロールバックすることになるため、コストが最悪になる。if else ブロックのどちらが実現確率が高いか、コンパイラが判断・制御できていない。
それに対して②はパイプライン処理を乱す要素がない。

どう中間コンパイルされ、どう IL が動くのか、最近の低レイヤーの処理は全く知らないため、見当外れかもしれないが。
2019/11/16(土) 00:46:48.34ID:D8F8Ex6/0
条件分岐は遅い
一方ビットシフトと加減はCPUが最も得意な処理
そのレベルのことを考慮するような処理にC#はあまり向いてないと思うが
2019/11/16(土) 00:59:24.83ID:NxgYCWhy0
パイプライン処理の詳細は Wiki で調べて、命令パイプライン、パイプラインハザード、制御ハザードの節あたりを参照しておくれ。

条件分岐がなぜ遅いかわかる。確率考えてアセンブリレベルで制御しないと速くならないよ。
2019/11/16(土) 01:04:27.12ID:NxgYCWhy0
あ、ごめん。よく読んだらランダムな値に対してって書いてあった。確率 50% の先読み最悪ケースになるね。アセンブリレベルでも最適化は無理。
2019/11/16(土) 01:07:09.62ID:m6RZqer/0
>>711
ありがとうございます。
アセンブラというのはSharpLabのページの
ResultsをJIT Asmにしたときに表示されるものと考えて正しいですか？
IL命令について色々と調べていたのですが、
JIT Asmのほうが書いてあることが少ないので先にこちらに挑戦してみようと思います。

あと最適化されたILというのは、ResultsをILにして、
一番右上の選択肢をReleaseにしたときに表示されるものと考えて正しいですか？

>>712
ありがとうございます。UnitStep?(int x)のxはプラスとマイナスが50%ずつになるように
ランダムに決めているので、確かに分岐の確率は50%です。
まだパイプラインについて完全に理解できていないので見当外れかもしれませんが、
試しにプラスとマイナスの割合を変えてどうなるかについても検証してみようと思います。

>>713
>>714
ありがとうございます。やはりハードウェアについてしっかりと理解しないといけないのですね。
ひとまず、>>714に書いていただいたキーワードについて調べてみたいと思います。
2019/11/16(土) 01:19:12.81ID:NxgYCWhy0
もしパイプライン処理がビンゴだったら IL 見ててもわからないよ。

CPU の fetch, decode, exec という内部処理の流れを理解しないと。

質問の書きぶりから大学かなんかの課題に見えるんだけど、高級言語ばかり見ていて低レイヤーのこと知らないとハマることあるかもよって警告するためのお題なのかもね。
2019/11/16(土) 01:26:24.15ID:D8F8Ex6/0
C#で考えるべき速度は計算量まで
メモリレベルの最適化を考えるならCで書くべきだし
CPUレベルでの最適化がしたいならアセンブラを覚えるべき
719デフォルトの名無しさん (ｱｳｱｳｳｰ Sa45-CsEk)
垢版 |
2019/11/16(土) 01:33:47.48ID:KEmuW3Wza
分岐先読み失敗って言ったって
x >= 0 ? 1 : 0
さすがにこんなのゼロコストじゃないの？

単純に機械語レベルの命令数の差を反映しているだけのような気が
知らんけど
2019/11/16(土) 01:41:11.97ID:NxgYCWhy0
>>718
いいインサイトですね。勉強になります。

>>716
もし true ? 1 : 0 の速さが②にかなり近くなって false ? 1 : 0 の速さが①よりさらに悪くなる、(あるいはその逆) ならパイプライン処理が原因だと考えて間違いないと思う。
2019/11/16(土) 01:50:49.22ID:NxgYCWhy0
>>719
機械語レベルの命令数に差があるように見える？
①②どちらも 2, 3 ステップだよ。

先読み失敗リカバリーはものすごくコスト高いよ。
パイプライン上の仕掛かりを全部クリアしなければならないんだから。その 2, 3 ステップの 1.5 ～ 3 倍くらいのクロックサイクルを無駄にすると思う。
2019/11/16(土) 02:00:02.51ID:NxgYCWhy0
>>719
ごめん、言い過ぎた。
IL わからんから、中間コンパイル通したらなんとも言えない。機械語の命令数が膨らむ可能性もありうる。
721 はネイティブコンパイルしたら、という仮定の話。
723デフォルトの名無しさん (ｱｳｱｳｳｰ Sa45-CsEk)
垢版 |
2019/11/16(土) 02:19:10.34ID:KEmuW3Wza
不勉強で今時のCPUのアーキテクチャーさっぱり分からんが、
ググってみると、投機的実行は予測が当たれば儲け、はずれても損なしだからこそ意味があると書いてある

コインの裏が出たら損をするなら意味がないと思うんだけど
2019/11/16(土) 02:28:53.52ID:m6RZqer/0
>>715
>>720
ありがとうございます。
xのプラスとマイナスの割合を変えて実験してみたところ、
UnitStep2では処理時間はほとんど変わりませんでしたが、
UnitStep1では、50:50のときが一番遅くてUnitStep2の10倍程度、
75:20と25:75はどちらも少し速くなってUnitStep2の6倍程度、
100:0と0:100はどちらもさらに速くなってUnitStep2の2倍程度になりました。
やっぱりパイプライン処理が原因っぽいですよね？

>>717
ありがとうございます。勉強になります。
高級言語では計算量までしか考える価値がなくて、
しかし計算量さえ小さければあとはマシンパワーでなんとでもなる。
だからこそ高級言語が今の時代に合っているということでしょうか。

>>719
ありがとうございます。
機械語レベルの命令＝JIT Asmの命令だとすれば、
UnitStep1とUnitStep2では6命令と4命令で確かに差はあるものの、
単純計算なら10倍もの違いはないようです。
2019/11/16(土) 02:35:13.39ID:NxgYCWhy0
>>723
それ出典教えてもらえる？
外れても損なし、だったらいいなっていう理想を言っているのではないのかな。

ランダムデータには弱いけど、正常系と異常系の分岐はたいてい正常系の発生確率が高いためこちらに賭けるのよ。で、ロジックの多くはこの手の分岐でしょ、っていうことを想定して先読みのアーキテクチャになっている。

ということをその文献も (独特の表現で) 言いたいのではないかと思うのだが。

もれも最近の CPU がわかっているわけではない。80286 ～ 386 時代でアップデート止まってる。
2019/11/16(土) 02:40:12.76ID:m6RZqer/0
>>720
>>724の75:20というのは間違いで、正しくは75:25でした。失礼しました。

ところで、ランダムに50:50ではなくプラスとマイナスを交互にしたら
もっと遅くなるかと思いきや、むしろ75:25よりも少し早いくらいになりました。
（ランダムの場合も交互の場合もあらかじめ入力データを配列に格納してから
　計測を開始しているので、入力データの作成コストは結果に影響していないはずです）

どんな仕組みで先読みをしてるのかさっぱり分かりませんが、
とにかく予測ができないのが遅くなる一番の原因のようです。
2019/11/16(土) 02:46:49.96ID:NxgYCWhy0
>>724
そうですね、データ依存なんでパイプラインと先読みが原因だと個人的には思います。

そういえば思い出しましたが、if else ブロックの片方に固定的に賭けると必要以上に大負けすることがあるため、条件分岐を何度か通ったところで学習し、勝てる見込みのより高い方へ賭けるアーキ設計だったような気がします。

true : false = 100 : 0 or 0 : 100 に片方が大負けせず、同じ性能になったのはこの学習効果ではないかと。

モダン言語の進化の方向の一つに高級化があるのは、仰るとおり。低レイヤーの最適化はコンパイラと進化したハードウェアに任せ、コードは人間にわかりやすくして開発生産性を高めようということです。

もう一つの進化方向は Rust とか Go とか、低レイヤー向け言語を C++ よりわかりやすく、より安全にしようというものだと思います。
728デフォルトの名無しさん (ｱｳｱｳｳｰ Sa45-CsEk)
垢版 |
2019/11/16(土) 03:34:45.34ID:KEmuW3Wza
>>725
失礼、例えばここにそんなことが書いてある
http://e-words.jp/w/%E6%8A%95%E6%A9%9F%E7%9A%84%E5%AE%9F%E8%A1%8C.html

でもこの通りだとしても>>723は的外れだねすんません。
「損はない」というのは並列ではなくシーケンシャルに実行した場合のコストを
上回ることはないって意味だと思う。

同じ100ステップでも素直に並列化できる部分が大きい100ステップの方が
低コストなのは当たり前の話でした
2019/11/16(土) 03:57:31.89ID:NxgYCWhy0
>>728
ありがとう。

この説明は失敗時のリカバリーがノーコストでできる環境を前提にしていると思う。
投機的実行をした面とは別の面を持っていて、そちらにすぐスイッチしてロジックを実行しつつ、その裏で失敗した面を同時並行で捨てられるような感じ。それが一般的かどうかはわからない。

複数面を持たず、失敗ステータスを捨てて (= クリアして)、その後に分岐別側のロジックを走らせるというようにシーケンシャルにリカバリーするのが一般的なのではないかなと思ったんだけどね。

最近のは複数面持ってるのかもしれない。ただ、複数面持っていると分岐ない時にリソースが遊んで無駄だからねぇ、分岐なくても普段からその面で並列演算すればいいって話になるよね。
2019/11/16(土) 09:45:55.26ID:+/ZlAd+w0
スレタイの初心者用とはいったいｗ
初めに回答したのが的外れとまでは行かなくてホッとしてるｗ
2019/11/16(土) 09:50:21.82ID:hIGr9Z3d0
こいつらウンチクごちゃごちゃ長くても作るもん電卓だから
2019/11/16(土) 10:49:58.51ID:42LkciGb0
>>730
全てわかっている人なんていないのだし、それぞれ知っていることを持ち寄って可能性をいろいろ検討してみるのが健全なやりとりなんだと思いますよ。

IL をうんぬんは知らない観点だったし、CPU アーキの話するのも 25 年ぶりくらいだったし、高級言語と C とアセンブリの使い分けを簡潔に整理してくれた人がいたので、とても勉強になりました。

>>731
ま、C# からはかなり離れてしまったね。
でも、電卓をバカにするものは電卓に泣くよ。AI もゲームも業務アプリも全てそのマイクロ電卓の組み合わせなんだから。高級言語の時代でも低レイヤーの動作原理を知っているに越したことはない。
2019/11/16(土) 11:14:24.24ID:lqoaSlCM0
色々と教えていただきどうもありがとうございました。
とりあえず、下のような感じの結論でまとめたいと思います。

・UnitStep1が遅い原因はパイプライン処理における分岐先読みの失敗による制御ハザードだと思われる
・分岐の方向の入れ替わりが激しくてもそこに規則性があれば制御ハザードは起こりにくいようで、
　分岐先読みにおいて高度な学習が行われていることが伺える
・高級言語の目的を考えれば、開発生産性を優先してUnitStep1を選択することも十分にあり得る

UnitStep1の入力データをランダムに決定した場合の、±の割合に応じた実行時間の計測結果
http://iup.2ch-library.com/i/i2026606-1573870091.png

何かおかしなところがあれば指摘していただけると嬉しいです。
親切にしていただきどうもありがとうございました。
2019/11/16(土) 11:20:09.54ID:42LkciGb0
>>733
733 さんは fact-base で真摯に検証・報告してくれる誠実な人ですね。
おかげで楽しかったし、とても勉強になりました。
感謝。
2019/11/16(土) 11:44:37.21ID:lqoaSlCM0
>>734
お褒めいただきありがとうございます。
パイプライン処理はとても奥が深いようで完全に理解するのはなかなか大変そうですが、
データの割合に関するご指摘のおかげでわかりやすい計測結果も得られて私もとても楽しかったです。
あまりにもわかりやすすぎる結果のせいで今後しばらく条件分岐恐怖症になりそうですがｗ
736デフォルトの名無しさん (ﾜｲｰﾜ2 FFca-/nAh)
垢版 |
2019/11/16(土) 12:23:55.13ID:HpU1Ehe+F
>>710
C4LglgNgPgAgzAAhgJgQYQQbwLACgEFICMAbAmAHbAICqFYwAysAKYAORAFJdQB4CUCALwA+BLwQihCAAwIA/AiIIQsgNx5CxMj1r0mrNsm5Vxg0Qk4SRYuEUEBqJWoR4AvkA===

個人情報漏れてね？
2019/11/16(土) 12:48:10.35ID:fOFWPIeT0
>個人情報漏れてね？
？？？
2019/11/16(土) 14:00:04.80ID:t9DFByLU0
これはAUTO
2019/11/16(土) 20:18:46.13ID:/0XYhqwL0
>>731
Windows10の電卓のソースコードがGithubに公開されてるけどかなり複雑なことやってるぞ
2019/11/16(土) 20:32:31.30ID:hIGr9Z3d0
>>739
そう言って最強の電卓を横に出して
自分が作ってるゴミまで光らせるのやめてもらえます？
ダッサイので
2019/11/16(土) 20:57:09.66ID:v94aDxHUd
>>740
電卓が簡単でないことを指摘されて逆ギレw
2019/11/16(土) 21:05:45.94ID:379I+6zB0
1enter2+
2019/11/16(土) 21:38:31.95ID:tPkM1yht0
>>740
お前のレス光ってるな
ゴミだけど
2019/11/16(土) 22:32:22.78ID:hIGr9Z3d0
>>741
お前が作ってるのは簡単だろ
2019/11/16(土) 22:36:56.78ID:fOFWPIeT0
>>744
輝いてるよ！
2019/11/16(土) 22:46:30.74ID:KlgbujPN0
お前らいっつもケンカしてんな
2019/11/16(土) 22:49:01.28ID:QmX0E4+sd
ID:hIGr9Z3d0
ｸｽｸｽｸｽ
2019/11/16(土) 22:49:34.30ID:hIGr9Z3d0
>>745
LEDだけな
2019/11/16(土) 23:29:47.38ID:JWQCRo2F0
ﾜｯﾁｮｲ 2922-pwu9
ｽﾌﾟﾌﾟ Sda2-pwu9
ﾜｯﾁｮｲ 02a7-Bv1e
ﾜｯﾁｮｲ d163-r7Uq
NG推奨
2019/11/19(火) 18:50:59.68ID:wDZa4BoT0
WPF開発に使われるMVVMパターンについてですが、Viewは良いとしてViewModelとModelの役割分担についての理解がイマイチです
ModelではOnPropertyChanged();などの記述はするべきではないという理解で良いんでしょうか？
2019/11/19(火) 19:09:43.87ID:t6NsCYD5r
雑な解釈

基本的に一画面ごとに最低一つViewModelつくる
なんも画面用にいじらなくてすべて共通部分しかないならModelオンリーで
2019/11/19(火) 19:16:11.51ID:t6NsCYD5r
基本的に変更も通知するモデルを作る
各画面ごとにそれをViewで使いやすい形に成形したVMを作る

深く考えない
困ったら考える
2019/11/21(木) 12:06:43.32ID:sWsV7L/3a
趣味でタッチパネル用のアプリ開発始めたのですが
IsMouseOverだとタッチイベントが認識されなくて辛い
なんかいい方法ご存知だったりしませんか？
2019/11/21(木) 12:19:33.38ID:Bs6+HN1rM
タッチパネルならUWPを使いましょう
WPFは終わった技術であり、過去の資産のために残されているだけです
2019/11/21(木) 13:20:56.61ID:qO3ULcJY0
そもそもタッチ操作ではマウスオーバーを表現できないってのは明らかだけど
なんでIsMouseOverが出てくるの？
2019/11/21(木) 14:44:35.71ID:5f7eRC930
なにを使うのが適切？
2019/11/21(木) 14:49:09.23ID:vYs/9NCN0
C#でQUEUEクラスを利用した際、Dequeue()後にメモリは残るのでしょうか？
EnQueue()とDeQueue()を繰り返しているのですが、（Countは0になる）
Visual Studioでメモリ使用量をみるとサイズがとても大きくなってるのですがこれはどういうことでしょうか？
2019/11/21(木) 14:50:14.67ID:5f7eRC930
GCされてないだけじゃね
適当なところでGC.Collect() してみなよ
2019/11/21(木) 14:55:41.36ID:RWorgXN+d
surfaceをペンとで使ってるけどペンを画面に近づけるだけでボタンの色が変わったりしてるな
2019/11/21(木) 14:58:37.65ID:5f7eRC930
ペンはマウス扱いなんだろうけど
タッチはどうなんだろうな
2019/11/21(木) 15:03:46.75ID:htKo0xsj0
そりゃ対応ペンは少し浮いた状態でも座標検知できるけど指は無理っしょ
2019/11/21(木) 15:06:06.00ID:m1a1HPIBp
APIによって色々
WM_POINTERなら全部別デバイスとして判別されてる
wpfにもタッチイベントあるんだからそれでやりゃいいやんと思うが
2019/11/21(木) 15:06:47.73ID:5f7eRC930
あるんだ
最近WPF始めたから知らんかった
まだまだ使えそうだな
764デフォルトの名無しさん (ｱｳｱｳｳｰ Sa9d-927E)
垢版 |
2019/11/21(木) 15:36:34.05ID:2+YsLjv3a
>>761
ペンに特殊な仕掛けがあるわけじゃないと思うので、
ペンだろうが指だろうが同じだと思う
知らんけど

でも普通に静電容量式のタッチパネルでしょ？
765デフォルトの名無しさん (ｱｳｱｳｳｰ Sa9d-927E)
垢版 |
2019/11/21(木) 15:39:50.86ID:2+YsLjv3a
一応Windows7からOSネイティブでタッチ操作に対応してるんだよね。

当時技術サンプルとして鯉が泳いでる池をタッチすると波紋が広がるスクリーンセーバーが
公開されてたけど、なぜかコードは非公開で意味ねえと思ったなw
2019/11/21(木) 15:52:09.65ID:vYs/9NCN0
>>758
GCではだめでした
TrimExcess()呼び出せばいいんですって、奥様
2019/11/21(木) 15:58:35.96ID:5f7eRC930
へぇーためになるわ
2019/11/21(木) 17:29:49.14ID:0iDNy5//0
>>764
surfaceのペンをスマホに当てても使えないから指とは仕組みが違うのでは？
769デフォルトの名無しさん (ﾜｯﾁｮｲ 5161-CJzu)
垢版 |
2019/11/21(木) 17:45:14.26ID:0fDEV4Sz0
>>764
ペンは電池式で何らかの仕掛けがあります。
良く知りませんが、恐らく「交番電界（周波数が低い電磁波とも言える）」を
出している可能性が高いです。
2019/11/21(木) 17:48:28.33ID:0fDEV4Sz0
>>769
もともとタッチパネルの方が交番電界を出しているので、それを相殺するような
逆位相の降板電界をタッチペンの方が出している、と考えられるようです。
771デフォルトの名無しさん (ﾜｯﾁｮｲ 8901-o5/b)
垢版 |
2019/11/21(木) 18:08:29.79ID:2xdKb6kz0
テレパシーの実用化。
772デフォルトの名無しさん (ｱｳｱｳｳｰ Sa9d-927E)
垢版 |
2019/11/21(木) 19:22:17.78ID:iJSjE21Ua
>>769
へー
静電容量式の原理から普通に考えればペン側に仕掛けが必要とは思えんけど、
よく分からんね。

接触しているかどうかの識別はCの大きさで判定するだけのはずだと思うんだけど
2019/11/21(木) 19:40:36.49ID:zBKzddxbr
>>772
ペンは静電容量式に対応してないと反応しないよ
手袋とかでタッチしても反応しない
2019/11/21(木) 20:37:16.26ID:oCiIkumQ0
専用ペン使うのは電磁誘導方式でしょ。
静電容量とは根本的に違う。
775デフォルトの名無しさん (ｱｳｱｳｳｰ Sa9d-927E)
垢版 |
2019/11/21(木) 20:57:25.88ID:phtIa0Jsa
>>773
対応って言ったって要するに導電性があるだけだよw
だから100均でも売ってる

>>774
surfaceってペン「も」使える設計だよね？
776デフォルトの名無しさん (ﾜｯﾁｮｲ 93bd-AvZR)
垢版 |
2019/11/22(金) 00:36:21.37ID:k4KfXICB0
長い名前を持つクラスに、thisを返すメソッドがあるとします

　// 超長いクラス名
　class VeryLongLongClassName {

　　　// thisを返すメソッド
　　　VeryLongLongClassName Foo( ) {
　　　　　return this;
　　　}
　}

このとき、Foo()の定義につけるクラス名を省略、
あるいは置き換える方法はありますか？

たとえば以下のような形が理想です

　var Foo() { … }　// 型推論っぽく書けるとか
　__CLASS__ Foo() { … }　//自身のクラスを表す予約語とか
2019/11/22(金) 01:05:43.88ID:FPmCk6jV0
ないです。
2019/11/22(金) 01:10:47.79ID:JIfSXtJz0
>>776
外部との境界に var 型推論はムリ。それやると型を差し替えたときに影響が甚大になるため、型推論はローカルでしか許されない。
using エイリアスディレクティブで短い別名付けるとよいのではないかな。
779デフォルトの名無しさん (ﾜｯﾁｮｲ 93bd-AvZR)
垢版 |
2019/11/22(金) 01:39:19.16ID:k4KfXICB0
ありがとうございます
ないですかー　残念
2019/11/22(金) 01:41:38.83ID:JMhA1FIB0
問題点や何がやりたいのかを言うと
違うアドバイスか得られることもあるぞ
781デフォルトの名無しさん (ﾜｯﾁｮｲ 7997-Rk0C)
垢版 |
2019/11/22(金) 01:41:47.12ID:9t5OvAOe0
インタフェースとか継承を考えても、thisで型推論するのは無理じゃない？
782デフォルトの名無しさん (ﾜｯﾁｮｲ 93bd-AvZR)
垢版 |
2019/11/22(金) 02:06:03.92ID:k4KfXICB0
戻り値が特に必要ないメソッドはreturn thisにして繋げれるようにしておこうかなあと
return thisにするか同じクラスをnewするかはさておき
2019/11/22(金) 03:39:52.30ID:zCaqBpsza
VisualStudio2017を使用

Form1にsplitContainer1を上下に分割して全面に貼ってあり、splitContainer1の下段側にリッチテキストボックス1をドッキングさせて貼ってあります。
このリッチテキストボックス1が、ScrollBarsプロパティ:Both、WardWrapプロパティ:false

このリッチテキストボックス1に縦と横幅を超えるテキスト表示をした時、
縦のスクロールバーは普通に表示されるけど、水平のほうのスクロールバーが表示されなくなったのだけど何が原因と考えられるでしょうか？

・右キー押して自分でカーソルを右端まで動かせば一応画面のスクロールはさせられる
・以前はちゃんとスクロールバーが表示されてたはずなんだけどいつの間にか表示されなくなった？
2019/11/22(金) 09:14:29.30ID:miLj5dAA0
>>782
クラス名が500文字とかあるならわかるけど100文字以内なら気にすることでもないと思う
気になるならそもそもクラスの命名が間違っているのでは？
2019/11/22(金) 10:12:54.94ID:NcGK5KJU0
xamlの質問になってしまいますが、全コントールアイテムのBorderBrushやForegroundの色を統一することって出来ないのでしょうか？
<Style TargetType="Button">
<Setter Property="BorderBrush" Value="Black"/>...
と一つ一つのコントロールを定義して回るしか方法はないのでしょうか？
2019/11/22(金) 10:34:58.33ID:8LwJ3HSF0
>>785
この辺が参考になるかも
ttps://www.atmarkit.co.jp/ait/articles/1009/07/news096.html
787デフォルトの名無しさん (ｱｳｱｳｳｰ Sa9d-927E)
垢版 |
2019/11/22(金) 11:05:21.71ID:fOeQA7sva
>>776
ファイルスコープの別名なら普通に可能。
グローバルに別名が欲しいと考えてるならそもそも何か考え方が根本的に間違ってる気がする
2019/11/22(金) 11:21:07.27ID:k4KfXICB0
>>784
そういう話ではない
それだと「変数をvarで定義するのは設計が間違っているからだ」と言ってるようなもん
789デフォルトの名無しさん (ｱｳｱｳｳｰ Sa9d-927E)
垢版 |
2019/11/22(金) 11:34:48.44ID:fOeQA7sva
>>788
いや誰が考えてもそういう（>>784）話ですw
それ以外にありえない
2019/11/22(金) 12:09:19.86ID:miLj5dAA0
returnの型から推論できるんだからメソッドの戻り型にもvarを使わせろって話？
んじゃあ始め書き込みで予約語の例示が意味不明
というか長い名前という言葉から文章を開始しといて何が違うんだ？

変数でvarを使うのは名称が長いからではないぞ？
長いものも3文字で表現できるという副次的メリットはあれどそのために導入されたものではない
2019/11/22(金) 12:18:11.80ID:627roQa/M
メンバの型に型推論が使えないのは単純に技術的な問題だよ
コンパイラは先にメンバのシグネチャだけを見てリストアップしてから各メソッドの本体を処理することで依存関係を解決している
メソッドの中身を見ないとメンバの型が確定しないとなると、一度メソッドを処理しただけでは依存関係を解決しきれないから
メソッドを何度も繰り返し処理する必要がでてきてコンパイルが遅くなる
2019/11/22(金) 12:18:49.41ID:Da5ctjWBa
>>785
できるよ～
１つのxamlにスタイルを定義して、全てのxamlから参照したりとか
2019/11/22(金) 12:21:55.56ID:k4KfXICB0
なんか結論としては>99の質問と同じような感じになっちゃったけど
最初の質問が微妙に異なるので見落ちとしてた、すまん

>>787
単純に自身と同型のオブジェクトを返すときに、なんかスマートな方法あるのかな？と思っただけ
言語によってはそのへんの仕組みがあったりする

ファイルスコープでのエイリアスが可能なら>>778の言うように
分かりやすいところに ThisClass みたいな名前のエイリアスを用意しておいて
クラス内部では基本的にそっちを使うのもアリかなと思っている
予約語ではないのでエディタとの相性はそこまで良くないけのが欠点か
2019/11/22(金) 12:26:27.67ID:8PnAlYZlM
戻りの型名を普通に書くのがスマート
くだらないアイデアでコードを汚さないで
2019/11/22(金) 12:29:12.04ID:k4KfXICB0
>>791
なるほど、確かにそうだな
動的な言語だとまた違うんだろうけど比較できるようなもんでもないしな
2019/11/22(金) 12:35:32.03ID:k4KfXICB0
>>794
んだね

アリかナシかで言えばアリだと思ったけど
言語仕様として存在しないなら自分個人ではなるべく避けたいな
2019/11/22(金) 13:01:16.69ID:VuiommTl0
>>791
今どきのコンパイラでワンパスなんてないだろw
2019/11/22(金) 13:09:44.77ID:miLj5dAA0
な？名称が長いかどうかなんて関係ない質問なのに余計な単語から質問を始めるから周りが混乱する。
コメントで超長いクラス名とかまで書いてんじゃん
そんで指摘したらそーじゃねぇよ！ってあほかとｗどんだけ説明下手くそなのｗ
799デフォルトの名無しさん (ｱｳｱｳｳｰ Sa9d-927E)
垢版 |
2019/11/22(金) 13:09:46.78ID:fOeQA7sva
>>793
なるほど失礼w

長い名前云々書いたのははミスリードだったねw
戻り値を型推論で省略できないか？とシンプルに書いて欲しかった
2019/11/22(金) 13:22:21.21ID:k4KfXICB0
型推論ともちょっと違うからなあ
2019/11/22(金) 13:24:19.67ID:627roQa/M
>>797
誰がワンパスだなんて言ったんだ？
現在何パス使っているにせよメンバの型推論を許せば間違いなくパスは増えるし、
791で書いた内容は俺の想像じゃなくてMS公式のコメントだぞ
2019/11/22(金) 13:48:44.67ID:VuiommTl0
>>801
多少パスが増えることぐらいでガタガタ騒ぐなよ
って話な
あとMSの見解がどうかしたのか？w
803デフォルトの名無しさん (ｱｳｱｳｳｰ Sa9d-927E)
垢版 |
2019/11/22(金) 14:08:44.11ID:fOeQA7sva
>>800
そうなの？w

// VLLCNじゃ何だかわからないので必要な場面で説明的な名前を与えるためだけのクラス
// 空っぽの継承のまま維持せよ。メンバ追加禁止！！！
class VeryLongLongClassName : VLLCN { private VeryLongLongClassName(){} }

// VeryLongLongClassNameの実体はこっち。
class VLLCN
{
　　....
}

まさかこんなのがお好みなのかなw
2019/11/22(金) 14:16:21.50ID:miLj5dAA0
自身のクラス返すときだけ利用したいんでしょ
tweenerみたいな設定が多いものをチェインメソッドで必要な設定を好きな順番で書くとか
他にはfactoryみたいなのをわかりやすくするとか
気持ちはわからんでもないけど局所的すぎると思う
805デフォルトの名無しさん (ﾜｯﾁｮｲ b32d-gZQb)
垢版 |
2019/11/22(金) 14:17:29.50ID:k9hYLF030
.Net CoreからBitFlyerの認証が必要なWebAPIを使いたいんだけどさあ
業者は暗号化キーをソースコードやファイル等に保存しないよう求めてるんだけど、.Net Coreでキーを守る手段ってどういうのがあるの？
WindowsやmacOS付属の機能も使えなさそうだし、最終的に動かしたいLinuxなんかそもそもそんな機能がないし・・・・
ランタイムにもそんな機能なさそうだし、どうすればいいんだろ
2019/11/22(金) 14:51:55.96ID:8PnAlYZlM
ソースはともかくファイルに保存は普通にやるよ
リポジトリに機密情報をコミットしない、と勘違いしてないか？
2019/11/22(金) 15:31:23.92ID:VuiommTl0
>>804
> tweenerみたいな設定が多いものをチェインメソッドで必要な設定を好きな順番で書くとか
チェインメソッドってよく見かけるようになったけど見易いのかなぁ…
X.A( ).B( ).C( );
より
X.A( );
X.B( );
X.C( );
の方が見易いと思う俺は老害なんだろうか
2019/11/22(金) 16:18:12.63ID:miLj5dAA0
>>807
linqでつなげるのに慣れてれば違和感なくならない？
linqとは意味合いが違うけども
まぁ可読性なんて人それぞれだとは思うよ
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況