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

2019/12/11(水) 22:12:11.28

!extend:checked:vvvvv:1000:512
次スレを立てる時は↑を2行冒頭に書くこと（1行分は消えて表示されない為）

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

■前スレ
ふらっと C#,C♯,C＃（初心者用） Part145
https://mevius.5ch.net/test/read.cgi/tech/1570446977/
■関連スレ
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/12/11(水) 22:32:15.34

2019/12/12(木) 09:41:18.58

2019/12/12(木) 14:29:42.64

ひらがな文字列をヘボン式ローマ字に変換するプログラム作りたいのですが
やっぱ正攻法でswitch-caseで123個くらい分岐させますか？
でも長音や促音の例外処理とか難しそうだなあ・・・

2019/12/12(木) 14:47:29.26

変換テーブルと検索

2019/12/12(木) 17:38:52.89

UNIXのShellのソースでコマンドを切り分ける場所では思いっきりswitch文の嵐だったな
１文字目でまず切り分けで、次にに文字目ってな具合で

速度なら圧倒的にswitch分だと思うが、作りやすかったり保守が簡単なのはDictionary使ったパターンだと思う

2019/12/12(木) 17:42:49.22

要素数が多くなれば多くなる程switch文よりDictionaryの方が速度的にも早くなるのでは？

2019/12/12(木) 17:52:34.02

つ libstree

2019/12/12(木) 18:32:36.61

>>7
C#コンパイラは多数の分岐先を持つswitchの場合には二分探索を行うコードを生成したりする
基本的に人間が最適化するより速い

2019/12/12(木) 19:09:09.93

>>4です
ありがとうございます
switchでコツウコツやることにします
要素の数え漏れでもっと増えそうだし
例外を拾う処理も考えなきゃww

2019/12/12(木) 19:47:35.25

vs2017ExpressでC#のフォームを使ってSQLiteのデータをDataGridViewに表示させたいです
セキュリティの関係でSystem.data.SQLiteを使うには申請が必要でMicrosoft.data.SQLiteを使っています
SQLiteをデータソース欄に追加する方法を教えてもらえないでしょうか？

2019/12/12(木) 21:16:54.09

ソース貼り忘れました
https://dotnetfiddle.net/DXwCTe
よろしくお願いします

2019/12/13(金) 10:16:06.63

いくら払えますか

2019/12/13(金) 11:41:55.37

>>13
自宅でSystem.data.SQLiteをインストールして同じコードを書いたらデータベースに接続出来ました
恐らくSQLiteConnection等の参照が足りずにエラーなっていると思いますが、解決策が思い浮かばなかったのでSQL Serverを使って試したいと思います
申し訳ありません

**デフォルトの名無しさん** (ｽﾌｯ Sd02-cBt2) · 2019/12/13(金) 12:10:09.33

Microsoft Visual Studio International Feature Pack を使うんだ！
KanaConversion クラスだったかに RomajiToHiragana メソッドがあったと思う

2019/12/13(金) 17:23:20.97

>>10

亀レスで申し訳ないが、正規表現と Dictionary と LINQ を使えば 5 行くらいで書けるよ。

var kana = “あ|い|う|え|お|か|き|く|け|こ”;
var roman = “A|I|U|E|O|Ka|Ki|Ku|Ke|Ko”;
var dic = kana.Split(‘|’).Zip(roman.Split(‘|’), (l, r) => new { Key = l, Value = r}).ToDictionary( x => x.Key, x => x.Value );

Console.WriteLine(Regex.Replace(original_string, $”({kana})”, match => dic[match.Value]));

2019/12/13(金) 17:33:03.63

あとは 50 音を全パターン書いてね。

ただし注意点があって、長いワードは短いワードよりも (例えば「ちょ」は「ち」よりも) 先に並べるんだ。
そうしないと短いワードが先に部分マッチしてしまう。

2019/12/13(金) 17:47:39.93

テーブル作る前提なら始めからdictionary作ればよくね？

