[TUHS] C declarations.

Dan Cross crossd at gmail.com
Mon May 15 10:14:47 AEST 2017


On Sun, May 14, 2017 at 7:34 PM, Arthur Krewat <krewat at kilonet.net> wrote:

> On 5/14/2017 7:06 PM, Ron Natalie wrote:
>
> array kludge
>
> Is it really a kludge?
>

Yes.

It's a pointer.
>

Of course it is! But that doesn't mean that it SHOULD be, which is the
point.

int array[128];
>
> Want to reference the array in a memcpy? Do: memcpy(destination, array,
> sizeof(array));
>
> Want to reference an element in the array? array[element #]
>
> Want to pass (a reference to) said array to a function? function(array)
>
> Not sure what the kludge is.
>

The kludge is that it works different than everything else for no really
good reason.

I think C is more consistent when it comes to arrays than a lot of other
> languages. At least with C you KNOW it's a pointer to the original.
>

Sure! But if someone had told you, back when you first learned C, that it
was an array and had value semantics, would you have thought THAT was
strange? "If you want a pointer to the array, use the address operator on
the array and pass that; that'll behave like a 'foo*' pointer for an array
of foo. Most people do this for efficiency."

The point is that it's a thought exercise. It's not that folks don't
understand how C works now or the semantics of array-decay-to-pointer; it's
just that folks can also imagine a world where things had been done
differently. That world doesn't exist, but we can still imagine it.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170514/42e2d44f/attachment.html>


More information about the TUHS mailing list