bug-bison
[Top][All Lists]
Advanced

[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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]