Previous: Split Symbols, Up: C++ Scanner Interface [Contents][Index]
If you specified both %define api.value.type variant
and
%define api.token.constructor
,
the parser
class also defines the class parser::symbol_type
which defines a complete symbol, aggregating its type (i.e., the
traditional value returned by yylex
), its semantic value (i.e., the
value passed in yylval
, and possibly its location (yylloc
).
Build a complete terminal symbol which token type is type, and which semantic value is value. If location tracking is enabled, also pass the location.
This interface is low-level and should not be used for two reasons. First, it is inconvenient, as you still have to build the semantic value, which is a variant, and second, because consistency is not enforced: as with unions, it is still possible to give an integer as semantic value for a string.
So for each token type, Bison generates named constructors as follows.
Build a complete terminal symbol for the token type token (not
including the api.token.prefix
) whose possible semantic value is
value of adequate value_type. If location tracking is enabled,
also pass the location.
For instance, given the following declarations:
%define api.token.prefix {TOK_} %token <std::string> IDENTIFIER; %token <int> INTEGER; %token COLON;
Bison generates the following functions:
symbol_type make_IDENTIFIER(const std::string& v, const location_type& l); symbol_type make_INTEGER(const int& v, const location_type& loc); symbol_type make_COLON(const location_type& loc);
which should be used in a Lex-scanner as follows.
[0-9]+ return yy::parser::make_INTEGER(text_to_int (yytext), loc); [a-z]+ return yy::parser::make_IDENTIFIER(yytext, loc); ":" return yy::parser::make_COLON(loc);
Tokens that do not have an identifier are not accessible: you cannot simply
use characters such as ':'
, they must be declared with %token
.
Previous: Split Symbols, Up: C++ Scanner Interface [Contents][Index]