Suggestion for revising documentation on writing custom parsers

オープン

#208 2024年12月5日に作成コメント 0 件リアクション 1 件担当者 0 名 GitHub で見る

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

評価

難易度: 3/5
見積もり時間: 1〜2日
初心者へのやさしさ: 35/100

issue の種類: ドキュメント
明瞭さ: おおむね明確
活発さ: 停滞
技術スタック: cpp
領域: documentation

調査の方向性

doc/tutorial.qbk の3792行目付近から始めて、カスタムパーサーについて説明しているセクションを読んでください。表現をより中立的なものに修正し、SystemVerilog の 5 'D 3 のような複雑なリテラルを扱うガイダンスまたは例を追加してください。セクションでカスタムパーサーが適切なのはどのような場合かを説明し、ユーザーに実践的な指針を示せば完了です。

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

説明

https://github.com/boostorg/parser/blob/f468d529fe440313d9d67d092f360b1a64a6f702/doc/tutorial.qbk#L3792

Thank you for your work on Boost Parser. It's an impressive library, and I've found it quite powerful.

While I appreciate the humor in the writing, I found the tone to be slightly dismissive of scenarios where writing custom parsers might genuinely be the most effective solution. For instance, I am working on parsing SystemVerilog code, which includes number literals with unique syntax, such as 5 'D 3. Parsing such constructs character by character using char_ primitives seems neither convenient nor effective, and it would make a strong case for writing a custom parser akin to uint_.

I believe this use case illustrates that there are situations where users might reasonably need more guidance on creating low-level parsers. If this section of the documentation could include:

A more neutral tone when addressing the use of custom parsers.
An example of how to effectively handle complex cases (like SystemVerilog number literals) using the library's primitives or via a custom parser.

This approach would make the documentation more inclusive and better serve a wider range of users.

Thank you again for your efforts, and I hope my feedback helps in further refining the excellent resources you provide.

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

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

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

はじめの一歩

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

boostorg/parser のほかの issue

Please provide an example for parsing a file オープン

難易度 2/5 1〜3時間初心者へのやさしさ 68/100

boostorg/parser#329 · 2026年7月5日に作成
`.github/workflows/deploy_unified_header.yml` needs `permissions: contents: write` オープン

難易度 1/5 1時間未満初心者へのやさしさ 82/100

boostorg/parser#322 · コメント 1 件 · 2026年3月3日に作成
Is Boost.Parser abandoned? オープン

難易度 1/5 1時間未満初心者へのやさしさ 20/100

boostorg/parser#333 · 2026年8月18日に作成
Sequence parser overwrites std::u32string オープン

難易度 3/5 1〜2日初心者へのやさしさ 55/100

boostorg/parser#327 · コメント 1 件 · 2026年4月5日に作成
Test structure is stressful in terms of compiler memory consumption オープン

難易度 3/5 1〜2日初心者へのやさしさ 48/100

boostorg/parser#321 · 2026年3月2日に作成

boostorg/parser の issue をすべて見る

似ている issue

[Bug] NULL pointer dereference in llm_running_callback (NGZA-AX-LLM #3) オープン

難易度 1/5 1時間未満初心者へのやさしさ 90/100

AXERA-TECH/ax-llm#77 · 2026年9月22日に作成
resume() sends a second HTTP response (400) after a successful resume オープン

難易度 1/5 1時間未満初心者へのやさしさ 90/100

games-on-whales/wolf#509 · 2026年9月21日に作成
pn7160: reader goes permanently deaf — post-read IRQ-low check fails reads that succeeded オープン

難易度 2/5 1〜3時間初心者へのやさしさ 74/100

esphome/esphome#19452 · 2026年9月21日に作成
Eval bug: Ministral-3 tool-calls during reasoning are not processed オープン

bug-unconfirmed

難易度 2/5 1〜3時間初心者へのやさしさ 76/100

ggml-org/llama.cpp#29248 · 2026年9月21日に作成
run_tests.py fails on windows, but running tests individually works オープン

難易度 2/5 1〜3時間初心者へのやさしさ 74/100

NVIDIA/cuda-samples#453 · 2026年9月21日に作成

C++ の issue をもっと見る