Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #12875 > unrolled thread

Array of Integers ?

Back to article view | Back to comp.lang.c

Contents

  Array of Integers ? arnuld <sunrise@invalid.address> - 2011-11-08 07:51 +0000
    Re: Array of Integers ? Ike Naar <ike@iceland.freeshell.org> - 2011-11-08 08:11 +0000
    Re: Array of Integers ? jacob navia <jacob@spamsink.net> - 2011-11-08 09:14 +0100
      Re: Array of Integers ? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-08 00:23 -0800
        Re: Array of Integers ? pete <pfiland@mindspring.com> - 2011-11-08 04:07 -0500
      Re: Array of Integers ? tom st denis <tom@iahu.ca> - 2011-11-08 06:23 -0800
        Re: Array of Integers ? "Scott Fluhrer" <sfluhrer@ix.netcom.com> - 2011-11-08 10:08 -0500
        Re: Array of Integers ? Noob <root@127.0.0.1> - 2011-11-08 16:25 +0100
          Re: Array of Integers ? bks@panix.com (Bradley K. Sherman) - 2011-11-08 15:39 +0000
          Re: Array of Integers ? Keith Thompson <kst-u@mib.org> - 2011-11-08 13:48 -0800
            Re: Array of Integers ? Keith Thompson <kst-u@mib.org> - 2011-11-09 19:34 -0800
        Re: Array of Integers ? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-08 06:59 -0800
        Re: Array of Integers ? jacob navia <jacob@spamsink.net> - 2011-11-08 22:48 +0100
      Re: Array of Integers ? Chad <cdalten@gmail.com> - 2011-11-08 07:12 -0800
        Re: Array of Integers ? pete <pfiland@mindspring.com> - 2011-11-08 11:49 -0500
        Re: Array of Integers ? James Kuyper <jameskuyper@verizon.net> - 2011-11-08 12:13 -0500
        Re: Array of Integers ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-08 21:45 +0000
          Re: Array of Integers ? James Kuyper <jameskuyper@verizon.net> - 2011-11-08 16:48 -0500
            Re: Array of Integers ? Keith Thompson <kst-u@mib.org> - 2011-11-08 14:25 -0800
            Re: Array of Integers ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-08 22:42 +0000
          Re: Array of Integers ? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-10 12:01 +0200
            Re: Array of Integers ? Keith Thompson <kst-u@mib.org> - 2011-11-10 03:14 -0800
              Re: Array of Integers ? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-10 17:41 +0200
                Re: Array of Integers ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-10 16:44 +0000
                  Re: Array of Integers ? Keith Thompson <kst-u@mib.org> - 2011-11-10 10:59 -0800
                  Re: Array of Integers ? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-11 17:49 +0200
        Re: Array of Integers ? Keith Thompson <kst-u@mib.org> - 2011-11-08 14:00 -0800
          Re: Array of Integers ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-09 00:57 +0000
            Re: Array of Integers ? pete <pfiland@mindspring.com> - 2011-11-09 00:05 -0500
              Re: Array of Integers ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-09 11:06 +0000
                Re: Array of Integers ? Keith Thompson <kst-u@mib.org> - 2011-11-09 13:36 -0800
                  Re: Array of Integers ? Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-25 00:45 -0800
                    Re: Array of Integers ? Keith Thompson <kst-u@mib.org> - 2012-01-25 02:56 -0800
                Re: Array of Integers ? pete <pfiland@mindspring.com> - 2011-11-09 18:34 -0500
                  Re: Array of Integers ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-10 00:57 +0000
            Re: Array of Integers ? Keith Thompson <kst-u@mib.org> - 2011-11-08 22:14 -0800
              Re: Array of Integers ? Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-25 01:46 -0800
    Re: Array of Integers ? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-08 01:39 -0800
      Re: Array of Integers ? Keith Thompson <kst-u@mib.org> - 2011-11-08 14:05 -0800
    Re: Array of Integers ? James Kuyper <jameskuyper@verizon.net> - 2011-11-08 06:19 -0500

Page 2 of 2 — ← Prev page 1 [2]

#13008

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Chad <cdalten@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.

Phil
-- 
Unix is simple. It just takes a genius to understand its simplicity
-- Dennis Ritchie (1941-2011), Unix Co-Creator

[toc] | [prev] | [next] | [standalone]

#13012

Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Chad <cdalten@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.

-- 
Keith Thompson (The_Other_Keith) kst-u@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"

