Suggestion for revising documentation on writing custom parsers
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 35/100
- Tipo di issue
- Documentazione
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- cpp
- Ambito
- documentation
Direzione di ricerca
Inizia in doc/tutorial.qbk intorno alla riga 3792 e leggi la sezione sui parser personalizzati. Rivedi la formulazione per renderla più neutrale e aggiungi indicazioni o un esempio che affronti letterali complessi come 5 'D 3 di SystemVerilog. Il lavoro sarà completo quando la sezione spiegherà quando i parser personalizzati sono appropriati e fornirà agli utenti indicazioni pratiche.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
- Lingua principale
- C++
- Stelle
- 183
- Fork
- 28
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di boostorg/parser
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
-
`.github/workflows/deploy_unified_header.yml` needs `permissions: contents: write`Forse già presa @Berserk-hub150 l’ha presa 50 giorni fa. Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 82/100
-
Is Boost.Parser abandoned?Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 20/100
-
Sequence parser overwrites std::u32stringForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 55/100
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 48/100
Tutte le issue di boostorg/parser
Issue simili
-
Make Catch2 optional when `RDK_BUILD_CPP_TESTS=OFF`Forse già presa @pechersky l’ha presa oggi. Apertabug
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 2 giorni
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
dice-group/dice-hash#111 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 64/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
MerginMaps/mobile#4741 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
ros-perception/image_pipeline#1198 ·