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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2078dddcdcd8d83 X-Google-Attributes: gid103376,public From: kaz@vision.crest.nt.com (Kaz Kylheku) Subject: Re: Warning: Religious naming convention discussion :-) [was: assign help!!] Date: 1997/05/13 Message-ID: <5laovr$l7t@bcrkh13.bnr.ca>#1/1 X-Deja-AN: 241367191 References: <5kjvcv$evt@news.cis.nctu.edu.tw> Organization: Prism Systems Inc. Newsgroups: comp.lang.ada Date: 1997-05-13T00:00:00+00:00 List-Id: In article , Robert A Duff wrote: >In article , Robert Dewar 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.