[antlr-interest] Re: build issues: bytecode assembly generation

[micheal_jor]

--- In antlr-interest at yahoogroups.com, "Don Caton" <dcaton at s...> wrote:
>  And to be honest, there's no "official"
> support for Antlr on Windows platforms to speak of.  It took quite a
bit of
> trial and error to get Antlr to even run under Windows. 

I presume you mean support for "using the ANTLR C++ code generator and
runtime library with MSVC++ on Windows". If so, all I can say is that
the support has gotten much better since 2.7.4 was released (Ric now
has MS's compiler I believe). There has been a lot of useful
discussion on this list about ANTLR/C++ on Windows.

> > Given developers with the same level of proficiency and 
> > experience with C++ and Java, most will be able to produce an 
> > application like ANTLR much more quickly and easily with Java 
> > than C++. 
> 
> Well, with all due respect I'm not sure how you can make that assertion.

I based it on my experience, that of many colleagues and employers
(past and present) and, on the findings of quite a few published
studies including: 
- http://www.wellscs.com/robert/java/productivity.htm
- http://www.mind2machine.com/gb/openmind/index.php
- http://page.mi.fu-berlin.de/~prechelt/Biblio/jccpprtTR.pdf
- http://www.spirus.com.au/papersAndPresentations.shtml

> IMO, it depends to a large degree on the individual programmer.

Yes, productivity is generally more affected by individual programmer
skill than choice of implementation language.

> If any
> particular language was significantly easier to use, everyone would
be using
> it.

True. Of course no language is best at *everything* so we still get to
cherry pick...

> In any case, this is a philosophical issue on which we may simply
> disagree.

Not really. Productivity can be measured.

> >           There are of course some applications where the 
> > need to optimize memory usage and/or speed aggressively 
> > suggest C++ (or perhaps C or assembly
> > language) might be a better choice.
> 
> Yes, like parsers <g>.  In a debug build, it takes my
antlr-generated (C++)
> parser about 15 seconds to parse a 77k source file.  With full
optimizations
> enabled, the same code finishes in slightly under 2 seconds.  I'm not
> kidding.  I was sweating bullets when got my parser to work and
found it was
> so slow.

There are some efficiency issues with ANTLR lexers (especially if you
use the more advanced ANTLR lexer options) which ANTLR3 should fix.
The distribution has a sample showing how to couple Flex lexers to
ANTLR parsers. Search the list for past discussions.

Micheal







 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/antlr-interest/

<*> To unsubscribe from this group, send an email to:
    antlr-interest-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/