[antlr-interest] [C Target] Problem with ANTLR 3.1b1 - C codegeneration

George J. Shannon George.Shannon at raphaelanalytics.com
Mon Jun 16 09:43:03 PDT 2008


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)

 <mailto:George.Shannon at raphaelanalytics.com>
George.Shannon at raphaelanalytics.com

 <http://www.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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20080616/ef67d344/attachment-0001.html 


More information about the antlr-interest mailing list