Consider adding omit, prefix and suffix template parameters to all parsers

オープン
#160 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
30/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
停滞
技術スタック
cpp
領域
compilers, performance

調査の方向性

まず、Parser、omit_parser::call()、omit_parser、expect_parser、および issue で説明されている if_(cond) 展開を調べます。既存の呼び出し経路をプロファイリングし、これらのパラメーターをすべての parser に移動することで、parser の動作を変更せずに測定可能な改善が得られるかどうかを判断します。issue では特定のファイルやテストは指定されていません。

索引モデルが issue の本文から書いたものです。

説明

The new parameters would be something like:

bool Omit, typename Prefix, typename Suffix, ...

It turns out that the omit_parser::call() shows up pretty high in profiling of Parser. If each parser knew if it was wrapped in a notional omit[], omit[] could just take a parser, and return a copy with true for the template parameter Omit. This means that the actual function call to omit_parser::call() (and omit_parser itself) goes away.

No so sure the other two would be as big a win, but a lot of parsers are something like eps(cond) >> p (that's what if_(cond) expands to). If all those instances, and expect_parser itself, were just built in to every parser (with a nope when there's no prefix and/or sufffix condition(s)), that might similarly speed things up. expect_parser would just go away in that case.

主要言語
C++
スター
182
フォーク
28
30日以内にマージされた PR はありません

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

boostorg/parser のほかの issue

boostorg/parser の issue をすべて見る

似ている issue

C++ の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。