1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
|
B() generates a bf(C++) parser em(class), rather than a parsing em(function),
like Bison. B()'s class is a plain bf(C++) class and not a fairly complex
macro-based class as generated by Bison++.
The bf(C++) class generated by b() does not require em(virtual) members
(when polymorphic semantic values are used (cf. section ref(POLYMORPHIC) a
polymorphic base class em(is) used, but that class has no further implications
for the parser class generated by bic()); in this case polymorphism is merely
used internally, inaccessible to bic()'s user, to define a common interface
for the various polymorphic data types).
The generated parser class's essential member (the member tt(parse)) is
generated from the grammar specification and so the software engineer will
therefore hardly ever feel the need to modify that function. All but a few of
the remaining predefined members have very clear definitions and meanings as
well, making it unlikely that they should ever require overriding.
It is likely that members like tt(lex) and/or tt(error) need dedicated
definitions with different parsers generated by bic(); but then again: while
defining the grammar the definition of the associated support members is a
natural extension of defining the grammar, and can be realized em(in parallel)
with defining the grammar, in practice not requiring any virtual members. By
not requiring virtual members the parser's class organization is simplified,
and calling non-virtual members will be just a trifle faster than calling
these member functions as virtual functions.
In this chapter all available members and features of the generated parser
class are discussed. Having read this chapter you should be able to use the
generated parser class in your program (using its public members) and to use
its facilities in the actions defined for the various production rules and/or
use these facilities in additional class members that you might have defined
yourself.
In the remainder of this chapter the class's public members are first
discussed, to be followed by the class's private members. While constructing
the grammar all private members are available in the action parts of the
grammar's production rules. Furthermore, any member (and so not just from the
action blocks) may generate errors (thus initiating error recovery procedures)
and may flag the (un)successful parsing of the information given to the parser
(terminating the parsing function tt(parse)).
Symbols defined in the generated parser and parser base class usually end in
an underscore character. Such symbols should not be masked or
redefined. Some members have names not ending in an underscore
character. Those names have either historically been used (like tt(parse) and
tt(ERROR)) or they can be redefined by the user (like tt(int lex()) and
tt(void print())). Their specific requirements are documented below.
|
