31

これは、正規表現を書く初心者にとって大きな混乱の原因であり、隠れたパフォーマンスの問題を引き起こす可能性があり、典型的なユースケースは貪欲ではないように思われます。

これは単にレガシーの理由（それが最初に行われた方法であり、すべての実装がそれをコピーする方法でした）ですか、それとも理由がありますか？

4

6 に答える 6

11

ヒステリックライセン

答えの一部には、実際のコンピューティングにおける RE の起源が関係している可能性があります。Ken Thompson 自身が実際の実装を書き、qedとed(1)で使用するまでは、それらはもともとオートマトン理論と形式言語理論からの理論的概念でした。

元のバージョンには貪欲な構文しかなかったため、決定することすらありませんでした。

于 2010-02-16T18:03:12.810 に答える
9

パフォーマンスの場合、バックトラッキングのために遅延量指定子が常に高速であるとは限りません: http://blog.stevenlevithan.com/archives/greedy-lazy-performance

実際の設計に関しては、量指定子がデフォルトで貪欲である理由を正直に言うことはできませんが、量指定子を怠惰ではなく貪欲にするためにどの制御文字が使用されたのか疑問に思います。私は?それをカットしなかったと思います:-)

于 2010-02-16T17:54:41.060 に答える
6

考えられる理由:貪欲でない場合、正規表現エンジンは多くのバックトラックを必要とします。

于 2010-02-16T17:53:31.397 に答える
3

ここでの本当の問題は、Kleene クロージャー オペレーター (スター) です。正規表現の他のすべての場合、最長一致は最短一致と同じです。

このような観点から考えると、最近のツールでは両方が必要であることがわかっていることがわかります。私は遅くまで起きているので、2 つの例しか考えられません。

  • との両方が、ほとんどの特別な変数変更演算子の「最長一致」形式と「最短一致」形式をksh提供します。bash

  • Lua の正規表現には*、Kleene クロージャの最長一致と-Kleene クロージャの最短一致が含まれます。-文字通りの記号をエスケープするのを忘れると、これはいつも私を噛みます.

Kleene の元の作業に戻って、それが初期のツールに最長一致への影響を与えた可能性があるかどうかを確認することは興味深いでしょう。

于 2010-02-17T04:05:12.697 に答える
3

コンピューターが可能な限り予測どおりに動作することが重要です。したがって、少なくとも経験豊富なプログラマーがコードの結果を予測できるように、正しい動作は貪欲なマッチングなどの単純なルールに従う必要があります。

典型的な使用例が貪欲ではないかどうかについては、次の場合はどうでしょうか: foo1909、bar3939、baz3331 などのエントリを持つファイルがあり、これらの数値を抽出したいだけだとします。これは正規表現として (\d*) と書くのが自然に思えます。

(\d*)\D などと書くのは簡単だと言うかもしれませんが、基本的には、プログラマーがより明示的であいまいさを少なくできる場合がほとんどです。100% 予測可能で、頭の中で計算するのは簡単なデフォルトの動作が必要だったので、それは私には理にかなっているように思えます。

于 2010-02-16T17:54:27.207 に答える
1

典型的なユースケースは貪欲ではないようです。

「典型的なユースケース」が HTML ハッキングを意味しない限り、これが間違っていることを明確にしたいと思います。

簡単な例は、プログラミング言語の字句解析器です。あなたは単にしたくない

foo = 42

3 つの変数として解釈され、その後に等号が続き、その後に 2 つの数字が続きます。それどころか、通常、パーサーは可能な限り最長の一致を考慮することを期待します。

HTML が登場する前、私たち年配者は貪欲な正規表現とともに何十年も生きてきました。今日でも、99% のケースで貪欲でないものを使用していません。これは、確かに私が構文を調べるのが面倒だからです。たとえば、文字列を照合するには:

"(\\"|[^"])*"
于 2013-02-12T21:07:17.193 に答える