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

■ このスレッドは過去ログ倉庫に格納されています
2017/10/17(火) 00:41:22.60ID:JxIRdCj70
■Visual Studio 2017 Community(無償の統合開発環境)等はこちら
http://www.visualstudio.com/downloads/

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

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

■次スレは>>970が建てる事。
建てられない場合は他を指定する事。
VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured
2019/12/08(日) 13:00:29.22ID:7KQ7NXxs0
>>281
エラーになる設定に値を設定への操作を許可してりゃ詰んでないじゃんｗ
そもそもそういう操作を禁止するなんて話どこにあった？
ユーザーの操作は何も制限なんてする必要は無い
設定保持classが現在入力されている設定値が正常か否かだけを分かってればいい
2019/12/08(日) 13:00:57.18ID:pSs03yKS0
画面に入力された文字は変数記録クラスに記録させて、
変数記録クラスを参照していると、

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

とかなるのは自分の頭がクソ仕様ということか・・・。
2019/12/08(日) 13:04:18.68ID:7KQ7NXxs0
この理論、パスワードは8文字以上でって制限だと
1文字目を打ったタイミングでエラー出して入力ボックス消すってことか？
そんでコピペ以外で8文字以上打つことができずに詰んだってか？
そんなびっくり仕様どこにあるの？
2019/12/08(日) 13:04:22.11ID:oZbmRsqQ0
>>286
そこは間違いないな
2019/12/08(日) 13:06:20.25ID:BE6HVZz80
だからワンクッション置かないと駄目だよねって話
2019/12/08(日) 13:08:13.78ID:KIb7eBZ10
>>286
変数記録クラスで変数を入れておくのをプロパティにしておけば、VSの機能で参照先をすぐに探せる
2019/12/08(日) 13:17:20.81ID:WI1y2v9y0
>>287
開始終了は入力中だけじゃなく
killfocusやvalidatedでもだめでしょ？
2019/12/08(日) 13:26:39.13ID:7KQ7NXxs0
>>291
だからダメだったら何なの？
不正な値が入力されたらそうであることが参照するclassがわかればいいだけ
登録ボタン形式であっても登録時にチェックして正常異常を判定するのだから異常入力をユーザーに通知できるタイミングの違いでしか無い

何も詰まないのに詰むでしょ？考えて？組んだこと無いの？
って勝手に操作入力制限の要件足して突っかかってくるのやめてね
2019/12/08(日) 13:42:37.78ID:z1c2Df2S0
>>292
元は
>>262
の
>登録ボタンなんて作らずに画面上の
>設定値が変更されたら即座に
>設定値管理用classに反映させればいいのでは？
って発言に対するレスな
2019/12/08(日) 13:49:38.20ID:B7mwO2xN0
>>293
反映させ方にもいろいろあるから開始/終了の制限があっても別に詰まないよ
質問と関係ないからもうやめれ
2019/12/08(日) 13:50:09.94ID:7KQ7NXxs0
>>293
そんなん分かってるよ
設定値管理用classが異常値を保持するだけで何も詰んでない
2019/12/08(日) 13:53:27.09ID:rNTMaYhL0
>設定値が変更されたら即座に
>設定値管理用classに反映させればいいのでは？

これ、バリデーションとか無い場合の方がやっかいだよね。
ユーザーは10を入力したかったのに1で処理されちゃうとか。
2019/12/08(日) 13:58:30.12ID:7KQ7NXxs0
個人的に割とよくある設計だと思ってる
入力したタイミングからエラーチェックして早めにユーザーに通知できるメリットがでかい
webなんかではよく見る形式
で、そんなよくある設計を詰むよ、なんて言って初学者（かどうかわからんが）に対して無意味に敬遠させるべきでは無いと思う
2019/12/08(日) 14:06:24.08ID:90QfBCQ40
>>294
え？コントロールの値を直接参照してるのにどうやるの？
無理ゲーじゃね？
2019/12/08(日) 14:08:43.35ID:90QfBCQ40
>>297
ガチでどうやるの？
範囲指定があった時点でOKボタン的もんが必要でしょ？
2019/12/08(日) 14:18:51.74ID:WpCL9e8A0
MVVMを持ち出してる割にVMとMがごっちゃになってるように見える
2019/12/08(日) 14:19:22.37ID:7KQ7NXxs0
>>299
何を無理だと感じているのかさっぱりわからん
from/toが範囲外になったってユーザーがそう入力してるならその値を保持するだけ
で処理に進む段階で異常値があるなら進ませない
登録ボタン形式なら異常値があるなら受け付けない

