Re: simply question about syntatic sugar

[Coda Highland <chighland@...>]

On Sun, Jun 7, 2015 at 3:17 PM, Nagaev Boris <bnagaev@gmail.com> wrote:
> On Sun, Jun 7, 2015 at 10:10 PM, Coda Highland <chighland@gmail.com> wrote:
>> 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?
>> 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. 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.
>>
>> On Sun, Jun 7, 2015 at 2:45 PM, Nagaev Boris <bnagaev@gmail.com> wrote:
>>> If C used "." to dereference a pointer and get a field from a
>>> structure, it would be incompatible with C++. C++ allows overriding
>>> "->", which allows smart pointers and iterators. C++ compiler would
>>> not tell the difference between smart pointer's methods and methods of
>>> pointed value. It is impossible to override "." in C++.
>>>
>>>
>>>
>>> C would be better and cleaner language if array type removed in favor
>>> of pointers.
>>>
>>>    void bar(int[] foo);    -->    void bar(int* foo);
>>>
>>> A variable created by static array declaration would be a pointer.
>>>
>>> sizeof(array) would not work, well and good -- it is too easy to make
>>> an error using this feature.
>>
>> So wait. You're telling me you want to take the most dangerous feature
>> in C... and make it MORE dangerous?!
>>
>> /s/ Adam
>>
>
> How could it be more dangerous than now? It is a false sense of
> safety, since array bounds are not checked anyway, so arrays are
> already as dangerous as pointers. Just to be clear, I don't propose
> removing array[index] syntax sugar for *(array + index).
>

With T[], you can't reassign the pointer itself and can be certain
it's not null unless somebody sidestepped the analysis in the
compiler. With T[constant], you can reliably determine the length of
the array. With T* you don't even know if you're INTENDED to be
looking at a single element or an array of elements, except through
the documentation of the function. With T[], you can allocate memory
on the stack and have it automatically freed; with T*, you can only
accomplish this through the use of the unsafe, discouraged alloca()
(and even then you have to do the multiplication yourself).

In short, arrays are distinctly superior to pointers when what you
want is an array.

/s/ Adam