Re: Ichibah flames, and flames out over, Ada 9X

[dag@control.lth.se (Dag Bruck)]

In <comp.lang.ada> stt@spock.camb.inmet.com (Tucker Taft) writes:
>
>Independent of this type=module vs. type-inside-module issue, 
>there are in fact some differences between the Ada (83 and 9X) 
>language design philosophy and the C++ philosophy.  But even
>in the fundamental philosophy, there has been more convergence
>than divergence as time has passed.  

It is worth pointing out that in many cases, classes in C++ are used
only as abstract datatypes, i.e., without using inheritance or virtual
functions.  This common use of classes is very close to Ada packages.

>Interestingly, a number of tools have sprung up to 
>provide run-time checks for C++ programmers (e.g. CenterLine's
>ObjectCenter, Pure Software's Purify).  However, the run-time checks
>provided by such tools currently impose a higher run-time 
>overhead than the corresponding (standardized) checks in Ada, 
>because they haven't been integrated in with the optimizer, and in 
>some cases, are performed by interpreting rather than by direct execution.

I would like to comment as a user of Purify.  Some of the overhead,
probably a significant portion, comes from checks that are not normally
done by a civilized compiler with run-time checks.  Purify will also
check all system libraries, e.g., your X11 library, which are normally
compiled without debugging and checks turned off to improve speed.

>The fact that these checks are provided by separate tools (much
>as "lint" used to be used instead of having function prototypes) reflects
>the C/C++ philosophy of keeping the language semantics simple, and leaving
>checking to the environment.  The advantage of this approach is offset
>somewhat by the lack of portability in what checks any given environment 
>enforces, and in the (currently significant) difference in performance in the 
>presence of checks.

I think this has nothing to do with language semantics.  For example,
it is clear that accessing a piece of storage that was explicitly
deallocated is an error, in C++ as in any other language.  Few, if any,
language implementations check this, but Purify does.

I think this is a typical example where tools go beyond the language
implementation by adding checks that are not normally present, but
still does not add any semantics to the language.

There are of course other advantages to the tool approach.  In the
case of Purify, one advantage is that it can be used on code produced
by several compilers (but not any compiler, of course), which in some
sense increases portability.

Perhaps someone can answer this question: what kind of debugging
support (along the lines suggested above) will typical Ada
implementations give for unchecked deallocation?


			-- Dag