|
From: | Hans Aberg |
Subject: | Re: A polymorphic YYSTYPE for C++ (instead of the %union) |
Date: | Tue, 19 Jun 2007 13:39:45 +0200 |
On 17 Jun 2007, at 00:10, Michiel De Wilde wrote:
Here is a "generic" analysis of Bison support required/useful for any "polymorphic-type-other-than-a-union" solution. (1) The definition of YYSTYPE/semantic_type as a polymorphic type(usable like a union, but please not a real C union with its limitations)--> current support: a real C union{} or any user-defined type(2) A way to express the type of the semantic value of tokens and nonterminals.--> current support: the %token and %type clause indicating a C union field between angular brackets (3) Automatic correct type selection (or enforcement) in actions of objects of the polymorphic semantic_type. --> current support: field selection of the union: yyval.type_field (4) Cleanup of dicarded (non)terminals--> current support: %destructor which takes care of cleanup in all cases(but only those cases) that cannot be handled by actions (5) Defined behavior for rules without actions --> current support: $$=$1, undefined behavior when there is no $1.
The only think that needs some substantial work is 5. as the typed form becomes $<type0>$=$<type1>1. Cleanup, as in 4, can be done via the C++ language, so %destructor is not needed. As before in 1, one just defines YYSTYPE to whatever type one wants. As for 3, as you note, the <type> just expands to a field selection yyval.type, and when using a C++ polymorphic class hierarchy, one may use (depending on model): static_cast<type>(f(yylval)) if the base class is not derived as virtual, or otherwise dynamic_cast<type> >(f(yylval)), where f is a function depending on implementation. So there are a number of models here, but it can be handled with some M4 macro, I think. As for 2, I haven't given thought to that, but such changes can be easily handled, as Bison uses .l and .y files for its grammar.
Hans Aberg
[Prev in Thread] | Current Thread | [Next in Thread] |