Re: bison and C++

[Hans Aberg]

On 13 Dec 2006, at 11:33, Evan Lavelle wrote:

> > 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.
>
> I have a lot of C++ code in my .y file, and no problems. This is  
> 1.875c - has this support been dropped since then?

Yeah, somewhere around there. The compile C as C++ was never  
official. And if you define an YYSTYPE with nontrivial copy  
constructors, they will not be invoked during parser stack  
reallocation. Plus, there was some parser stack implementation that  
cause compiled under C++ failing.

I do not remember the details. But it is safest to switch to the C++  
skeleton of some of the latest Bison versions

> But then, I can't immediately see why any C++ support is required,  
> as long as you use the union/struct mechanism for passing data.

It is OK if you use %union or a struct or calls which is POD.

> My YYSTYPE is a struct which contains reference-counted classes.

A C++ struct, is just a class in which contents is declared public.  
If you use a reference count in a class, and put that in YYSTYPE, noy  
merely a pointer, it will not be invoked when the C parser stack  
reallocates. It will probably bomb when objects are deleted twice.

> Maybe this is the confusion? Do you only need the C++ skeleton if  
> your YYSTYPE is a real C++ class?

Yes. When the class is a non-POD, "plain-ol'-data", essentially the C  
structs as a C++ language subset.

> BTW, you don't even need Satya's 'extern "C"' declarations if  
> you're using gcc; don't know about other compilers.

C++ names are essentially mangled C names, and 'extern "C"'  
essentially says: do not mangle the names. So if you start to play  
around with this stuff, though possible, funny things may start to  
happen.

  Hans Aberg