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

[kaz@vision.crest.nt.com (Kaz Kylheku)]

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?

>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.

>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.

>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.

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.

>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.

>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.

>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! :)))

>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. 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.