array

[Keith Thompson]

Re: array

Mark McIntyre <markmcintyre@s pamcop.netwrite s:

On Thu, 08 Mar 2007 17:31:40 -0800, in comp.lang.c , Keith Thompson
<kst-u@mib.orgwrote:
>

>>Ben Pfaff <blp@cs.stanfor d.eduwrites:

>>Keith Thompson <kst-u@mib.orgwrites :
>>>
>>>Mark McIntyre <markmcintyre@s pamcop.netwrite s:
>>>>An array isn't a type. Its a derived type, and has different
>>>>behaviour . Similarly structs.
>>>>
>>>No, an array type, like any derived type, is a type. For example,
>>>"int[4]" is a type, "array of 4 ints".
>>>
>>I thought about responding similarly to Mark's article, but then
>>it occurred to me that, in fact, "array" isn't a type in the same
>>sense that, say, "int" is a type. "Array of int" (e.g.) is an
>>(incomplete ) type, but "array" isn't really a type; it's more of
>>a declarator, to adopt name from the Standard's syntax
>>productions .

>>
>>Good point, though I don't know whether that's what Mark meant (note
>>that he said "an array", not "array".

>
It would have been clearer if I'd said "an array is not a simple
type".

Yes, it would have been clearer. It would also have been correct,
which your original statement quite simply was not.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Re: array

Mark McIntyre <markmcintyre@s pamcop.netwrite s:

On Fri, 09 Mar 2007 23:21:27 GMT, in comp.lang.c , Yevgen Muntyan
<muntyan.remove this@tamu.eduwr ote:

>>Mark McIntyre wrote:

>>>
>>Really? Can you say , given some suitable definition of a struct with
>>two integer members
>>>
>> ss = {4, 5};

>>
>>struct Foo a, b;
>>a = b;

>
Nit: some would say you're copying here, not assigning....

It's an assignment, specifically a simple assignment. The effect of
an assignment is to copy a value. Your "nit" is senseless.

Nit2: an example isn't a proof, whereas a counterexample is a
disproof. I've a feeling we've had this conversaton before.

A counterexample of what?

Suppose ss is of an arithmetic type. Can you give some suitable
definition such that

ss = { 42 };

is a valid assignment? If not, what exactly does that prove or
disprove?

>>Try this with arrays.

>
I'm curious as to how that answers my question above.
>

>>You really don't see what it's all about?

>
Of course I do. The point I'm making is that derived types have
different semantics for assignment.

Different *types* have different semantics for assignment. The
distinction between derived types and non-derived types is not
relevant. Specifically:

The arithmetic types (integer, floating, and complex) are not
derived types. Assignment is defined for all of them.

void is not a derived type. Assignment is not defined for type
void.

Array types are derived types. Assignment is not defined for
array types.

Structure and union types are derived types. Simple assignment is
defined for them, just as it is for the arithmetic types.

Function types are derived types. No assignment.

Pointer types are derived types. Pointer and arithmetic types
collectively are called scalar types; assignemnt is defined for
them.

There is no correlation between whether a type is derived, and whether
assignment is defined for it.

Stop digging.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[buuuuuum@gmail.com]

Re: array

On Mar 9, 12:07 am, Keith Thompson <k...@mib.orgwr ote:

buuuu...@gmail. com writes:

If you wanted to support array assignment, you could just say that a3
and a5 have different types and can't be assigned. Or you could allow
a subset of an array to be copied to a subset of another, but that
requires inventing a syntax to specify a subset of an array, something
C doesn't have.

>
I wrote the above, starting with "If you wanted ...". Please don't
snip attribution lines.

im sorry
im not familiar with newsgroups yet

yes,

>

int a3[3];
int a5[5];

>

are different type, so, cant be assigned

>
It sounds like you're suggesting allowing assignment for arrays, but
only when both arrays have the same constant length. If you wanted,
for example, to copy just the first three elements of a5 into a3, or
copy all of a3 into the first three elements of a5, then your proposed
array assignment operation couldn't be used. I suppose you could do
something with pointer conversions, but the result would be more
difficult to read than the equivalent memcpy() call.

like i said, you could write '&array[0]' instead 'array'

In my opinion, an array assignment operation that works only on
matching constant-length array objects is too limited to be
particularly useful, and one that's sufficiently general to be useful
(working on dynamic arrays, for example) would require too much
additional infrastructure to be practical *as an addition to C*. As I
wrote before, the existing C constructs give you all the flexibility
you could want, at the cost of some loss of convenience.

i think in arrays just like structs

struct somestruct {
char name[50];
int age;
...
char address[50];
};

struct similartosomest ruct {
char name[50];
int age;
...
char address[50];

char sex;
};

they are very similar, but not assignable

But it's also important to be able to deal with
dynamically allocated arrays, preferably using the same syntax. This
introduces the possibility of writing an array assignment where the
source and target lengths don't match, but the mismatch can't be
detected until run time.

>

are you talking about:

>

int *ptr=malloc(siz eof(int) * 10);

>

where ptr is a pointer

>

or

>

int (*ptr)[10];

>

where we know the array size?

>
The former, mostly. The malloc() call effectively creates an array of
10 ints; ptr points to the first of them, but doesn't include any
information about the size of the array. The second declaration makes
ptr a pointer to an array of exactly 10 ints; this is rarely useful
because it's so inflexible.

but, ptr is not an array, its a pointer to int, how can we write an
array assingment with this pointer?

If you want to be able to copy arrays, put them in a struct and copy the
structs.

[snip]

its simple, isn't?
so, why arrays can't do this?

>
Because that's the way the language is designed.

yes, and that is my question.

sacrifice all the simplicity and elegance of C's arrays.

>

if arrays were assignable you still could write &array[0], isn't it
the same thing?

>
Sure, if arrays were assignable, the implicit conversion of an array
name to a pointer would have to be modified. I'm not sure *how* it
would have to be modified. Getting rid of it altogether would require
other changes to the language. Any such change would almost
inevitably break existing code, and that's just not going to happen.
>
How often do you really need to assign arrays, anyway? There are
certainly times when copying an array can be useful, but in many cases
it's more useful just to copy pointers around.
>
Can you provide a realistic example of a program that would be
significantly easier to write if arrays were assignable?

i think the main thing that would change is to change 'array' by
'&array[0]',

im not asking for changes on the language, of course, its just a
question, why arrays are like this, i think there is no need
for me, would be much more simple and with sense if array were
assignable
so they could be passed and returned by function too, just like structs

[Keith Thompson]

Re: array

buuuuuum@gmail. com writes:

On Mar 9, 12:07 am, Keith Thompson <k...@mib.orgwr ote:

>buuuu...@gmail .com writes:

[big snip]

>If you want to be able to copy arrays, put them in a struct and copy the
>structs.

>[snip]

its simple, isn't?
so, why arrays can't do this?

>>
>Because that's the way the language is designed.

>
yes, and that is my question.

And I've answered it about as well as I can.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Default User]

Re: array

buuuuuum@gmail. com wrote:

im sorry
im not familiar with newsgroups yet

<http://groups.google.c om/support/bin/topic.py?topic= 9246>




Brian

[Richard Heathfield]

Re: array

Default User said:

buuuuuum@gmail. com wrote:
>
>

>im sorry
>im not familiar with newsgroups yet

>
>
<http://groups.google.c om/support/bin/topic.py?topic= 9246>

What would Google know about newsgroups?

Furrfu.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at the above domain, - www.

[Default User]

Re: array

Richard Heathfield wrote:

Default User said:
>

buuuuuum@gmail. com wrote:

im sorry
im not familiar with newsgroups yet

<http://groups.google.c om/support/bin/topic.py?topic= 9246>

>
What would Google know about newsgroups?
>

He's a Google user, he ought to be at least familiar with their help
section.




Brian

[Richard Heathfield]

Re: array

Default User said:

Richard Heathfield wrote:
>

>Default User said:
>>

buuuuuum@gmail. com wrote:
>
>
>im sorry
>im not familiar with newsgroups yet
>
>
<http://groups.google.c om/support/bin/topic.py?topic= 9246>

>>
>What would Google know about newsgroups?
>>

>
He's a Google user, he ought to be at least familiar with their help
section.

Yeah. What he might not realise from reading Google's help pages is that
newsgroups are not a Google product, but a well-established on-line
society to which Google has attached itself like a remora. Nor will he
learn that Google behaves irresponsibly by refusing to clamp down on
Usenet abuse perpetrated via their servers.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at the above domain, - www.

[Mark McIntyre]

Re: array

On 9 Mar 2007 16:03:04 -0800, in comp.lang.c , "Harald van D?k"
<truedfx@gmail. comwrote:

>You claimed that array assignment /has/ to be disallowed, because
>arrays are derived types. Yevgen Muntyan's example disproved this.

No I didn't. I said that an array was a derived type, not a simple
type and has different behaviour.

***********

>Mark McIntyre <markmcintyre@s pamcop.netwrite s:

>On 8 Mar 2007 11:01:30 -0800, in comp.lang.c , buuuuuum@gmail. com
>wrote:
>>
>An array isn't a type. Its a derived type, and has different
>behaviour. Similarly structs.

***********

(snippage)

>I'm curious as to how that answers my question above.

>
>It doesn't, because your question was not relevant,

My point was that derived types have different behaviour to simple
types, and so you cannot assume that simple assignment will be
possible. I gave an example showing how you cannot assign to a struct
using a method that other languages support, and indeed C allows you
to use to /initialise/ a struct (and indeed an array).

>Assignment requires an lvalue, and assignment operator, and an
>expression. You have an lvalue, an assignment operator, and an
>initialiser list.

This is a post-facto argument, and also merely a repetition of what I
said couched in standardese.

>Of course I do. The point I'm making is that derived types have
>different semantics for assignment.

>
>Your point is incorrect.

Oh? So you think that derived types have the same semantics, despite
evidence you yourself have produced to the contrary...
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Mark McIntyre]

