[TUHS] C declarations.
Theo Pavlidis
theopav at gmail.com
Fri May 12 12:41:51 AEST 2017
I tend to stay away from using arrays as arguments of procedures, too many
surprises. Instead I use structures.
For example:
typedef struct {
.........
xteam NoSo[MAXB], EsWe[MAXB];
} xboard;
............
xboard TB;
............
ScoreBoard(..., &TB, ...);
Of course, in my old age I only do simple game programming
Theo Pavlidis
(
Member of 1127: 1980-86)
On Thu, May 11, 2017 at 8:15 PM, Bakul Shah <bakul at bitblocks.com> wrote:
> On Thu, 11 May 2017 15:32:32 PDT Larry McVoy <lm at mcvoy.com> wrote:
> >
> > I dunno if it is one of its greatest joys but pointers in C have always
> > made sense to me.
> >
> > I'm curious as to what is busted about arrays in C? To me they just
> > seemed like a way to define how to look at a wad of memory and they
> > seem to work for me. About the only thing I don't like about them is
> > that there is no late binding as to the size, Ada has late binding and
> > I thought it could be useful (I only know because Rob Netzer and I
> > wrote an Ada compiler for CS736 at UW-Madison that did a lot of Ada
> > but exceptions and late binding we did not do).
>
> Coming from a Pascal background I really liked the terseness
> of C. But theere were three things that bothered me.
>
> a) K&R style argument declarations. This got fixed in ANSI C.
> C declarations were messy but that did not bother me much.
>
> b) No nested procedures. Gnu C had added them but the
> implementation was a bit screwy and most people didn't care
> in any case so there was no hope of this getting fixed.
> Partly because most people used it as a portable assembly
> language!
>
> c) arrays were not first class objects. Given "T v[N];" v[i]
> is of type T and i+v or v+i is of type T* -- this is
> perfectly well defined and fine. What is not fine is that
> an array is a second class object. Thus you can not do
> for example,
>
> int v[5];
> struct foo {
> int w[5];
> int x;
> } y;
> ...
> y.w = v;
>
> You can not pass a whole array to a function (or return
> one) without enclosing it in a struct. You can not take an
> address of an array, only an element of it. There is no way
> to declare or pass a subarray. A function that operates on a
> arbitray sized multi dim. array can be written but can get
> messy.
>
> One big impact of current array behavior is that the onus
> to do boundary condition checks is on the programmer and
> can't be done by the compiler.
>
> Just as Pascal got "conformant arrays" in its 1990 standard,
> arrays could've been made first class (but without "ref"
> parameters code can look messy). For instance, consider the
> folloowing:
>
> double a[5,20], b[20,10], c[5,10];
> int err = mat_multiply(c, a, b);
>
> int mat_mult(ref double c[int cx, cy], a[int ax, ay], b[int bx, by]) {
> if (cx != ax || cy != by || ay != bx) return -1;
> ...
> return 0;
> }
>
> This can be implemented without much trouble and allows
> full boundary condition checking. Currently the user will
> have to manually pass {a,b,c}{x,y} parameters and he would
> have to either create auxiliary vectors to point to each row
> or have the function to do all the index arithmetic explicitly
> (and the compiler can't check if your code has no boundary
> condition bugs).
>
> A slightly more difficult situation arises when you want to
> pass sub arrays. For instance,
>
> mat_mutl(c[5,0:9], a[5,10:19], b[0:9,0:5])
>
> Here you will have to somehow pass stride and offset (or use
> iliffe vectors or some such).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170511/0b5b8993/attachment.html>
More information about the TUHS
mailing list