Re: Learning Ada (newbie)

["David Thompson" <david.thompson1@worldnet.att.net>]

(posted&mailed)
Mark Lundquist <mark@rational.com> wrote :
[ long and good summary from which I pick only a few nits ]
...
> The second factor has to do with early detection of programming errors.
> .... Now, if you write an Ada function with no "return"
> statement, the compiler will reject it because this is not legal Ada.  But
> in C, it's perfectly legal for a non-void-returning function not to have a
> return statement.  The result of this at run-time is that the caller simply
> takes as the return value whatever happens to be in the return-value
> register.  Don't miss the fact that this behavior is in fact the *meaning*
> of that formulation in C.  Now how likely is it that the programmer intended
> this meaning?  Fat chance...

Technically in the C standard it is Undefined Behavior (= unbounded error)
if a non-void function "falls off the end" without executing a return statement
_and_ the caller tries to use the returned value.  What you describe
(just using whatever happens to be lying about in the return register)
is a common implementation but not required.

> That's just one example out of many.  Another is Ada's "case" statement,
> compared to the fall-through semantics of C's "switch" statement.  And it's
> well-known that  in C, a simple typo of "=" in place of "==" (or
> vice-versa) can escalate right up to an unbounded run-time error.  ...

Certainly substituting = for == or vice versa is a common bug,
to the point that better compilers warn about (but can't reject)
using an assignment where a predicate is normally expected,
but rarely unbounded error; if a comparison == was legal
and the assignment = does not violate the compile-time constraint
that the left hand side must be an lvalue and apparently modifiable,
the assignment is usually well-defined though wrong.
The only case that gets by here is if the target is actually
a const object but you have "deconstified" the lvalue
used in the assignment, which is hard to do by accident.
If an assignment was legal a comparison is well-defined
unless the left hand side is an "auto" (stack) object
not initialized or previously assigned, and a good compiler
can frequently warn of this.

> Link-time errors are more of a pain than compile-time errors.  The compiler
> has all kinds of information that the linker can't see, so a compiler is
> able to give error messages with a lot more specifics about what went wrong.
> All a linker can say is "I couldn't resolve symbol X", and then it's up to
> me to figure out what I did wrong.

Especially in C++ where the (apparently) missing symbol
may be one of many overloads of a function, or implicit
template instantiations, involving implicitly promoted types.

...
> Obviously, in C all run-time errors fall into the last category (unbounded
> run-time error), since C doesn't have exceptions.  ...

In practice mostly true, although it is not actually prohibited
and _occasionally_ done for the runtime support to detect
an error and give a clean dump.

...
> 2) Ada has a powerful type system.  ....
> user-defined array types (most array types in Ada are named, while in
> C-class languages they are all anonymous), real enumeration types that are
> not aliases for integers and can be used as array index types (and that
> don't collapse into ints as soon as you get in with a debugger), and more.

C can create a name for an array type (or any other) with typedef,
though it is often confusing to do so for arrays in particular because
they are not first-class (as you note below).  Good debuggers can
handle enum names properly -- but there is no in-language facility
for doing so like 'Image.  Your other points stand.

> 3) Generic units, which are similar to C++ templates except that they are
> almost perfectly type-safe and compile-time checkable.  ...
> ... mistake in C++ can result in a linker error message that is truly
> epic in size and whose cryptic syntax renders it virtually unreadable (if
> you've ever used STL, then you know what I'm talking about! :-)
>
C++ template instantiations are fully compile-time checked
(at any rate as fully as explicitly-written code) and can be
typesafe if you write them that way, although to the extent
you use them for C-ish code they tend not to be.
Most STL mistakes tend to produce cryptic _compiler_ error
messages rather than linker ones (not much better).

...
> 8) True array types, including constrained and unconstrained array types and
> multidimensional arrays.  The concept of an "array" is another fundamental
> programming concept, and collapsing to the pointer-based, machine-model
> level
> a la C/C++ doesn't do it justice.
>
In C++ (only) you have the option of writing array-like classes
which are somewhat better, if you go to the trouble,
but the builtin C-style arrays can't be disabled.


--
- David.Thompson 1 now at worldnet.att.net