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
255デフォルトの名無しさん (ｱｳｱｳｳｰ Saa9-GapK)
垢版 |
2019/12/07(土) 22:46:49.22ID:1bDOsUysa
普通じゃね？シリアライズするなら当然そうしねーか？
2019/12/07(土) 23:08:25.55ID:zukzhMoh0
C#関係ないようなｗ
設定値の復帰させるとかでも一括で管理する部分あった方が取り回し楽になるし何がクソなのかもわからない
>>254
むしろ該当部分組みなおすのに数日かかってしまう形になっているのが問題では
257デフォルトの名無しさん (ｱｳｱｳｳｰ Saa9-FVm2)
垢版 |
2019/12/07(土) 23:09:21.20ID:Ga9vuWSha
>>253
言ってること誤解してるかもしれないけど、
UIの入力をダイレクトに設定に反映しないのはMSのお作法的には
むしろ正しいんじゃないの？

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

まあ、仕様が適切かどうかは要件次第だと思うんで、あんまり教条主義的に考えない方が...
要は使いやすければそれでいいんで
258デフォルトの名無しさん (ﾜｯﾁｮｲ 032d-Do/g)
垢版 |
2019/12/08(日) 00:00:10.40ID:Oblj5J3Y0
大まかな設計は悪くないと思うけど、
2. 設定値を入力して登録ボタンを押すと、設定値保管用クラスの 「変数に値を渡す」
3. 他クラスは画面の値でなく、設定用保管クラスの「変数の値を参照する」 (画面の値でも同様によくない)
って仕組みは直した方がいいんじゃないかな
一箇所仕様を変えたら全部が狂うとか、変なことが起きてくるんじゃないの
2019/12/08(日) 00:29:06.09ID:pSs03yKS0
>>258
まさにそこなんですよね。。。
他クラスで使用しているときに値を変更されないように2、3を実装したんですけど、単に画面を入力できないようにロックすればよかった。

2の変数の名前とか少し替えるとどこで参照先を全て直さなければいけない。
この仕様直したいんですけど、時間がかかるのと単純作業を繰り返すので、
考えただけで目眩がします。
2019/12/08(日) 00:38:02.22ID:3vBWNciC0
え？何が悪いのかさっぱりわからん
〜すればってのも俺には的外れに見える
2019/12/08(日) 00:50:00.57ID:tOnI98EO0
>>259
変数の名前ならVisual Studioの機能で簡単に一括変更できるぞ
https://docs.microsoft.com/ja-jp/visualstudio/ide/reference/rename?view=vs-2019
2019/12/08(日) 01:02:05.03ID:7KQ7NXxs0
変数名の変更はVSの機能で一発で済む
vsじゃなくても最近のIDEなら標準的な機能じゃないかな？

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

画面ロックすればよかったって言ってるってことはあとから値変えられて困ってるってこと？
登録ボタンなんて作らずに画面上の設定値が変更されたら即座に設定値管理用classに反映させればいいのでは？
2019/12/08(日) 01:04:08.10ID:PIvqmbCd0
>>262
それやると設定値にチェックが必要なとこで詰むぞ
やめるべき
2019/12/08(日) 01:06:23.59ID:KIb7eBZ10
>260
同じく、何がくそ実装なの分からない
普通はGUIの変数を直参照しちゃってるから>>253の2,3みたいに直したいって悩みそうなもんだけど
2019/12/08(日) 01:06:29.61ID:PIvqmbCd0
開始日、終了日の入力で
開始日から終了日の期間に制限がある場合とかバインドに弱い
開始値、終了値も同様
2019/12/08(日) 01:13:11.42ID:7KQ7NXxs0
>>263
いや、何も詰まないけど？
反映するときにチェックして異常値であることがわかればいいじゃん
登録ボタンで登録時にチェックしてエラーとするのと何らかわらん

設定値保持classは常に正常な値のみを保持する
って要件ならそら無理よ
267デフォルトの名無しさん (ﾜｯﾁｮｲ 032d-Do/g)
垢版 |
2019/12/08(日) 04:54:32.09ID:Oblj5J3Y0
>>259
前の書き込みじゃわからなかったけど、主要な心配は、コードの保守性の問題じゃなくて処理中の入力に対する問題なの？
もし後者なら本当に作り直しレベルかも・・・・・
2019/12/08(日) 06:45:15.65ID:h14g0YSH0
WPFとかだとそういう風に組むのが推奨されてるし
2019/12/08(日) 08:21:03.71ID:rNTMaYhL0
>って要件ならそら無理よ

