[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Token types with constructor
From: |
Akim Demaille |
Subject: |
Re: Token types with constructor |
Date: |
Mon, 13 Sep 2004 10:50:23 +0200 |
User-agent: |
Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) |
>>> "Hans" == Hans Aberg <address@hidden> writes:
>> There is just no decent way to store different object types, you have
>> to store pointers (there are nice proposals for Variant types in
>> future C++es, but that's not for tomorrow). Also, introducing an
>> artificial common root to all the symbols often breaks the AST design,
>> or worse, weakens types hence type safety.
> Actually, I use:
> class semantic_type {
> public:
> long number_;
> std::string text_;
> object object_;
> semantic_type() : number_(0) {}
> };
> #define YYSTYPE semantic_type
> where the class object spots a reference counted pointer to a common
> polymorphic hierarchy. Sometimes these types are used in parallel, text_
> for token name, number_ for lookup table token values (used in the case of
> definitions), and object_ usually contains the semantic value.
OK.
> I cannot use the Bison %union then, because of the limitation of C++ to not
> use non-POD's in unions, but I experimented with a %type feature which does
> not implement unions. But in this polymorphic approach I use, it turns out
> not to be every essential, as an erroneous type operation will cause a C++
> runtime dynamic_cast exception. But others ay want a %type feature for
> keeping track of a static pointer.
We cannot afford such a solution in Bison, for performance reasons.
First, the copy are expensive because of the size of the stack
members, plus the ctor they involve, and in addition dynamic_cast is
an expensive operation.
The C++ skeleton still has much to do to be really what everybody
needs, but once its interface etc. stable, we will try to find a
better solution, based on the ideas for Variants. Meanwhile, it won't
change.
> In order to be able to write a decent C++ parser, I need essentially one
> feature, a command
> %code <name> {...}
> that would put {...} into a M4 macro derived from <name>. The thing is that
> code can under C++ put in several more places than in C, and the setup
> should be properly be synced with Flex. This takes some experimentation to
> do.
It exists, it's called %define, but I'm not ready to open this publicly.
- Re: Token types with constructor, (continued)
- Re: Token types with constructor, Hans Aberg, 2004/09/02
- Re: Token types with constructor, Martin Trautmann, 2004/09/02
- Re: Token types with constructor, Wolfgang Wieser, 2004/09/02
- Re: Token types with constructor, Hans Aberg, 2004/09/02
- Re: Token types with constructor, Akim Demaille, 2004/09/03
Re: Token types with constructor, Martin Trautmann, 2004/09/09
Re: Token types with constructor, Hans Aberg, 2004/09/13