Re: %union errors that shouldn't be there
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
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: %union errors that shouldn't be there
> With unions, one wants to avoid dynamic allocations. Each dynamic
> allocation takes several tens, sometimes, hundreds of cycles.
If pointers are used, then memory needs to be allocated for the objects they
point to, whether the pointers are in a `struct' or a `union'. It needn't be
allocated dynamically in either case.
I don't see any advantage to having multiple
members of pointer types in a `union', e.g.,
union
{
A* a;
B* b;
C* c;
...
};
In practice, it will probably make some code simpler and some more
complicated.
It's certainly not needed in order for the compiler to calculate the size
needed for the `union'. I would prefer
union
{
void* v;
...
};
but off the top of my head, I don't see any decisive advantages or
disadvantages either way for automatically generated code. For user code, I
think the `void* v' variant would be easier.
> Unions are faster than dynamic allocations, and in the past, it was
> important that they take little space.
I have nothing against `unions'. I think if pointers are going to be used
anyway, then a single `void*' could be used for all types, in which case there
would be no need for a `union'. If class types are to be allowed, the
constructors of objects of these types might be performing dynamic allocation,
so it might not pay to take the trouble of avoiding it for the other types. I
think it's an interesting problem.
Laurence
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
