|Parsing C++ with lex++ and bison++ ? email@example.com (1994-06-16)|
|Re: Parsing C++ with lex++ and bison++ ? firstname.lastname@example.org (1994-06-19)|
|Re: Parsing C++ with lex++ and bison++ ? email@example.com (Boris Burshteyn) (1994-06-23)|
|Re: Parsing C++ with lex++ and bison++ ? firstname.lastname@example.org (1994-06-25)|
|Re: Parsing C++ with lex++ and bison++ ? email@example.com (Boris Burshteyn) (1994-06-29)|
|From:||firstname.lastname@example.org (Allen Leung)|
|Keywords:||C++, parse, tools, comment|
|Organization:||Netcom Online Communications Services (408-241-9760 login: guest)|
|Date:||Sat, 25 Jun 1994 23:49:45 GMT|
Boris Burshteyn <email@example.com>:
>I do not know exactly why BISON++ does not allow $-types with user-defined
>constructors, but one could suppose this comes from the fact that a
>LR1 parser constantly pushes attributes on the stack during shifts and goto
>steps, and then pops them out at reductions. ...
I haven't had a chance to use Bison++ or Flex++ yet but I'll
hazard a guess why $-type with constructors aren't allowed: the semantic
stack(at least in Bison) is implemented as an array of unions and
C++ disallows constructors in components of a union.
BTW, isn't the output of Bison++ and Flex++ similar to that of
Bison and Flex; they all generate lookup tables, right?
[The problem is that the parse value stack is an array of unions, so that
when you push and pop them stack C++ can't tell what type each is. In fact,
yacc programmers invariably use %type to tell yacc what type each each
stack entry is, give or take a little cheating, but there seems to be no
way to communicate this to C++. C++ has no discriminated union type
and it's painful to fake with classes. -John]
Return to the
Search the comp.compilers archives again.