On 13 Dec 2006, at 01:11, Satya wrote:
Putting the in the .y file would not suffice, as those functions need
to be put in a file compiled by the C++ associated C-compiler;
Well, when Bison generates an xyz.tab. c file, it can be compiled
by a C++ compiler. Thats the idea.
Once upon the time, Bison had an informal support for the C-parser to
be compiled as C++, but this was dropped, being too difficult to
maintain. Instead, a separate C++ skeleton was developed.
So, for C++, it is best to use the C++ skeleton file.
one
cannot then use C++ containers. If the C-parser is compiled using a C+
+ compiler, would it succeed, in view of that support for this has
been terminated, then the parser stack will not invoke copy
constructors when reallocating: it will only work with POD semantic
types.
The parser stack will not allow any special types anyway.
Sure it will: the C++ parser uses some 'std' container, like
std::vector.
You can put only *pointers* to STL or user defined data types on
the stack. I don't see how reallocation of the stack can affect
this. Maybe I am missing something. Can you elaborate pls.. (maybe
an example?)
It is the use of %union that forces POD semantic types, as it is
implemented using a C++ 'union', which only admits those. Then one
will have to tweak Bison to get it working.
Hans Aberg
_______________________________________________
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
