Chapter 9: Invoking Bisonc++

9.1: Bisonc++ options

Where available, single letter options are listed between parentheses beyond their associated long-option variants. Single letter options require arguments if their associated long options also require arguments. Options affecting the class- or implementation header files are ignored if these files already exist. Options accepting a `filename' do not accept path names, i.e., they cannot contain directory separators (/); options accepting a 'pathname' may contain directory separators.

Some options may cause errors. This happens when they conflict with the contents of a file which bisonc++ cannot modify (e.g., a parser class header file exists, but doesn't define a namespace, but a --namespace option was specified).

To solve the error the offending option could be omitted; the existing file could be removed; or the existing file could be hand-edited according to the option's specification.

Note that bisonc++ currently does not handle the opposite error condition: if a previously used option is omitted, then bisonc++ does not report an inconsistency. In those cases compilation errors may be observed.

9.2: Bisonc++ usage

When bisonc++ is called without any arguments it generates the following usage information:

bisonc++ by Frank B. Brokken (

LALR(1) Parser Generator V 5.03.00
Copyright (c) GPL 2005-2017. NO WARRANTY.
Designed after `bison++' (1.21.9-1) by Alain Coetmeur <>

Usage: bisonc++ [OPTIONS] file
  [OPTIONS] - zero or more optional arguments (int options between
              parentheses. Short options require arguments if their
              long option variants do too):
   --analyze-only (-A): only analyze the grammar; except for possibly
           the verbose grammar description file no files are written.
   --baseclass-header=<header> (-b):
           filename holding the base class definition.
   --baseclass-preinclude=<header> (-H):
           preinclude header in the base-class header file.
           Use [header] to include <header>, otherwise "header"
           will be included.
   --baseclass-skeleton=<skeleton> (-B):
           location of the baseclass header skeleton.
   --class-header=<header> (-c):
           filename holding the parser class definition.
           the name of the generated C++ class.
   --class-skeleton=<skeleton> (-C):
           location of the class header skeleton.
           write details about the grammar analysis to stdout.
           generates debug output statements in the generated parse
           function's source.
   --default-actions=<off|quiet|warn|std> (-d):
           unless 'off', add a $$ = $1 action block to production rules
           not defining final action blocks.
           the parse function will dump the parser's state stack to stdout
           when a syntactic error is reported
   --filenames=<filename> (-f):
           filename of output files (overruling the default filename).
           use the traditional `flex' interface.
   --help (-h):
           produce this information (and terminate).
   --implementation-header=<header> (-i):
           filename holding the implementation header.
   --implementation-skeleton=<skeleton> (-I):
           location of the implementation header skeleton.
           show selected semantic values in the output generated by
           --debug. Ignored unless --debug was specified.
           sets the maximum number of nested grammar files (default: 10).
   --namespace=<namespace> (-n):
           define the parser in the mentioned namespace.
           don't create the parser's base class header.
   --no-decoration (-D):
           do not include the user-defined actions when generating the
           parser's tt(parse) member.
           don't put #line directives in generated output, overruling the 
           %lines directive.
           don't create the member parse().
           bisonc++ displays the actions of its parser while processing
           its input file(s) (implies --verbose).
   --own-tokens (-T):
           bisonc++ displays the tokens and corresponding matched text,
           received from its lexcial scanner.
   --parsefun-skeleton=<parserskel> (-P):
           location of the parse function's skeleton.
   --parsefun-source=<source> (-p):
           filename holding the parse function's source.
   --polymorphic-code-skeleton=<skeleton> (-L):
           location of the non-inline polymorphic functions skeleton.
   --polymorphic-skeleton=<skeleton> (-M):
           location of the polymorphic semantic values skeleton.
   --print-tokens (-t):
           the print() member of the generated parser class displays
           the tokens and their corresponding matched text.
           minimum number of successfully processed tokens between
           errors (default: 0).
   --scanner=<header-file> (-s):
           include `header-file' declaring the class Scanner, and call
           d_scanner.yylex() from Parser::lex().
   --scanner-class-name=<scanner class name>:
           specifies the name of the scanner class: this option is
           only interpreted if --scanner (or %scanner) is also used.
           extensive display of the actions of bisonc++'s scanner
   --scanner-matched-text-function=<function call>:
           specifies the function to call returning the text matched by
           the lexical scanner when returning a token
   --scanner-token-function=<scanner token function>:
           specifies the function to call by the parser's lex() function
           returning the next token returned by the lexcial scanner
           (by default d_scanner.yylex() when --scanner is used)
           show the names of the used/generated files on the standard
           error stream.
   --skeleton-directory=<skeleton-directory> (-S):
           location of the skeleton directory.
           unless 'off', issue a warning if no $$ statement was detected
           in an action block, or if no default $$ = $1 action can be
           added to a production rule without final action block, or
           if run-time a tag-mismatch is observed.
           pathname defines the directory where generated files should be
           written. By default this is the directory where bisonc++ is
           no static data are modified, making bisonc++'s generated
           code thread-safe.
   --usage: produce this information (and terminate).
   --verbose (-V):
           generate verbose description of the analyzed grammar.
   --version (-v):
           display bisonc++'s version and terminate.