We already have a hint of the dynamic nature of the Spirit framework. This
capability is fundamental to Spirit. Dynamic parsing is a very powerful concept.
We shall take this concept further through run-time parametric parsers. We are
able to handle parsing tasks that are impossible to do with any EBNF syntax
alone.

A Little Secret

A little critter called boost::ref lurking in the boost distribution
is quite powerful beast when used with Spirit's primitive parsers. We are used
to seeing the Spirit primitive parsers created with string or character literals
such as:

When boost::ref is used, the actual parameters to ch_p and
range_p are held by reference. This means that we can change the values
of ch, from and to anytime and the corresponding
ch_p and range_p parser will follow their dynamic values.
Of course, since they are held by reference, you must make sure that the referenced
object is not destructed while parsing.

What about str_p?

While the first form of str_p (the single argument form) is reserved
for null terminated string constants, the second form (the two argument first/last
iterator form) may be used:

Hey,
don't forget chseq_p. All these apply to this seldom used primitive
as well.

Functional Parametric Primitives

#include<boost/spirit/attribute/parametric.hpp>

Taking this further, Spirit includes functional versions of the primitives.
Rather than taking in characters, strings or references to characters and strings
(using boost::ref), the functional versions take in functions or functors.

f_chlit and f_ch_p

The functional version of chlit. This parser takes in a function
or functor (function object). The function is expected to have an interface
compatible with:

CharT func()

where CharT is the character type (e.g. char, int, wchar_t).

The functor is expected to have an interface compatible with:

struct functor
{
CharT operator()() const;
};

where CharT is the character type (e.g. char, int, wchar_t).

Here's a contrived example:

struct X
{
char operator()() const
{
return 'X';
}
};

Now we can use X to create our f_chlit parser:

f_ch_p(X())

f_range and f_range_p

The functional version of range. This parser takes in a function
or functor compatible with the interfaces above. The difference is that f_range
(and f_range_p) expects two functors. One for the start and one for
the end of the range.

f_chseq and f_chseq_p

The functional version of chseq. This parser takes in two functions
or functors. One for the begin iterator and one for the end iterator. The function
is expected to have an interface compatible with: