Re: Java equivalent of C++ Spirit or Boost Graph Library ?

Fab wrote:
Very thanks for the help and for the interesting answers !

Chris warns me about the difficulty of learning Java. Good thing :
must think about this. At first glance Java seemed to have very similar
syntax than C++. The main differences I was able to notice was the
simple inheritance and the non overloaded operators. I now realize it
is more deeply different.

About Spirit substitute, I see antlr is available as a package for my
debian. I discover it can work for Java and C++ too.

About BGL replacement :
Here is what it can do :
http://www.boost.org/libs/graph/doc/
a lot indeed but its pretty painful interface gives me headeache.
(So I wrap it for an easier use :
http://fabrice.marchant.free.fr/INFO/wrappers/DiGraphPtr.h
)
Looking at Jgraph. (There is a free version too). It seems indeed to
give "... more support for tasks like drawing things ... than for
mathematical operations."

Christopher wrote :
"...I could definitely believe that the code rampantly abuses
templates, ..."
Yes, your absolutely right. When you launch a compile including these
big templates (not really a lib then) on an old PII 350 MHz, you can go
and fetch a beer... But the executable is fast.

( More, maybe you would consider this as an abuse : the Boost MPL,
template metaprogramming give you the possibility to compute absolutely
all you want by the compiler ! Submit it a chess position and it 'll
solve mate at compile time. )

( I snip experts discussion about generic programming in Java. )

Jeffrey wrote :
"C++ provides excellent memory management via its standard library.
Post in comp.lang.c++.moderated."
I did post in comp.lang.c++. Moderated forum would be better for this
question ?

Possibly. The posters are generally far more familiar with the language, and more accomplished in their fields. Many of them have strong affections for smart pointers, though, which are likely to be their suggestion to you re. memory management; let me disagree a priori. :)

Is this your post in comp.lang.c++?

http://groups-beta.google.com/group/comp.lang.c++/browse_thread/thread/e5356a7323ae95bb/ec868a8be396b6df?hl=en#ec868a8be396b6df

"I need to use a GC in order to program an
interpreter for a functional language. Memory
handling would be otherwise difficult too much."

Do you understand RAII and deterministic destruction? Once you do, you will probably be far less nervous about using C++. Of course you if you go with Java, this group is certainly a great resource, and the level of discourse in comp.lang.java.programmer seems (believe it or not) to be generally higher than comp.lang.c++. :)

"IMO, automatic garbage collection would be a really bad reason to
choose Java over C++, especially since I prefer C++-style resource
management."
The interpreter I try to write is for a new Lisp-like language.
Mc Carthy created Lisp and Garbage Collection too ( I think ).

So sayeth Wikipedia.

I do need GC too cos the project is a functional language that causes
cyclic references and it would be very hard to explicitely unallocate
the forms that are generated at each evaluation.

No, that point does not follow from your requirements. At any time, each dynamically created object A should be owned by exactly one object B. You can have all the circular references you like, as long as you avoid circular ownership. Circular references have gained notoriety because they don't get properly collected by reference-counted garbage collectors, e.g. Perl's. They're not a problem in either a well-designed C++ program or a typical, mark & sweep Java implementation.

Here is an excerpt from the agressive book, The UNIX-Haters :

"C++ users, alas, are forced to pick up their garbage manually. Many
have been brainwashed into thinking that somehow this is more efficient
than using something written by experts especially for the platform
they use.
These same people probably prefer to create disk files by asking for
platter, track, and sector numbers instead of by name.

Well, *** the UNIX-Haters, too. C++ does not force you to pick up your garbage "manually." It does, however, force you to think (for programs beyond a certain size) about object ownership and other relationships. It supports you in this endeavor with probably the best static type system of any language in popular use. You can use (almost) whatever design techniques you find most natural: procedural, object-oriented, or even functional; low-level or abstract. (On the down-side, some techniques, e.g. aspect-oriented programming, do require a silly amount of typing.)

...a study comparing performance of programmer-optimized memory
management techniques in C versus using a standard garbage collector.
C programmers get significantly worse performance by rolling their own.

Right on. You're unlikely to roll a GC that's better than the HotSpot VM's. Remember, though, that C is a very different language from C++; C++ gives you vastly better ways to manage memory and other resources.

OK, suppose you are one of those enlightened C++ programmers who wants
a garbage collector portable and reusable..."

I agree with you in the way it would be very cleaner to be able to
accurately free all we have created. Relying on a GC seems at best
blurred.
However do not know how to avoid this.

Post some details (and preferably a little code) in clc++m and watch the magic fly. :)

"...If your interpreted language can reasonably be parsed with regular
expressions and parse trees, you might not even need a separate library
for it."

Joel de Guzman (Spirit) wrote : "True, there are tools such as
regular-expression libraries (such as boost regex) or scanners (such as
boost tokenizer), but these tools do not scale well when we need to
write more elaborate parsers.

Do you need an elaborate parser? How does your grammar look? Can you post some sample code from your interpreted language?

Attempting to write even a
moderately-complex parser using these tools leads to code that is hard
to understand and maintain. "

That has not been my experience. The only interpreted languages I've written that actually got used regularly by other people have been very domain-specific, but the parsers were at least moderately complex, and the code was straight-forward to maintain. My languages of preference for parsers have been C++ (because it lets me use one language for the whole application) and Perl. I don't doubt that one *can* write hideous code using regular expressions and tokenizers, but saying so is like pointing out that only one end of a hammer is any good for whacking nails.

I wrote the parse part of my interpreter project using only the
Standard Template Library and the code is complicated, ugly...

Don't blame the STL! The STL on its own is not meant to be a complete solution to every problem, any more than Java Collections are.

Then I discovered Spirit, I was amazed about the clarity it provides.
Moreover, you program in BNF-like C++ directly ! No extra translation
step required.

Cool. I have not used Spirit. On the other hand, I don't usually specify languages in BNF. :)

Thank you again Jeffrey for your interesting comparison between the
languages.

Please, is there somewhere a classified list of the numerous Java
libraries (with a concise description) that we could browse by category
?

No, there's not CPAN-like central repository. This group seems to be as good a place as any to ask about specific libraries, though. You might start here to get some ideas:

http://directory.google.com/Top/Science/Math/Combinatorics/Software/Graph_Drawing/
.