処理に進むのを実行ボタンとすれば
前者なら異常値があれば実行ボタンを無効化しておき、設定値が全て正常になったタイミングで有効化する
みたいな要件が実現しやすい
2019/12/08(日) 14:25:09.69ID:90QfBCQ40
>>301
即時反映の話はどこいったん？
2019/12/08(日) 14:26:41.39ID:90QfBCQ40
さらに設定値を参照してる奴全員に異常値の対応をさせるってありえなくね？
2019/12/08(日) 14:27:36.72ID:7KQ7NXxs0
>>302
その値を保持する
ってのが反映だ
根本から話がずれてる
2019/12/08(日) 14:28:42.21ID:7KQ7NXxs0
>>303
そんな仕様どこに書いてあった？
2019/12/08(日) 14:32:02.79ID:90QfBCQ40
なんかすでに議論に勝つためだけに頑張っちゃってる感じ？
2019/12/08(日) 14:34:19.70ID:rNTMaYhL0
登録ボタンと実行ボタンがある前提で登録ボタンの方は無くせる、と言っているのかな？
2019/12/08(日) 14:41:07.50ID:eGeBS+CxM
>>299
入力中はアンダーラインを引いたりメッセージを出して通知はするが間違ってても即保存する
入力された不正な設定値を読み取る時に無視するあるいは警告を出して無視するはたまたエラーを出して失敗させる
後々設定をアプリ外から弄ることも視野に入れると読み取り時にデータの正確性を保証したほうがいい
2019/12/08(日) 14:50:30.86ID:7KQ7NXxs0
UI→登録ボタンによるチェック処理→設定値保持class
UI→チェック機能を有した設定値保持class
こんだけ
前者はチェック処理で弾けば設定値保持classには異常値が入っていないことが担保できる
後者は設定値保持class自身が正常と判断してるかどうかで異常値があるかどうかを判断する

別に前者の設計が一概にダメとは思わないしこういうこともよくするが後者が詰むという理論は理解できん
2019/12/08(日) 14:51:48.07ID:B7mwO2xN0
>>272
一般的には読みやすくメンテしやすくするため
画面からの入力を処理する役割と設定値を管理する役割は別のクラスに持たせる
ただ簡単なプログラムなら画面クラスに設定値管理の役割を持たせるのでも別に構わない

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

レス見る限り他のクラスの変数を
プロパティやメソッド経由せずに直接設定したり直接参照してる風に読めるんだが
もしそうなら役割ごとにクラスを分離したのに密結合してるのが一番の問題
でもブチ切れるレベルの人ならササッと書き換えるから心配する必要ないと思う
311デフォルトの名無しさん (ﾜｯﾁｮｲ 032d-Do/g)
垢版 |
2019/12/08(日) 15:03:31.77ID:Oblj5J3Y0
>>272
いやいや、2みたいなものは要るし、3は一番ダメだよ
問題なのはフィールドを他クラスのオブジェクトから読み書きする点で、ここをプロパティーやフレームワークの内部コマンドに置き換えたりしないと徐々にコードが酷くなっていくよ
2019/12/08(日) 17:55:31.29ID:zhe6A2K90
この一連の流れは相談か？
2019/12/08(日) 18:19:08.18ID:54HI4DkC0
そうだんですよ川崎さん
314デフォルトの名無しさん (ｱｳｱｳｳｰ Saa9-FVm2)
垢版 |
2019/12/08(日) 18:25:13.90ID:q5OZjWUaa
正直最初の質問が結局何を質問してるんだか俺にはいまいちよく分からないんだけど、
こんな雲をつかむような話でよくレスが50も進むよねw

まず質問者が何を聞きたいと思ってるのかを明確にするのが先だと思うんだけど
2019/12/08(日) 19:25:44.35ID:h14g0YSH0
>>253の質問内容はわかるだろ
既に>>268, >>270で答え出てるし本人ぽい人も>>284で一応納得してる
レスが伸びてるのは場外乱闘してる基地害が２匹いるっていういつのも流れだからスルーでいい
316デフォルトの名無しさん (ｱｳｱｳｳｰ Saa9-FVm2)
垢版 |
2019/12/08(日) 19:40:58.07ID:q5OZjWUaa
>>315
漠然とは、ね。
逆にいうと漠然としか分からない

