ふらっと 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 があぼーんで読めない。。。