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: Hans Aberg
Subject: Re: %union errors that shouldn't be there
Date: Sat, 26 Mar 2005 14:09:15 +0100

At 14:56 +0100 2005/03/25, Laurence Finston wrote:
 > This discussion is very confusing, because it mixes two topics:
 Extending C++, and what is appropriate for Bison.

This is just my opinion, but I don't think adding type information to `union'
would be in the spirit of C.  If this feature were added, the first thing I'd
do would be to look for a way to turn it off.

It would be in the spirit of C++. :-)

 > As for the latter
 question, one would have to give iyt a different name that %union.
 But with the %typed and other features suggested here (%define),
 that would not be a problem.

No, but what would be the advantage over something like the following?

struct Yystype_Struct
{
   unsigned short type;

   void* object;

};

With unions, one wants to avoid dynamic allocations. Each dynamic allocation takes several tens, sometimes, hundreds of cycles.

I don't understand why you would want to use `union' at all.  Of course,
what's appropriate for Bison is up to the maintainers and developers, so I'll
stay out of that one.   From my point of view as a user, it's perfectly simple
to use `void*' in `%union', and I suspect that it will be perfectly simple to
use it as `YYSTYPE' (I haven't tried it yet).
So what problem are you trying to solve?

Unions are faster than dynamic allocations, and in the past, it was important that they take little space. One example where I have used it is a series of function pointer of different type.
--
  Hans Aberg




reply via email to

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