[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Sat, 11 Feb 2006 15:55:17 -0500
. <address@hidden> <address@hidden> <address@hidden>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Cc: Bison Bugs <address@hidden>
From: Hans Aberg <address@hidden>
Subject: Re: too many warnings from Bison CVS for Pike
Date: Sat, 11 Feb 2006 14:07:33 +0100
To: Paul Eggert <address@hidden>
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
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.
|[Prev in Thread]
||[Next in Thread]|