[Top][All Lists]
[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
- %union errors that shouldn't be there, DYP, 2005/03/20
- Re: %union errors that shouldn't be there, Laurence Finston, 2005/03/21
- Re: %union errors that shouldn't be there, Hans Aberg, 2005/03/21
- Re: %union errors that shouldn't be there, Laurence Finston, 2005/03/23
- Re: %union errors that shouldn't be there, Hans Aberg, 2005/03/23
- Re: %union errors that shouldn't be there,
Laurence Finston <=
- Re: %union errors that shouldn't be there, Hans Aberg, 2005/03/23
- Re: %union errors that shouldn't be there, Laurence Finston, 2005/03/24
- Re: %union errors that shouldn't be there, Hans Aberg, 2005/03/24
- Re: %union errors that shouldn't be there, Hans Aberg, 2005/03/24
Re: %union errors that shouldn't be there, Hans Aberg, 2005/03/21
Re: %union errors that shouldn't be there, Laurence Finston, 2005/03/22