Re: Memory Leaks

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

Re: Memory Leaks

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.

Re: Memory Leaks

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

Re: Memory Leaks

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

Re: Memory Leaks

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

Re: Memory Leaks

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

Memory Leaks

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

Re[2]: memory leaks

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

Re[2]: memory leaks

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

Re[2]: memory leaks

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

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 have common base class for all parse tree nodes (so I can't have > a storage for all parse tree node

Re: memory leaks

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

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 critical, since program terminates anyway, I'd like to have no leaks in any case, so tha