[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(no subject)
From: |
haberg |
Subject: |
(no subject) |
Date: |
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
Message-Id: <address@hidden>
Cc: Bison Bugs <address@hidden>
Content-Transfer-Encoding: 7bit
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
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |