Re: %union errors that shouldn't be there

[Hans Aberg]

At 19:34 +0100 2005/03/23, Laurence Finston wrote:
> On Wed, 23 Mar 2005, Hans Aberg wrote:
>
> >  At 14:16 +0100 2005/03/23, Laurence Finston wrote:
>
> >  >Add it where?
>
> >  Just add a field, invisible to the user, with the type information.
>
> I meant "in C++ or in Bison?"

In the context, I though you meant extending union in the C++ 
language. But this lead to the idea to do it by hand within the 
current language. Then Bison might support it.

>  > Dynamic allocations must have such a field with the size, so that it
> >  can be properly deallocated.
>
> Yes, this information must be stored somewhere.  However, when
> programming applications in C++, one usually doesn't have to worry about
> the sizes of objects.  Even when using C, I usually just use `sizeof()'.
>
> >  So it nothing strange as such. In fact,
> >  one can do thi by hand:
> >
> >  class Union {
> >  public:
> >     typedef Type int;
> >
> >     union Value {
> >       ...
> >     };
> >
> >     Type type;
> >     Value Value;
> >  };
>
> Yes, but this isn't a `union' anymore.

It would not be the old union, but a new union with new required 
semantics, that is clear.

>  > >I suspect that doing so in C++ would break compatibility
> >  >to C.
> >
> >  Not really, as C and C++ are different languages.
>
> The compatibility of C++ to C is not complete but reasonably close.
> I think this is one of the best and most important features of C++.
> If C++ was less compatible to C, it's quite possible that I wouldn't be
> able to use it in my parser rules.

Personally, I think this is one of the biggest hurdles with C++, 
because it inherits all C language quirks.
--
  Hans Aberg