Re: About %destructor is c++ mode

[Min Wang]

HI

@Hans. thanks for the info.

since my process is a deamon, I need to clean up memory leak.

What does  error recovery really mean? My current grammar rules does not
include error, so does it mean that I do not have error recovery?

My confusion is:  it seems the %destructor is called even for the normal
parse!!

see below:

I comment out the delete $$ in the %destructor

%destructor { std::cout << " **** I am PROG " << $$ ;

              //delete $$;

              std::cout << " delete done" << std::endl;

            } PROG

 ...

here is my simple test with the following input:

a=="b"

the output is ( enabled trace) following, please pay attention to those
 **** lines:

 ./TestFilter -p -s  ./MyTest.sample2


Starting parse
Entering state 0
Reading a token: --(end of buffer or a NUL)
--accepting rule at line 101("a")
Next token is token _SYMB_JSON_KEY (1.1: a)
Shifting token _SYMB_JSON_KEY (1.1: a)
Entering state 3
Reading a token: --accepting rule at line 71("==")
Next token is token _SYMB_EQ (1.2-3: )
Reducing stack by rule 21 (line 284):
   $1 = token _SYMB_JSON_KEY (1.1: a)
-> $$ = nterm JSON_FIELD (1.1: 0x24291f0)
Stack now 0
Entering state 11
Next token is token _SYMB_EQ (1.2-3: )
Shifting token _SYMB_EQ (1.2-3: )
Entering state 22
Reading a token: --accepting rule at line 106(""")
--accepting rule at line 115("b")
--accepting rule at line 108(""")
Next token is token _STRING_ (1.4-6: b)
Shifting token _STRING_ (1.4-6: b)
Entering state 36
Reducing stack by rule 23 (line 287):
   $1 = token _STRING_ (1.4-6: b)
-> $$ = nterm QUERY_CONDITION (1.4-6: 0x2429270)
Stack now 22 11 0
Entering state 39
Reducing stack by rule 11 (line 265):
   $1 = nterm JSON_FIELD (1.1: 0x24291f0)
   $2 = token _SYMB_EQ (1.2-3: )
   $3 = nterm QUERY_CONDITION (1.4-6: 0x2429270)
-> $$ = nterm Exp3 (1.1-6: 0x2429290)
 **** I am QUERY_CONDITION 0x2429270 delete done
 **** I am JSON_FIELD 0x24291f0 delete done
Stack now 0
Entering state 10
Reducing stack by rule 10 (line 263):
   $1 = nterm Exp3 (1.1-6: 0x2429290)
-> $$ = nterm Exp2 (1.1-6: 0x2429290)
 **** I am Exp3 0x24291f0 delete done
Stack now 0
Entering state 9
Reducing stack by rule 8 (line 260):
   $1 = nterm Exp2 (1.1-6: 0x2429290)
-> $$ = nterm Exp1 (1.1-6: 0x2429290)
 **** I am Exp2 0x24291f0 delete done
Stack now 0
Entering state 8
Reading a token: --accepting rule at line 124(" ")
--accepting rule at line 123("
")
--accepting rule at line 123("
")
--(end of buffer or a NUL)
--accepting rule at line 123("
")
--(end of buffer or a NUL)
--EOF (start condition 0)
Next token is token "end of file" (4.1: )
Reducing stack by rule 6 (line 257):
   $1 = nterm Exp1 (1.1-6: 0x2429290)
-> $$ = nterm Exp (1.1-6: 0x2429290)
 **** I am Exp1 0x24291f0 delete done
Stack now 0
Entering state 7
Next token is token "end of file" (4.1: )
Reducing stack by rule 2 (line 248):
   $1 = nterm Exp (1.1-6: 0x2429290)
-> $$ = nterm ListExp (1.1-6: 0x24292b0)
 **** I am Exp 0x2429290 delete done
Stack now 0
Entering state 6
Reducing stack by rule 1 (line 241):
   $1 = nterm ListExp (1.1-6: 0x24292b0)
-> $$ = nterm PROG (1.1-6: 0x2429300)
 **** I am ListExp 0x24292b0 delete done
Stack now 0
Entering state 5
Next token is token "end of file" (4.1: )
Shifting token "end of file" (4.1: )
Entering state 18
Cleanup: popping token "end of file" (4.1: )
Cleanup: popping nterm PROG (1.1-6: 0x2429300)
 **** I am PROG 0x2429300 delete done
OK

Parse Succesful!
------------------------------------
out of the parser....

[Abstract Syntax]

(Json_Filter [(Eeq [(Ejson_field "a")] [(Equery_cond_s "b")])])


[Linearized Tree]

a == "b"



As you can see, even with successful parsing, it try to run that
%destructor, why?

I saw the destructor was generated at: filter_parser.hh

filter_parser::basic_symbol<Base>::clear ()  {
    ...
        basic_symbol<Base>& yysym = *this;

    (void) yysym;

    switch (yytype)

    {

      case 25: // PROG



#line 159 "filter_parser.yy" // lalr1.cc:377

        { std::cout << " **** I am PROG " << yysym.value.template as< PROG*
> () ;
              //delete $$;

              std::cout << " delete done" << std::endl;

            }

#line 1138 "filter_parser.hh" // lalr1.cc:377
}

in the bison generated filter_parser.cpp:

filter_parser::parse () {
....
       YY_SYMBOL_PRINT ("-> $$ =", yylhs);

       yypop_ (yylen);

       yylen = 0;

       YY_STACK_PRINT ();

}


It seems  yypop_ (yylen)  will call basic_symbol<Base>::clear () thus call
%destructor code no matter if it is the error recovery mode or not?



thanks

min



On Thu, Aug 18, 2016 at 4:59 AM, Hans Åberg <address@hidden> wrote:

>
> > On 18 Aug 2016, at 01:20, Min Wang <address@hidden> wrote:
>
> > so if I have something like that ( pointer) in as token type:
> >
> > %type <PROG*> PROG
> >
> > %type <ListExp*> ListExp
> >
> > My thinking about using PROG* instead of PROG is because I do not want to
> > copy constructor a big PROG, is it correct?
> >
> > In this case of pointer, do I need to have a %destructor?
> >
> > %destructor { delete $$; } PROG
> > %destructor {  delete $$; } ListExp
>
> Yes, if your pointers have explicit allocators in the actions, then if you
> want to avoid memory leaks during error recovery, the corresponding
> deallocator should be called as you indicate.
>
> > (2) when %destructor  is called?
> >
> > Assuming I need those %destructor, it seems that %destructor was called
> > even for a every  successful parse. I thought it should only called
> during
> > During error recovery.
>
> It is called only during error recovery. For a normal parse, without
> errors, the corresponding deallocator should be in the actions. So you need
> to keep track in the grammar of where an object becomes obsolete.
>
> So if your program is not doing much of error recovery, some memory leaks
> during that process might be acceptable.
>
>
>


-- 
http://www.comrite.com
Yellow pages, Ads and Search

http://www.meidongnet.com
News, Ads, Free Online dating, Games for Chinese Community in NY, NJ, PA