〜だろ？w
頭悪そう
2019/12/08(日) 20:06:20.23ID:h14g0YSH0
いや、わからないならスルーしとけよ
別にお前がわかる必要はないんだしw
2019/12/08(日) 20:19:46.26ID:vQtEDwKW0
また昨日の続きかよ
2019/12/08(日) 20:37:00.33ID:h14g0YSH0
自分がわからないのは質問者のせいだ
って思い込んでる人は一定数いるからw
2019/12/11(水) 18:58:15.46ID:neU6iLAlM
該当クラスがどこのネイムスペースから
なのかすぐわかる方法ってない？
321デフォルトの名無しさん (ｱｳｱｳｳｰ Saa9-FVm2)
垢版 |
2019/12/11(水) 19:12:17.36ID:A2ve7TTYa
>>320
型名ならマウスオーバーでポップアップ表示されない？
変数ならF12で以下同文
2019/12/11(水) 19:16:20.62ID:neU6iLAlM
>>321
メモ帳しか使えない
すぐわからない？
ideが前提なの？
javaだと省略しないのに
2019/12/11(水) 19:22:09.23ID:3diBwqZu0
名前空間を省略せずに書けばいいだろ
2019/12/11(水) 19:27:51.94ID:2za+15ZK0
javaだってするだろ
2019/12/11(水) 19:31:24.40ID:tBBOlHQ00
>>322
C#に限らず最近の言語はほぼIDEや高機能エディタ前提だと思うが
326デフォルトの名無しさん (ｱｳｱｳｳｰ Saa9-FVm2)
垢版 |
2019/12/11(水) 20:19:46.44ID:A2ve7TTYa
>>322
ライブラリの型ならC#と一緒にググればすぐ出てくるでしょ
2019/12/11(水) 20:25:15.92ID:EPJ4Sm/w0
vscodeすら入れられないの？
メモ帳縛りとかコンパイルもめんどいやん
てかコンパイラ単体で持ってきたの？
2019/12/11(水) 23:25:24.84ID:fjLZq11N0
昔はviとかで普通にコーディングしてたが
今更メモ帳でコーディングする気にはなれんな
今のIDEとかもう便利すぎる
2019/12/12(木) 00:08:12.86ID:n05Ewb3K0
dotnet buildでいいからコンパイルは楽でしょ
2019/12/12(木) 00:22:15.51ID:AJjh9lU00
今時viだってコーディング支援あるしね
2019/12/21(土) 08:44:14.52ID:mOkYxWI2r
インデントもわざわざ打たなきゃならんでしょメモ帳・・・
2019/12/21(土) 09:28:59.77ID:RVospelqd
>>327
WindowsならC#コンパイラcsc.exeが標準で入ってる。

>>322
でもなあ、IDE無しでは効率悪いでしょ。
規模にもよると思うけどVisualStudio入れられないならC#諦める選択肢もある。
といって代わりに何を使うかで良いのがあるとも思えないけど。
2019/12/21(土) 09:53:05.63ID:elCUYmNmM
クラウドIDE良いよ
インストール不自由でも使える
2019/12/21(土) 11:11:56.97ID:tKqa0Mcd0
vim
https://youtu.be/X0vVVHGFotc?t=306

makeファイルとかの下りは今は不要
2019/12/21(土) 12:14:55.25ID:wj7YAMPY0
メモ帳しか使えない環境だからいくら紹介しても無駄だぞ
2019/12/22(日) 01:12:40.65ID:BLYFt7Uup
最初にメモ帳でC#に特化したエディタ作る
以降はそれで開発
2019/12/22(日) 02:09:51.62ID:thbQEK090
C言語はC言語で書かれてると聞いたことがあるような…
最初にどう始めたかは知らない
アセンブラか他言語で始めてCに移行だとは思うが
2019/12/22(日) 05:49:50.97ID:By9IH60L0
セルフホスティングやな
2019/12/22(日) 12:27:43.38ID:BM7u1zydM
そんなことも知らないのかよ

cの場合は最初にクロスコンパイラを作るから、新しいプラットフォームでもアセンブラは不要。
て、さっきwikiで読んだ
2019/12/22(日) 13:11:54.70ID:0l5I7UXk0
原初の環境では機械語直入力だ
2019/12/22(日) 14:27:23.59ID:4GpMlcpo0
>>339
そのクロスコンパイラとやらはなんの言語で書かれてるんだ？
2019/12/22(日) 15:28:16.06ID:la1jzM750
もちろんCだよ。

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

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

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

