[antlr-interest] [C Target] Problem with ANTLR 3.1b1 - C codegeneration
David Benn
dbenn at computer.org
Tue Jun 17 06:21:20 PDT 2008
As a counterpoint, I just want to say that I am currently using the C
Runtime for a fairly non-trivial translation task and am satisfied
enough to continue using it. I am using it for a commercial
application with a tight timeline.
Apart from lexing and parsing, I am generating and walking an AST
multiple times, and have wrapped the C lexer, parser, walker calls in
a C++ class, and embedded some C++ code within tree walker actions.
Pre-ANTLR3, I used the Java and C++ runtimes, but I can't say that the
ANTLR3 C Runtime took took all that much getting used to, apart from
the differences in invocation of the generated code, for which there
are good, commented examples. Some of the changes in ANTLR3 itself
probably took more getting used to, but that was only because I'd used
ANTLR2.x for quite awhile. The book helped with that.
Yes, I've found bugs, and reported them, and found Jim to be very
responsive. No it's not perfect, but as Jim has said, it's beta.
I'd like to thank Jim for all his hard work on the C Runtime so far.
I've released free software in the past (e.g. a compiler) and I know
how much work is involved.
Also, a vote of Thanks to Terrence. ANTLR3 has several welcome
improvements, and the book is good too.
Regards,
David
On 17/06/2008, at 2:13 AM, George J. Shannon wrote:
> I’m just sending out a note in support of Mr. Iglesias’ request.
>
> Please note that my intent is not to be critical of the C runtime or
> imply that the C runtime ought to mimic OO architecture. I just
> want to mention some of the needs we uncovered that relate
> specifically to C++. The bottom line is that it would be very
> helpful to have a C++ runtime that makes it possible to mimic
> instantiating objects and invoking object methods inside the grammar
> in the same way it is currently done using the Java version.
>
> Specifically I wanted to request support for a C++ runtime library
> that is architected for consistency with the object-oriented design
> of the existing Java version. It has been difficult to transition
> from Java to use the C runtime. Due to time constraints it has been
> necessary for us to back away from using the C version for the
> grammar runtime.
>
> I’m not an architect but for example it would be helpful to have a C+
> + runtime library with classes that mimic the existing Java
> classes. This would appear to make it more reasonable to reuse
> existing Java documentation/books, in particular when using the
> ANTLRworks tool to develop and debug a grammar, and also when
> embedding C++ runtime actions into the grammar. Then user needs for
> separate and unique documentation for a C++ version I hope would be
> minimized at least in comparison to a non OO runtime such as C.
>
> This is just my opinion if of interest.
>
> Regards,
>
> George Shannon
> President, Raphael Analytics, Inc.
> 16 Spur Drive
> Fenton, MO 63026
> (314) 550-5589 (cell)
> George.Shannon at raphaelanalytics.com
> www.raphaelanalytics.com
>
> The information transmitted is intended only for the person or
> entity to which it is addressed and may contain confidential and/or
> privileged material. Any review, retransmission, dissemination or
> other use of, or taking of any action in reliance upon, this
> information by persons or entities other than the intended recipient
> is prohibited. If you received this in error, please contact the
> sender and delete the material from any computer.
> From: antlr-interest-bounces at antlr.org [mailto:antlr-interest-bounces at antlr.org
> ] On Behalf Of Garry Iglesias
> Sent: Monday, June 16, 2008 10:25 AM
> To: antlr-interest at antlr.org
> Subject: [antlr-interest] [C Target] Problem with ANTLR 3.1b1 - C
> codegeneration
>
> Hi everybody,
> Sorry to disturb you, I've been successfully using ANTLR v3 with
> JAVA for 3 months now, for one client, and I'm pretty happy with it.
>
> Now I tried to generate a C++ parser for another project, and I
> was quite disapointed by the absence of support for C++ and the very
> poor support for C... First I tried the 3.0.1, which was generated
> 'good' c sources, but I was stuck with de C/C++ interface, I needed
> to have more 'C++' inside my rules, and the 'extern "C" {}' was too
> restrictive. (Needed a lot of 'glue code' to interface the C++
> classes).
> Then I tried to #include my generated parser files in C into some
> CPP file. It worked well except a 'cast' problem (which I localized
> in the C.stg code generation template...) that was preventing to
> compile things like : TFoo tmp = ANTL3_MALLOC(sizeof(TFoo)).
> I hesitated to patch the stg and recompile ANTLR (still 3.0.1 at
> that time).
>
> When I remember about a recent beta, which I installed immediatly.
> Nice :)... But... ;)
> ...But it seems things are worse !!! I still haven't noticed any
> cast problem (yet... :) ). But I found some weird bug, which seems
> to show the generated code (I assume from the current C .stgs) is
> buggy. Sorry, I'm surprised, (maybe it's on my side but I can't
> understand how...).
>
> First here is a extract of my grammar source :
>
> [...]
> defIndexed
> : INDEXED sz=bitWidth id=identifier '[' cnt=immediateInteger ']'
> access=quotedString
> {
> SStringPtr l_pidStr=$id.s;
> [...]
>
> [...]
> identifier returns [SStringPtr s]
> : quoted=IDENTIFIER
> {
> const char* l_pString=(const char*)($quoted.text->chars);
> $s = newStringFromLimitedString(1+l_pString,strlen(l_pString)-2);
> }
> ;
> [...]
>
> This looks alright for me, I had almost the same rule in my JAVA
> project and it works well. (I remind you that this was not a problem
> on ANTLR v3.01)...
>
> Now here is the generated code by ANTLR :
>
> // The 'buggy' rule code :
> static MyparserParser_defIndexed_return
> defIndexed(pMyparserParser ctx)
> {
> [...]
> id=identifier(ctx);
> [...]
> //Here is the generated code for the rule action :
> {
> SStringPtr l_pidStr=( id != NULL ? id.s : NULL ); //!! THis is NOT
> a pointer !!
> [...]
> [...]
> // The indifier rule that seems to works well...
> static MyparserParser_identifier_return
> identifier(pMyparserParser ctx)
> {
> MyparserParser_cpu_identifier_return retval;
> [..]
> return retval;
> }
>
> As you can see, the 'identifier' rule implementation returns its
> result into a 'by value' struct, whereas the 'defIndexed' rule
> implementation try to see if a 'by reference' (some kind of pointer)
> result exists...
> I would be greatly surprise to be the first one to find this bug,
> it seems so straightforward... Did I do something wrong ? Did I miss
> something ? I'll have another note as I 'digged' into the C runtime
> project, the beta version has several 'vsrulesfiles' directory (all
> empty but one... :) ), and some other 'ghost/empties' directory. It
> seems far more 'work in progress' than the 3.0.1.
>
> Also : I'm a 'warning killer maniac' and compile (using Visual C++
> 2005), in warning level 4, warning as error...
>
> Finally, as a C++ programmer I don't mind you use classes in your
> parser... It can be a C target only. Just if it can compile
> 'embedded' in a C++ file, or C++ compliant, without warnings. The
> most important stuff for a 'C++ ANTLR user' (or for me :) ), is to
> be able to use 'C++' code inside my rules actions. I don't mind if
> ANTLR generated code or ANTLR runtime is C++ or not. I need 'my
> code' to be C++ that's it. :)
>
> Despite my first contact with the community is to report a bug,
> great job to all of you.
> Thank you !
>
> (By the way : ANTLR is a GREAAAT tool, as a long time 'parser geek'
> I enjoy it, and it opens more new perspectives to me :) ).
>
> Garry.
Regards,
David Benn
dbenn at computer.org
0407 261163
"The real voyage of discovery consists not in seeking new landscapes
but in having new eyes." (Marcel Proust)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20080617/13993db5/attachment-0001.html
More information about the antlr-interest
mailing list