[antlr-interest] Couple of issues with C target's runtime code

Jim Idle jimi at temporal-wave.com
Fri Jun 8 12:17:49 PDT 2007



> -----Original Message-----
> From: antlr-interest-bounces at antlr.org [mailto:antlr-interest-
> bounces at antlr.org] On Behalf Of Stuart Dootson
> Sent: Friday, June 08, 2007 12:03 PM
> To: antlr-interest
> Subject: [antlr-interest] Couple of issues with C target's runtime
code
> 
> Jim - I used the C target for the first time today - nice job! Looking
> at the code, I'm glad I use C++ to do OO ;-)
> 
> Anyway - couple of issues (guess I ought to mention I'm using the
> version of the runtime that comes with the release of Antlr 3.0 - if
> there's a later version of the runtime I ought to be using, please let
> me know!!!) -
> 
> 1. You use the presence of the macro 'WIN32' to determine that you're
> compiling for Windows 32. However, you might be better using '_WIN32'
> (see http://msdn2.microsoft.com/en-us/library/b0084kay(VS.80).aspx).
> 'WIN32' is added to the command line by Visual Studio 2005, whereas
> '_WIN32' is *always* defined. I compiled my first sample grammar at
> the command line (what can I say - I'm an old-fashioned sort of a
> developer), and it complained about not finding 'antlr3config.h', as
> it was following the Unix path.

Yeah - that's a fair point, I guess I just typed that in a few times and
never thought about it ;-) However, I am 10%% sure I can't always have
had it like that because I show the DEVENV command line example in the
wiki docs.

> 2. The release mode static library for Windows is compiled using the
> '_fastcall' calling convention (when using the Visual Studio 2005
> project). Is this for a reaason other than performance? 

Just performance testing, however I wasn't decided on it yet. But, I
think I did not change the normal stuff because you cannot use _fastcall
when you take an address of the function and it is in a DLL. Can't
remember the exact reasoning, but I figured that you would either change
the static library back to the default cdecl, or change your calling
project to use fastcall. Basically, the answer is that I have to finish
deciding whether it is even worth it, so for the moment you best bet is
just to change the project settings back to normality until I have
finished looking at the various options for 32 bit vs 64 bit and so on.

 
> Apart from that, I found your runtime very easy to get up and running
> - took about half an hour, including building the runtime and
> deciphering the runtime source to determine what sequence of calls to
> tie file stream, lexer, token stream and parser together.

Please see the examples and the wiki docs that I spent ages on (and will
spend more time on). The examples are especially poignant as they are
commented with all sorts of pointers for C programmers (and will get
better over time). I believe that the last example I checked in is only
half way finished because I was changing systems to a 64 bit machine, so
if you get errors in one project just ignore them.

Jim


More information about the antlr-interest mailing list