僕くらい博識になるとこんなの常識だね。明日には忘れるけど
2019/12/22(日) 15:36:37.89ID:ngCRczT7M
まるでC博士だな
大したやつだ
2019/12/22(日) 15:38:35.28ID:sqLa+RyJa
いきなりネイティブのコンパイラは無理っぽいわ。
2019/12/22(日) 15:47:44.02ID:EAnHyDWL0
>>342
gcc は確か C++ で記述されていたはず、C++ のサブセットなんてどんなものなんですかね？
2019/12/22(日) 16:11:14.32ID:5lkZulIS0
元々はただのCだぞ
2019/12/22(日) 16:23:54.21ID:EAnHyDWL0
>>346
ずいぶん昔に gcc は c++ になってしまいましたよ…
2019/12/22(日) 16:45:16.31ID:lRvby7lea
元々はって日本語わからんのかな
2019/12/22(日) 16:46:38.86ID:uiOI59Hv0
昔のc++はcのコードを一旦出力してcコンパイラでバイナリを作っていたな
2019/12/22(日) 17:21:58.53ID:4GpMlcpo0
>>339
> アセンブラは不要。

と書きながら

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

とか自称博識がアホすぎるw
2019/12/22(日) 17:31:31.94ID:EAnHyDWL0
>>348
では質問を変えましょう

その昔の to C トランスレータの頃のC++は、控えめに言って C++98/03 の範囲の何パーセントくらいがカバーできていたのでしょうか？
2019/12/22(日) 18:56:50.05ID:5lkZulIS0
かわいそうに、馬鹿なのだな
2019/12/22(日) 19:39:34.09ID:tqOBQt+/0
>>352
コテでググったら各所で問題児扱いされている奴だったわ
2019/12/22(日) 21:03:00.98ID:0l5I7UXk0
>>350
よーく読んでみ
2019/12/22(日) 21:43:42.23ID:la1jzM750
>>350
バーンドブレードアタッチメントな僕の知識に反論しようとは笑止千万。

前者は今後出てくる新しいPFに関する記述で、後者は当初のコンパイラに関する記述なので、なんの矛盾もない。
2019/12/22(日) 21:55:06.63ID:4GpMlcpo0
>>355
> 前者は今後出てくる新しいPFに関する記述で
誰もそんな話はしてない
Wikipediaレベルのチンケな知識自慢は要らんよw
2019/12/23(月) 00:11:53.87ID:GXjcw1770
だめだこいつ…ｗ
2019/12/23(月) 06:44:48.06ID:AlxEeRKZM
>>357
自己紹介乙ww
2019/12/25(水) 16:59:22.64ID:Zg8ebJFL0
今日もつまらないことで5chは盛り上がっております
2019/12/26(木) 11:49:58.62ID:2UlJm9YS0
using/disposeについて確認したいんだが、
あれって厳密には「リークする」ではなくて、
「解放のタイミングが不明で、場合によっては問題が発生することもあり得る」なだけだよな？
https://docs.microsoft.com/ja-jp/dotnet/standard/garbage-collection/using-objects

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

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

結果、作法としては正しいがほぼ命中しない問題に関して一々using使うのもウザイ、
ということでMSDNのドキュメントがusing無しになってる、ということで合ってるかな？
(なお関係ないとは思うが俺が使っているのはVC++/CLIとForms)
2019/12/26(木) 12:35:29.16ID:WMR2NHe80
サンプルプログラムに厳密性を求めるな　ってだけ
2019/12/26(木) 12:37:11.96ID:Fsuom43iM
サンプルだから本質には関係ないところをバッサリ省略してるだけでしょ
ガチな例外処理とか入れられても見辛いだけだし
それと同じ話
2019/12/26(木) 13:02:58.04ID:Wx+k6OqqM
まあサンプルをコピペしちゃうレベルなら他にもっとまずいところはいくらでもあるだろうから、
少々Disposeが先延ばしになるくらいは無視しても問題ないかと
2019/12/26(木) 13:36:36.96ID:2UlJm9YS0
>>253
周回遅れだが一応参戦。当該院生が冬休みでもう一度読んでいることを期待する。
他の人も言っているとおり、設計としては253で正しい。直す必要はない。
なおその点はForms->WPFで思想が修正された点であり、（つまりFormsが駄目だった点）
これも他の人が既に言っているとおり、「最新のフレームワークの流儀」で設計するのが妥当。
判断する能力がないなら、とにかく「最新の流儀」に乗っかるのが
無駄に嵌るのを未然に防ぐ適切な方策となるのでそうすべき。