2019/12/13(金) 17:49:41.61

一文字ずつ正規表現でマッチしてたらとんでもなく時間食いそうだな
姓名の変換くらいならどうとでもなるだろうけど

2019/12/13(金) 18:16:48.88

>>18
作っているのはテーブルだけではないし、このように書くとスッキリ書ける。

>>19
処理の重さの本質はワード比較による分岐であって、switch 分岐もそれに引きずられるから、C# で比較するならどちらも大差ないと思う。

正規表現の方が、むしろ、最適化がかかることに期待できる。

2019/12/13(金) 18:33:49.64

まったくスッキリしてない
圧倒的にswitchが早い

2019/12/13(金) 18:44:01.44

>21
それは感情論だな。計時してみてくれよ。

Perl, JavaScript, Java, C# で正規表現を使うこと 30 年弱になるけど、パターンの複雑さによらず、正規表現が目に見えて遅いということはなかったな。

アセンブラでゴリゴリに最適化したものと比べたら遅いだろうが、同じ言語のユーザー定義関数より目に見えて遅いことはまあないと思うよ。

2019/12/13(金) 18:48:06.09

これならDictionary作るわ

2019/12/13(金) 18:51:56.74

>>23
何か勘違いしてないか？
こっちも Dictionary つくっているが。

2019/12/13(金) 19:49:57.23

2文字置換を考慮したらスッキリは書けなかった
すまんこ
こんなクソみたいなコードでもregexよりは数倍早い
https://ideone.com/c7ILX4
頭良い人がもっとスッキリしたコード書いてくれそう

長文のほうがreplaceは不利だろうから数千文字にしたけどそれでも余裕
速度気にしないならregexで良いと思う

2019/12/13(金) 19:58:53.60

最終文字が2文字置換対象じゃないときにsubstringで範囲外例外出るわ
条件1個追加しといて

2019/12/13(金) 20:57:05.81

小さい「っ」が未対応なことに気付いた
これ正規表現でもめんどいね
正規表現ならっを無視してreplaceした後に1個ずつ置換かなぁ

2019/12/13(金) 21:07:14.03

多少簡略化したロジックで計測してみた。

マッチ文字列が 1 文字固定なら、ユーザー定義関数の方が正規表現より 8 倍速かったが、1 ～ 2 文字可変なら所要時間は同じ。

パターンマッチの文字列長が可変・複雑になるとそれをハンドルするための分岐が増えるせいでユーザー定義関数は遅くなる。

もちろん置換をかけるオリジナル文字列の文字出現パターン＆確率にもよる。

チューニングするなら C やアセンブラで書くべきだし、C# で書くなら正規表現で簡潔に書けるほうがよいのでは？

2019/12/13(金) 21:12:22.88

>>27
おもしろいところに気づいたね。

例えば仮文字 $ とかに変換しておいて、最後に直後の子音字に変換。

ちゃっと => cha $ to => cha t to

2019/12/13(金) 21:22:02.14

どうあがいてもregexは遅くないという結論にしたいみたいだけど
string単体で見ても遅いのにregexが遅くないわけがない
簡潔に書くならregexがスマートなパターンが多いのは分かってるよｗ
処理速度求められるパーサーなんかではまずregexなんか使わない

遅いと言っても数万文字の処理が何万回も必要とかでなければ気にするようなレベルではないので問題ないなら素直にregex使ったほうが良いよ
25ですでにそう言ってるしね

2019/12/13(金) 21:26:23.93

あるいはワンショットで置換するなら、下記のようなパターンを使って後方参照し、第1マッチ文字列が空でないなら、第2マッチ文字列の置換先の1文字目に置換するとか。

(っ?)(あ|い|う|え|お|か|き|く|け|こ)

2019/12/13(金) 21:26:56.26

「ンョ゛ハー゛」みたいなのが来た時の対応とか考え出すと仕様肥大化するだろうなあ
ひらがなカタカナ両対応とか、半角カナとか、
長音の代わりにハイフン使いだした場合とか
「ヴァッソ」とか
テストパターン考えるのも厄介そうだね