Re: array

On Fri, 09 Mar 2007 17:04:54 -0800, in comp.lang.c , Keith Thompson
<kst-u@mib.orgwrote:

>Mark, you could save us all a great deal of time and trouble if, every
>now and then, you'd just admit when you've made a mistake.

I would, if I thought I had. I don't think I have.

>Instead,
>when you make a sloppy and incorrect statement (which we all do now
>and then), you respond to corrections by insisting that you were right
>and it's our fault for not understanding you.

I resent the implications of that. When I am wrong, I admit it.

On the other hand when I think I'm right, or that people are arguing
with me foolishly, I am not prepared to go quietly into the night.

>It's tiresome.

Thats a shame for you but hardly my problem. If you don't like my
style, you have no obligation to read my posts.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Mark McIntyre]

Re: array

On Fri, 09 Mar 2007 17:05:49 -0800, in comp.lang.c , Keith Thompson
<kst-u@mib.orgwrote:

>Mark McIntyre <markmcintyre@s pamcop.netwrite s:

>On Thu, 08 Mar 2007 17:31:40 -0800, in comp.lang.c , Keith Thompson
><kst-u@mib.orgwrote:
>>

>Yes, it would have been clearer. It would also have been correct,
>which your original statement quite simply was not.

My original statement was absolutely correct, An array is a derived
type.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Re: array