構成としては、おそらく、
「設定値変更画面(V)」「設定値保管用クラス(M)」「他クラス（多分演算ルーチン）(EXE)」で、
これはMVCの通りであり、V-M, M-EXE 間は結合しているがV-EXEは結合していない。
これに対して、誰か（≒老害）に指摘されたのだと思うが、君が253の時点でいいと思っている構成は、
「設定値変更画面(V+M)」「他クラス（多分演算ルーチン）(EXE)」となっており、Mが分離していない。
（=EXE側がVを知っている必要がある）
この構成の利点は、
・コードが多少少なく済む
点であるが、結局使い勝手が悪いので、ずっと改善していくと最終的に253みたくMVCに分離することになる。
2019/12/26(木) 13:37:07.04ID:2UlJm9YS0
>>259
といっても分かりにくいだろうから具体的に指摘すると、
君の問題は、間違った方策で解決しようとして、余計におかしくなっていることだ。
> 他クラスで使用しているときに値を変更されないように2、3を実装したんですけど、単に画面を入力できないようにロックすればよかった。
これは「画面をロック」ではなく、演算開始時に「設定値保管クラスのコピーを演算ルーチンに渡す」とすべき。
これにより、一つの実行画面から多数の演算ルーチンを並列に起動したり、
或いはGUI無しでコマンドラインから起動することも普通に可能となる。
（つまりプログラムとしての汎用性/柔軟性が上がっている）

「クラスのコピー」ってのはディープコピーだが、単純に値が入っているクラスなら、
Cなら構造体の代入、つまり
SomeClass myCopy = reference;
の1行で事足りる。或いは通常、関数呼び出しには構造体への「ポインタ」を用いているはずだが、そこを構造体の「値」に変えればいいだけ。
C#だとstructは値型だったと思うので、設定値保管用『struct』なら自動的に上記が常に行われる構造になるが、
余程小さくない限りそれでは使いにくい筈なので、設定値保管用『クラス』で正しく、何らかの方策でディープコピーをした方がいい。
インミュータブルに組んでいればシャローコピーでも行けるようには出来るはずだが。
2019/12/26(木) 14:38:18.82ID:2UlJm9YS0
>>361-363
つかこれ、どれくらいgraphicsヘビーにすればヒットするんだ？
以下はヒットしているようだが、俺はヒットしない。
https://sorayukinoyume.hatenadiary.org/entry/20121029/1351525436

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

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

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

という感じなのだが、お前らこれヒットするのか？
VC++/CLIとC#だとGC周りがだいぶ違うって事か？
367デフォルトの名無しさん (ｱｳｱｳｳｰ Sab5-655U)
垢版 |
2019/12/26(木) 14:50:50.75ID:+pzqFzNua
>>366
DC(Graphics)は不要になった時点でDisposeした方がいいと思うけど、
PebとかBrushとかFontとか、このあたりがIDisposable実装してるのは
たぶんWin9xを想定してるんだろうねw

.NET 1.1とかの時代に、Win2kやXPではそこまで神経質にならなくていいよ、
って記事を結構読んだ記憶がある
2019/12/26(木) 14:53:40.92ID:g3TV29VW0
多いから糞って単純な話でもないだろ。表示しているオブジェクトが多いなら仕方がない。
explorerもウィンドウを大量に開くとモリモリ消費する。
2019/12/26(木) 15:25:02.44ID:2UlJm9YS0
>>368
いやJaneはガチでリークしてると思うぜ。

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

字しか表示しねえJaneでどうやって8,677個になるんだよ？
フォントや色でも精々100だろ。
そもそも複数ページ表示してるchrome越えてる時点でだいぶおかしい。
2019/12/26(木) 15:25:33.99ID:2UlJm9YS0
>>367
そのわりにusingガーというのが多いのはなんでだ？
若干Java的オブジェクト指向（オブジェクト指向が唯一絶対神であり、それ以外は認めない）に近い偏見を感じる。
GCなんて手抜きの為の機構であり、逆に言えば、GC使っている以上、書かなくて済む事は書かない、というのが正しいだろ。
全部書け、ならC++を使って全部書き、GCなんて使っている軟派野郎は死ね、とあるべき。

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