2019/12/13(金) 21:30:11.16

LALRを受理するジェネレータ書いたことがあるんだけど、状態表の大きさは字句解析のほうが遥かに大きくなるのが普通みたいですよ。
字句解析と構文解析は一つの表にまとめられるのに、なぜ分けるのかというのが最初の疑問だけど、なぜか答えが載ってる本が無い。
実際にやってみると表の大きさが爆発的に大きくなるからでした。
状態機械は分けられる箇所があるなら積極的に分けたほうが効率的になるようです。

2019/12/13(金) 21:30:12.87

>>30
文字列操作だからもちろん絶対的には遅いよ。

C# で書いたユーザー定義関数と比べたときに正規表現が相対的にそんなに不利かといったらそうではないだろうという予想を立てただけで。実際測ったら同等だったわけだけど。

2019/12/13(金) 21:30:26.83

日経だったか「むかっっ」という促音が
重なる文章というか記事があったな

2019/12/13(金) 21:33:36.65

字句解析におけるNFA対DFAというのも最初に気になる部分です。
結論から言うと、NFAの選択は十分に考慮できるはずです。
僕も最初はDFAにこだわっていました。
でも、字句解析は表が大きくなりがちです。
特にregex並みの便利機能を組み込もうとすると、とても大きくなります。
たいていはNFAで十分かと思います。

2019/12/13(金) 21:37:02.69

ちなみに、DFAにこだわる理由は、多くの本がDFAのほうが効率的と述べているからです。
みんなそうだと思います。
最悪のケースではその通りですし、最悪のケースを考慮するのはセキュリティにも関わります。
でも最悪のケースはめったになく、たいていはNFAで十分で、たいていは効率的だと思います。

2019/12/13(金) 21:39:05.74

>>34
その同等だったっていうコード貼ってくれない？
25で貼ったコードで1文字2文字の比率変えてもregex側が常に3～4倍くらい遅いんだよね
古い.NETだとsubstringが遅いとかあった気がするんだけどその影響じゃないよね？

2019/12/13(金) 21:42:16.88

>>38
コード書いてくれてたんだね。
25 があぼーんで読めない。。。

2019/12/13(金) 21:42:32.85

>>4でーす
>>16以降、何書いてるのかサッパリ分かりません！
なんせまだifとforとswitchと文字列操作のメソッドくらいしか知らないもんでww
半年くらい後に読みに来まーす

2019/12/13(金) 21:51:25.19

>>38
コードは長すぎて多分アップできないと思う。

やっていることは switch 式を2 文字マッチの場合と 1 文字マッチの場合で 2 種類つくり、残文字列が 2 文字以上あるなら前者にかける (破棄パターン _ => で後者を呼び出す)、1文字なら後者にかけ、インデックスを進めるだけ。

置換後文字列の連結には StringBuilder 使っているし、メソッド呼び出しは AggressiveInlining している。ユーザー定義関数を意図的に遅くするようなことはしていない。

1文字あるいは2文字の切り出しに Substring 使っているけど、それが遅いのかな？

2019/12/13(金) 21:52:27.04

ローマ字変換でばっとググってみた

お勉強用ならJavaScriptで書かれてるこれを理解しながらC#に移植するのがよさそうかな
ソースコードも簡潔だし悪くなさそう
https://www.pandanoir.info/entry/2016/03/29/190000

とにかく動けばいいというならMicrosoftが配ってるらしい「Japanese Kana Conversion Library」？でもこんなの使ったことないや

2019/12/13(金) 22:00:14.44

ンボマはmboma
ンバッペはmbappe
だからね

練習用なんだろうけど
簡単に見えても文字変換を自力でやるのはかなり面倒くさい

2019/12/13(金) 22:10:51.66

正規表現のほうが単純文字列比較より遅いのは当たり前
1文字比較の場合に単純比較と同等になるような
最適化が施されてるエンジン積んでれば数倍とかの差はつかない