[toc] | [prev] | [next] | [standalone]

#13027

Keith Thompson <kst-u@mib.org> writes:
> Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
> > Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> >> Chad <cdalten@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.

Compound literals can be arrays and have values too, I'm surprised nobody's used them 
as an example yet.

Phil
-- 
Unix is simple. It just takes a genius to understand its simplicity
-- Dennis Ritchie (1941-2011), Unix Co-Creator

[toc] | [prev] | [next] | [standalone]

#13029

Phil Carmody <thefatphil_demunged@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).  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.

[toc] | [prev] | [next] | [standalone]

#13039

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Phil Carmody <thefatphil_demunged@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).  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.

The way I prefer to think of it is that array values are just as
"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.

-- 
Keith Thompson (The_Other_Keith) kst-u@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"

[toc] | [prev] | [next] | [standalone]

#13095

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Phil Carmody <thefatphil_demunged@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
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!

Phil
-- 
Unix is simple. It just takes a genius to understand its simplicity
-- Dennis Ritchie (1941-2011), Unix Co-Creator

[toc] | [prev] | [next] | [standalone]

#12914

Chad <cdalten@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.  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 (The_Other_Keith) kst-u@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"

[toc] | [prev] | [next] | [standalone]

#12937

Keith Thompson <kst-u@mib.org> writes:

> Chad <cdalten@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
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.

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.

> 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.

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.

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.

[toc] | [prev] | [next] | [standalone]

#12939

Ben Bacarisse wrote:
> 
> Keith Thompson <kst-u@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.

-- 
pete

[toc] | [prev] | [next] | [standalone]

#12948

pete <pfiland@mindspring.com> writes:

> Ben Bacarisse wrote:
>> 
>> Keith Thompson <kst-u@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.

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.

[toc] | [prev] | [next] | [standalone]

#12984

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> pete <pfiland@mindspring.com> writes:
>> Ben Bacarisse wrote:
>>> Keith Thompson <kst-u@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.
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.

Given:

    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.

-- 
Keith Thompson (The_Other_Keith) kst-u@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"

[toc] | [prev] | [next] | [standalone]

#16182

Keith Thompson <kst-u@mib.org> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> pete <pfiland@mindspring.com> writes:
>>> Ben Bacarisse wrote:
>>>> Keith Thompson <kst-u@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]

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.

[toc] | [prev] | [next] | [standalone]

#16187

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> pete <pfiland@mindspring.com> writes:
>>>> Ben Bacarisse wrote:
>>>>> Keith Thompson <kst-u@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]
>
> 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.

<shameless_handwave>I was talking about the *abstract* running
program.</shameless_handwave>

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#12993

Ben Bacarisse wrote:
> 
> pete <pfiland@mindspring.com> writes:
> 
> > Ben Bacarisse wrote:
> >>
> >> Keith Thompson <kst-u@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.
> 
> 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.

It doesn't matter whether the verb is "specify" or "designates".
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

[toc] | [prev] | [next] | [standalone]

#12994

pete <pfiland@mindspring.com> writes:

> Ben Bacarisse wrote:
>> 
>> pete <pfiland@mindspring.com> writes:
>> 
>> > Ben Bacarisse wrote:
>> >>
>> >> Keith Thompson <kst-u@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.
>> 
>> 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.
>
> It doesn't matter whether the verb is "specify" or "designates".
> 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.

Okay, okay, I give in!  C has array values.

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.

[toc] | [prev] | [next] | [standalone]

#12941

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Chad <cdalten@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
> 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
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.

The footnote says:

    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.

Array values do not show up during expression evaluation.  But (I
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.

-- 
Keith Thompson (The_Other_Keith) kst-u@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"

[toc] | [prev] | [next] | [standalone]

#16183

Keith Thompson <kst-u@mib.org> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Chad <cdalten@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
>> 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
> 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*.  [snip..snip..snip]
>
> 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]

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.

[toc] | [prev] | [next] | [standalone]

#12881

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. 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

[toc] | [prev] | [next] | [standalone]

#12915

Malcolm McLean <malcolm.mclean5@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?

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.

Yes.  An array of integers is also an object itself.  Given:

    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 (The_Other_Keith) kst-u@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"

[toc] | [prev] | [next] | [standalone]

#12884

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
shorthand for "array of objects of integer type"; the distinction he's
trying to make is pointless.
-- 
James Kuyper

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web