home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!elroy.jpl.nasa.gov!ames!tulane!uflorida!usf.edu!figment!woodard
- From: woodard@figment.tmc.edu (Chris Woodard)
- Newsgroups: comp.lang.c
- Subject: Re: Moving from Pascal to C, Help please!!!!!!
- Message-ID: <1993Jan18.215357.2591@ariel.ec.usf.edu>
- Date: 18 Jan 93 21:53:57 GMT
- References: <C04E63.863@newcastle.ac.uk> <1993Jan5.162504.1680@leland.Stanford.EDU> <4293@dozo.and.nl>
- Sender: news@ariel.ec.usf.edu (News Admin)
- Organization: University of South Florida, Department of Computer Science and Engineering
- Lines: 37
-
-
-
- I beg to differ with you on one point. Segment addresses are *only* ignored
- if you're in a memory model that uses 16-bit pointers. In others, such as
- Large and Huge, all 32 bits are important and the segment address *is* used in
- the pointer arithmetic.
-
- There _is_ a good reason for using pointers instead of arrays. If you had
- code such as
-
- [ example 1]
-
- register char *p1;
- register char *p2;
-
- while( *p1 ) *p2++ = *p1++;
-
- to copy the contents of one "string" to another, the generated code only has
- to access a single variable (which can be given "register" class for faster
- access). If, on the other hand, you have code such as
-
- [ example 2 ]
-
- char p1[26], p2[26];
- int k = 0;
-
- while( p1[k] ) p2[k] = p1[k++];
-
- then (a) your source and destination addresses are in const pointers, (b) you
- have to access them using an index variable that requires a MOV instruction
- for each invocation of the variable, and (c) you have some implicit address
- arithmetic in computing the offset into the array in the first place.
-
- Making a fetish out of avoiding address arithmetic is a cop-out for people who
- aren't comfortable with pointers ... and they should probably stick to
- programming in (ugh) Pascal or (double ugh) COBOL, and let the rest of us
- alone.
-