[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments in %union processed incorrectly
|
From: |
Hans Aberg |
|
Subject: |
Re: Comments in %union processed incorrectly |
|
Date: |
Thu, 3 Jan 2002 12:29:53 +0100 |
At 10:15 +0100 2002/01/03, Akim Demaille wrote:
>>> The problem is that we now use an union to compute the alignments,
>>> and only for that. It just happens that I do have a Location
>>> class, which does have ctors. But now, because of this single
>>> union, this is no longer proper C++: classes with ctors cannot be
>>> stored in a union.
>>>
>>> As a result, my code no longer compiles.
>
>Hans> I have looked a little on the skeleton code, and there are two
>Hans> problems with union's and C++:
>
>Hans> First, if one is using the %union option and C++ types, then a
>Hans> proper C++ compiler should reject that. Now, Bison does not seem
>Hans> to do anything with the types, except putting them in when
>Hans> defined. %union seems to only require that all nonterminals are
>Hans> typed; for that last part, I introduced a %typed option. Thus
>Hans> %union { <body> } should be equivalent to %{ typedef union {
>Hans> <body> } yystype; #define YYSTYPE yystype ... %} %typed ...
>
>Hans, I would *really* appreciate if you could keep the threads
>focused on their subject. I was *not* referring to what you just
>wrote, and I made that *perfectly* clear.
>
>We all know the other issue. It's just not the subject.
I really do not see what you are hinting at here, because if the thread is
"Comments in %union processed incorrectly", then the stuff you mention have
nothing to do about that, and if you have a class with non-trivial
constructors, there is no way to combine that with unions, so if you are
aware of it, I do not see why you are mentioning it at all.
Hans Aberg
- Re: Comments in %union processed incorrectly, (continued)