[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: Sun, 30 Dec 2001 12:17:39 +0100

At 11:14 +0100 2001/12/30, Akim Demaille wrote:
>But we have introduced something which makes it worse than before.  It
>annoys me a bit, since I had something which used to work, and now no
>longer does.  If we can reestablish the previous behavior without
>major surgery, nor throwing away the good stuff Paul brought, I'd be
>most happy.  Otherwise, it just means that I'll have to wait for my
>students' work on the C++ parsers.

I would want to move ahead with 1.31, so that some of the tweaks I need for
my C++ skeleton file can get installed. Then that could be used as input
for your students work, plus you could see if there is possible to see if
there is possible for a common C/C++ macro code for the parser component.
(What I have done is basically to replace yours stacks with C++ stacks. By
building a macro interface, one can then remove my C++ code, thus landing
on a common C/C++ interface again.)

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

I have looked a little on the skeleton code, and there are two problems
with union's and C++:

First, if one is using the %union option and C++ types, then a proper C++
compiler should reject that. Now, Bison does not seem to do anything with
the types, except putting them in when defined. %union seems to only
require  that all nonterminals are typed; for that last part, I introduced
a %typed option. Thus %union { <body> } should be equivalent to
  typedef union { <body> } yystype;
  #define YYSTYPE yystype

>Again, if there are other means than unions, I'm all for it.

If one is using types with non-trivial constructors, then one should
instead use a polymorphic hierarchy. I made such a construction with a
reference count, a class object with a pointer to a class object_root, and
other types are derived from object_root. I think that if your students
haven't seen this before, it would be difficult to develop it from scratch,
so I would want to drop it off to you and them.

The second problem with unions and C++ is that the code uses:
/* A type that is properly aligned for any stack member.  */
union yyalloc
  short yyss;
  YYSTYPE yyvs;
  YYLTYPE yyls;
# endif

To me it looks as though the code constructs two or three stacks of the
same value size using type (and I really do not know why the value type
must be of the same size). If one is using types with nontrivial
constructors, then this will also be rejected by the compiler, but on the
other hand, the C stacks you wrote are not calling any C++ constructors

This problem goes away if one is using the standard C++ containers instead,
because this type is not needed anymore.

However, I think of merging these different stacks into one. Then one would
instead use:
struct yyalloc
  short yyss;
  YYSTYPE yyvs;
  YYLTYPE yyls;
# endif
and use that type for a single stack.

>..But if
>this is troublesome, forget about it, and let's focus on 1.49.

I think that if you just release 1.31, then in 1.31x we could install my
tweaks. Then it is possible to experiment with genuine C++ code, and your
students could work that up to standard release at any point in time it

  Hans Aberg

reply via email to

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