少し古いバージョンのブラウザのJSのなら平気で10倍近い差が出てた
でもその差がUXに影響を与えるようなユースケースはそう多くはない

ちなみにstringのswitch caseは数が増えると
.NET Core以前は内部的にDictionary使うみたいよ
.NET Coreもhash比較するのは同じだけどDictionaryをアロケートしない方法にしてるらしい

2019/12/13(金) 22:12:49.12

>>39
これで見えるかね
ttps://ideone.com/c7ILX4
このコードはswitchじゃなくDictionaryでやった
おそらくswitchのほうがこれより早くなるか最適化で同程度になるはず
switch版までは作るのめんどい

配列の境界値チェックも遅い要因なのでできるだけチェックが発生しないのが望ましい
このコードでは2文字変換したときに境界値チェックが入ってしまうので2文字変換比率が高いと性能が悪くなる
2文字変換ばかりにしてもregexよりは早い

2019/12/13(金) 22:38:36.62

>>45
ありがとう。週末に評価してみる。

switch より Dictionary の方が処理性能がぶれない気がする。ハッシュで検索がワンショットに決まるから。switch は if カスケードを通ることで前スレで議論したパイプライン処理の影響を受けるため、処理速度がデータに強く依存する。

そんなわけでこの件の性能はコードの書き方 (チューニング含む)、データ、環境にかなり依存すると思う。

これは価値観の問題なのでみなが同じように考えるとは思わないが、正規表現で 3 - 4 倍程度の性能悪化なら、ユーザー定義関数よりチューニングより正規表現を私は採用する。
10 倍の悪化なら用途によっては考える。(パターンが複雑・多岐の場合) 正規表現は開発効率と保守性が 10 倍よいと思うので。

2019/12/13(金) 22:59:26.50

>>46
switchとdicの関連は44が説明してくれてる
最適化次第でいい感じにしてくれるはずだからどっちもたいさない感じになると思う

個人的には性能差が10倍だろうが1000倍だろうが許容できるケースなら可読性を取る
今どき文字→数値変換でc-'0'なんて書かずに大体int.Parse使うのと同じ

UIに入力された氏名のローマ字変換みたいな1ユーザー1回で済むような処理に速度なんて無意味
GB単位のログデータをいじるなら数倍の差でも考慮すべき
なんなら入力データの傾向に応じてチューニングしやすい単純処理のほうが更に高性能にしやすい

2019/12/13(金) 23:21:38.26

俺なら、ひらがな小文字の変換は、変換元「ちゃ」とか「ぱっ」のパターンを文字数降順で優先的に置き換えるかな。
配列で変換パターンを保持して、それにない文字パターンは先頭から徐々に削っていく。
それなら「ぱ」と「は゜」なんかも判りやすく対応できると思うよ。

2019/12/13(金) 23:36:31.48

>>44, 45, 47
みんな有益な考察をしてくれるのでありがたい。感謝。

今まで正規表現が際立って遅いと体感することなかったけど、利用目的を想定した評価をきちんとしたことなかったので一連の議論はとても参考になりました。

2019/12/13(金) 23:57:37.29

オリジナルの文字列を1文字ずらしでzipして
2文字ずつ取得するイテレータでやるのがいいかなとか思ってたが
多少非効率でも↓ここの実装みたいに繰り返し変換していく方が
条件分岐が少なくて読みやすいかも

https://tools.m-bsys.com/original_tooles/romaji.php
https://tools.m-bsys.com/js/romaji.js

