2

argpやC++のboost::program_optionsのサブセットなど、よく知られているコマンドライン引数パーサーはたくさんあります。

たとえば、最近、C++で次のような単純なシナリオを解析できるようにするものを作成しようとしました。

int main (int argc, char *argv[]) {
    auto state = parse (argc, argv);
    const auto foo  = mandatory<int>            (state, {'f', "foo"});
    const auto bar  = optional_with_default<int>(state, {'b', "bar"}, 42);
    const auto frob = optional<std::string>     (state, {'F', "frob"});
    if (!frob) {
        ...
    }
}

しかし、位置に依存しないフラグの解析は簡単ではないことがすぐにわかりました（たとえば-fgx、と同じになります-f -xg）。その後、値引数を使用して位置に依存しないフラグをスローすることは、実際には簡単ではなくなりました（たとえばtar -xvzf frob.tar.gz）。

問題は経験論によってのみ明らかになりました。たとえば、この検索で​​は何も見つかりませんでした。

このトピックに関する優れたリソースを知っていますか？あなた自身のベストプラクティスは何ですか？

注：いくつかのC ++の例に名前を付けていますが、この質問は言語に依存しないはずです。アルゴリズムと一般的な提案を求めています。

4

1 に答える 1

0

（例のように）宣言部分を持たずにコマンドラインパーサーを記述していて、フラグ/ショートオプションのグループ化を可能にする場合（-xfと同じ-x -f）、どういうわけかクライアントの順序を強制する必要があると思います呼び出します。

たとえば（それがunixtarプログラムの有効な呼び出しであると仮定して）考えてみてください。

tar -vfxul.tar -x

ここでは、次のオプションがあります。

x
v
f=xul.tar

xフラグ（pコード）を最初にテストする場合は、

state = parse(argc, argv)
x_set = flag (state, 'x')
...
filename = mandatory (state, 'f' or "filename")

あなたは質問に答えるのに苦労します：どれxですか？

tar -vfxul.tar -x
       ^        ^
       x?       x?

パーサーはオプションについてまだ認識していないため、では、すべての文字（、、、、... ）が認識されるフラグである可能性があるfilenameと想定する場合があります。vfxul.tarvxu

したがって、（単純な人工知能や複雑なヒューリスティックに頼ることなく）考えられる最善の推測は、の最初の出現を取得することだと思いますx。

short-option-with-valueが解析された後は、flag-optionsを解析することを禁止する必要があると思います。

state = parse(argc, argv)
x_set = flag (state, 'x')
...
filename = mandatory (state, 'f' or "filename") // THROW ERROR HERE!

これにより、コードを特定の順序にクランチする必要がある状況になり、そのようなライブラリの適用性がさらに低下します。したがって、これは、相互に依存しない引数リストがある非常に単純なシチュエーションパーサーにのみ当てはまります。 。

注：短いオプションが可能な場合、またはフラグ/短いオプションのグループ化が許可されている場合にのみ、解析を並べ替える必要があります。

ソース

  • 経験主義
于 2012-07-10T13:45:47.687 に答える