Re: Token types with constructor

[Hans Aberg]

At 11:27 +0200 2004/09/03, Akim Demaille wrote:
>| What is the problem with the following code in the current bison
>| version:
>| class Token
>| {
>|   std::string str;
>|   int i;
>| };
>| #define YYSTYPE Token
>
>This is unrealistic:
>
>- There are usually many more than merely two different entities.  So
>  you're possibly wasting way too much space.
>
>- From the C++ point of view, it's even worse: you're calling n
>  different ctor and dtor for each symbol!  Not to mention the cost of
>  the copy.
>
>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.

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.

Clearly, I am wasting a few words in each entry of my stack. But this at
about the same order that say a location tracking would do. So, if your
program needs to run tight in memory, do not do it, but otherwise it is
convenient.

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.

For proper Bison multilingual development, one might need similar features
    %option <name> {...}
    %macro <name> {...}
that would do exactly the same. Instead of putting these language
specialized features into Bison, one merely creates some M4 macros for them.

  Hans Aberg