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
