bug-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: too many warnings from Bison CVS for Pike


From: Hans Aberg
Subject: Re: too many warnings from Bison CVS for Pike
Date: Wed, 15 Feb 2006 01:15:42 +0100

On 15 Feb 2006, at 00:29, Joel E. Denny wrote:

If %union using a C++ compiler automatically invokes the dynamic C-
parserstack, then there would only be the need for such an option for user
that want to use a POD type without %union.

Well, I hate to admit it, but I have a peculiar situation when I don't use %union and I do use #define YYSTYPE_IS_TRIVIAL 1. YYSTYPE_IS_TRIVIAL is not actually documented for the user, but the problem should go away once
I can convert to the C++ skeletons.

The best approach, I think, would be that the proper C++ skeletons come up and running, so that essentially all C++ users can convert to that.

But is not the combination of YYLTYPE_IS_TRIVIAL and YYSTYPE_IS_TRIVIAL the same as the macro CPP_SEMANTIC_POD I suggested? Why do you need two macros? Is not enough with one macro YYTYPES_ARE_POD, which, when defined, invoked the
dynamic C-parser?

The easiest approach is just to document the existing macros. Who knows,
other Bison users might be using them now anyway.

Probably and perhaps. It is probably best to figure out what should happen down the road, and be conservative until that has been settled.

I have no strong
preference about this.

Nor do I. The thread started because somebody noticed there was compiler C as C++ support, whereas I tacitly assumed it had been dropped, in view of various past difficulties. Then this led to a re- examination of those difficulties.

I use my own C++ skeleton, which requires a tweak of Bison, producing a code placement version of %define. In addition, %union cannot be used with non-POD's, so there is a need for another command that triggers the Bison static type mechanism, but which does not implement a union.

  Hans Aberg






reply via email to

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