|Bison, C++ and shared_ptr<> firstname.lastname@example.org (Paulo Matos) (2006-02-03)|
|Re: Bison, C++ and shared_ptr<> email@example.com (2006-02-03)|
|Re: Bison, C++ and shared_ptr<> firstname.lastname@example.org (2006-02-06)|
|From:||email@example.com (Hans Aberg)|
|Date:||6 Feb 2006 00:06:04 -0500|
|Posted-Date:||06 Feb 2006 00:06:04 EST|
In article 06-02-022, "Paulo Matos" <firstname.lastname@example.org> wrote:
> Lately I've been dealing with some wierd memory leaks reported by
> valgrind on my bison generated parser. One of the things I had
> difficulty with when I designed the parser is that I cannot have types
> with constructors on the %union.
There are two issues involved: how to fix the memory leaks and whether to
use %union. If you use a C++ non-POD semantic type, as already pointed out
elsewhere in this thread, C++ prohibits non-POD's in unions, and Bison
implements %union using a C/C++ union, so then you cannot use %union. And
if you want to use Bison's grammar static type checking mechanism, then in
effect, you currently must use %union.
So if you want to use Bison grammar static type checking, then you must
use %union. Then I think people use a void* pointer for that, as the exact
type will then be handled by the Bison type system. Then one writes normal
cleanup of the pointer in the grammar actions, plus using %destructor to
provide cleanup during error recovery.
On the other hand, if you do not want to use Bison static type checking,
then you can define YYSTYPE to any C++ type. There I use a polymorphic
class hierarchy, with a reference count in the base class. In this model,
there are two variants: the base class is virtual, in which case one must
use (by requirements the C++ standard) dynamic_cast for type conversion,
which will require some couple of tens machine cycles for each one, or the
base class is non-virtual, in which case one can use static_cast, and the
type conversions can be computed at C++ compile time. The latter will
cause undefined behavior if one is doing some code writing errors, and one
must also make sure the base class is singly derived by hand.
So one would really want to use Bison's static type checking with a
non-virtual reference count base class so that one can use static_cast
safely. In order to do implement that in Bison, I would need about a
version of %union that does not implement a union, plus a code placement
version of an experimental command %define that can be used to create M4
macros. Hopefully this will arrive in the future, but the Bison
development seems to currently have another development direction.
Return to the
Search the comp.compilers archives again.