Re: Token types with constructor

[Hans Aberg]

At 20:52 +0200 2004/08/28, Martin Trautmann wrote:
>>From your discussion I know that you propose two ways of integrating
>bison in a C++ framework. But I am not happy with both ways:
>
>1) I would like to use a well supported parser template which works in
>future versions of bison in the same way

You are not alone.

> (It doesn't seem to me that the
>bison team really stands behind the C++ extension)

Right. There is a C++ parser that comes with Bison, but I could not get it
working. So I wrote my own. It is published in the Bison-Patches list.

>2) I don't want to use new and delete in every rule (that is why I don't
>like to use pointers to Objects)

My approach lets a C++ stack invoke the usual class destructors, so with
hat approach, it is not needed. With the method that Laurence Finston
suggests, one will have to delete the resources explicitly. This is
especially tricky during error recovery, so there is an experimental
%destructor feature for that.

>What is the problem with the following code in the current bison
>version:

And which version is that?

>class Token
>{
>  std::string str;
>  int i;
>};
>#define YYSTYPE Token
>
>The problem is that the token is stored within a union.
>Extract of yacc.c:
>union yyalloc
>{
>  short yyss;
>  YYSTYPE yyvs;
>};
>
>So there is a very easy fix for that problem that only costs two byte
>per Token:
>struct yyalloc
>{
>  short yyss;
>  YYSTYPE yyvs;
>};

This is an easy fix. But a problem is that you are using the C-stack, and
that does not invoke the C++ copy constructors when reallocating. So funny
things will probably start to happen then.

>What about changing this in future versions of bison or offering an
>option within the official version to allow Token types with
>constructors?

This is the C parser. It turns out to be too complicated to write a fully
working combined C/C++ parser. So the decision was to make separate parsers
for different output languages.

  Hans Aberg