lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 



On 07/06/15 07:34 PM, Coda Highland wrote:

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
And this is how you turn a thread about Lua into a thread about C... and C++ >.> 

--
Disclaimer: these emails are public and can be accessed from <TODO: get a non-DHCP IP and put it here>. If you do not agree with this, DO NOT REPLY.