In article <37421291.3A3A8136@wizard.net>,
James Kuyper  <kuyper@wizard.net> wrote:
>
>Joerg Barfurth wrote:
>....
>> IMHO Mr.Aitken has found a hole in the standard. He is clearly aware of clause
>> 5 p.8. His example showed an array rvalue (according to [5.2.5]/p.4). So there
>
>I've been trying to figure out how he concluded that it was an rvalue.
>If that's the relevant section, I don't see how it applies. it mentions
>circumstances in which E1.E2 is an lvalue, but it doesn't say that it's
>an rvalue whenever those circumstances don't hold. It says that E2 is
>not an lvalue if E2 is a non-static member function or a member
>iterator, but we're talking about an array, so those clauses don't
>apply.
>
>

 Interesting question.   The best I can come up with is that I did
it the same way I deduce that 1 || 2 is an rvalue.   Note that by 3.10 p.1
it suffices to show that it is not an lvalue.   3.10 p.4 strongly suggests
(at least to me) that clause 5 is intended to exhaustively list the cases
in which expressions are lvalues.   But it's just a note, and in any case, I
admit that I may be doing too much reading between the lines here.

BTW: Thanks to Mr. Barfurth for pointing out that 4.2 allows coercions
from rvalues of array type: I had missed this change from CD2.
--
William E. Aitken        | Formal verification is the
email: aitken@halcyon.com                   |  future of computer science ---
Snail: 8500 148th Ave NE #H1026 Redmond WA  | Always has been, always will be.
===============================================================================
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

William E. Aitken wrote:
>
> In article <37421291.3A3A8136@wizard.net>,
> James Kuyper  <kuyper@wizard.net> wrote:
> >
> >Joerg Barfurth wrote:
> >....
> >> IMHO Mr.Aitken has found a hole in the standard. He is clearly aware of clause
> >> 5 p.8. His example showed an array rvalue (according to [5.2.5]/p.4). So there
> >
> >I've been trying to figure out how he concluded that it was an rvalue.
> >If that's the relevant section, I don't see how it applies. it mentions
> >circumstances in which E1.E2 is an lvalue, but it doesn't say that it's
> >an rvalue whenever those circumstances don't hold. It says that E2 is
> >not an lvalue if E2 is a non-static member function or a member
> >iterator, but we're talking about an array, so those clauses don't
> >apply.
....
>         Interesting question.   The best I can come up with is that I did
> it the same way I deduce that 1 || 2 is an rvalue.   Note that by 3.10 p.1
> it suffices to show that it is not an lvalue.   3.10 p.4 strongly suggests
> (at least to me) that clause 5 is intended to exhaustively list the cases
> in which expressions are lvalues.   But it's just a note, and in any case, I

