It is a one-time extraction every time you create the parser object and you are just hiding the grammar issues. Also, it means that you need memory to store the compressed string and memory to store the expanded tables. The Java version is only done this way because there was no equivalent to the C declaration style until Java 1.7. The size of the overhead depends on the size of your tables of course.
Jim *From:* Mike Lischke [mailto:[email protected]] *Sent:* Thursday, April 05, 2012 12:15 AM *To:* Jim Idle *Cc:* ANTLR Mailing List *Subject:* Re: [antlr-dev] C and C++ targets in ANTLR Hi Jim, It is a function of your grammar, which is badly organized and ambiguous. This is causing the generation of huge DFA tables and convoluted code. Thanks a lot for being so clear. I also found this grammar not being a real good one. You will find that it is the same with Java if you set the –X settings to the same as C, however the DFA tables in Java are generated as run length compressed strings, which means that when you look at the source code it fools you in to thinking that it is smaller but it is just replaced by a huge overhead in expanding the strings at runtime instead. Is this really such a big overhead to do a one-time extraction? To me this runlength compressions looks like an excellent way to reduce the parser code size. Follow the advice about removing backtracking one rule at a time, do the left factoring, and you will find it is good. When you are writing a grammar, you should do so in small increments, solving any introduced ambiguities as you go, and not piling them up until the end as then it will seem like an intractable problem. Thanks again. I'll try to follow your advice. Mike -- www.soft-gems.net
_______________________________________________ antlr-dev mailing list [email protected] http://www.antlr.org/mailman/listinfo/antlr-dev
