[antlr-interest] stuff I don't like about ANTLR 2.x

[Braden McDaniel]

On Sun, 2004-03-14 at 15:39, Terence Parr wrote:
> On Mar 13, 2004, at 8:27 PM, Braden McDaniel wrote:
> > I use ANTLR to generate C++. For some time, my major complaint about 
> > the
> > C++ part of ANTLR has been that the support library seems to be poorly
> > factored. For instance, I don't use ANTLR's AST support. But because of
> > the rather monolithic nature of the support library, there seems to be
> > no way to keep from pulling in all the support library's AST machinery
> > when linking.
> 
> The issue could be that C++ / C header files are a poor mechanism in 
> general for factoring stuff due to very coarse granularity of 
> dependencies.  Can you suggest some factoring tips?

Specifically, header files aren't the problem. I think the classes
themselves could be factored differently; couldn't the AST stuff be
factored into a subclass of antlr::Parser? That way a generated parser
that doesn't use an AST could inherit an AST-ignorant abstract parser.

Since you mention header files, though, I will make the comment that I
find the "one header + one source file per class" strategy to be a poor
one for factoring C++ projects into files. It leads to a lot of files
with hard-to-track dependencies. It also encourages the use of "private
headers" to factor out implementation details common to different
classes. Private headers, while not intrinsically bad, are an
all-too-convenient vehicle for leaking private symbols into a library
interface.

By keeping closely related classes (that are likely to be used together)
in the same header-source file pair, one can keep common implementation
details in an unnamed namespace where they are out of the library
interface. And since there are fewer files, there are fewer header file
dependencies to keep track of. One has a clearer idea of what gets
pulled in by a particular include directive simply because more code is
in fewer places.

Also, for a given volume of code, a project with fewer translation units
will almost always compile faster than one with more translation units
(however, incremental compilation will generally be slower with fewer
translation units). There is also the theoretical observation that the
more code is thrown at the compiler at once, the more opportunities it
should have to optimize the code.

> [Side note from an anti-C++ bigot: I can't believe people don't 
> complain about the complete lack of portability of C++.

Because it is figment of the imagination of anti-C++ bigots. ;-)

Really, ANTLR's C++ library builds on many platforms; and I could rattle
off a number of other C++ projects that do the same (including my own).
Doesn't sound like a "complete lack of portability" to me.

>   Never once 
> have I heard people say that the Java code won't compile somewhere 
> (course the build process is a different story perhaps<wink>).

And I never heard a C++ developer complain of CLASSPATH issues,
unexpected behavior on an untested VM, poor performance due to
constraints inherent in the dynamism of the language...

I'll stop. ;-)

>   It is 
> truly astounding that nearly 20 years after the first lecture I heard 
> on C++, we still don't have a portable language.  Stroustroup (SP?) is 
> coming to USF to speak soon...I'll try to leave my heavier projectiles 
> at home.] ;) :D  Just my opinion folks ;)

Perhaps we don't have a fully portable language; but we do have a
standard vendor-independent one. With sufficient interest and time for
standard support to materialize (and C++ has that), that can be just as
good. Maybe better. ;-)

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>



 
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/