[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: Thu, 24 Mar 2005 00:00:56 +0100

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

reply via email to

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