Re: accessing yyval outside lex and yacc

[Hans Aberg]

At 18:32 +0200 2001/07/21, Axel Kittenberger wrote:
>Looking at c globally I don't see all what 'union' has an advantage against
>nomral typecasts,...

I think unions in C show up because one wants to save memory.

>... same goes for bison where union is only internally used,
>why not simply make directly typecasts at output?

As for Bison, there are two components of %union, one that allows one to
make static checks in the grammar rules, and another that implements it in
C++.

>union TOKEN {
>  int i;
>  char *s;
>}
>
>Normally a rule would aprox. look like this:
>token1.i = strlen(token2.s);
>
>what's the advantage against having the generator generate:
>(int) token1 = strlen( (char *) token2);

I am not sure what you are doing here: If the idea is to just have an "int"
and do typecasts, one must somehow make sure that void* fits into an int.

>Okay fair question would be what's the advantage doing it this way? You'll
>save the union definition, and don't know for sure, would it help for your c++
>problems?

A more normal way in C++ would be to build a polymorphic hierarchy:
  class object;
  class object_root { ... };
  class object {
    object_root* data_;
  }
and derive the other classes from object_root.

Then the common semantic values will be an instantiation of the class
object. One then has to get the Bison %union write out the correct
dynamic_cast's.

But for now, I skipped over this Bison static type-checking. If I am only a
bit more careful when making sure when writing out the section rules, I do
not need it.

  Hans Aberg