Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Array of Integers ?
35 views
Skip to first unread message
arnuld
Nov 8, 2011, 2:51:51 AM11/8/11
to
I wrote my blog on Insertion Sort some time back and used words "Array of
Integers" on that. I was told by someone that there is nothing like array
of integers in C. C has array of objects only.
So how do we differentiate between array of integers and array of
characters (not string constant) in communication if there is no such
thing as array of integers ?
--
arnuld
http://LispMachine.Wordpress.com
Integers" on that. I was told by someone that there is nothing like array
of integers in C. C has array of objects only.
So how do we differentiate between array of integers and array of
characters (not string constant) in communication if there is no such
thing as array of integers ?
--
arnuld
http://LispMachine.Wordpress.com
Ike Naar
Nov 8, 2011, 3:11:13 AM11/8/11
to
On 2011-11-08, arnuld <sun...@invalid.address> wrote:
> I wrote my blog on Insertion Sort some time back and used words "Array of
> Integers" on that. I was told by someone that there is nothing like array
> of integers in C. C has array of objects only.
>
> So how do we differentiate between array of integers and array of
> characters (not string constant) in communication if there is no such
> thing as array of integers ?
By their names.
> I wrote my blog on Insertion Sort some time back and used words "Array of
> Integers" on that. I was told by someone that there is nothing like array
> of integers in C. C has array of objects only.
>
> So how do we differentiate between array of integers and array of
> characters (not string constant) in communication if there is no such
> thing as array of integers ?
jacob navia
Nov 8, 2011, 3:14:06 AM11/8/11
to
Le 08/11/11 08:51, arnuld a écrit :
int array[256];
The person that told you that arrays of integers do not exist in C is
completely wrong.
In general you declara an array like this:
TYPE ArrayName [ array-size ] ;
For instance:
double array[256];
or
char array[256];
In general since a standard string is an array of characters finished
by a zero character there is no way of distinguishing it from an array
of characters that is zero terminated.
char array[] = { 'a', 'b', 0};
This has the same representation as the string "ab".
> I wrote my blog on Insertion Sort some time back and used words "Array of
> Integers" on that. I was told by someone that there is nothing like array
> of integers in C. C has array of objects only.
>
> So how do we differentiate between array of integers and array of
> characters (not string constant) in communication if there is no such
> thing as array of integers ?
>
>
>
You define an array of integers like this:
> Integers" on that. I was told by someone that there is nothing like array
> of integers in C. C has array of objects only.
>
> So how do we differentiate between array of integers and array of
> characters (not string constant) in communication if there is no such
> thing as array of integers ?
>
>
>
int array[256];
The person that told you that arrays of integers do not exist in C is
completely wrong.
In general you declara an array like this:
TYPE ArrayName [ array-size ] ;
For instance:
double array[256];
or
char array[256];
In general since a standard string is an array of characters finished
by a zero character there is no way of distinguishing it from an array
of characters that is zero terminated.
char array[] = { 'a', 'b', 0};
This has the same representation as the string "ab".
Nick Keighley
Nov 8, 2011, 3:23:30 AM11/8/11
to
On Nov 8, 8:14 am, jacob navia <ja...@spamsink.net> wrote:
> Le 08/11/11 08:51, arnuld a écrit :
> > I wrote my blog on Insertion Sort some time back and used words "Array of
> > Integers" on that. I was told by someone that there is nothing like array
> > of integers in C. C has array of objects only.
>
> > So how do we differentiate between array of integers and array of
> > characters (not string constant) in communication if there is no such
> > thing as array of integers ?
>
> You define an array of integers like this:
>
> int array[256];
>
> The person that told you that arrays of integers do not exist in C is
> completely wrong.
I agree. The array-of-T terminology has been around for an age. cdecl
> Le 08/11/11 08:51, arnuld a écrit :
> > I wrote my blog on Insertion Sort some time back and used words "Array of
> > Integers" on that. I was told by someone that there is nothing like array
> > of integers in C. C has array of objects only.
>
> > So how do we differentiate between array of integers and array of
> > characters (not string constant) in communication if there is no such
> > thing as array of integers ?
>
> You define an array of integers like this:
>
> int array[256];
>
> The person that told you that arrays of integers do not exist in C is
> completely wrong.
and such like use the terminology.
Ah, from the standrard (draft '89)
* An array type describes a contiguously allocated set of objects
with a particular member object type, called the element
type .Array
types are characterized by their element type and by the number of
members of the array. An array type is said to be derived from its
element type, and if its element type is T , the array type is
sometimes called ``array of T .'' The construction of an array type
from an element type is called ``array type derivation.''
pete
Nov 8, 2011, 4:07:28 AM11/8/11
to
Nick Keighley wrote:
>
> On Nov 8, 8:14 am, jacob navia <ja...@spamsink.net> wrote:
> > Le 08/11/11 08:51, arnuld a écrit :
>
> > > I wrote my blog on Insertion Sort some time back and used words "Array of
> > > Integers" on that. I was told by someone that there is nothing like array
> > > of integers in C. C has array of objects only.
> >
> > > So how do we differentiate between array of integers and array of
> > > characters (not string constant) in communication if there is no such
> > > thing as array of integers ?
> >
> > You define an array of integers like this:
> >
> > int array[256];
> >
> > The person that told you that arrays of integers do not exist in C is
> > completely wrong.
>
> I agree. The array-of-T terminology has been around for an age. cdecl
> and such like use the terminology.
>
> Ah, from the standrard (draft '89)
>
> * An array type describes a contiguously allocated set of objects
> with a particular member object type, called the element
> type .Array
> types are characterized by their element type and by the number of
> members of the array. An array type is said to be derived from its
> element type, and if its element type is T , the array type is
> sometimes called ``array of T .'' The construction of an array type
> from an element type is called ``array type derivation.''
C90 also has:
>
> On Nov 8, 8:14 am, jacob navia <ja...@spamsink.net> wrote:
> > Le 08/11/11 08:51, arnuld a écrit :
>
> > > I wrote my blog on Insertion Sort some time back and used words "Array of
> > > Integers" on that. I was told by someone that there is nothing like array
> > > of integers in C. C has array of objects only.
> >
> > > So how do we differentiate between array of integers and array of
> > > characters (not string constant) in communication if there is no such
> > > thing as array of integers ?
> >
> > You define an array of integers like this:
> >
> > int array[256];
> >
> > The person that told you that arrays of integers do not exist in C is
> > completely wrong.
>
> I agree. The array-of-T terminology has been around for an age. cdecl
> and such like use the terminology.
>
> Ah, from the standrard (draft '89)
>
> * An array type describes a contiguously allocated set of objects
> with a particular member object type, called the element
> type .Array
> types are characterized by their element type and by the number of
> members of the array. An array type is said to be derived from its
> element type, and if its element type is T , the array type is
> sometimes called ``array of T .'' The construction of an array type
> from an element type is called ``array type derivation.''
6.1.2.5 Types
There are four signed integer types,
designated as signed char, short int, int, and long int.
For each of the signed integer types,
there is a corresponding (but different)
unsigned integer type
(designated with the keyword unsigned)
that uses the same amount of storage
(including sign information)
and has the same alignment requirements.
The type char, the signed and unsigned integer types,
and the enumerated types are collectively called integral types.
In C99,
6.2.5 Types
17 The type char, the signed and unsigned integer types,
and the enumerated types are collectively called integer types.
--
pete
Malcolm McLean
Nov 8, 2011, 4:39:16 AM11/8/11
to
On Nov 8, 9:51 am, arnuld <sunr...@invalid.address> wrote:
>
> I wrote my blog on Insertion Sort some time back and used words "Array of
> Integers" on that. I was told by someone that there is nothing like array
> of integers in C. C has array of objects only.
>
C has several integer types, "int" is meant to be the default signed
>
> I wrote my blog on Insertion Sort some time back and used words "Array of
> Integers" on that. I was told by someone that there is nothing like array
> of integers in C. C has array of objects only.
>
type and is the "natural integer type" for the machine, which usually
means that it's the same width as a register.
An "object" in C is either an atomic type or a structure or, rarely,
an array. Objects are contiguous in memory. So an array of integers,
whether they be ints, longs, shorts or whatever, is an array of
objects. It's often useful to treat an array as an array of blind
objects, by passing in a void * to the start of the array and the
object width and count. memcpy(), memmove(), qsort() just treat arrays
as lists of bytes, and can be used on ints, doubles, structures, or
any object type.
--
Basic Algorithms: advance your knowledge of C programming
http://www.malcolmmclean.site11.com/www
James Kuyper
Nov 8, 2011, 6:19:14 AM11/8/11
to
On 11/08/2011 02:51 AM, arnuld wrote:
> I wrote my blog on Insertion Sort some time back and used words "Array of
> Integers" on that. I was told by someone that there is nothing like array
> of integers in C. C has array of objects only.
>
> So how do we differentiate between array of integers and array of
> characters (not string constant) in communication if there is no such
> thing as array of integers ?
Ignore this person. "Array of integers" is nothing more or less than
> I wrote my blog on Insertion Sort some time back and used words "Array of
> Integers" on that. I was told by someone that there is nothing like array
> of integers in C. C has array of objects only.
>
> So how do we differentiate between array of integers and array of
> characters (not string constant) in communication if there is no such
> thing as array of integers ?
shorthand for "array of objects of integer type"; the distinction he's
trying to make is pointless.
--
James Kuyper
tom st denis
Nov 8, 2011, 9:23:49 AM11/8/11
to
On Nov 8, 3:14 am, jacob navia <ja...@spamsink.net> wrote:
> In general since a standard string is an array of characters finished
> by a zero character there is no way of distinguishing it from an array
> of characters that is zero terminated.
>
> char array[] = { 'a', 'b', 0};
>
> This has the same representation as the string "ab".
Exception being you can then do
> In general since a standard string is an array of characters finished
> by a zero character there is no way of distinguishing it from an array
> of characters that is zero terminated.
>
> char array[] = { 'a', 'b', 0};
>
> This has the same representation as the string "ab".
array[1] = 'c';
Whereas "ab"[1] = 'c' may work but isn't generally a good idea.
Tom
Bradley K. Sherman
Nov 8, 2011, 9:28:13 AM11/8/11
to
In article <37c51614-8e33-47b1...@o15g2000vbo.googlegroups.com>,
tom st denis <t...@iahu.ca> wrote:
> ...
--bks
tom st denis <t...@iahu.ca> wrote:
> ...
>Whereas "ab"[1] = 'c' may work but isn't generally a good idea.
Why not? Looks like standard C to these old eyes.
--bks
Scott Fluhrer
Nov 8, 2011, 10:08:28 AM11/8/11
to
"Bradley K. Sherman" <b...@panix.com> wrote in message
news:j9be9t$iag$1...@reader1.panix.com...
examples of what a realistic compiler might do:
- It does what you would naively expect it to
- The write is ignored (although you probably need to paw through memory to
distinguish this from the previous case)
- It updates the string, and it also updates other instances of "ab" (and
strings ending in "ab") elsewhere in the program
- It crashes
As Tom said, it's generally not a good idea...
--
poncho
Chad
Nov 8, 2011, 10:12:01 AM11/8/11
to
On Nov 8, 12:14 am, jacob navia <ja...@spamsink.net> wrote:
> Le 08/11/11 08:51, arnuld a écrit :
>
> > I wrote my blog on Insertion Sort some time back and used words "Array of
> > Integers" on that. I was told by someone that there is nothing like array
> > of integers in C. C has array of objects only.
>
> > So how do we differentiate between array of integers and array of
> > characters (not string constant) in communication if there is no such
> > thing as array of integers ?
>
> You define an array of integers like this:
>
> int array[256];
>
> The person that told you that arrays of integers do not exist in C is
> completely wrong.
>
What about the following...
> Le 08/11/11 08:51, arnuld a écrit :
>
> > I wrote my blog on Insertion Sort some time back and used words "Array of
> > Integers" on that. I was told by someone that there is nothing like array
> > of integers in C. C has array of objects only.
>
> > So how do we differentiate between array of integers and array of
> > characters (not string constant) in communication if there is no such
> > thing as array of integers ?
>
> You define an array of integers like this:
>
> int array[256];
>
> The person that told you that arrays of integers do not exist in C is
> completely wrong.
>
http://67.40.109.61/torek/c/expr.html
And I quote..
"Array objects have a special, fundamental rule in C. This rule is
essentially arbitrary, and simply must be memorized. It falls out
from a key fact: C does not have array values. (There is one
exception to this, which I will save for later.) C does have array
objects -- just the values are missing. For instance, int a[5];
declares an ordinary array containing five ints. Logically, the
‘value’ of this array ought to be the five int values stored in that
array -- but it is not. Instead, the ‘value’ of the array is a
pointer to the first element of that array. "
The point being that, if I understand correctly, C does not have
'array of integers'. Instead, at least according to the former
comp.lang.c regular on here, the language has 'array objects'.
Chad
Noob
Nov 8, 2011, 10:25:03 AM11/8/11
to
Bradley K. Sherman wrote:
> Tom wrote:
>
>> Whereas "ab"[1] = 'c' may work but isn't generally a good idea.
>
> Why not? Looks like standard C to these old eyes.
String literals may not be modified.
> Tom wrote:
>
>> Whereas "ab"[1] = 'c' may work but isn't generally a good idea.
>
> Why not? Looks like standard C to these old eyes.
Bradley K. Sherman
Nov 8, 2011, 10:39:07 AM11/8/11
to
--bks
Nick Keighley
Nov 8, 2011, 9:59:31 AM11/8/11
to
On Nov 8, 2:28 pm, b...@panix.com (Bradley K. Sherman) wrote:
> In article <37c51614-8e33-47b1-a5e6-9e3e6fdcb...@o15g2000vbo.googlegroups.com>,
compilers to share string representaions or place them in read-only
memory.
> In article <37c51614-8e33-47b1-a5e6-9e3e6fdcb...@o15g2000vbo.googlegroups.com>,
> tom st denis <t...@iahu.ca> wrote:
> >Whereas "ab"[1] = 'c' may work but isn't generally a good idea.
>
> Why not? Looks like standard C to these old eyes.
it is undefined behaviour to modify a string literal. This allows
> >Whereas "ab"[1] = 'c' may work but isn't generally a good idea.
>
> Why not? Looks like standard C to these old eyes.
compilers to share string representaions or place them in read-only
memory.
pete
Nov 8, 2011, 11:49:33 AM11/8/11
to
> > Le 08/11/11 08:51, arnuld a Ècrit :
happens to be the "one exception to this"
which he was saving for later,
he's wrong.
ISO/IEC ISO/IEC 9899:1999 (E)
6.7.8 Initialization
Semantics
8 An initializer specifies the initial value stored in an object.
16 Otherwise, the initializer for an object
that has aggregate or union type shall be a brace
enclosed list of initializers for the elements or named members.
> The point being that, if I understand correctly, C does not have
> 'array of integers'. Instead, at least according to the former
> comp.lang.c regular on here, the language has 'array objects'.
Given, as above:
int array[256];
then (array), is an "array of 256 int".
ISO/IEC 9899:1999 (E)
and if its element type is T, the array type is sometimes
called ëëarray of Tíí.
Since int is an integer type,
I don't see anything wrong
with calling (array) "an array of integers".
--
pete
> >
> > > I wrote my blog on Insertion Sort some time back
> > > and used words "Array of
> > > Integers" on that. I was told by someone
> > > that there is nothing like array
> > > of integers in C. C has array of objects only.
> >
> > > So how do we differentiate between array of integers and array of
> > > characters (not string constant)
> > > in communication if there is no such
> > > thing as array of integers ?
> >
> > You define an array of integers like this:
> >
> > int array[256];
> >
> > The person that told you that arrays of
> > integers do not exist in C is
> > completely wrong.
> >
>
> What about the following...
>
> http://67.40.109.61/torek/c/expr.html
>
> And I quote..
>
> > > I wrote my blog on Insertion Sort some time back
> > > and used words "Array of
> > > Integers" on that. I was told by someone
> > > that there is nothing like array
> > > of integers in C. C has array of objects only.
> >
> > > So how do we differentiate between array of integers and array of
> > > characters (not string constant)
> > > in communication if there is no such
> > > thing as array of integers ?
> >
> > You define an array of integers like this:
> >
> > int array[256];
> >
> > The person that told you that arrays of
> > integers do not exist in C is
> > completely wrong.
> >
>
> What about the following...
>
> http://67.40.109.61/torek/c/expr.html
>
> And I quote..
>
> C does not have array values. (There is one
> exception to this, which I will save for later.)
Unless the case which is under discussion here and now,
> exception to this, which I will save for later.)
happens to be the "one exception to this"
which he was saving for later,
he's wrong.
ISO/IEC ISO/IEC 9899:1999 (E)
6.7.8 Initialization
Semantics
8 An initializer specifies the initial value stored in an object.
16 Otherwise, the initializer for an object
that has aggregate or union type shall be a brace
enclosed list of initializers for the elements or named members.
> The point being that, if I understand correctly, C does not have
> 'array of integers'. Instead, at least according to the former
> comp.lang.c regular on here, the language has 'array objects'.
int array[256];
then (array), is an "array of 256 int".
ISO/IEC 9899:1999 (E)
6.2.5 Types
17 The type char, the signed and unsigned integer types,
and the enumerated types are collectively called integer types.
20 An array type is said to be derived from its element type,
17 The type char, the signed and unsigned integer types,
and the enumerated types are collectively called integer types.
and if its element type is T, the array type is sometimes
called ëëarray of Tíí.
Since int is an integer type,
I don't see anything wrong
with calling (array) "an array of integers".
--
pete
James Kuyper
Nov 8, 2011, 12:13:03 PM11/8/11
to
...
non-standard language. He claims to be using 'object' to refer to what
the standard calls an 'lvalue'. However, his actual use of the term
doesn't support that claim; he frequently uses that term in ways where
'lvalue' wouldn't fit; in those cases he's actually using it in pretty
much the same way the standard defines it.
> "Array objects have a special, fundamental rule in C. This rule is
> essentially arbitrary, and simply must be memorized. It falls out
> from a key fact: C does not have array values. (There is one
> exception to this, which I will save for later.) C does have array
> objects -- just the values are missing. For instance, int a[5];
> declares an ordinary array containing five ints. Logically, the
> ‘value’ of this array ought to be the five int values stored in that
> array -- but it is not. Instead, the ‘value’ of the array is a
> pointer to the first element of that array. "
That paragraph fails to correctly explain what's going on in expressions
like &a or sizeof a, but for most other expressions, it's close enough
to be useful. He gives something closer to the correct rule farther down.
The correct rule is in 6.3.2.1: "Except when it is the operand of the
sizeof operator or the unary & operator, or is a string literal used to
initialize an array, an expression that has type ‘‘array of type’’ is
converted to an expression with type ‘‘pointer to type’’ that points to
the initial element of the array object and is not an lvalue."
> The point being that, if I understand correctly, C does not have
> 'array of integers'. Instead, at least according to the former
> comp.lang.c regular on here, the language has 'array objects'.
The discussion has been about an "array of objects", not an "array
object". An array object has sub-objects called elements. Those elements
have a type, and an array of objects which have the type T are routinely
referred to as an "array of T"; this usage is common in the standard
itself. The first five examples I found of such usage were 6.2.5p20,
footnote 36, 6.2.5p29, 6.3.2.1p3, and 6.5p6; there's many more. Nothing
said on the page you're referring to is incompatible with that usage.
>> The person that told you that arrays of integers do not exist in C is
>> completely wrong.
>>
>
> What about the following...
>
> http://67.40.109.61/torek/c/expr.html
Note that at the top of that page, the author indicates use of
>> completely wrong.
>>
>
> What about the following...
>
> http://67.40.109.61/torek/c/expr.html
non-standard language. He claims to be using 'object' to refer to what
the standard calls an 'lvalue'. However, his actual use of the term
doesn't support that claim; he frequently uses that term in ways where
'lvalue' wouldn't fit; in those cases he's actually using it in pretty
much the same way the standard defines it.
> "Array objects have a special, fundamental rule in C. This rule is
> essentially arbitrary, and simply must be memorized. It falls out
> from a key fact: C does not have array values. (There is one
> exception to this, which I will save for later.) C does have array
> objects -- just the values are missing. For instance, int a[5];
> declares an ordinary array containing five ints. Logically, the
> ‘value’ of this array ought to be the five int values stored in that
> array -- but it is not. Instead, the ‘value’ of the array is a
> pointer to the first element of that array. "
like &a or sizeof a, but for most other expressions, it's close enough
to be useful. He gives something closer to the correct rule farther down.
The correct rule is in 6.3.2.1: "Except when it is the operand of the
sizeof operator or the unary & operator, or is a string literal used to
initialize an array, an expression that has type ‘‘array of type’’ is
converted to an expression with type ‘‘pointer to type’’ that points to
the initial element of the array object and is not an lvalue."
> The point being that, if I understand correctly, C does not have
> 'array of integers'. Instead, at least according to the former
> comp.lang.c regular on here, the language has 'array objects'.
object". An array object has sub-objects called elements. Those elements
have a type, and an array of objects which have the type T are routinely
referred to as an "array of T"; this usage is common in the standard
itself. The first five examples I found of such usage were 6.2.5p20,
footnote 36, 6.2.5p29, 6.3.2.1p3, and 6.5p6; there's many more. Nothing
said on the page you're referring to is incompatible with that usage.
Ben Bacarisse
Nov 8, 2011, 4:45:58 PM11/8/11
to
arrays. The point is not that an array of ints does not exist, but that
there is no way to denote it's value.
This is unlike the behaviour of many other types in C. Given
int i = 42;
struct point { int x, y; } p = { 1, 2 };
int ia[5] = { 1, 2, 3, 4, 5 };
the expression 'i' denotes the value of i, and the expression 'p'
denotes the value of p. You can't do this with an array. The
expression 'ia' does not denote the array named ia -- it is an
expression of type pointer to int.
It's a moot point whether the sub-expression 'ia' denotes the array in
the expression 'sizeof ia'. I'd go with "no" since the sub-expression
is not evaluated.
--
Ben.
Keith Thompson
Nov 8, 2011, 4:48:36 PM11/8/11
to
string literal is undefined. The conclusion is the same: Don't
Do That. The difference is that the compiler isn't obligated to
diagnose the attempt (and it *could* "work").
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
jacob navia
Nov 8, 2011, 4:48:52 PM11/8/11
to
Le 08/11/11 15:23, tom st denis a écrit :
put immediate strings constants in a read only section,
some not. The standard says those shouldn't be modified.
OK.
But what I said still holds:
I said:
>> This has the same representation as the string "ab".
The same representation. Nothing else. Some compilers
>> This has the same representation as the string "ab".
put immediate strings constants in a read only section,
some not. The standard says those shouldn't be modified.
OK.
But what I said still holds:
James Kuyper
Nov 8, 2011, 4:48:45 PM11/8/11
to
On 11/08/2011 04:45 PM, Ben Bacarisse wrote:
...
...
> This is unlike the behaviour of many other types in C. Given
>
> int i = 42;
> struct point { int x, y; } p = { 1, 2 };
> int ia[5] = { 1, 2, 3, 4, 5 };
>
> the expression 'i' denotes the value of i, and the expression 'p'
> denotes the value of p. You can't do this with an array. The
> expression 'ia' does not denote the array named ia -- it is an
> expression of type pointer to int.
>
> It's a moot point whether the sub-expression 'ia' denotes the array in
> the expression 'sizeof ia'. I'd go with "no" since the sub-expression
> is not evaluated.
How about in &ia?
>
> int i = 42;
> struct point { int x, y; } p = { 1, 2 };
> int ia[5] = { 1, 2, 3, 4, 5 };
>
> the expression 'i' denotes the value of i, and the expression 'p'
> denotes the value of p. You can't do this with an array. The
> expression 'ia' does not denote the array named ia -- it is an
> expression of type pointer to int.
>
> It's a moot point whether the sub-expression 'ia' denotes the array in
> the expression 'sizeof ia'. I'd go with "no" since the sub-expression
> is not evaluated.
Keith Thompson
Nov 8, 2011, 5:00:05 PM11/8/11
to
Chad <cda...@gmail.com> writes:
[...]
C does have array values; it just doesn't let you manipulate them
directly in most cases. The standard's definition of the word
"value" (C99 3.17) is "precise meaning of the contents of an object
when interpreted as having a specific type". Nothing in that
definition excludes arrays. Given:
int arr[5];
the value of arr consists of the values of its 5 elements,
interpreted as having type "int[5]". When you store something
into an array object, that object has a value, and that value is
an array value.
The relevant rule (stated in C99 6.3.2.1p3) is that an expression
of array type is implicitly converted to a (non-lvalue) pointer to
the array object's first element -- *unless* the array expression
is the operand of a unary "&" (address-of) or of "sizeof", or is
a string literal in an initializer used to initialize an array;
in those cases, an array expression really is an array expression.
Note that when we refer to "an array", we generally mean "an object
of array type", or equivalently "an array object".
arr, as defined above is an array object (of type int[5]). Like any
array object, it is an array of objects (those objects happen to
be of type int). More precisely, it's an array of integers (an
array of longs, or of chars, would also be an array of integers).
Even more precisely, it's an array of ints.
[...]
> What about the following...
>
> http://67.40.109.61/torek/c/expr.html
>
> And I quote..
>
> "Array objects have a special, fundamental rule in C. This rule is
> essentially arbitrary, and simply must be memorized. It falls out
> from a key fact: C does not have array values. (There is one
> exception to this, which I will save for later.) C does have array
> objects -- just the values are missing. For instance, int a[5];
> declares an ordinary array containing five ints. Logically, the
> ‘value’ of this array ought to be the five int values stored in that
> array -- but it is not. Instead, the ‘value’ of the array is a
> pointer to the first element of that array. "
>
> The point being that, if I understand correctly, C does not have
> 'array of integers'. Instead, at least according to the former
> comp.lang.c regular on here, the language has 'array objects'.
I find the quoted text misleading at best.
>
> http://67.40.109.61/torek/c/expr.html
>
> And I quote..
>
> "Array objects have a special, fundamental rule in C. This rule is
> essentially arbitrary, and simply must be memorized. It falls out
> from a key fact: C does not have array values. (There is one
> exception to this, which I will save for later.) C does have array
> objects -- just the values are missing. For instance, int a[5];
> declares an ordinary array containing five ints. Logically, the
> ‘value’ of this array ought to be the five int values stored in that
> array -- but it is not. Instead, the ‘value’ of the array is a
> pointer to the first element of that array. "
>
> The point being that, if I understand correctly, C does not have
> 'array of integers'. Instead, at least according to the former
> comp.lang.c regular on here, the language has 'array objects'.
C does have array values; it just doesn't let you manipulate them
directly in most cases. The standard's definition of the word
"value" (C99 3.17) is "precise meaning of the contents of an object
when interpreted as having a specific type". Nothing in that
definition excludes arrays. Given:
int arr[5];
the value of arr consists of the values of its 5 elements,
interpreted as having type "int[5]". When you store something
into an array object, that object has a value, and that value is
an array value.
The relevant rule (stated in C99 6.3.2.1p3) is that an expression
of array type is implicitly converted to a (non-lvalue) pointer to
the array object's first element -- *unless* the array expression
is the operand of a unary "&" (address-of) or of "sizeof", or is
a string literal in an initializer used to initialize an array;
in those cases, an array expression really is an array expression.
Note that when we refer to "an array", we generally mean "an object
of array type", or equivalently "an array object".
arr, as defined above is an array object (of type int[5]). Like any
array object, it is an array of objects (those objects happen to
be of type int). More precisely, it's an array of integers (an
array of longs, or of chars, would also be an array of integers).
Even more precisely, it's an array of ints.
Keith Thompson
Nov 8, 2011, 5:05:50 PM11/8/11
to
Malcolm McLean <malcolm...@btinternet.com> writes:
> On Nov 8, 9:51 am, arnuld <sunr...@invalid.address> wrote:
>> I wrote my blog on Insertion Sort some time back and used words "Array of
>> Integers" on that. I was told by someone that there is nothing like array
>> of integers in C. C has array of objects only.
>>
> C has several integer types, "int" is meant to be the default signed
> type and is the "natural integer type" for the machine, which usually
> means that it's the same width as a register.
>
> An "object" in C is either an atomic type or a structure or, rarely,
> an array.
What's rare about array objects?
> On Nov 8, 9:51 am, arnuld <sunr...@invalid.address> wrote:
>> I wrote my blog on Insertion Sort some time back and used words "Array of
>> Integers" on that. I was told by someone that there is nothing like array
>> of integers in C. C has array of objects only.
>>
> C has several integer types, "int" is meant to be the default signed
> type and is the "natural integer type" for the machine, which usually
> means that it's the same width as a register.
>
> An "object" in C is either an atomic type or a structure or, rarely,
> an array.
An "object" is, by definition, a "region of data storage in the
execution environment, the contents of which can represent values"
(C99 3.14). It can be of any type other than an incomplete or
function type: scalar (including arithmetic and pointer ("atomic"
means something else)), struct, union, or array.
> Objects are contiguous in memory. So an array of integers,
> whether they be ints, longs, shorts or whatever, is an array of
> objects.
int arr[5];
arr is an object of type int[5], and each of its 5 elements is an
object of type int.
[...]
Keith Thompson
Nov 8, 2011, 5:25:14 PM11/8/11
to
object. (I maintain that it does have a value (see my other followup),
but it's not used here.)
Ben Bacarisse
Nov 8, 2011, 5:42:37 PM11/8/11
to
term "value" does not include lvalues (see footnote 53 of 6.3.2.1 p1).
C does have lvalues of array types, but these are not some special kind
of value. In C, the "l" in "lvalue" is not a modifier. lvalues are
*expressions* and they get evaluated -- they are not themselves the
result of an evaluation (again, see 6.3.2.1 p1).
--
Ben.
Ben Bacarisse
Nov 8, 2011, 7:57:01 PM11/8/11
to
Keith Thompson <ks...@mib.org> writes:
> Chad <cda...@gmail.com> writes:
> [...]
>> What about the following...
>>
>> http://67.40.109.61/torek/c/expr.html
>>
>> And I quote..
>>
>> "Array objects have a special, fundamental rule in C. This rule is
>> essentially arbitrary, and simply must be memorized. It falls out
>> from a key fact: C does not have array values. (There is one
>> exception to this, which I will save for later.) C does have array
>> objects -- just the values are missing. For instance, int a[5];
>> declares an ordinary array containing five ints. Logically, the
>> ‘value’ of this array ought to be the five int values stored in that
>> array -- but it is not. Instead, the ‘value’ of the array is a
>> pointer to the first element of that array. "
>>
>> The point being that, if I understand correctly, C does not have
>> 'array of integers'. Instead, at least according to the former
>> comp.lang.c regular on here, the language has 'array objects'.
>
> I find the quoted text misleading at best.
>
> C does have array values; it just doesn't let you manipulate them
> directly in most cases. The standard's definition of the word
> "value" (C99 3.17) is "precise meaning of the contents of an object
> when interpreted as having a specific type". Nothing in that
> definition excludes arrays.
That definition is effectively useless. Functions, for example, are
> Chad <cda...@gmail.com> writes:
> [...]
>> What about the following...
>>
>> http://67.40.109.61/torek/c/expr.html
>>
>> And I quote..
>>
>> "Array objects have a special, fundamental rule in C. This rule is
>> essentially arbitrary, and simply must be memorized. It falls out
>> from a key fact: C does not have array values. (There is one
>> exception to this, which I will save for later.) C does have array
>> objects -- just the values are missing. For instance, int a[5];
>> declares an ordinary array containing five ints. Logically, the
>> ‘value’ of this array ought to be the five int values stored in that
>> array -- but it is not. Instead, the ‘value’ of the array is a
>> pointer to the first element of that array. "
>>
>> The point being that, if I understand correctly, C does not have
>> 'array of integers'. Instead, at least according to the former
>> comp.lang.c regular on here, the language has 'array objects'.
>
> I find the quoted text misleading at best.
>
> C does have array values; it just doesn't let you manipulate them
> directly in most cases. The standard's definition of the word
> "value" (C99 3.17) is "precise meaning of the contents of an object
> when interpreted as having a specific type". Nothing in that
> definition excludes arrays.
said to return values. What object is being interpreted to get the
value returned by afunction? In the expression '1 + 1.0' something (it
is a value?) of type int is converted to a value of type double by the
usual arithmetic conversions, but there are no objects involved here.
The same goes for (int)1.0.
Some operators seem to try hard to avoid talking about values. For
example, '1 + 2' has a result but not a value. Others talk about "the
value of the result", further complicating matters.
> Given:
>
> int arr[5];
>
> the value of arr consists of the values of its 5 elements,
> interpreted as having type "int[5]". When you store something
> into an array object, that object has a value, and that value is
> an array value.
seems to make it clear that the unqualified term "value" means what
other languages call an rvalue and 'arr' is not one of those.
> The relevant rule (stated in C99 6.3.2.1p3) is that an expression
> of array type is implicitly converted to a (non-lvalue) pointer to
> the array object's first element -- *unless* the array expression
> is the operand of a unary "&" (address-of) or of "sizeof", or is
> a string literal in an initializer used to initialize an array;
> in those cases, an array expression really is an array expression.
>
> Note that when we refer to "an array", we generally mean "an object
> of array type", or equivalently "an array object".
>
> arr, as defined above is an array object (of type int[5]). Like any
> array object, it is an array of objects (those objects happen to
> be of type int). More precisely, it's an array of integers (an
> array of longs, or of chars, would also be an array of integers).
> Even more precisely, it's an array of ints.
/expression/, not a particular kind of /value/. When used on its own,
this lvalue, this expression, is converted to a pointer to the array.
At no point is there a value (read rvalue) in existence; the expression
is converted, not its value.
In the case of '&arr', the lvalue expression is, of course, not
converted. Section 6.3.2.1 p1 says that when an lvalue is evaluated it
simply "designates an object". Given 'int x;', the expression '&x' does
not, at any stage, involve a value of type "int object". The
sub-expression 'x' simply designates an int object and it is this object
whose address is taken. The same is true of '&arr'. There is no value
of array type involved at any stage.
I think the use of the term "designate" both in 6.3.2.1 p1 and in the
description of the & operator is deliberate and significant. It means
that lvalue expressions of array type never need to be said to have a
value.
--
Ben.
pete
Nov 9, 2011, 12:05:41 AM11/9/11
to
Ben Bacarisse wrote:
that an initializer for an array,
specifies the initial value stored in the array.
--
pete
>
> Keith Thompson <ks...@mib.org> writes:
> > C does have array values; it just doesn't let you manipulate them
> > directly in most cases. The standard's definition of the word
> > "value" (C99 3.17) is "precise meaning of the contents of an object
> > when interpreted as having a specific type". Nothing in that
> > definition excludes arrays.
>
> That definition is effectively useless.
The standard says
> Keith Thompson <ks...@mib.org> writes:
> > C does have array values; it just doesn't let you manipulate them
> > directly in most cases. The standard's definition of the word
> > "value" (C99 3.17) is "precise meaning of the contents of an object
> > when interpreted as having a specific type". Nothing in that
> > definition excludes arrays.
>
> That definition is effectively useless.
"An initializer specifies the initial value stored in an object."
Which leads me to believe
that an initializer for an array,
specifies the initial value stored in the array.
--
pete
Keith Thompson
Nov 9, 2011, 1:14:04 AM11/9/11
to
Ben Bacarisse <ben.u...@bsb.me.uk> writes:
> Keith Thompson <ks...@mib.org> writes:
>> Chad <cda...@gmail.com> writes:
>> [...]
>>> What about the following...
>>>
>>> http://67.40.109.61/torek/c/expr.html
>>>
>>> And I quote..
>>>
>>> "Array objects have a special, fundamental rule in C. This rule is
>>> essentially arbitrary, and simply must be memorized. It falls out
>>> from a key fact: C does not have array values. (There is one
>>> exception to this, which I will save for later.) C does have array
>>> objects -- just the values are missing. For instance, int a[5];
>>> declares an ordinary array containing five ints. Logically, the
>>> ‘value’ of this array ought to be the five int values stored in that
>>> array -- but it is not. Instead, the ‘value’ of the array is a
>>> pointer to the first element of that array. "
>>>
>>> The point being that, if I understand correctly, C does not have
>>> 'array of integers'. Instead, at least according to the former
>>> comp.lang.c regular on here, the language has 'array objects'.
>>
>> I find the quoted text misleading at best.
>>
>> C does have array values; it just doesn't let you manipulate them
>> directly in most cases. The standard's definition of the word
>> "value" (C99 3.17) is "precise meaning of the contents of an object
>> when interpreted as having a specific type". Nothing in that
> Keith Thompson <ks...@mib.org> writes:
>> Chad <cda...@gmail.com> writes:
>> [...]
>>> What about the following...
>>>
>>> http://67.40.109.61/torek/c/expr.html
>>>
>>> And I quote..
>>>
>>> "Array objects have a special, fundamental rule in C. This rule is
>>> essentially arbitrary, and simply must be memorized. It falls out
>>> from a key fact: C does not have array values. (There is one
>>> exception to this, which I will save for later.) C does have array
>>> objects -- just the values are missing. For instance, int a[5];
>>> declares an ordinary array containing five ints. Logically, the
>>> ‘value’ of this array ought to be the five int values stored in that
>>> array -- but it is not. Instead, the ‘value’ of the array is a
>>> pointer to the first element of that array. "
>>>
>>> The point being that, if I understand correctly, C does not have
>>> 'array of integers'. Instead, at least according to the former
>>> comp.lang.c regular on here, the language has 'array objects'.
>>
>> I find the quoted text misleading at best.
>>
>> C does have array values; it just doesn't let you manipulate them
>> directly in most cases. The standard's definition of the word
>> "value" (C99 3.17) is "precise meaning of the contents of an object
>> definition excludes arrays.
>
> That definition is effectively useless. Functions, for example, are
> said to return values. What object is being interpreted to get the
> value returned by afunction? In the expression '1 + 1.0' something (it
> is a value?) of type int is converted to a value of type double by the
> usual arithmetic conversions, but there are no objects involved here.
> The same goes for (int)1.0.
The problem with the definition is that it's incomplete (like a
>
> That definition is effectively useless. Functions, for example, are
> said to return values. What object is being interpreted to get the
> value returned by afunction? In the expression '1 + 1.0' something (it
> is a value?) of type int is converted to a value of type double by the
> usual arithmetic conversions, but there are no objects involved here.
> The same goes for (int)1.0.
number of other definitions in the standard). What it describes
is certainly an *example* of a value, but surely the evaluation of
an expression also results in a *value*. Indeed the definition of
"expression" (6.5p1) is "a sequence of operators and operands that
specifies computation of a value, or that designates an object
or a function, or that generates side effects, or that performs a
combination thereof". (Which, taken literally, implies that 42 isn't
an expression, since it contains neither operators nor operands.)
But what I conclude from that definition is that any object with
valid contents has a "value", which is the meaning of its contents
when interpreted as having a specific type.
> Some operators seem to try hard to avoid talking about values. For
> example, '1 + 2' has a result but not a value. Others talk about "the
> value of the result", further complicating matters.
>
>> Given:
>>
>> int arr[5];
>>
>> the value of arr consists of the values of its 5 elements,
>> interpreted as having type "int[5]". When you store something
>> into an array object, that object has a value, and that value is
>> an array value.
>
> I disagree, though I expect to regret it! The footnote on 6.3.2.1 p1
> seems to make it clear that the unqualified term "value" means what
> other languages call an rvalue and 'arr' is not one of those.
What is sometimes called "rvalue" is in this International
Standard described as the "value of an expression".
That's not the unqualified term; it's the value *of an expression*.
The only consistent interpretation I can come up with is:
The Standard's definition of "value" is incomplete.
Any object in which something valid has been stored (handwaving meant to
exclude trap representations and perhaps indeterminate values) has a
"value", which is the "precise meaning of the contents of an object
when interpreted as having a specific type".
Any expression which (a) is not of function type, (b) is not an
lvalue, and (c) is not of void type yields a *value* when it's
evaluated. This is not covered by the definition of "value" in 3.17,
but it is covered by the definition of "expression" in 6.5p1.
6.3.2.1p2 ties these together:
Except when it is the operand of the sizeof operator, the unary &
operator, the ++ operator, the -- operator, or the left operand
of the . operator or an assignment operator, an lvalue that does
not have array type is converted to the value stored in the
designated object (and is no longer an lvalue). If the lvalue
has qualified type, the value has the unqualified version of
the type of the lvalue; otherwise, the value has the type of
the lvalue. If the lvalue has an incomplete type and does not
have array type, the behavior is undefined.
This says that evaluating the name of an object yields the value of
the object (and likewise for more complex lvalues). You can't get
the value of an array object by evaluating its name. That doesn't,
IMHO, imply that the array object doesn't have a value, and in fact
the incomplete definition of "value" in 3.17 implies that an array
object *does* have a value.
I'd be happier if the standard stated this more directly.
[...]
> The sub-expression 'arr' is an lvalue. I.e. it is an kind of
> /expression/, not a particular kind of /value/. When used on its own,
> this lvalue, this expression, is converted to a pointer to the array.
> At no point is there a value (read rvalue) in existence; the expression
> is converted, not its value.
argue) they do exist in array objects.
[...]
> I think the use of the term "designate" both in 6.3.2.1 p1 and in the
> description of the & operator is deliberate and significant. It means
> that lvalue expressions of array type never need to be said to have a
> value.
I agree with that.
> description of the & operator is deliberate and significant. It means
> that lvalue expressions of array type never need to be said to have a
> value.
Ben Bacarisse
Nov 9, 2011, 6:06:06 AM11/9/11
to
pete <pfi...@mindspring.com> writes:
> Ben Bacarisse wrote:
>>
>> Keith Thompson <ks...@mib.org> writes:
>
>> > C does have array values; it just doesn't let you manipulate them
>> > directly in most cases. The standard's definition of the word
>> > "value" (C99 3.17) is "precise meaning of the contents of an object
>> > when interpreted as having a specific type". Nothing in that
> Ben Bacarisse wrote:
>>
>> Keith Thompson <ks...@mib.org> writes:
>
>> > C does have array values; it just doesn't let you manipulate them
>> > directly in most cases. The standard's definition of the word
>> > "value" (C99 3.17) is "precise meaning of the contents of an object
>> > definition excludes arrays.
>>
>> That definition is effectively useless.
>
> The standard says
> "An initializer specifies the initial value stored in an object."
>
> Which leads me to believe
> that an initializer for an array,
> specifies the initial value stored in the array.
Does that mean that it *is* an array value? Maybe. I get the feeling
>>
>> That definition is effectively useless.
>
> The standard says
> "An initializer specifies the initial value stored in an object."
>
> Which leads me to believe
> that an initializer for an array,
> specifies the initial value stored in the array.
that wording like "specifies" and "designates" are deliberately
non-specific.
Initialisers specify values in some very indirect ways. {0} can specify
the initial value of any object (at least I can't think of an exception)
so it's rather unnatural to think of these things as denoting values of
some type or other.
--
Ben.
Keith Thompson
Nov 9, 2011, 4:36:04 PM11/9/11
to
Ben Bacarisse <ben.u...@bsb.me.uk> writes:
> pete <pfi...@mindspring.com> writes:
>> Ben Bacarisse wrote:
>>> Keith Thompson <ks...@mib.org> writes:
>>> > C does have array values; it just doesn't let you manipulate them
>>> > directly in most cases. The standard's definition of the word
>>> > "value" (C99 3.17) is "precise meaning of the contents of an object
>>> > when interpreted as having a specific type". Nothing in that
>>> > definition excludes arrays.
>>>
>>> That definition is effectively useless.
>>
>> The standard says
>> "An initializer specifies the initial value stored in an object."
>>
>> Which leads me to believe
>> that an initializer for an array,
>> specifies the initial value stored in the array.
>
> Does that mean that it *is* an array value? Maybe. I get the feeling
> that wording like "specifies" and "designates" are deliberately
> non-specific.
No, an initializer is a syntactic construct that appears in source
> pete <pfi...@mindspring.com> writes:
>> Ben Bacarisse wrote:
>>> Keith Thompson <ks...@mib.org> writes:
>>> > C does have array values; it just doesn't let you manipulate them
>>> > directly in most cases. The standard's definition of the word
>>> > "value" (C99 3.17) is "precise meaning of the contents of an object
>>> > when interpreted as having a specific type". Nothing in that
>>> > definition excludes arrays.
>>>
>>> That definition is effectively useless.
>>
>> The standard says
>> "An initializer specifies the initial value stored in an object."
>>
>> Which leads me to believe
>> that an initializer for an array,
>> specifies the initial value stored in the array.
>
> Does that mean that it *is* an array value? Maybe. I get the feeling
> that wording like "specifies" and "designates" are deliberately
> non-specific.
code, while a value is something that exists in a running program.
It "specifies" that value in the sense that it tells the compiler
to generate code that will create that value when the program
is executed.
> Initialisers specify values in some very indirect ways. {0} can specify
> the initial value of any object (at least I can't think of an exception)
> so it's rather unnatural to think of these things as denoting values of
> some type or other.
int arr[5] = { 0 };
the initializer "{ 0 }" specifies the initial value of arr. This is
a value of type int[5], consisting of 5 values of type int, all 0.
The value that an initializer specifies can be determined only
in context. Given that context, the value that it specifies is
unambiguous.
pete
Nov 9, 2011, 6:34:04 PM11/9/11
to
The point is that the thing being either specified or designated,
is the value being stored in the array.
The point is that the array has a value stored in it.
--
pete
Ben Bacarisse
Nov 9, 2011, 7:57:22 PM11/9/11
to
Now, what does that tell us about C? Nothing useful, because we can't
compute with the values like we can with, say, struct values. In fact
these values can never appear during the execution of a program -- they
can't be "denoted" (to borrow a phrase from a related field). The now
indisputable existence of array values is, for me, and accident of
wording, not a fundamental property of the language like the existence
of int values.
--
Ben.
Message has been deleted
Keith Thompson
Nov 9, 2011, 10:34:53 PM11/9/11
to
>>Correction: The behavior of a program that attempts to modify a
>>string literal is undefined.
>
> A string literal is part of the source code.
>>string literal is undefined.
>
>
> The source code usually is not there when a program is running.
[...]
Yes, I was using a verbal shorthand. (And I've made enough similar
criticisms that it's a fair point.)
A string literal in source code corresponds to an array with static
storage duration that exists during program execution (C99 6.4.5).
The behavior of a program that attempts to modify that array is
undefined.
An example:
"hello"[0] = 'H';
A more realistic example:
void foo(char *s) { s[0] = 'h'; }
...
foo("hello");
Phil Carmody
Nov 10, 2011, 5:01:52 AM11/10/11
to
Ben Bacarisse <ben.u...@bsb.me.uk> writes:
then where is the normative definition of "value"? A quick grep shows
it's not in n869, for example.
Phil
--
Unix is simple. It just takes a genius to understand its simplicity
-- Dennis Ritchie (1941-2011), Unix Co-Creator
> Chad <cda...@gmail.com> writes:
> > The point being that, if I understand correctly, C does not have
> > 'array of integers'. Instead, at least according to the former
> > comp.lang.c regular on here, the language has 'array objects'.
>
> No, that quote says that C has no array values, not that it has no
> arrays.
If an argument is being pinned on the implication of the word "value",
> > The point being that, if I understand correctly, C does not have
> > 'array of integers'. Instead, at least according to the former
> > comp.lang.c regular on here, the language has 'array objects'.
>
> No, that quote says that C has no array values, not that it has no
> arrays.
then where is the normative definition of "value"? A quick grep shows
it's not in n869, for example.
Phil
--
Unix is simple. It just takes a genius to understand its simplicity
-- Dennis Ritchie (1941-2011), Unix Co-Creator
Keith Thompson
Nov 10, 2011, 6:14:47 AM11/10/11
to
Phil Carmody <thefatphi...@yahoo.co.uk> writes:
> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
>> Chad <cda...@gmail.com> writes:
>> > The point being that, if I understand correctly, C does not have
>> > 'array of integers'. Instead, at least according to the former
>> > comp.lang.c regular on here, the language has 'array objects'.
>>
>> No, that quote says that C has no array values, not that it has no
>> arrays.
>
> If an argument is being pinned on the implication of the word "value",
> then where is the normative definition of "value"? A quick grep shows
> it's not in n869, for example.
C99 3.17: "precise meaning of the contents of an object when
> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
>> Chad <cda...@gmail.com> writes:
>> > The point being that, if I understand correctly, C does not have
>> > 'array of integers'. Instead, at least according to the former
>> > comp.lang.c regular on here, the language has 'array objects'.
>>
>> No, that quote says that C has no array values, not that it has no
>> arrays.
>
> If an argument is being pinned on the implication of the word "value",
> then where is the normative definition of "value"? A quick grep shows
> it's not in n869, for example.
interpreted as having a specific type".
As I discussed elsethread, this is an incomplete definitions;
it's clear that expressions can also yield values.
Phil Carmody
Nov 10, 2011, 10:41:51 AM11/10/11
to
Keith Thompson <ks...@mib.org> writes:
> Phil Carmody <thefatphi...@yahoo.co.uk> writes:
> > Ben Bacarisse <ben.u...@bsb.me.uk> writes:
> >> Chad <cda...@gmail.com> writes:
> >> > The point being that, if I understand correctly, C does not have
> >> > 'array of integers'. Instead, at least according to the former
> >> > comp.lang.c regular on here, the language has 'array objects'.
> >>
> >> No, that quote says that C has no array values, not that it has no
> >> arrays.
> >
> > If an argument is being pinned on the implication of the word "value",
> > then where is the normative definition of "value"? A quick grep shows
> > it's not in n869, for example.
>
> C99 3.17: "precise meaning of the contents of an object when
> interpreted as having a specific type".
>
> As I discussed elsethread, this is an incomplete definitions;
> it's clear that expressions can also yield values.
Ah, yes, that will teach me to grep, rather than pulling up a GUI pdf viewer. Many thanks.
> Phil Carmody <thefatphi...@yahoo.co.uk> writes:
> > Ben Bacarisse <ben.u...@bsb.me.uk> writes:
> >> Chad <cda...@gmail.com> writes:
> >> > The point being that, if I understand correctly, C does not have
> >> > 'array of integers'. Instead, at least according to the former
> >> > comp.lang.c regular on here, the language has 'array objects'.
> >>
> >> No, that quote says that C has no array values, not that it has no
> >> arrays.
> >
> > If an argument is being pinned on the implication of the word "value",
> > then where is the normative definition of "value"? A quick grep shows
> > it's not in n869, for example.
>
> C99 3.17: "precise meaning of the contents of an object when
> interpreted as having a specific type".
>
> As I discussed elsethread, this is an incomplete definitions;
> it's clear that expressions can also yield values.
Compound literals can be arrays and have values too, I'm surprised nobody's used them
as an example yet.
Ben Bacarisse
Nov 10, 2011, 11:44:08 AM11/10/11
to
Phil Carmody <thefatphi...@yahoo.co.uk> writes:
<snip>
containing bits, they can be said to have a value (as per 3.17). A
compound literal like
(int [3]){1,2,3}
is an lvalue expression so, unless you put & or sizeof in front of it,
it gets converted to an expression of pointer type.
Compound literals of struct types are different: they denote proper
values (I can't think of a better term -- values you can refer to and
use). They too are lvalue expressions, but they get converted to a
value of the appropriate type when they are used.
--
Ben.
<snip>
> Compound literals can be arrays and have values too, I'm surprised
> nobody's used them as an example yet.
They have an array value only the literal sense that, being arrays and
> nobody's used them as an example yet.
containing bits, they can be said to have a value (as per 3.17). A
compound literal like
(int [3]){1,2,3}
is an lvalue expression so, unless you put & or sizeof in front of it,
it gets converted to an expression of pointer type.
Compound literals of struct types are different: they denote proper
values (I can't think of a better term -- values you can refer to and
use). They too are lvalue expressions, but they get converted to a
value of the appropriate type when they are used.
--
Ben.
Keith Thompson
Nov 10, 2011, 1:59:59 PM11/10/11
to
"proper" as any other values. The only thing "improper" about
them is that the language doesn't let you refer to them as a whole.
Though of course arr[i] yields a value that's *part of* the value
of the array value of arr.
Phil Carmody
Nov 11, 2011, 10:49:42 AM11/11/11
to
Ben Bacarisse <ben.u...@bsb.me.uk> writes:
> Phil Carmody <thefatphi...@yahoo.co.uk> writes:
> <snip>
> > Compound literals can be arrays and have values too, I'm surprised
> > nobody's used them as an example yet.
>
> They have an array value only the literal sense that, being arrays and
> containing bits, they can be said to have a value (as per 3.17).
Indeed. It's amusing to see the how the different perspectives change
> Phil Carmody <thefatphi...@yahoo.co.uk> writes:
> <snip>
> > Compound literals can be arrays and have values too, I'm surprised
> > nobody's used them as an example yet.
>
> They have an array value only the literal sense that, being arrays and
> containing bits, they can be said to have a value (as per 3.17).
people's perception of this issue. I think Keith has worded my view most
coherently. I thought I was providing another example of how we look at
things and now see it's amusingly dismissable as just being another
example of how others look at things differently!
Tim Rentsch
Jan 25, 2012, 3:45:43 AM1/25/12
to
Keith Thompson <ks...@mib.org> writes:
> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
>> pete <pfi...@mindspring.com> writes:
>>> Ben Bacarisse wrote:
>>>> Keith Thompson <ks...@mib.org> writes:
>>>> > C does have array values; it just doesn't let you manipulate them
>>>> > directly in most cases. The standard's definition of the word
>>>> > "value" (C99 3.17) is "precise meaning of the contents of an object
>>>> > when interpreted as having a specific type". Nothing in that
>>>> > definition excludes arrays.
>>>>
>>>> That definition is effectively useless.
>>>
>>> The standard says
>>> "An initializer specifies the initial value stored in an object."
>>>
>>> Which leads me to believe
>>> that an initializer for an array,
>>> specifies the initial value stored in the array.
>>
>> Does that mean that it *is* an array value? Maybe. I get the feeling
>> that wording like "specifies" and "designates" are deliberately
>> non-specific.
>
> No, an initializer is a syntactic construct that appears in source
> code, while a value is something that exists in a running program.
> [snip elaboration]
> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
>> pete <pfi...@mindspring.com> writes:
>>> Ben Bacarisse wrote:
>>>> Keith Thompson <ks...@mib.org> writes:
>>>> > C does have array values; it just doesn't let you manipulate them
>>>> > directly in most cases. The standard's definition of the word
>>>> > "value" (C99 3.17) is "precise meaning of the contents of an object
>>>> > when interpreted as having a specific type". Nothing in that
>>>> > definition excludes arrays.
>>>>
>>>> That definition is effectively useless.
>>>
>>> The standard says
>>> "An initializer specifies the initial value stored in an object."
>>>
>>> Which leads me to believe
>>> that an initializer for an array,
>>> specifies the initial value stored in the array.
>>
>> Does that mean that it *is* an array value? Maybe. I get the feeling
>> that wording like "specifies" and "designates" are deliberately
>> non-specific.
>
> No, an initializer is a syntactic construct that appears in source
> code, while a value is something that exists in a running program.
Actually, programs don't hold values - what they hold are
representations of values. A value is a "meaning" or abstract
notion like the number 3. There aren't any 3's in a running
program; a program may have one or more bit patterns that are
used to represent the number 3, but it doesn't store the actual
number, which is just an abstract concept.
Tim Rentsch
Jan 25, 2012, 4:46:35 AM1/25/12
to
>
> The only consistent interpretation I can come up with is:
>
> The Standard's definition of "value" is incomplete.
>
> Any object in which something valid has been stored (handwaving meant to
> exclude trap representations and perhaps indeterminate values) has a
> "value", which is the "precise meaning of the contents of an object
> when interpreted as having a specific type". [snip elaboration]
> The only consistent interpretation I can come up with is:
>
> The Standard's definition of "value" is incomplete.
>
> Any object in which something valid has been stored (handwaving meant to
> exclude trap representations and perhaps indeterminate values) has a
> "value", which is the "precise meaning of the contents of an object
Let me suggest a different and IMO more useful way of thinking
about this.
A value is the /meaning/ of an object (considered as a particular
type). The key word here is /meaning/ - a 'value' is an
abstraction, an idea, not something that can be held in a
program, but a point in an abstract value space that follows
certain rules (eg, mathematical addition, etc).
It's true that bit patterns stored in objects are used to
represent values (again, under a particuilar type). However, the
value itself -- the "meaning" -- is something that does not
depend on any object for its existence: an unchanging, abstract
idea (such as, for example, the number 3).
When the Standard says an expression yields a certain value, what
that means is the program produces something whose "meaning" is
the same if the abstract value were stored into an object that
has the same type as that of the value. (All values in C
programs are effectively indexed by what type they are.) More
concretely, an expression like
21 + 21
yields the same value (ie, the same meaning) as is held by
the variable 'x' (an object) after
int x = 42;
Viewed from this perspective, what is produced by evaluating an
expression has the same meaning as some bit pattern stored in an
object. Because it has the same meaning, it is the same value.
To say that another way, objects do hold patterns of bits that
represent values, but values don't depend on objects for their
existence -- if something has the same meaning as a certain bit
pattern would if held in an object, then that is the same value
as the object would have, whether an object is present or not.
(As always, subject to the necessary qualifications about types.)
I agree that the text of the Standard takes certain linguistic
liberties -- eg, saying an expression yields a value (which is
quite nonsensical, whatever expressions produce it certainly
isn't a 'meaning') -- that sometimes are frustrating or
confusing. However, I don't think the problem in this case is
that the definition is incomplete; rather, there is some
looseness in the language that describes how expressions work,
glossing over the distinction between abstract values and what
is produced in an actual program that represents such values.
Because the distinction usually isn't important, the Standard
largely ignores it. Is that a big problem? Personally I would
say no: most people understand it without having to think too
hard, and that's probably more important than trying to be
completely precisely accurate if that comes with some loss in
readability or ease of understanding.
I would of course support a proposed change that results in text
that is more precise and equally readable. I just haven't seen
one yet.
Keith Thompson
Jan 25, 2012, 5:56:06 AM1/25/12
to
program.</shameless_handwave>
Will write code for food.
0 new messages