On 22 Nov 2006, at 19:31, Paulo J. Matos wrote:
> Which means that since I'm using a C generated parser I should use
> destructor. But destructor will be called after each successful
action
> or after each failed parsing (to which an action never gets
called but
> the given value is actuall
On 21 Nov 2006, at 14:00, Paulo J. Matos wrote:
The C++ parser uses for parser stack a class like std::vector or
std::deque, which invokes the class destructors when the stack is
unwound. So if the classes of the objects on the parser stack are
properly written, no special cleanup is needed.
On 18 Nov 2006, at 17:39, Paulo J. Matos wrote:
There is now %destructor to clean up C-code leaks during error
recovery; otherwise, do it by hand in the actions.
What do you mean by error recovery? If the parsing fails?
Right.
I still cannot understand when %destructor code is called.
Th
On 11/13/06, Hans Aberg <[EMAIL PROTECTED]> wrote:
There is now %destructor to clean up C-code leaks during error
recovery; otherwise, do it by hand in the actions.
What do you mean by error recovery? If the parsing fails?
I still cannot understand when %destructor code is called.
I think th
On 13 Nov 2006, at 18:17, Sean Walton wrote:
I've generated a parser with bison and I tried running valgrind on
it.
The wierd thing is... there's a huge bunch of memory leaks reported.
:-(
Is this known? Is this a bison leak or a valgrind bug?
Regards,
If you are using malloc
Paulo J. Matos wrote:
Hi all,
I've generated a parser with bison and I tried running valgrind on it.
The wierd thing is... there's a huge bunch of memory leaks reported.
:-(
Is this known? Is this a bison leak or a valgrind bug?
Regards,
If you are using malloc() in your semant
Hi all,
I've generated a parser with bison and I tried running valgrind on it.
The wierd thing is... there's a huge bunch of memory leaks reported.
:-(
Is this known? Is this a bison leak or a valgrind bug?
Regards,
--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.s
On Wed, 8 Jun 2005, Laurence Finston wrote:
> If you only ever delete objects by means of their corresponding
> 'Object_Type::object' pointers, than it would be safe to use simple
> pointers to 'Foo*'.
Sorry, I meant "simple pointers to 'Foo'".
Laurence
On Tue, 7 Jun 2005, hz kto wrote:
>
>
> If I have a list like this wouldn't I run into the problem when,
> a parent node deletes some child nodes, then when I come across
> this child in the list, I will crash since it has been deleted already?
That was the point of the following remark:
> > Dep
03:05 +0200 (MEST)
Subject: Re: memory leaks
>
> On Tue, 7 Jun 2005, hz kto wrote:
>
> >
> > I am using C++ with bison 1.25, so it does not have %destructor. I cannot
> > rely on
> > garbage collecting, so I have to free everything myself.
> > Also I do not hav
On Tue, 7 Jun 2005, hz kto wrote:
>
> I am using C++ with bison 1.25, so it does not have %destructor. I cannot
> rely on
> garbage collecting, so I have to free everything myself.
> Also I do not have common base class for all parse tree nodes (so I can't have
> a storage for all parse tree node
5:28:31 +0400
Subject: memory leaks
>
>
>
> Hi, all,
>
> in my parser, when a syntax error happens, all allocated parse tree
> nodes are left dangling, and not freed. Does anybody try and clean up
> allocated memory after parser error?
> Even though it is not cri
Hi, all,
in my parser, when a syntax error happens, all allocated parse tree
nodes are left dangling, and not freed. Does anybody try and clean up
allocated memory after parser error?
Even though it is not critical, since program terminates anyway, I'd like
to have no leaks in any case, so tha
13 matches
Mail list logo