このことを「詰む」って言ってたんではないかと
2019/12/08(日) 08:33:51.79ID:YBiAuaAw0
DocumetViewとかMVVMパターンでは普通の実装だね。
2019/12/08(日) 10:03:29.48ID:K3lJ24NK0
>>266
だからいつ？
ちゃんと考えて

開始と終了の期間に制限があるんだよ
組んだことないの？
2019/12/08(日) 10:24:22.87ID:pSs03yKS0
>>264
>>267

1　画面に数値を保持して、開始ボタンを押すと画面入力はロックする
3　クラスは1の画面上の値を直接読みに行く

とすると2はいらなかったのかなと。

2があると、設定を増やしたり変数名を変更するたびに1→2→3全部直さなければいけず、
保守が面倒くさいので、後でソースを見た人にブチ切れられないかと・・・。
あと、画面上なら間違って他クラスから値を書き換えることはしないと思うのですが、
変数だと他クラスから不用意に値を書き換えてしまわないか不安で。。。
2019/12/08(日) 10:25:27.96ID:pSs03yKS0
自分で途中からクソ仕様と思い始めてしまったんですが、これが標準なんですかね。
だとしたら安心して引き継げるのですが。

正直面倒くさくて直したくないorz
2019/12/08(日) 10:29:01.88ID:1rCojsjZ0
>>272
画面に範囲guyのヤツブチ込んでも誰も死なんの？
コントロールだから絶対に想定guyのヤツは来ないはないよ
2019/12/08(日) 10:34:32.17ID:JIo60cn60
>>272
>変数名を変更するたびに
vsなら参照してるところもすべて書き換える機能あるよ
2019/12/08(日) 10:48:39.51ID:sqNFXMf8a
>>273
引き継ぐならそのままにしてあげたほうが良い
わざわざ手間をかけて設計を壊して後任の恨みを買う必要はない
277デフォルトの名無しさん (ｱｳｱｳｳｰ Saa9-GapK)
垢版 |
2019/12/08(日) 10:56:36.45ID:z9x/0bTQa
>>272
ちょっとした吐き捨ての設定ならそれで問題ないかもしれないけど、入力の項目が多くなってアプリを開いてあの設定を保存して呼び出したいってなった時とかどうすんの？とか結局仕様と設計の問題じゃないか？
2019/12/08(日) 10:57:28.44ID:8fOog+TqM
>>273
てか、WinFormなの？ それともWPF？
自分のこだわりがないならとりあえずフレームワークの流儀に倣ってりゃいいんじゃね
2019/12/08(日) 11:04:44.31ID:C3XpVZQF0
画面遷移されたら消えるの？
たまたま今回画面遷移せんの？
問題が起こりまくるから止めろと言っておく
コントロールの不正な入力を完璧にガードするのはよく知ってる奴でも結構難しいときあるし
2019/12/08(日) 12:32:23.17ID:7KQ7NXxs0
>>271
ユーザーが設定値を変更したとき
そうやって突っ込むってことは
>設定値保持classは常に正常な値のみを保持する
って要件はないんだよね？
開始終了とか関係なくユーザーが設定した値保持するだけじゃん
mvvmとか見たこと無いの？
2019/12/08(日) 12:50:54.37ID:MsET5CX00
>>280
開始に1980/01/01
終了に1980/02/01
が設定されてたとき
期間に3ヶ月って制限がかかってたときに
開始と終了に2019/09/01-2019/10/01を設定したいとするわな？

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

詰んだじゃん
2019/12/08(日) 12:55:17.97ID:pSs03yKS0
>>275
それやったんですけど、なんか変更されないところも出てきて・・・。
ここ以外で変なことやってるのかもしれません。
2019/12/08(日) 12:56:57.51ID:pSs03yKS0
>>279
開始ボタンをおしても、設定入力画面は開いたままで画面遷移させてないんですよね。
2019/12/08(日) 12:59:14.97ID:pSs03yKS0
みなさんのお話を聞いていると、
登録ボタンを押して、変数記録クラスに画面の値を記録させるというのはクソ仕様ではなかったんですね。
ホッとしました。
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
よーく読んでみ
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況