Re: Is C++ really used ?

David.Monniaux@ens-lyon.fr (David Monniaux)
8 May 1997 21:16:51 -0400

          From comp.compilers

Related articles
[6 earlier articles]
Re: Is C++ really used ? dwight@pentasoft.com (1997-05-04)
Re: Is C++ really used ? cdg@nullstone.com (Christopher Glaeser) (1997-05-04)
Is C++ really used ? peter@bj-ig.de (Peter Brueckner) (1997-05-04)
Re: Is C++ really used ? danwang@nordica.CS.Princeton.EDU (1997-05-07)
Re: Is C++ really used ? kbreinho@bsquare.com (Keith L. Breinholt) (1997-05-08)
Re: Is C++ really used ? geert@sun3.iaf.nl (1997-05-08)
Re: Is C++ really used ? David.Monniaux@ens-lyon.fr (1997-05-08)
Re: Is C++ really used ? chase@world.std.com (David Chase) (1997-05-08)
Re: Is C++ really used ? clark@quarry.zk3.dec.com (1997-05-08)
Re: Is C++ really used ? cliffc@risc.sps.mot.com (Cliff Click) (1997-05-08)
Re: Is C++ really used ? nasser@apldbio.COM (Nasser Abbasi) (1997-05-08)
Re: Is C++ really used ? shankar@chromatic.com (1997-05-08)
Re: Is C++ really used ? bduncan@tiac.net (Bruce Duncan) (1997-05-08)
[3 later articles]
| List of all articles for this month |
From: David.Monniaux@ens-lyon.fr (David Monniaux)
Newsgroups: comp.compilers
Date: 8 May 1997 21:16:51 -0400
Organization: Ecole Normale Superieure de Lyon, France
References: 97-04-156 97-05-044
Keywords: C++, practice, OOP, ML

Dwight VandenBerghe (dwight@pentasoft.com) wrote:
[ criticism on C++ cut ]


I stopped using C++ last year, because of the problems you cite.
Mainly, the lack of a standard library addressing the most common data
structures (now, there is the STL, of course), which forces
programmers to reinvent the wheel all of the time, and the C-like
memory management that seems to lead inevitably into pointer salads
(yes, I know, this is rather a problem of bad programming :-); but the
language favorizes such problems). Also, templates and exceptions
weren't quite working.


I know some of the problems (standard library, templates and
exceptions) have been partially sorted out in the meantime. Moreover,
a deeper problem may be that I don't find that OOP is the silver
bullet many people have described. To me, OOP is nice to describe
hierarchies of classes of, say, graphical interface components (such
as Borland's Turbo Vision) or, as I used it once, to describe
ray-traceable objects. May I just don't know what OOP is all
about. :-)


: I'm writing my current compiler (a domain-specific language
: translator for an actuarial company) in a variant of ML called
: Objective Caml.


I'm myself writing a compiler for a Pascal-like language in O'Caml.


: I think it is an astoundingly beautiful language,


The language is good, though some syntactical choices weren't perhaps
well chosen. For instance, parenthesises tend to abound. Perhaps it is
just me that doesn't master well enough the priorities.


: and the performance is nearly that of C++.


The performance with the native code compiler is quite impressive
indeed. I would not advise to use it for computation-intensive tasks
(the kind of things people write in FORTRAN), but for tree and
structures manipulations it's superior to C++, at least in my humble
opinion.


[...]
: Caml is a very mature product, and the library is
: clean and elegant and has just about everything you would ever want.


Slight exaggeration here. But I agree that the library provides many
ready-to-use data structures; and implementing other ones is easy,
especially if you can use the standard ones as building blocks.


For our readers that don't know O'Caml: O'Caml provides higher-order
functions (functions that return functions), polymorphic functions and
types (ie part of the manipulated structures can be of any type; for
instance, lists are generally defined as 'a list, and you can
instanciate the parameter 'a with any type you want), and modules and
functors (you can parameter whole modules of the program with other
modules; for example, you can write a module to handle binomial heaps
and parameter it with a module handling an ordered type; or write a
module that uses some kind of priority queues and parameter with the
actual kind of priority queues you use, for example a binomial
heap... the possibilities are impressive). Those are, to me, powerful
and easy to use, and favor reusability.


: Caml also has a full set of object-oriented features to it, but you
: know, I find them not so useful as with C++.


Here comes the $100 question: WHO uses the OO features of O'Caml? :-)


: You want a language made in heaven just for compiler writers? Try
: Caml. It's free! http://pauillac.inria.fr:80/caml/ Be forewarned:
: there is a significant learning curve.


Back to our point, compilers. Last year, I witnessed people writing
similar compilers in C, and I had the impression that they spent more
time debugging pointer problems than actually being productive on the
compiler. That sort of things doesn't happen with O'Caml. Moreover,
the pattern matchings are very handy to catch patterns in code that
can be optimized (and not compiled in the standard way, equivalent but
less efficient). The standard modules made trivial several important
things such as symbol tables.


We expect our compiler to be around 6000 lines of code; I don't think
you can get to such simplicity in C or C++.


Moreover, O'Caml has its own Lex and Yacc, so... :-)


The biggest criticism I have to make to O'Caml is that the quality of
the manual is well under the quality of the compiler itself. The
"steep learning curve" you were talking of is not inherent to the
language; it's mainly due to a terse manual and rather obscure
tutorials.


Let's add that O'Caml is one of the standard languages for higher
education teaching of programming in France, and that it is the
implementation language of several projects, such as the Coq theorem
prover and the Ensemble distributed computing system.


--
Computer science student at ENS, Lyon, France
http://www.ens-lyon.fr/~dmonniau
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.