Re: Java

[Dan Weinreb <address@hidden>]

   Date: Tue, 11 Dec 2001 15:55:50 -0500
   From: "Oliver Steele" <steele@cs.brandeis.edu>

   A couple of other niceties about C++ that don't get much press:

   C++ distinguishes between pointers and references.  This is frequently
   advertised as a way .  But this distinction also allows you to distinguish
   between variables that may hold null, and those that can't (and some style
   guides recommend using the distinction between pointers and references to
   document exactly this distinction): in
     void fn(int* a, int& b) {...}
   *a is either an int or undefined; b is an int.

But it really, really sucks that in order to say whether nulls are
allowed or not, you have to change your whole program all over the
place, i.e.  use ampersands or not use ampersands, use dots versus
using arrows, etc.

I spent eight years in the C++ salt mines, and basically found that
mixing pointers and references made it just impossible for me to get
work done.  I'd constantly have to remember whether to use dots versus
arrows, and it all seemed so arbitrary.  So I ended up always using
pointers and arrows, and staying as far away from references as
possible.  (Not all my colleagues did the same, which resulted in our
coding conventions being inconsistent between major modules, which was
bad.)

   And C++ has unwind-protect!:

I always hated that you had to make these little phony classes every
time you wanted an unwind-protect.  The scope of the unwind-protect
was effectively denoted by the curly-braces that enclosed the instance
of the little class, but it was not prima facie obvious that those
curlies were unwind-protect boundaries.

   This lets you abstract the behavior of bracketing code in the same way
   macros and unwind-protect do in Lisp, in a way that you can't in Java (or a
   number of other more dynamic languages).

Well, I see your point about abstracting, but I really prefer Java
try/finally, personally, to the C++ way.  (Of course macros expanding
into unwind-protect (e.g. with-output-to-string) is the best; I'm
still looking forward to JSE...)