Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[bobduff@world.std.com (Robert A Duff)]

In article <5laovr$l7t@bcrkh13.bnr.ca>,
Kaz Kylheku <kaz@vision.crest.nt.com> wrote:
>In article <EA4J04.LpH@world.std.com>,
>Robert A Duff <bobduff@world.std.com> wrote:
>>In article <dewar.863495951@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>>>Why are C arrays very low-level notions?
>>
>>Because:
>>
>>1. They don't carry their length (or bounds) with them.  You have to
>>pass this information "by hand", as a separate thing.
>
>C structures don't carry a count of their elements with them either.
>Are they low level notions?

No.  C structures don't have a "give me the N'th component" operation,
so of *course* they don't need to know how many components they have.
The *do* know they're size, though (sizeof(x)).

>>2. There are no "whole array" operations, such as assignment and
>>comparison.  (Yes, there are library functions for these, but they don't
>>operate on whole arrays -- they take pointer-to-first-element and
>>size/length parameters separately.)
>
>This is more due to a quirk in the language which disallows an array 
>from being a modifiable lvalue. However when arrays are embedded in
>structures, they may be assigned along with the structure, and may also
>be passed into functions by value, and returned from functions.

What you call a "quirk" I call a major language design flaw.  Anyway,
I'm not sure what you mean by "more due to...".  The fact is, in C, you
can't pass arrays, but only pointers.  That makes the notion of arrays
"low level", IMHO.

>>3. You can't pass an array as a parameter -- you have to pass a pointer
>>to the first component, instead.  (Or, looking at it a different way, an
>
>You can also pass a pointer to the whole array. For example;
>
>    typedef char user_id[8];
>
>    int user_exists(user_id *foo);
>
>The argument foo is a pointer to array of 8 char. Getting to the first
>character in that array would look like this:  (*foo)[0] . 
>In many circumstances, this technique is far preferred.

Granted.  But it only works if the "8" happens to be a
compile-time-known quantity, which if often isn't.  And, anyway, inside
user_exists, you can't know whether user_id is a pointer to a foo, or a
pointer to an array of foo's.

>>array *is* a pointer to the components.  C is pretty confused on this
>>point.)
>
>C isn't confused: some C newbies are confused perhaps. It's a hard rule
>though. It's a major failing of the language that it doesn't provide
>``bona fide'' arrays. It has to do with C's historical roots dating
>back to the B language.

OK, perhaps C isn't confused.  I should have said "C is inconsistent",
since sometimes an array is an array, and sometimes it's merely a
pointer.  And that *leads* to confusion.  Don't blame the "newbies" --
the *language* is at fault here.  The fact remains that within a
function, a *thing could be a pointer-to-a-thing, or a
pointer-to-the-first-element-of-an-array-of-things, and there's no
language-defined way to tell.

>In fact, in the B language, arrays _were_ pointers. Arrays actually contained,
>in their first cell, a pointer to their data section. A pointer was just an
>array with no data section, just the pointer cell (declared by not writing
>anything between the square brackets as in ``int foo[]'' which would be
>interpreted in C as an incomplete array declaration).  This became a problem in
>the design of C which allowed arrays to be embedded into structures---with no
>automatic initialization or finalization constructs, how would the cell be 
>properly initialized inside a dynamically created structure?  So Ritchie
>changed the rules so that evaluating an array would cause a pointer to its
>first element to be computed rather than loaded from a cell.  A few badly
>behaved B programs had to be changed: those which actually played with the cell
>contents to relocate an array. The alternate notations for declaring a pointer
>argument to a function (e.g.   char **argv and char *argv[]) are a merely a
>historic artifact left over from B.

I don't know B.  But I fail to see how blaming C's poor language design,
in this area, somehow makes it "high level".  Maybe B was quite
consistent in this regard.  So what?  We're talking about C.

>>And having done that, there's no way to tell, in the language,
>>whether a given formal parameter of type t* is pointing to a t, or to
>>the first element of an array of t's.
>
>That's unfortunate in many circumstances, though convenient in others.  It's
>good in those circumstances when the extra array management overhead isn't
>needed. It's bad in those circumstances when a C programmer is forced to invent
>a more general array data type, such as a structure containing a length and a
>pointer to data. Today, I wouldn't think of designing a language without decent
>arrays. What I find appealing are two dimensional slice extractions. Even
>Ada doesn't have those!  The ``Dragon Book'' gives a good discussion for
>the representation of arrays such that efficient extractions of rectilinear
>sub-arrays portion are possible.

But that's all about "good" vs. "bad", which isn't *quite* the same
thing as "low level" vs. "high level".  My claim is that the C
definition of arrays is "low level", as compared to Ada's definition of
arrays.  I certainly didn't claim that Ada's arrays are at the highest
possible level -- after all, they require the index type to be discrete!
(We're talking about "level" of abstraction, here, not level of goodness
or some such thing.)  And I certainly agree that a C struct containing
bounds info plus an array (plus associated operations) might be at the
same abstraction level as an Ada array.

>>4. Array indexing is defined in terms of pointer arithmetic.
>>(Well, I admit this is a rather weak reason.)
>
>These are all weak reasons for the argument that arrays are a low level
>construct; they are good reasons for some other claim though, such as the claim
>that C arrays are insufficiently general for some purposes.

I disagree.  An Ada array is more-or-less at the same level of
abstraction as a C struct that has bounds plus array components.
The plain-old-array, in C, is at a lower level of abstraction.

>>5. The lower bound is always zero, rather than whatever makes sense to
>>the programmer.  E.g. if you want a table that maps the numbers A..B
>>onto something-or-other, you have to subtract off A "by hand"
>
>If you program C long enough, nothing but zero based arrays makes sense! :)))

That's the problem with programmers, today.  ;-)

>>All of the above give me the feeling that a C array is, conceptually, a
>>pointer to a hunk of contiguous storage.  That's a low-level,
>>machine-oriented, notion.
>
>Except that the elements of that hunk still have a type, possibly a const
>qualifier, etc.

Granted.  It's not quite as low-level as I claimed -- you still have the
notion that ptr++ increments by the "right" amount.  And you still have
const.  I.e., granted that ptr++ is not quite as low level as address
arithmetic.  Hence my caveat on point (4) above.  I still stand by the
other points.

>... The true low level notion in C is that any object can
>be treated as though it were an array of characters, and that all storage
>is measured in characters.

Yeah.  That, too.

- Bob