123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172 |
- [section The design of the library]
- The purpose of the library is to provide tools to build template metaprograms
- being able to interpret the content of a string literal and generate code,
- display error messages, etc based on the content of the string literal. Such
- metaprograms are called [link parser parser]s. Metaparse is based on
- [@https://en.wikipedia.org/wiki/Parser_combinator parser combinators].
- The key components of the library:
- * [link ref-string Compile-time string representation]. These are tools for
- representing the content of a string literal in a way that makes it possible
- for template metaprograms to work on them. For this the library provides the
- [link string `string`] template class, which is a drop-in replacement of
- Boost.MPL's `string` implementation, and the [link BOOST_METAPARSE_STRING
- `BOOST_METAPARSE_STRING`] macro.
- * [link parsers Parsers]. These are template metafunction classes parsing a
- prefix of a string literal. These are simple [link parser parser]s providing
- the basic building blocks for more complicated ones doing some useful work.
- * [link combinators Parser combinators]. These are
- [link metafunction template metafunction]s taking [link parser parser]s as
- argument and/or returning [link parser parser]s as their result. They can be
- used to build more and more complex [link parser parser]s out of the simple
- ones.
- [section Design rationale]
- * [*Why template metaprogramming?]
- An alternative is using `constexpr` functions instead of template metaprograms.
- There are certain things that are difficult (if possible) using `constexpr`
- functions: building containers (at compile-time) the length of which depend on
- the parsed text (eg. parsing a JSON list), generating and validating types (eg.
- `printf`).
- * [*Why are there so many folding parsers?]
- Compilation speed and memory consumption is a critical part of template
- metaprogramming-based libraries. Users of the library interfaces built with
- Metaparse will have to pay for that every time they compile their code.
- Therefore it is important to provide the parser authors the ability to use the
- parser combinators with minimal overhead, while it is also important to provide
- convenient combinators for beginners and for the cases where that is the best
- option anyway.
- [link repeated `repeated`] combined with [link sequence `sequence`],
- [link accept_when `accept_when`] and [link transform `transform`] can replace
- any of the folding parsers, however, for the cost of constructing intermediate
- containers, that are (usually) processed sequentially after that.
- * [*Why external code generator for `BOOST_METAPARSE_STRING`?]
- To be able to support longer strings. It generates code using macros to reduce
- the size of the header files (the reducion is multiples of MBs).
- * [*Why defining a custom version of Boost.Preprocessor macros?]
- There are two reasons for the library defining its own set of preprocessor
- metaprogramming macros: to have control over the upper limit of iteration steps
- and to be able to clean the macros up once they have done their job (and avoid
- polluting the macros of the users).
- Note that these macros live in the `impl` directory, which means that they are
- an implementation detail of the library and should be used internally only.
- [endsect]
- [endsect]
|