[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: simply question about syntatic sugar
- From: Sean Conner <sean@...>
- Date: Mon, 8 Jun 2015 01:50:34 -0400
It was thus said that the Great Coda Highland once stated:
> On Sun, Jun 7, 2015 at 8:17 PM, Sean Conner <sean@conman.org> wrote:
> > So, if C (or rather, the C compilers) can tell the difference between an
> > array and a pointer to an array and still use the same syntax, then it
> > should be just as easy (or the same) for C (or rather, the C compiler) to
> > tell the difference between a struct and a pointer to a struct and use the
> > same syntax. The only reason we have what we have now is historical [1][2].
>
> Do you really think it's safer to use identical syntax for member
> access when the two types are otherwise handled entirely differently?
You're talking about arrays, right? Because it's deadly when you do:
file1.h
extern int *foo;
file1.c
int foo[256];
even though at the source level, you can use the same syntax, even though
this creates a huge mess rather quickly ... oh wait! You're talking about
structs! Silly me.
> If you have two structs, assignment to one can't possibly modify the
> other; if you have two pointers, they might well be pointers to the
> same object.
C is trying to solve that problem with restrict [1]. And that sill leaves
the same issue with arrays, with identical syntax:
foo[4] = 4;
pfoo[4] = 5;
/* is foo[4] still 4? */
So I don't really think the argument along these lines is constructive.
> If you compare two structs, they might be distinct
> objects but look identical; if you compare two pointers, they'll only
> be the same if they refer to the same object. If you assign one struct
> to another one, you have two structs with the same contents; if you
> assign one pointer to another one, you leak memory and have two
> handles to the same data.
>
> It's not just historical reasons. The two types are FUNDAMENTALLY
> distinct, and the syntax should reflect that, even though the compiler
> clearly knows how to dereference both.
So are arrays and pointers. But they aren't treated differently
syntactically.
-spc
[1] Although C++ compilers don't seem to respect restrict.