Re: simply question about syntatic sugar

[Coda Highland <chighland@...>]

On Mon, Jun 8, 2015 at 10:51 AM, Sean Conner <sean@conman.org> wrote:
>> And in this case, assuming that at least one of them is a local
>> variable, you CAN be certain that foo[4] is still 4 after this. (If
>> they're both function parameters, then that's where restrict is
>> necessary.)
>
> But I'm failing to see how that is different from structures. I'm willing
> to accept that not only do you accept the -> operator, you prefer the ->
> operator as it makes a distinction you care about visble.  I have to accept
> the -> operator because that's how C works (and I am NOT a C++ programer---I
> can't stand the language myself) but would rather see it go as I don't see
> it serving any real useful purpose.

It's NOT different from structures. That's the whole point. Dealing
with arrays (that is, arrays declared as arrays and not as pointers)
and dealing with structures are analogous. If you have a *, you need
->, and it makes it clear that you're operating at an indirection. If
you don't have a *, you need ., and it makes it clear that you're
operating directly upon the data you've been given. I don't know of
any language that supports the full extent of both kinds of semantics
without having two different syntaxes.

>   I surprised our C++ programmer around here [1] with this:
>
>         struct foo  foo;
>         struct foo *pf = &foo;
>
>         pf[0].b = 1;    /* um ... wat? */
>
> He knew this worked though:
>
>         (*pf).b = 1;

Well yeah, it's not hard to surprise non-guru C++ programmers by using
stupid C tricks. It's not the kind of thing that C++ programmers want
to think about because we KNOW it's a bad idea and we have better ways
of doing it. You could probably elicit even more surprise by using:

0[pf].b = 1;

which does exactly the same thing because a[b] is LITERALLY synonymous
with *(a+b) unless operator overloading is in the picture.

>> >   So are arrays and pointers.  But they aren't treated differently
>> > syntactically.
>>
>> I could argue that they're NOT fundamentally different in C, that an
>> array is just a specific kind of pointer that happens to refer to a
>> contiguously-allocated block of elements instead of a single item.
>
>   Looked at the right way, the same could be said of a struct---it's a
> contiguously-allocated block of elements, but that each element can be of a
> different type and the index is "named" not numbered.  But than again, I
> come from a very strong assembly langauge background and can see that under
> the hood, these two have the same layout:
>
>         struct foo
>         {
>           int a;
>           int b;
>           int c;
>         } foo;
>
>         int bar[3];

Yes, but if you change one of those ints to a double, that comparison
falls flat. Arrays are sequential data. structs are structured data.
The idea of sorting an array makes sense. The idea of sorting a struct
does not. In an array, every element is intended to be treated the
same. In a struct, every element serves a distinct purpose.

>> But that's actually not necessary. No one ever claimed C was the
>> pinnacle of well-designed languages. There are certainly things that C
>> could do better. But don't suggest that you change something that C is
>> doing something right just for consistency with something else that it
>> does wrong.
>
>   So what does C do right and what does C do wrong that I'm trying to
> change?

What C does right is that it makes you aware that you're working with
something potentially dangerous, and the various syntaxes involved
provide important information about what operations you need to watch
out for.

What C does wrong (from your perspective) is that it uses two
different syntaxes for operations that ought to be analogous.

/s/ Adam