Re: %union errors that shouldn't be there
Hans Aberg wrote: > With unions, the problem is, if con-/de-structors are non-trivial, that it > is impossible to know which ones to apply and when. Stroustrup, _The C++ Programming Language_, Special Edition, 2000, p. 257, Section 10.4.12: "Consequently, a union may not have members with constructors or destructors. It wouldn't be possible to protect that object against corruption or to guarantee that the right destructor is called when the union goes out of scope." > 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? I suspect that doing so in C++ would break compatibility to C. I haven't checked whether any C++ implementation has implemented such a facility as an extension, though. 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*'. Laurence ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: %union errors that shouldn't be there
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
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: %union errors that shouldn't be there
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
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: %union errors that shouldn't be there
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
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
