[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: %union errors that shouldn't be there
From: |
Hans Aberg |
Subject: |
Re: %union errors that shouldn't be there |
Date: |
Wed, 23 Mar 2005 18:45:09 +0100 |
At 14:16 +0100 2005/03/23, Laurence Finston wrote:
> The union does not
contain any type information which field is selected. If one adds that,
unions with non-trivial con-/de-Structors would be possible.
Add it where?
Just add a field, invisible to the user, with the type information.
Dynamic allocations must have such a field with the size, so that it
can be properly deallocated. 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;
};
Then write the class Union as to hide away the constructor stuff.
Perhaps Bison should support such a version. Then one does not need
to use the %destructor stuff. The drawback is the extra memory each
int takes on the parser stack.
I suspect that doing so in C++ would break compatibility
to C.
Not really, as C and C++ are different languages. One would need to
be aware that the C++ unions
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.
It might be possible to implement a way of using class types with
constructors and destructors in a `%union' in Bison, but not with an
unextended C or C++ union. This is just my opinion, but I think it's
simpler to just use `void*'.
So you have a suggestion of an extended union above.
--
Hans Aberg
- %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 <=
- 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, 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