help-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: %union errors that shouldn't be there


From: Laurence Finston
Subject: Re: %union errors that shouldn't be there
Date: Wed, 23 Mar 2005 19:34:59 +0100 (MET)

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?"

> 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.

> Perhaps Bison should support such a version. Then one does not need
> to use the %destructor stuff.

I don't use it now.

> >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.

> One would need to
> be aware that the C++ unions

The rest of this sentence was missing.

>
> >I haven't checked whether any C++ implementation has
> >implemented such a facility as an extension, though.
>
> Doubt it. The C++ paradigm is to use a class hierarchy instead.

I doubt it, too, but because I don't think it would be useful.  Anyone
who wants such a feature can do it himself or herself, as your example
shows.

Laurence




reply via email to

[Prev in Thread] Current Thread [Next in Thread]