It would have been clearer if 3.10 p4 had said that rvalues are
permitted/yielded wherever the standard doesn't explicitly state
otherwise. That's a possible interpretation of the note, but if that's
the intent, it's poorly worded. Reviewing the descriptions of the other
operators, I see that use of the term 'rvalue' is pretty sparse, even in
sections describing operators that I'm positive require/yield rvalues.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <2sJYXNAYsfO3Ewgn@robinton.demon.co.uk>,
Francis Glassborow  <francisG@robinton.demon.co.uk> wrote:
>In article <7hcnsh$pm6$1@halcyon.com>, William E. Aitken
><aitken@halcyon.com> writes
>>int main(int argc, char **argv)
>>{
>>       char rgch;

Ooops.   This should have read
 char rgch[5];

>>
>>       rgch = Foo().rgch; // what stops this from being legal...
>
>Type miss-match?
>
>rgch is of type char while Foo().rgch is char[5] which can decay to
>char *.
>
>

My apologies for any confusion this may have caused.
--
William E. Aitken        | Formal verification is the
email: aitken@halcyon.com                   |  future of computer science ---
Snail: 8500 148th Ave NE #H1026 Redmond WA  | Always has been, always will be.
===============================================================================
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <ucvhdxestd.fsf@soft.mercury.bc.ca>,
Joachim Achtzehnter  <joachim@kraut.bc.ca> wrote:
>aitken@halcyon.com (William E. Aitken) writes:
>>
>> Where is the language to prevent array assignment?
>
>In section 8.3.4 on Arrays you can find a note (item 5):
>
>  Objects of array types cannot be modified, see 3.10.
>
>Section 3.10 doesn't say any more about arrays, however.
>

That makes sense.  Unfortunately paragraph 5 is a note.  I was under
the impression that notes were non-normative.  Was I mistaken?  As you
say, there is nothing else said in 3.10, so the question remains.

--
William E. Aitken        | Formal verification is the
email: aitken@halcyon.com                   |  future of computer science ---
Snail: 8500 148th Ave NE #H1026 Redmond WA  | Always has been, always will be.
===============================================================================


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7hcnsh$pm6$1@halcyon.com>, William E. Aitken
<aitken@halcyon.com> writes
>int main(int argc, char **argv)
>{
>       char rgch;
>
>       rgch = Foo().rgch; // what stops this from being legal...

Type miss-match?

rgch is of type char while Foo().rgch is char[5] which can decay to
char *.



Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Joerg Barfurth wrote:
....
> IMHO Mr.Aitken has found a hole in the standard. He is clearly aware of clause
> 5 p.8. His example showed an array rvalue (according to [5.2.5]/p.4). So there

I've been trying to figure out how he concluded that it was an rvalue.
If that's the relevant section, I don't see how it applies. it mentions
circumstances in which E1.E2 is an lvalue, but it doesn't say that it's
an rvalue whenever those circumstances don't hold. It says that E2 is
not an lvalue if E2 is a non-static member function or a member
iterator, but we're talking about an array, so those clauses don't
apply.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Joerg Barfurth wrote:

>
> > Hyman Rosen <hymie@prolifics.com> writes:
> >
>
> > >In section [Arrays] 8.3.4 paragraph 5, it says
> >
> > >       [Note: conversions affecting lvalues of array type are
> > >       described in 4.2. Objects of array types cannot be
> > >       modified, see 3.10. ]
> >
> The (non-normative) note Mr.Rosen mentions is misleading:

Where does the standard say that the note is non-normative?
I search the standard and found only 17.3.1.1/2 that states that notes and
examples are informative, but is seems to apply only to the library part.

-- Dag Henriksson



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hyman Rosen <hymie@prolifics.com> writes:

>aitken@nwnexus.com writes:
>> It's all very well to assert that arrays aren't first class objects.
>> I *know* that's the way things *should* be for C/C++.  What I'm
>> asking is where does the standard say this.

>In section [Arrays] 8.3.4 paragraph 5, it says

> [Note: conversions affecting lvalues of array type are
> described in 4.2. Objects of array types cannot be
> modified, see 3.10. ]

See also clause 5 paragraph 8:
"Whenever an lvalue expression appears as an operand of an operator
that expects an rvalue for that operand, the lvalue-to-rvalue (4.1),
array-to-pointer (4.2), or function-to-pointer (4.3) standard
conversions are applied to convert the expression to an rvalue."

--
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7hcnsh$pm6$1@halcyon.com>,
  aitken@halcyon.com (William E. Aitken) wrote:

> Where is the language to prevent array assignment?

> In particular, 5.17 only seems to require that the left argument
> be a modifiable lvalue. Arrays are certainly lvalues,
Yes they are. I found this surprising.

> and I can't seem to find any language that says they
> aren't modifiable.

> The right argument needs to be implicitly converted to the type
[snip]
> But what if it already has the correct type and lvalueness?
> That is, what if the right hand side is an array rvalue?
> Then it seems that the assignment is okay.

This text seems to be arguing for this:

    char foo[] = "Foo";
    char bar[] = "Bar";
    foo = bar;

I am certain that this was never intended to be legal, even
though I couldn't find the appropriate section of the standard.

> To be concrete, consider this code:
>
> struct FOO {
>  char rgch[5];
> };
>
> FOO Foo() {
>  FOO foo = {'a', 'b', 'c', 'd', 'e'};
>  return foo;
> }
>
> int main(int argc, char **argv)
> {
>  char rgch;
>
>  rgch = Foo().rgch; // what stops this from being legal...

Well, for starters, main's auto "rgch" is a char while FOO's
member "rgch" is an array of 5 chars.

You seem to be confusing the idea of an array with the idea
of a structure that CONTAINS an array. Let me give a different
example that is not controversial:

    struct Bar {
        char data[16];
        bool operator==(const Bar&) const;
    };
    void baz() {
        Bar bar1, bar2, bar3;
        // ...
        if (bar1==bar2)
            bar3=bar2;
        else
            bar2=bar3;
        // ...
    }
This is 100% legal, but it doesn't address your original
question (assignment of arrays) because it demonstrates
assignment of structures.

Let's go back and change your example. I'll assume that you
meant this:

    int main(int argc, char**argv) {
        char rgch[5];
        rgch = Foo().rgch;
    }

Now, somewhere in the standard there's some verbage that makes
this illegal. I think it's somewhere in section 3 or 4, but I
haven't found it (yet).

----
Allan_W@my-dejanews.com is a "Spam Magnet" --
never read.


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

clamage@eng.sun.com (Steve Clamage) writes:
> See also clause 5 paragraph 8:
> "Whenever an lvalue expression appears as an operand of an operator
> that expects an rvalue for that operand, the lvalue-to-rvalue (4.1),
> array-to-pointer (4.2), or function-to-pointer (4.3) standard
> conversions are applied to convert the expression to an rvalue."

That's irrelevant, because section 5.17 [expr.ass] (Assignment operators)
nowhere says that the right operand must be an rvalue! It does say that
if the left operand is not of class type, then the right operand is
implicitly converted to that type. However, 4 [conv] (Standard conversions)
allows this implicit conversion to consist of the application of zero
conversion rules. So this would not prohibit the assignment of arrays.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage wrote:
>
> Hyman Rosen <hymie@prolifics.com> writes:
>
> >aitken@nwnexus.com writes:
> >> It's all very well to assert that arrays aren't first class objects.
> >> I *know* that's the way things *should* be for C/C++.  What I'm
> >> asking is where does the standard say this.
>
> >In section [Arrays] 8.3.4 paragraph 5, it says
>
> >       [Note: conversions affecting lvalues of array type are
> >       described in 4.2. Objects of array types cannot be
> >       modified, see 3.10. ]
>
> See also clause 5 paragraph 8:
> "Whenever an lvalue expression appears as an operand of an operator
> that expects an rvalue for that operand, the lvalue-to-rvalue (4.1),
> array-to-pointer (4.2), or function-to-pointer (4.3) standard
> conversions are applied to convert the expression to an rvalue."

IMHO Mr.Aitken has found a hole in the standard. He is clearly aware of clause
5 p.8. His example showed an array rvalue (according to [5.2.5]/p.4). So there
is no lvalue to be converted. In fact no conversion is necessary to obtain an
rvalue as expected for the operand.

The (non-normative) note Mr.Rosen mentions is misleading:
- 4.2 allows hhe array-to-pointer standard conversion not only for lvalues,
but also for rvalues. This doesn't make a difference here though - [5] p.8 is
about lvalues in expressions only.
- 3.10 doesn't say anything to the effect that arrays cannot be modified. It
explicitly states (p.11) that "Functions cannot be modified." While functions
resemble arrays in being automagically converted to pointers when they appear
in an expression, they still need this explicit statement. There is no such
statement for arrays.

The only place I could find that would not allow assignment from an rvalue of
array type to a (non-const) lvalue of the same type is section 13.6.
In paragraphs 18-20 which cover the builtin assignment operators, there is no
signatore that would allow an assignment of array types. But afaics 13.6 is
intended to make explicit the signatures that can be inferred from clause 5
for the purpose of overload resolution. It should therefore not be normative
with respect to builtin operators, except as their effect on overload
resolution is concerned.

So I join Mr.Aitken: Where does the standard say that
- either lvalues of array type cannot be modified
- or one cannot assign to such an lvalue, even if an appropriate rvalue (of
the same type) can be provided


-- J   rg Barfurth


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

 Where is the language to prevent array assignment?   In particular,
5.17 only seems to require that the left argument be a modifiable lvalue.
Arrays are certainly lvalues, and I can't seem to find any language that says
they aren't modifiable.   The right argument needs to be implicitly converted
to the type of the left argument (minus the cv qualifiers), and since nothing
is said about it being an lvalue, it needs to be converted to an rvalue.   This
seems to be enough to prevent most naive attempts to assign arrays: if the
right expression doesn't have the correct type, or is an lvalue the assignment
won't go through because there are no implicit coercions that result in
array rvalues (not even user defined, because functions can't return arrays).
But what if it already has the correct type and lvalueness?   That is, what
if the right hand side is an array rvalue?    Then it seems that the
assignment is okay.   To be concrete, consider this code:

struct FOO {
 char rgch[5];
};

FOO Foo() {
 FOO foo = {'a', 'b', 'c', 'd', 'e'};
 return foo;
}

int main(int argc, char **argv)
{
 char rgch;

 rgch = Foo().rgch; // what stops this from being legal...
 /* note that Foo() is an rvalue, thus Foo().rgch is an array rvalue */
}

   Am I missing something?


--
William E. Aitken        | Formal verification is the
email: aitken@halcyon.com                   |  future of computer science ---
Snail: 8500 148th Ave NE #H1026 Redmond WA  | Always has been, always will be.
===============================================================================


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

aitken@halcyon.com (William E. Aitken) writes:
>
> Where is the language to prevent array assignment?

In section 8.3.4 on Arrays you can find a note (item 5):

  Objects of array types cannot be modified, see 3.10.

Section 3.10 doesn't say any more about arrays, however.

Joachim

--
joachim@kraut.bc.ca      (http://www.kraut.bc.ca)
joachim@mercury.bc.ca    (http://www.mercury.bc.ca)
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

aitken@halcyon.com (William E. Aitken) writes:

> Where is the language to prevent array assignment?   In particular,
>5.17 only seems to require that the left argument be a modifiable lvalue.
>Arrays are certainly lvalues, and I can't seem to find any language that says
>they aren't modifiable.   The right argument needs to be implicitly converted
>to the type of the left argument (minus the cv qualifiers), and since nothing
>is said about it being an lvalue, it needs to be converted to an rvalue.

Since an array is not a class type, 5.17 says the usual conversions
are applied, meaning that the array is converted to a pointer to its
first element. You wind up with what would be pointer assignment, not
array assignment, assuming the pointer assignment would be allowed.
Normally it would not:
    int a1[10];
    int a2[10];
    a1 = a2;
You'd try to assign &a2[0] to a1 itself, which is not allowed.

Arrays are not first-class objects. When an array appears in an
expression or as a function parameter, it is converted to a pointer.

--
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7hfd6q$ok2$1@engnews1.eng.sun.com>,
Steve Clamage <clamage@eng.sun.com> wrote:
>aitken@halcyon.com (William E. Aitken) writes:
>
>> Where is the language to prevent array assignment?   In particular,
>>5.17 only seems to require that the left argument be a modifiable lvalue.
>>Arrays are certainly lvalues, and I can't seem to find any language that says
>>they aren't modifiable.   The right argument needs to be implicitly converted
>>to the type of the left argument (minus the cv qualifiers), and since nothing
>>is said about it being an lvalue, it needs to be converted to an rvalue.
>
>Since an array is not a class type, 5.17 says the usual conversions
>are applied, meaning that the array is converted to a pointer to its
>first element. You wind up with what would be pointer assignment, not
>array assignment, assuming the pointer assignment would be allowed.
>Normally it would not:
>    int a1[10];
>    int a2[10];
>    a1 = a2;
>You'd try to assign &a2[0] to a1 itself, which is not allowed.
>
>Arrays are not first-class objects. When an array appears in an
>expression or as a function parameter, it is converted to a pointer.
>
>--

 Not so fast.   Array *lvalues* are converted to pointers to their first
element.   In the example that was in my post, I attempted to assign an
rvalue of type array of 5 chars to a variable of the same type.   Here's
roughly what I had.

struct FOO {
 char rgch[5];
};

FOO Foo();

int main(int argc, char **argv)
{
 char rgch[5];

 rgch = Foo().rgch; // what stops this from being legal...
 /* note that Foo() is an rvalue, thus Foo().rgch is an array rvalue */
}

There isn't any need to do anything to the RHS to make it an rvalue of
type array of 5 chars, already is one.  Paragraph 1 of clause 4 makes
it fairly clear that an empty sequence of conversions is a standard
conversion sequence.   So 5.17 paragraph 3 can't be the answer.

It's all very well to assert that arrays aren't first class objects.   I *know*
that's the way things *should* be for C/C++.   What I'm asking is where does
the standard say this.
--
William E. Aitken        | Formal verification is the
email: aitken@halcyon.com                   |  future of computer science ---
Snail: 8500 148th Ave NE #H1026 Redmond WA  | Always has been, always will be.
===============================================================================
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7hfd6q$ok2$1@engnews1.eng.sun.com>,
Steve Clamage <clamage@eng.sun.com> wrote:
>aitken@halcyon.com (William E. Aitken) writes:
>
>> Where is the language to prevent array assignment?   In particular,
>>5.17 only seems to require that the left argument be a modifiable lvalue.
>>Arrays are certainly lvalues, and I can't seem to find any language that says
>>they aren't modifiable.   The right argument needs to be implicitly converted
>>to the type of the left argument (minus the cv qualifiers), and since nothing
>>is said about it being an lvalue, it needs to be converted to an rvalue.
>
>Since an array is not a class type, 5.17 says the usual conversions
>are applied, meaning that the array is converted to a pointer to its
>first element. You wind up with what would be pointer assignment, not
>array assignment, assuming the pointer assignment would be allowed.
>Normally it would not:
>    int a1[10];
>    int a2[10];
>    a1 = a2;
>You'd try to assign &a2[0] to a1 itself, which is not allowed.
>
>Arrays are not first-class objects. When an array appears in an
>expression or as a function parameter, it is converted to a pointer.
>
>--

 Not so fast.   Array *lvalues* are converted to pointers to their first
element.   In the example that was in my post, I attempted to assign an
rvalue of type array of 5 chars to a variable of the same type.   Here's
roughly what I had.

struct FOO {
 char rgch[5];
};

FOO Foo();

int main(int argc, char **argv)
{
 char rgch[5];

 rgch = Foo().rgch; // what stops this from being legal...
 /* note that Foo() is an rvalue, thus Foo().rgch is an array rvalue */
}

There isn't any need to do anything to the RHS to make it an rvalue of
type array of 5 chars, already is one.  Paragraph 1 of clause 4 makes
it fairly clear that an empty sequence of conversions is a standard
conversion sequence.   So 5.17 paragraph 3 can't be the answer.

It's all very well to assert that arrays aren't first class objects.   I *know*
that's the way things *should* be for C/C++.   What I'm asking is where does
the standard say this.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

aitken@nwnexus.com writes:
> It's all very well to assert that arrays aren't first class objects.
> I *know* that's the way things *should* be for C/C++.  What I'm
> asking is where does the standard say this.

In section [Arrays] 8.3.4 paragraph 5, it says

 [Note: conversions affecting lvalues of array type are
 described in 4.2. Objects of array types cannot be
 modified, see 3.10. ]


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <t7675ve1uj.fsf@calumny.jyacc.com>,
Hyman Rosen  <hymie@prolifics.com> wrote:
>
>aitken@nwnexus.com writes:
>> It's all very well to assert that arrays aren't first class objects.
>> I *know* that's the way things *should* be for C/C++.  What I'm
>> asking is where does the standard say this.
>
>In section [Arrays] 8.3.4 paragraph 5, it says
>
> [Note: conversions affecting lvalues of array type are
> described in 4.2. Objects of array types cannot be
> modified, see 3.10. ]
>
>

 That seems reasonable.    Is it normative?   I had been under the
impression that notes (and examples and footnotes) were non-normative.
Was I mistaken?

--
William E. Aitken        | Formal verification is the
email: aitken@halcyon.com                   |  future of computer science ---
Snail: 8500 148th Ave NE #H1026 Redmond WA  | Always has been, always will be.
===============================================================================


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]