Re: Token types with constructor

[Hans Aberg]

At 17:50 +0200 2004/09/03, Wolfgang Wieser wrote:
>> You are essentially saying that, by certain assumptions on how the C-parser
>> is implemented, you can write a proper C++-stack, which does what a proper
>> sequence container would do.
>>
>> This is a quick-and-dirty implementation, as there is no guarantee that
>> future Bison versions uses the same stack implementation. For example,
>> Bison uses up to three stacks, for semantic, state and locations values,
>> but these can, if one so wants, be merged into a single stack.
>>
>Merging stacks will not pose any problem since all the C-types will get a
>suitable constructor automatically by the C++ compiler. We just need to
>make sure that these are actually called. And since malloc()/free() will
>not do this, we need to call the constructors/destructors "by hand".
>
>Of course this solution is semi-clean as from the design.

I just meant that one cannot expect it to work, without possible rewriting,
with future Bison versions. Of course, if Bison would change, it would be
easy to alter it. But for it be an officially supported Bison feature, one
needs somebody willing to maintain it.

>But it has no trouble when restructuring the inner workings and layout of
>the stack. At least I cannot see any.
>
>> So, if it works for you now, that is fine. But it is not a Bison standard
>> C++ solution that you have come up with.
>>
>I did not try it out, actually. I'm using this "technique" in other sources.

The idea is in fact good, if one wants to use it with C-parsers which, for
some reason, has not been ported to C++. For example, the GLR parser.

  Hans Aberg