. <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <[EMAIL PROTECTED]> Cc: Bison Bugs <bug-bison@gnu.org> Content-Transfer-Encoding: 7bit From: Hans Aberg <[EMAIL PROTECTED]> Subject: Re: too many warnings from Bison CVS for Pike Date: Sat, 11 Feb 2006 14:07:33 +0100 To: Paul Eggert <[EMAIL PROTECTED]> X-Mailer: Apple Mail (2.746.2)
On 9 Feb 2006, at 19:45, Hans Aberg wrote: > Static C-parserstack. This seems what Bison is implementing for C+ > +, i.e., yyoverflow is not defined, leaving up to the user to > implement parser stack extensions. This will work with all C++ > types, as long as the parser stack does not overflows. This will work also for non-POD's, but I think the constructor/ destructor semantics is not what is expected by C++ users: When yyparse() is invoked, under C++, the semantic stack array yyvsa is initialized, the default constructor YYSTYPE() is invoked for all components. Assignments to $$ will invoke the assignment operator YYSTYPE::operator=() to change that value. But when the stack shrinks, the $$-values will just be left in the array. By contrast, in a proper C++-container, the default constructors need only be invoked as needed, as the stack grows, and when it shrinks, the values on it will be destroyed immediately, by invoking the destructors YYSTYPE::~YYSTYPE(). This is just a caveat that C++ programmers may need to keep track of. One might possibly avoid this problem by implementing a C++ extension of the dynamic C-parserstack. But that requires some effort and care. Hans Aberg
