bisonc++.5.03.00.tar.gz bisonc++ parser generator



bisonc++ - Generate a C++ parser class and parsing function


bisonc++ [OPTIONS] grammar-file


Bisonc++ derives from previous work on bison by Alain Coetmeur (, who created in the early '90s a C++ class encapsulating the yyparse function as generated by the GNU-bison parser generator.

Initial versions of bisonc++ (up to version 0.92) wrapped Alain's program in a program offering a more modern user-interface, removing all old-style (C) %define directives from bison++'s input specification file (see below for an in-depth discussion of the differences between bison++ and bisonc++). Starting with version 0.98, bisonc++ represents a complete rebuilt of the parser generator, closely following descriptions given in Aho, Sethi and Ullman's Dragon Book. Since version 0.98 bisonc++ is a C++ program, rather than a C program generating C++ code.

Bisonc++ expands the concepts initially implemented in bison and bison++, offering a cleaner setup of the generated parser class. The parser class is derived from a base-class, mainly containing the parser's token- and type-definitions as well as several member functions which should not be modified by the programmer.

Most of these base-class members might also be defined directly in the parser class, but were defined in the parser's base-class. This design results in a very lean parser class, declaring only members that are actually defined by the programmer or that have to be defined by bisonc++ itself (e.g., the member function parse as well as some support functions requiring access to facilities that are only available in the parser class itself, rather than in the parser's base class).

This design does not require any virtual members: the members which are not involved in the actual parsing process may always be (re)implemented directly by the programmer. Thus there is no need to apply or define virtual member functions.

Before version 5.00.00 bisonc++ offered one single manual page. The advantage of one man-page is of course that you never have to look for which manual page contains which information. But on the other hand, bisonc++'s man-page grew into a huge man-page of about 2000 lines in which it was hard to find your way. From release 5.00.00 onward, three man-pages. The following index relates manual pages to their specific contents:

This man-page

This man-page concentrates on the bisonc++ program itself, offering the following sections:

files used by bisonc++;
  • SEE ALSO: references to other programs and documentation;
  • BUGS: some additional stuff that should not qualify as bugs.
  • ABOUT bisonc++: Some history;
  • AUTHOR: at the end of this man-page. )

    The bisonc++input(7) man-page covers the details of the grammar-specification file. This man-page offers these sections:

    The bisonc++api(3) describes the application programmer's interface, containing these sections:


    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.


    Bisonc++ may be used as follows:


    Bisonc++ may create the following files:



    bison(1), bison++(1), bisonc++api(3), bisonc++input(7), (using texinfo), flexc++(1),

    Lakos, J. (2001) Large Scale C++ Software Design, Addison Wesley.
    Aho, A.V., Sethi, R., Ullman, J.D. (1986) Compilers, Addison Wesley.


    Parser-class header files (e.g., Parser.h) and parser-class internal header files (e.g., Parser.ih) generated with bisonc++ < 4.02.00 require two hand-modifications when used in combination with bisonc++ >= 4.02.00. See the description of exceptionHandler__ for details.

    Discontinued options:

    To avoid collisions with names defined by the parser's (base) class, the following identifiers should not be used as token names:

    When re-using files generated by bisonc++ before version 2.0.0, minor hand-modification may be necessary. Refer to bisonc++'s git ( for details.

    The Semantic parser, mentioned in bison++(1) is not implemented in bisonc++(1). According to bison++(1) the semantic parser was not available in bison++ either. Maybe a so-called pure parser is available through the --thread-safe option.

    ABOUT bisonc++

    Bisonc++ was based on bison++, originally developed by Alain Coetmeur (, R&D department (RDT), Informatique-CDC, France, who based his work on bison, GNU version 1.21.

    Bisonc++ version 0.98 and beyond is a complete rewrite of an LALR-1 parser generator, closely following the construction process as described in Aho, Sethi and Ullman's (1986) book Compilers (i.e., the Dragon book). It uses the same grammar specification as bison and bison++, and it uses practically the same options and directives as bisonc++ versions earlier than 0.98. Variables, declarations and macros that are obsolete were removed.

    Compared to bison and bison++, the number and functions of the various %define declarations was thoroughly modified. All of bison's %define declarations were replaced by their (former) first arguments. Furthermore, `macro-style' declarations are not supported or required. Finally, all directives only use lower-case characters and do not contain underscore characters (but sometimes hyphens). E.g., %define DEBUG is now declared as %debug; %define LSP_NEEDED is now declared as %lsp-needed (note the hyphen).


    Frank B. Brokken (