function hebonG(s) {
s = s.replace(/ん([aiueoy])/g, "n$1");
s = s.replace(/ん/g, "n");
s = s.replace(/n([bpm])/g, "m$1");
…
var hebonGMap = {
"kuぁ": "kua", "kuぃ": "kui", "kuぇ": "kue", "kuぉ": "kuo",
…
}
…
s = s.replace(/っch/g, "tch");
s = s.replace(/っ([kstnhmyrwgzdbp])/g, "$1$1");

2019/12/14(土) 11:11:39.02

>>49
正規表現が遅いのは、コンパイルだろ

実行時ではなく、初期化時にコンパイルするようにと、Go の本には書いてある

2019/12/14(土) 11:24:37.56

>>4
Ruby では、条件分岐しなくても、変換用の辞書で書ける

>>16
も、これに似ている

hash = { 'ab' => 'あ', 'xy' => 'ん' }

p re = Regexp.union( hash.keys ) #=> /ab|xy/

p "9xy9ab9xyx".gsub( re, hash )
#=> 9ん9あ9んx

2019/12/14(土) 16:02:25.78

>>51
まあね。ただ、C# の Match Evaluator 付き Regex.Replace は事前コンパイルできないと思う。

ちなみにあの後何度か測り直したのだが、switch より事前コンパイルなし正規表現は 2 倍遅かった。同等ではなかった、すまん。

45 によると Dictionary & ユーザー定義文字列操作は正規表現より 3-4 倍良かったそうだから、今回のケースでは Dictionary : switch : 事前コンパイルなし正規表現 = 3-4 : 2 : 1 くらいの性能比かと考えられる。

switch はカスケードがさらに増えると内部で Dictionary 化して最適化されるから、一般論としては正規表現は事前コンパイルすれば switch に肉薄する、あるいは、多少超えるかもしれないが switch に Dictionary 最適化がかかったらまた離されるかもって感じではないかと。

>>52
ありがとう。Match Evaluator 正規表現でハッシュ置換するのはもう四半世紀も使っているテクだけど他で見たことなかったから、Ruby の例は参考になる。

2019/12/15(日) 00:27:58.57

このスレにいる人たちで
C#を日本語で記述ってのを実際にやってる人、どれくらいいるかな
https://togetter.com/li/1441951 を読んで試してみてもいいかなと思ったんだけど
VisualStudioのコード補完が利く環境ならIME切替の手間もさほどかからない気もするし
何か致命的なデメリットとかあるんだろうか

2019/12/15(日) 02:49:23.51

>>54
ほとんどいないのでは？w
デメリットはインテリセンスとの相性の悪さに尽きるね。

どうでもいいけど「C#を日本語で記述」の是非というより識別子に日本語を使うことの是非だよね
論より証拠、やってみたらいかに非合理な試みか分かると思うよ

2019/12/15(日) 05:39:16.51

Ruby では、RSpec(BDD)のユニットテストで、
日本語の関数名を付ける人はいるけど

まあ、テストだからね

2019/12/15(日) 05:45:38.27

テストのメソッド名とかなら使っちゃうかな

2019/12/15(日) 06:17:17.09

　enumの要素で使うと便利
どうせ数はないからインテリセンスも問題なし

2019/12/15(日) 13:41:49.81

>>54
補完のために半角英数+日本語が便利
これなら最初だけだしIME切り替えは

2019/12/15(日) 14:56:15.21

補完はomnisharp + migemoで解決できる

他言語で変数名に日本語使うのはよくやってるけど扱う対象の用語が固まってる場合は便利
そうじゃない場合は結構厳格に命名ルールを決めないと逆にわかりにくくなったりする

2019/12/15(日) 16:18:24.21

俺が英語ができなかったり、デザインパターンの理解が足りなかったりするせいだとは思うけどさ
どうしてもファイル名＝ネームスペース名＝クラス名＝主なメソッド名になりがちなんだわ
単一責任の原則に合わせた時、ファイル名～メソッド名まで決める簡単な基準とかあったら教えて欲しいな

2019/12/15(日) 16:21:28.32

Javaやりすぎると後遺症でそうなることがあるな

2019/12/15(日) 16:49:35.38

ファイル名=publicクラス名.csは一般的

ネームスペース名はそのクラスが属するレイヤーとかコンポーネントの名前
アーキテクチャが整理されてればあんまり迷わないと思う

クラス名=主なメソッド名は状況による
FormatterクラスにFormatメソッドがあるのは自然

Utilitiies > Formatter > Format

2019/12/15(日) 17:58:43.69

日本語を使った感想

メリット
名称に悩まない(重要)
比較的読みやすい

デメリット
インテリセンスと相性が悪い
imeの切り替えが面倒
大文字小文字がないから名称が被りやすい
システムハンガリアン推奨

他にも何かあった気がする

2019/12/15(日) 18:23:34.11

プロパティーやフィールドはいいけど、メソッドやイベントの名前は馬鹿っぽくはなるねw

2019/12/15(日) 18:24:56.51

プロパティはいいとしてメソッドは動詞（＋名詞）の形にするの
日本語だと不自然だけどどうしてるのかな

2019/12/15(日) 18:30:01.27

>>58
中点使ってるせいでC#6.0対応時にエラー吐いたプロジェクトあったわ

2019/12/15(日) 18:49:58.62

>>54
DBテーブル名/カラム名が日本語名のWindows業務システムで、
Entityクラスや画面コントロールの命名をDBそのまんまの日本語にしたら
ソースが滅茶苦茶読みやすくとても良い感じになった
以後、積極的に日本語で命名するようにしてる

自分の書き方だと、
日本語を使うのは画面項目や業務用語の名詞のみ、動詞は英語
英語とチャンポンして Update利用情報()、Is有効期限内みたいなメソッド/ブロパティをよく作る
ローカル変数はiとかsとかtとか適当なプレフィクスをつけて無理やりcamelにする
フィールドは_始まり
とかかな
日本語で書くコメントが大幅に減らせてメリット大だと思う

デメリットは…C#関係ないけど
postgresだとテーブル名が日本語だとテーブルエクスポートが出来なくて不便、
多分ASP.NETみたいなWebシステムだと日本語名を使うのはリスク高い、
とか

2019/12/15(日) 20:10:28.99

訳のわからん不具合踏みそう
日本語使ってると

2019/12/15(日) 21:16:07.17

Listについて質問なのですが
BindingList<T>にはToList()では代入できないのでしょうか？
LINQの結果をToListで代入しようと思ってたのですが
型が違うとか出るんです（自作クラスによるListです）
普通のList<T>へならできるのでBindingList固有の問題かと思います
仕方なくforeachで一つずつ代入して一応目的は達成してるんですが
LINQでforeach使わず抽出しておきながら
最後に代入でforeach使うのはバカらしいなあ・・・と思いまして
どうすれば直接LINQの結果をBindingListに入れられるのでしょう？

2019/12/15(日) 21:26:38.59

new BindingList<Hoge>(fuga.ToList())

2019/12/15(日) 22:05:28.60

>>71
おお！何かわからんけど、できた
初期化したらキャストできるの？
でもdataGridViewのDataSorceプロパティに入れてたのも外れるから
もう一度入れ直さないといけないけど・・・

2019/12/16(月) 05:42:00.98

razor page のコーディングについてなんですが、
1ページのデータ量が多くなれば必然的にソースも長くなりますが、2000行とかになるとごちゃっとして「目に優しくない」ソースになっちゃいます。
目に優しいコーディング方法やら規約やら法則があれば教えてください。

2019/12/16(月) 07:41:26.07

>>73
1メソッド300行以内っていう社内ローカルルール

2019/12/16(月) 15:28:44.50

>>73
Partial ViewとかView Component使って分割する
再利用しなくても分割する
個人的には200行超えると黄色信号

>>74
1メソッド300行ってすごいな

2019/12/16(月) 17:57:20.50

200も300も大差無いような…

2019/12/16(月) 20:05:28.74

やっと会社の環境がvisualstudio2010から2019になったわ、これで非同期無双できるw

2019/12/16(月) 20:08:09.24

そんな環境で2019なんか入れて大丈夫か？
アップデートで不具合引いてダウングレードさせられないように、不用意なアップデートはやめとけよ

2019/12/16(月) 20:09:20.42

2010とかサポート切れ直前やな

2019/12/16(月) 21:08:24.24

2010だとNuGetすら使えないんじゃ

54だけどレスありがとう>ALL
実践してる人もそこそこいるのね
テーブルやカラムを日本語で命名できるのってAccessに限らないのか・・・・
不具合の事例も知りたいけど、具体的に出てきたのは>>67くらい？
C#に閉じた範囲で使うぶんには大丈夫そうかな・・・・今度試してみるよ

2019/12/16(月) 21:33:12.54

>>76
viewの行数とメソッドの行数の違い

2019/12/17(火) 09:59:27.04

>>80
全角ピリオドとか＆とかヤバそうに思えるのは使わないのが無難
date前月末とか昔から使ってます

昔々のACCESSで一部の通常全角文字が使えないとかありましたが、今はもう大丈夫と思ってます
将来的にトラブル可能性はゼロではないとしても、可読性のメリットのほうが遥かに大きい
例えば「要介護認定等基準時間」みたいなのを英字変数にするとかアホにもほどがある

2019/12/17(火) 18:03:06.99

質問でふ（＾＾
Unityのアセットとか覗いたりするとifは使われてまふよね（＾＾
Switchが使われているの見たことないんでふが（＾＾
あれって使っちゃいけないとかってあるんでふか？（＾＾

ボッキング！（＾＾

2019/12/17(火) 18:30:01.62

最適化すると数行のswitch文はifに自動変換されるんじゃなかったっけ

2019/12/17(火) 18:39:07.95

そうだったんでふか（＾＾
教えていただき感謝感謝のボッキング！（＾＾

2019/12/17(火) 19:40:18.25

class Hoge{
int Id
ICollection<Hoge> Hoges
}
ってクラスをEntityFramework使ってテーブルにしたんだけど無理だったりする？
Hogeテーブル（Id）と、Gehoテーブル（id、HogeId、HogeId2）後ろ二つ外部キーみたいなイメージなんだけどこういうパターンが調べても出てこない

2019/12/18(水) 15:34:43.72

>>86
この構成じゃ出来ないことが分かったので質問を取り下げます

2019/12/19(木) 01:57:08.71

webview使ってブラウザ操作してるんですけど、相手がASP使ったサイトだとボタン押したりテキストボックスに文字入れたりって操作は無理ですかね？

2019/12/19(木) 12:09:36.23

jsonファイルを読んで、木構造を編集して、jsonファイルに出力する
ファイルの入出力はJson.NETを使用
この場合内部のデータ構造はどう持つのがいいでしょうか？

Json.NETのJTokenを使うか、自作するか考えてますが、
標準的な手法は有りますか？

2019/12/19(木) 12:13:14.10

ちゃんと型を付けてデシリアライズ→加工→シリアライズする
型を付けるまでもないアドホックな処理ならそもそもC#なんか使わずに他のスクリプト言語を使う

2019/12/19(木) 18:39:36.79

質問なのですが
エンティクラスを配列に入れて使うようなことはできないでしょうか?
数が多いのでループでコードをすっきりさせたいです。

こんな感じなのを
public class test()
{
using (var context = new MyContext(connection))
{
var datalist1 = context.MyEntities1.ToList();
～
var datalist100 = context.MyEntities100.ToList();
}

//以下　共通処理

}

こんな感じで使いたい
string[] MyEntitiesList = new string[100];
MyEntitiesList[0] = "MyEntities1";
MyEntitiesList[1] = "MyEntities2";
～
MyEntitiesList[99] = "MyEntities100";

for(var i =0;i<100;i++)
{
var datalist1 = context.MyEntitiesList[i].ToList();
}

2019/12/19(木) 19:11:55.40

var datalist1 =
上書きで良いなら最後のだけ入れろ

2019/12/19(木) 19:54:28.09

>>92
すまないよくわからないのでもう少し説明をお願いしたい

>>91
こんな感じで使いたいを修正してみました。

string[] MyList = new string[100];
MyList[0] = "MyEntities1";
MyList[1] = "MyEntities2";
～
MyList[99] = "MyEntities100";

public class test(int i)
{
for(var i =0;i<100;i++)
{
using (var context = new MyContext(connection))
{
　　　　　　var datalist1 = context.MyList[i].ToList();

　　　　　//以下　共通処理
　　　　　　　}
}
　　　　　}

2019/12/19(木) 20:10:40.73

>>93
92 は for ブロック内部の代入式の左辺が変わってないよ、というツッコミ。

やりたいことは、抽出対象プロパティをテキストで指定してシステマティックにデータ抽出したいってことでしょ？

Dictionary やインデクサで、テキスト => 対象プロパティ or 抽出メソッド、のマップを作って、Reflection か何かで呼び出せばできそうな気がするけど、LINQ to Entities でワークするかどうかは試してみないとわからないな。

2019/12/19(木) 20:25:17.21

>>93
有益な回答を得るためにもう少し説明が必要かも。

なぜ抽出対象プロパティをテキストで指定する必要があるの？
1 カラムごとに 100 回抽出しようとしているけど、まとめて 100 カラムをワンショットで抽出してから加工するのではなぜダメなの？

また環境が EF6 なのか EF Core なのかも言及した方がいいかもね。

2019/12/19(木) 20:38:12.29

ごめん、勘違いしていた。
テキストで指定したいのはカラムじゃなくてテーブルなんだね。

2019/12/19(木) 20:58:33.77

そうですそうです。
データを取り出すところ以外はほぼ変わらないのに
↑のコードだけでも1テーブルの数が多い場合余裕で1万行超えてしまうので

public bool test1()
{
｝
public bool test2()
{
｝
～～～～
public bool test1000()
{
｝
と用意して
test1();
test2();
～～
test100();

を
public bool test()
{
｝

for(var i =0;i<100;i++)
{
test( iLop );
}

だけにできないかと思っています。

2019/12/19(木) 21:00:56.21

>>95
環境はEF Core3.1 です。

2019/12/19(木) 21:11:26.20

抽出テーブルを動的に指定したいなら、DbSet<T> を返すプロパティが DbContext の派生クラスに定義されていると思います。

型引数 T にテキストは直接指定できないので、その DbSet<T> 型のプロパティをラップするメソッドを定義して、テキストを引数で渡してやればよいのではないでしょうか。こんな感じで。

class MyDbContext : DbContext {
DbSet<MyEntityDataModel1> MyEntity1 { get; set; }

DbSet<T> GetTable<T>(string table) where T : CommonBaseClassOfMyEntityDataModels =>
this.GetType().GetProperty(table) as IQueryable<T>;
}

// 呼び出し側
context.GetTable(“MyEntity1”).ToList();

2019/12/19(木) 21:54:02.04

>>97
そういう目的ならテーブル名をテキストで指定する必要もなくて、

foreach (var prop in context.GetProperties())
{
var table = (prop as IQueryable<CommonBaseClass>).ToList();

// table に対するテスト処理
}

でよいかもしれない。

ただし下準備として、DbContext の全プロパティのデータコンテナを共通で受ける基底クラス CommonBaseClass を定義する必要がある。

似たようなことはやったことあるのだけど、このコードが手直しなく動くかどうかはわからない。

テスト処理もラムダ式のリストで用意しておいて、各テーブルと Zip() して適用するなど、LINQ を活用するとよいと思うよ。

2019/12/19(木) 21:59:04.37

>>90
説明が稚拙で申し訳ないです

プログラムはフォームで、木構造の編集とはノードのコピーや削除、値の編集などをGUIで行います

GUIの理由はJSONファイルはあるスマートウォッチのカスタムフェイス用で配置などを確認するためです

自分が知りたい事はc#でよく使われる木構造を扱うライブラリです