On Mar 10, 12:05 pm, Mark McIntyre <markmcint...@s pamcop.netwrote :

On 9 Mar 2007 16:03:04 -0800, in comp.lang.c , "Harald van D?k"
<true...@gmail. comwrote:

You claimed that array assignment /has/ to be disallowed, because
arrays are derived types. Yevgen Muntyan's example disproved this.

>
No I didn't. I said that an array was a derived type, not a simple
type and has different behaviour.
>
***********>Mar k McIntyre <markmcint...@s pamcop.netwrite s:

On 8 Mar 2007 11:01:30 -0800, in comp.lang.c , buuuu...@gmail. com
wrote:

[un-snip start]

why? what's the reason? why array's cant be like any other type in C?
why it have to be different?

[un-snip end]

>

An array isn't a type. Its a derived type, and has different
behaviour. Similarly structs.

>
***********

You snipped too much. You claimed that an array isn't a type, and that
that is the reason it has to be different. If others don't read your
reply as an answer to the question (as "Because an array isn't a
type.") though, I'll admit I'm wrong on that part.

(snippage)
>

I'm curious as to how that answers my question above.

>

It doesn't, because your question was not relevant,

>
My point was that derived types have different behaviour to simple
types, and so you cannot assume that simple assignment will be
possible. I gave an example showing how you cannot assign to a struct
using a method that other languages support, and indeed C allows you
to use to /initialise/ a struct (and indeed an array).

And I showed that you /can/ assign to a struct using that same method.
The syntax is different from initialisation, but I also showed that
the syntax for initialising and assigning to basic types
(specifically, int) differs as well, so how did you read that as a
difference between structures and basic types?

[Default User]

Re: array

Richard Heathfield wrote:

Default User said:
>

Richard Heathfield wrote:

Default User said:

<http://groups.google.c om/support/bin/topic.py?topic= 9246>
>
What would Google know about newsgroups?
>

He's a Google user, he ought to be at least familiar with their help
section.

>
Yeah. What he might not realise from reading Google's help pages is
that newsgroups are not a Google product, but a well-established
on-line society to which Google has attached itself like a remora.

Did you actually READ the link I provided?

"What is a Usenet Newsgroup?

Usenet is an online bulletin board system that began at Duke University
in 1979. Usenet users can post messages to newsgroups that can be read
(and responded to) by anyone who has access to the system through a
newsreader. Over the years, the number of newsgroups has grown into the
thousands, hosted all over the world and covering every conceivable
topic.

Google Groups contains the world's most comprehensive archive of Usenet
postings, dating back to 1981. Google Groups eliminates the need for a
newsreader and lets you search this archive the same way you'd search
on the web. You can also use Google Groups to post your own comments to
an existing Usenet newsgroup."

Nor will he learn that Google behaves irresponsibly by refusing to
clamp down on Usenet abuse perpetrated via their servers.

That's a different story.



Brian

[Ben Pfaff]

Re: array

Mark McIntyre <markmcintyre@s pamcop.netwrite s:

On Fri, 09 Mar 2007 17:05:49 -0800, in comp.lang.c , Keith Thompson
<kst-u@mib.orgwrote:
>

>>Mark McIntyre <markmcintyre@s pamcop.netwrite s:

>>On Thu, 08 Mar 2007 17:31:40 -0800, in comp.lang.c , Keith Thompson
>><kst-u@mib.orgwrote:
>>>

>>Yes, it would have been clearer. It would also have been correct,
>>which your original statement quite simply was not.

>
My original statement was absolutely correct, An array is a derived
type.

That part of your original statement, in the second sentence, was
correct (except for the grammatical error of "its"). The problem
was with the first sentence. Here, let me present it again:

Mark McIntyre <markmcintyre@s pamcop.netwrite s:

An array isn't a type. Its a derived type, and has different
behaviour. Similarly structs.

--
"The way I see it, an intelligent person who disagrees with me is
probably the most important person I'll interact with on any given
day."
--Billy Chambless

[Mark McIntyre]

Re: array

On 10 Mar 2007 08:10:53 -0800, in comp.lang.c , "Harald van D?k"
<truedfx@gmail. comwrote:

>You snipped too much. You claimed that an array isn't a type, and that
>that is the reason it has to be different.

You apparently mentally snipped too much, for the distinction I was
drawing was between a simple and derived type.

>And I showed that you /can/ assign to a struct using that same method.

So what? As I've said ad nauseam, you can't prove it by example, only
disprove by counterexample.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan