From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,19e983c5955f75f X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-04-23 22:24:57 PST Path: newsfeed.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!arclight.uoregon.edu!wn4feed!worldnet.att.net!135.173.83.71!wnfilter1!worldnet-localpost!bgtnsc05-news.ops.worldnet.att.net.POSTED!not-for-mail From: "David Thompson" Newsgroups: comp.lang.ada References: <9af9ao$6ee$1@taliesin.netcom.net.uk> Subject: Re: Learning Ada (newbie) X-Newsreader: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: Date: Tue, 24 Apr 2001 05:24:57 GMT NNTP-Posting-Host: 12.89.136.83 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc05-news.ops.worldnet.att.net 988089897 12.89.136.83 (Tue, 24 Apr 2001 05:24:57 GMT) NNTP-Posting-Date: Tue, 24 Apr 2001 05:24:57 GMT Organization: AT&T Worldnet Xref: newsfeed.google.com comp.lang.ada:6875 Date: 2001-04-24T05:24:57+00:00 List-Id: (posted&mailed) Mark Lundquist 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