それとも
> DC(Graphics)は
これはdevice context だけは即時解放した方がいい、ということか？
具体的にはGetHdcメソッドを有する連中だが、見た目Graphicsだけかな。
だとすると俺がやってるBrushでは再現しないのも納得だが、
かといってGraphicsを10,000取得とかいう使い方もないとも思うが。
2019/12/26(木) 15:49:32.19ID:8rtfbEtYp
何をグダグタと気にしてるのかよーわからんな
どうせそのうち回収されるんだから無駄に残ってるのが気にならねえならどうでもいいだろ
精々Janeみたいに過剰に確保されてるのを観測されてクソクソ言われるのが自分のアプリになるだけだ
2019/12/26(木) 16:01:00.94ID:Wx+k6OqqM
つか本来は実際に画面に表示されてる間だけアンマネージリソースを確保すればいいわけで、設計が手抜きなんだよ
まあ、そういう思想でスマートなリソース管理をしてるWPFはゴミのように遅いわけだがw
373デフォルトの名無しさん (ｱｳｱｳｳｰ Sab5-655U)
垢版 |
2019/12/26(木) 16:08:06.67ID:+pzqFzNua
>>370
なんかちょっと被害妄想激しいよw

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

※ 個別にDisposeを呼ぶんじゃなくてusingを使え、という趣旨の記事ならいくつか読んだことある
2019/12/26(木) 16:15:52.27ID:2UlJm9YS0
>>371
俺自身は「usingを使うべき」とされる解説ページでお約束的に出される
・そこで例外が発生してdisposeされずに抜けてしまった場合、リークする
が間違い（というか誇大)だと見ているのだが、これが間違ってるかどうかをここで尋ねている。


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

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

JaneStyleは調べたところOpenJaneからの派生で、OpenJaneはDelphiで、これはGC無しらしい。
つまりモロにリークしてるだけだよ。
375デフォルトの名無しさん (ﾜｯﾁｮｲ f12d-vQnI)
垢版 |
2019/12/26(木) 16:30:20.52ID:bzjIw0U90
尋ねてるって言うけど、君の求めてる通りの回答以外は認めないんでしょ
聞くだけ無駄じゃん
2019/12/26(木) 16:40:38.25ID:2UlJm9YS0
>>373
> Disposeしなくてもいい、という確信が持てないなら素直にDisposeするのが普通に安全牌だよね。
つまりこれ。
実はDisposeしなくていいんじゃねえの？というのが俺の疑問。

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

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

結局のところ、これは俺の環境のみならず、
.NETが動くありとあらゆる環境に於いて問題なく動くプログラムを作る為の作法であって、
MSがusing使えと言う以上、書くしかない、ということか。
それが俺のPCでは再現不能だとしても、それはたまたまでしかない、ということであって。
2019/12/26(木) 16:47:16.53ID:BHrZHcGr6
c#のListをイテレーションするサンプルをウェブで探していたんだけど、インデックスでアクセスして回しているコードがよく見つかるんだけど、
Listのデータ構造はリストではないの？
378デフォルトの名無しさん (ｱｳｱｳｳｰ Sab5-655U)
垢版 |
2019/12/26(木) 16:48:04.03ID:+pzqFzNua
>>376
上に書いたWin9x環境を特に想定した実装、というようなケースを除けば
そのクラスを作ったプログラマは「不要になったらDisposeを呼んで欲しい」と思っているから
IDisposableを実装している。

だからDisposeしなくてもいい、という確信が持てないなら（以下略
2019/12/26(木) 16:55:18.99ID:WMR2NHe80
>>377
「リスト」だとデータ構造が説明できてないと思うのだが
List<T>は配列で実装してるよ
2019/12/26(木) 16:59:42.72ID:F8ujXl8x0
GC任せではなく明示的にメモリを開放していかきゃ動作に支障をきたすような少メモリな環境だって世の中にはある
2019/12/26(木) 17:03:28.05ID:Wx+k6OqqM
>>377
.NETではIListは順序が定義され効率的なランダムアクセスの可能なデータ構造
従って、リンクリストはIListを実装しない
2019/12/26(木) 17:07:04.85ID:2UlJm9YS0
>>378
なるほど確かにその通りだ。

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

まあ長期的に見てその思想が正しいんだろう。
なるほど納得した。
2019/12/26(木) 17:10:19.42ID:2UlJm9YS0
>>377
つhttps://docs.microsoft.com/ja-jp/dotnet/api/system.collections.generic.linkedlist-1?view=netframework-4.8
2019/12/26(木) 18:35:58.39ID:EoULV8Z50
disposeされなくてもデストラクタで解放されるが、
かなり高コストな処理が発生するそうな

https://ufcpp.net/study/csharp/rm_disposable.html#idisposable
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況