Re: member with constructor not allowed in union

[Richard B. Kreckel]

On 15 Mar 2002, Akim Demaille wrote:
[...]
> | > You are not using the C++ output!  Run bison -S bison.c++.
> | 
> | Ahh, I was not aware of this option in CVS' GNU Bison 1.49a.  Above error
> | is of course gone now.  However, several hundred other errors crop up, 
> | which I don't wish to analyze right now.  Methinks bison.c++ is something
> | for the long run...
> 
> Again, I'm using it with success.  I do agree it needs to be polished,
> but to do that, we need to meet other users, such as you.  So I
> perfectly understand your point wrt. the urgent need for an answer
> _now_.  But I'm really referring to something else: would you accept
> trying the CVS Bison and report to us the problems you face?

Sure, we can try that then.

> | [ ] Option 1: Only morons use bison.simple with C++!
> 
> That's true :)
> 
> | [ ] Option 2: It's eazy -- and backporting in distros suxx big time.
> | [ ] Option 3: Distributions should care about their software (LOL).
> | 
> | Hmm, I think I can guess Vincent's and Akim's votes.   :-)
> 
> I'm for providing a degraded bison.simple for C++ users.  Is that OK,
> or in addition you'd want the regular bison.simple to be OK with C++?

[X] I would prefer the regular bison.simple to work with C++, so we
    don't have to change all the packages.

What was wrong with the old skeleton?  From what Hans said, it would
memcpy as soon as the stack was full, causing not-so-nice pyrotechnical
effects.  Well, it was at least working as long as the stack was low.
And, out of curiosity: what makes the stack double-ended?

And, later, he wrote:
> Nevertheless, I would really like to see the actual code which is
> used.  In particular, I'd like to see the definition of YYSTYPE,
> because I don't understand what possibly could have changed for you.

Hmm, AFAICT, YYSTYPE is int and always has been...

> I agree yylloc causes new problems, but yylval should not.  It seems
> to me that the current Bison reveals a problem, but does not cause it.
> 
> Where can I see your package?

Our's is here:
:pserver:address@hidden:/home/cvs, module GiNaC.
Doxygen is there (careful, no subdir):
:pserver:address@hidden:/u/kp3softd/cvsroot, module doxygen.

Regards
    -richy.
-- 
Richard Kreckel
<address@hidden>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>