2

背景情報を簡単に説明します。

フォームのさまざまな側面を目的の入力と比較するルール エンジンを設計しているときに、ある数値が別の数値よりも大きいかどうかをチェックする必要があるという問題に遭遇しました。> 演算子と < 演算子を使えば簡単ですよね? 違います。比較する必要があるこれら 2 つの型は文字列です。文字列でなければなりません。変更できるものではありません。

エンジンがどこで故障するかを確認したいので、どこから始めればよいかを知りたいので、「100」と「10,000」を比較するように言いました。10k の方が大きいと正しく計算されたときの驚きを想像できます。文字列の長さなので、1001 と 1000 を比較すると、やはり正しくなりました。1001 の方が大きいです。

しかし、私はこれがうまくいかないことに固執していたので、エンジンが失敗するのを見るためにあらゆる種類のシナリオでエンジンを叩き続けました。同僚が、システムがファイル名として 1001 と 1000 を比較し、適切に順序付けできることを指摘した後、最新の考えでは、ある種の aschii 文字値を比較し、テストを続けました。これは失敗するでしょう。両方が文字列である場合、どちらが数値的に大きいかを適切に計算できることを受け入れることができませんでした。

そこで私が次に考えたのは、それぞれの最初の文字を並べて、文字列の各部分の値を比較することでした。11,111 から 9,999 をテストしたところ、9,999 の方が大きいと判断され、最終的に成功しました。パーフェクトです。1 と 9 を比較して、毎回 9 が勝ったことに十分満足していました。簡単な修正で、短い文字列の前に 0 を付けます。

この新しい理論をエンジンで実行したところ、どちらが大きいかを喜んで計算していました。

しかし、私はまだ確信が持てません。このタイプの比較には他の落とし穴があるに違いありませんが、私の理論を証明するためにテストする比較が不足しています。オーバーフラワーの皆さんへの私の質問は、これが失敗する可能性があるシナリオは何だと思いますか?

あなた自身がこれを試したことがありますか?数値が文字列である場合の数値の比較と、直面した落とし穴は何でしたか? それらをすべてカバーしましたか、それともいくつかの主要な落とし穴を見落としていますか?

私は、この方法が絶対確実であるとは確信していません (ただし、100d から 10000 などの文字列はテストしていないことに注意してください。それを確認するための検証があるからです)。

前もって感謝します!

注:私はいくつかのグーグル検索と検索を行いましたが、ここでの質問でカバーされているとは思いません。はい、いくつかは似ていますが、文字列に数字が必要ないこと、数字だけの文字列が必要ないことを懸念しているため、これは異なると見なしました投稿するには十分です。

注2:私の具体的な質問は、intの代わりに数字の文字列を使用すると、数値比較がどこで失敗するかです

4

2 に答える 2

4

文字列である数値を比較するには、最初に数値に変換することをお勧めしint.Parseます。文字列を数値に解析する際のカルチャに依存した複雑さを他の誰かに理解させ、その後で単純な数値比較を使用する方が、はるかに確実であり、簡単です。

文字列が常に数値であるとは限らない場合は、int.TryParse適切に使用および処理してください。

于 2012-07-20T13:35:30.040 に答える
3

私があなたの質問を理解しているかどうか見てみましょう:

基本的に、次のことが当てはまるかどうかを尋ねています。

正の整数 n1 および n2 と、それらに対応する字句表現 L(n1) および L(n2) が与えられた場合、L(n1) < L(n2) の場合に限り、n1 < n2?

それが「はい」よりも質問である場合、それは正しいです。辞書式順序付けの定義からそれを導き出すことができます。

参照: http://www.dartmouth.edu/~matc/DiscreteMath/III.5.pdf 定義 定義 III.5.2。

ただし、すべての整数が正であるとは言いませんでしたが、負の整数の場合は正反対です。

私が心配しているのは、整数を表さない非文字列が存在する可能性です。なんとか回避できませんか?そうでない場合は、非常に危険な方法であり、非常に予期しない動作が発生する可能性があります。

于 2012-07-20T14:48:08.223 に答える