help-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: C++ / multiple instances / iostreams


From: Hans Aberg
Subject: Re: C++ / multiple instances / iostreams
Date: Sun, 18 Jul 2004 19:53:30 +0200

At 14:15 +0200 2004/07/18, Laurence Finston wrote:
>> I've bison-1.875a installed and I've some questions to this version.
>>
>> 1) Does bison create an c++-parser class (wrapper) and can I use multiple
>> instances of the parser in an application?
>
>I've just been using 1.875, but the comments below might be helpful anyway.
>
>There's been some discussion about C++ parser classes recently,
>at least with respect to 1.875.
>You can look at the archives here:
>http://lists.gnu.org/archive/html/help-bison/
>
>I just generate a reentrant C parser and put C++ code in the actions for
>the rules.  It works fine.  I keep all the information about the parser
>state that I need in the object pointed to by the `void*' argument passed
>to `yyparse()'.  Therefore there's really no need for a parser class with
>`yyparse()' as a member function.  I use multiple threads that call
>`yyparse()' and that also works fine.

To this you must add that you are using %union and a Std-C++ compliant
compiler.  Then only POD's can be used in C++ unions, so they behave
essentially as under C, and as %union implements the parser semantic type
using a C union, it works. This does not work if one is using a semantic
type with non-POD data members, as the C stack will not invoke the copy
constructors when recopying.

Then, for that situation I made a C++ parser. The details are in the
Patches-Bison list. I need it, because, instead of a union type, I use a
polymorphic (virtual) class hierarchy. It does not work in a multi-threaded
environment; in order to achieve that, simply alter the skeleton file so
that the parser stack & other data are in the parser function.

>> 2) Does it support iostreams?
>
>If you use the method described above, this question becomes irrelevant,
>except with regard to the debugging output produced when using the `%debug'
>feature and `yydebug' is positive.

This is always irrelevat, except for diagnostic output, as the parser reads
tokens from the lexer, and not in any istream or other character flow.

  Hans Aberg






reply via email to

[Prev in Thread] Current Thread [Next in Thread]