help-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to correctly deallocate some token types ...


From: Johnny_xia
Subject: Re: How to correctly deallocate some token types ...
Date: Tue, 13 May 2003 09:47:46 +0800



I have the same trouble with deallocating C++ object in Bison. I think Ricardo
just wants to confirm that if the codes he presented are enough to ensure that
the object can be deallocated properly even when a parsing error occurs. But I
am still interested at the way Hans mentioned. Can you share an example of it,
or some reference guides?

Thanks in advance.
Regards,
Johnny Xia.


At 15:02 +0100 2003/05/12, Ricardo Rafael wrote:
> > C++ is doing this recursion automatically. But with C++, one
> > cannot use %union, as that is implemented using a C/C++ union,
> > which does not admit data types with non-trivial constructors.
>
>    That is the case, isn't it!? I just use primitive data types in the
>union (BOOL is a typedef for int just used for compatibility issues of
>one legacy library I use). The non-trivial constructors from class
>SomeClass are dealt indirectly in my code when I call new SomeClass();
>and the memory deallocation is done using delete (there is no recursive
>data structures pointed by SomeClass *).

I use a C++ skeleton file that uses for stack a proper C++ container (like
std::vector, std::deque, etc.). Then the C++ class system takes care of the
deallocation automatically.

Also, I put the stuff in a C++ polymorphic (virtual) class hierarchy with a
reference count. Then I do not really need the %union feature, because any
type error will throw an exception at parser runtime, which proves quite
sufficient.

>    I was just trying to confirm the correctness of the code above.

But if you want to use C++ with %union and the C stacks, then you must
write some code like what you have done.

  Hans Aberg




_______________________________________________
address@hidden http://mail.gnu.org/mailman/listinfo/help-bison








reply via email to

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