Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Am i just blind? Is "array = array;" allowed?

Reply
Thread Tools

Am i just blind? Is "array = array;" allowed?

 
 
Johannes Schaub (litb)
Guest
Posts: n/a
 
      08-27-2010
I really can't find where the Standard forbids the following!

int a[2] = { 1, 2 };
int b[2];
b = a;

I thought somewhere the Standard says that lvalue expressions of array type
are nonmodifiable, but I can't find it!

Any insights?
 
Reply With Quote
 
 
 
 
Goran Pusic
Guest
Posts: n/a
 
      08-27-2010
On Aug 27, 4:02*pm, "Johannes Schaub (litb)" <(E-Mail Removed)>
wrote:
> I really can't find where the Standard forbids the following!
>
> * int a[2] = { 1, 2 };
> * int b[2];
> * b = a;
>
> I thought somewhere the Standard says that lvalue expressions of array type
> are nonmodifiable, but I can't find it!


No idea about what standard might think, but if it did think
something, it would still sound like a silly arbitrary constraint.
What would be the rationale to prevent said assignment?

Goran.
 
Reply With Quote
 
 
 
 
Jonathan Lee
Guest
Posts: n/a
 
      08-27-2010
On Aug 27, 9:02*am, "Johannes Schaub (litb)" <(E-Mail Removed)>
wrote:
> I really can't find where the Standard forbids the following!
>
> * int a[2] = { 1, 2 };
> * int b[2];
> * b = a;
>
> I thought somewhere the Standard says that lvalue expressions of array type
> are nonmodifiable, but I can't find it!
>
> Any insights?


In [dcl.array]

5. [Node: conversions affecting lvalues of array type are described in
4.2. Objects of array types cannot be modified, see 3.10 -- end note]

--Jonathan
 
Reply With Quote
 
Johannes Schaub (litb)
Guest
Posts: n/a
 
      08-27-2010
Jonathan Lee wrote:

> On Aug 27, 9:02 am, "Johannes Schaub (litb)" <(E-Mail Removed)>
> wrote:
>> I really can't find where the Standard forbids the following!
>>
>> int a[2] = { 1, 2 };
>> int b[2];
>> b = a;
>>
>> I thought somewhere the Standard says that lvalue expressions of array
>> type are nonmodifiable, but I can't find it!
>>
>> Any insights?

>
> In [dcl.array]
>
> 5. [Node: conversions affecting lvalues of array type are described in
> 4.2. Objects of array types cannot be modified, see 3.10 -- end note]
>


Sorry, i can't accept a note. I am looking for normative wording. Is there
any?
 
Reply With Quote
 
Alf P. Steinbach /Usenet
Guest
Posts: n/a
 
      08-27-2010
* Johannes Schaub (litb), on 27.08.2010 16:31:
> Jonathan Lee wrote:
>
>> On Aug 27, 9:02 am, "Johannes Schaub (litb)"<(E-Mail Removed)>
>> wrote:
>>> I really can't find where the Standard forbids the following!
>>>
>>> int a[2] = { 1, 2 };
>>> int b[2];
>>> b = a;
>>>
>>> I thought somewhere the Standard says that lvalue expressions of array
>>> type are nonmodifiable, but I can't find it!
>>>
>>> Any insights?

>>
>> In [dcl.array]
>>
>> 5. [Node: conversions affecting lvalues of array type are described in
>> 4.2. Objects of array types cannot be modified, see 3.10 -- end note]
>>

>
> Sorry, i can't accept a note. I am looking for normative wording. Is there
> any?


I don't think so, but I think it was intended.

C++98 5/8 says that an array is converted to pointer when it's used where an
rvalue is expected.

Then 5.17/2 talks about the "value" of the right hand side of an assignment.



Cheers & hth.,

- Alf

--
blog at <url: http://alfps.wordpress.com>
 
Reply With Quote
 
Johannes Schaub (litb)
Guest
Posts: n/a
 
      08-27-2010
Christian Hackl wrote:

> Johannes Schaub (litb) ha scritto:
>
>> I really can't find where the Standard forbids the following!
>>
>> int a[2] = { 1, 2 };
>> int b[2];
>> b = a;

>
> It should not compile. Does it on your compiler? I guess you are just
> the victim of some proprietary extension.
>


It compiles with my built-in biological compiler. It needs fixing my being
pointed to a normative text! AHAHAHA
 
Reply With Quote
 
Johannes Schaub (litb)
Guest
Posts: n/a
 
      08-27-2010
Alf P. Steinbach /Usenet wrote:

> * Johannes Schaub (litb), on 27.08.2010 16:31:
>> Jonathan Lee wrote:
>>
>>> On Aug 27, 9:02 am, "Johannes Schaub (litb)"<(E-Mail Removed)>
>>> wrote:
>>>> I really can't find where the Standard forbids the following!
>>>>
>>>> int a[2] = { 1, 2 };
>>>> int b[2];
>>>> b = a;
>>>>
>>>> I thought somewhere the Standard says that lvalue expressions of array
>>>> type are nonmodifiable, but I can't find it!
>>>>
>>>> Any insights?
>>>
>>> In [dcl.array]
>>>
>>> 5. [Node: conversions affecting lvalues of array type are described in
>>> 4.2. Objects of array types cannot be modified, see 3.10 -- end note]
>>>

>>
>> Sorry, i can't accept a note. I am looking for normative wording. Is
>> there any?

>
> I don't think so, but I think it was intended.
>
> C++98 §5/8 says that an array is converted to pointer when it's used where
> an rvalue is expected.
>
> Then §5.17/2 talks about the "value" of the right hand side of an
> assignment.
>


Ohh i see now. So i guess it does the array-to-pointer conversion of the
right side, and then tries to convert "T*" to "T[N]" but since there is no
such implicit conversion, it fails hard. Thanks for the insights
 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      08-27-2010
Goran Pusic <(E-Mail Removed)> wrote:
> On Aug 27, 4:02*pm, "Johannes Schaub (litb)" <(E-Mail Removed)>
> wrote:
>> I really can't find where the Standard forbids the following!
>>
>> * int a[2] = { 1, 2 };
>> * int b[2];
>> * b = a;
>>
>> I thought somewhere the Standard says that lvalue expressions of array type
>> are nonmodifiable, but I can't find it!

>
> No idea about what standard might think, but if it did think
> something, it would still sound like a silly arbitrary constraint.
> What would be the rationale to prevent said assignment?


It's not arbitrary at all, and there is a perfectly good rationale
which can be derived from the definition of arrays.

Arrays effectively act as const pointers (in other words "int* const"),
the only exception being that the sizeof() operator returns the space
taken by the entire array rather than the size of a pointer. (I know this
is simplifying quite a lot, and there are probably other examples where
they don't actually act like const pointers, but you get the idea.)

So you can think of "b = a;" as the attempt to modify 'b' to make it
point to the same place as 'a' is pointing to (because that's what pointer
assignment does). However, 'b' is const, so you can't modify it to point
anywhere else.

Of course one could argue that the language should make an exception
to this general principle in the case where you are assigning an array to
another of the same type and size, and make it instead assign the contents
of the array to the other array. I don't know, however, if the
standardization committee had a reason to not impose such an exception
to the general rule (and we are probably talking about the C standardization
committee here, as this limitation is probably coming from C).
 
Reply With Quote
 
Johannes Schaub (litb)
Guest
Posts: n/a
 
      08-27-2010
Juha Nieminen wrote:

> Goran Pusic <(E-Mail Removed)> wrote:
>> On Aug 27, 4:02 pm, "Johannes Schaub (litb)" <(E-Mail Removed)>
>> wrote:
>>> I really can't find where the Standard forbids the following!
>>>
>>> int a[2] = { 1, 2 };
>>> int b[2];
>>> b = a;
>>>
>>> I thought somewhere the Standard says that lvalue expressions of array
>>> type are nonmodifiable, but I can't find it!

>>
>> No idea about what standard might think, but if it did think
>> something, it would still sound like a silly arbitrary constraint.
>> What would be the rationale to prevent said assignment?

>
> It's not arbitrary at all, and there is a perfectly good rationale
> which can be derived from the definition of arrays.
>
> Arrays effectively act as const pointers (in other words "int* const"),
> the only exception being that the sizeof() operator returns the space
> taken by the entire array rather than the size of a pointer. (I know this
> is simplifying quite a lot, and there are probably other examples where
> they don't actually act like const pointers, but you get the idea.)
>
> So you can think of "b = a;" as the attempt to modify 'b' to make it
> point to the same place as 'a' is pointing to (because that's what pointer
> assignment does). However, 'b' is const, so you can't modify it to point
> anywhere else.
>
> Of course one could argue that the language should make an exception
> to this general principle in the case where you are assigning an array to
> another of the same type and size, and make it instead assign the contents
> of the array to the other array. I don't know, however, if the
> standardization committee had a reason to not impose such an exception
> to the general rule (and we are probably talking about the C
> standardization committee here, as this limitation is probably coming from
> C).


I would argue the entire other way around, and make the pointer behavior a
"special case":

>>>>

Arrays are a container for N elements of the same type. In cases where array
elements need to be addressed, a pointer to the array is created.

Assigning an array to another array will take N elements from the source
array and copy it over.
<<<<<<<


You can apply your same sayings to any variable:

>>>>>>

In general, an "int" variable effectively acts as a const pointer (in other
words: "int *const") the only exception being that sizeof... .

So you can think of "a = b;" as the attempt to modify "a" to make it point
to the same place as "b" is pointing to (because thats what pointer
assignment does). However, 'a' is const, so you can't modify it to point
anywhere else.

Of course, one could argue .... and make it instead assign the contents of
the int to the other int. I don't know, however, ... .
<<<<<<

 
Reply With Quote
 
Andrey Tarasevich
Guest
Posts: n/a
 
      08-27-2010
Johannes Schaub (litb) wrote:
>> I don't think so, but I think it was intended.
>>
>> C++98 §5/8 says that an array is converted to pointer when it's used where
>> an rvalue is expected.
>>
>> Then §5.17/2 talks about the "value" of the right hand side of an
>> assignment.
>>

>
> Ohh i see now. So i guess it does the array-to-pointer conversion of the
> right side, and then tries to convert "T*" to "T[N]" but since there is no
> such implicit conversion, it fails hard. Thanks for the insights


Well, I would also expect this assignment to be "disabled" in C++ by a
different rule: array-to-pointer conversion on the RHS operand.

The 5/9 does indeed say that array-to-pointer conversion is applied when
an rvalue operand is expected.

Descriptions of various operators normally explicitly state whether a
given operand is expected/required to be an lvalue or an rvalue.
However, the description of the assignment operator only has the
requirements for the LHS operand. No requirement for the RHS is present
there.

So, where does it say that built-in assignment expects an rvalue on the
RHS??? I don't see it stated anywhere.

--
Best regards,
Andrey Tarasevich
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Is it just me or just Microsoft? Ark Khasin C++ 24 07-16-2007 11:11 AM
How do I clean a virus within an inbox or just clean only that infectedattachment or LOCATE AND delete just that attachment ? Vinayak Firefox 1 08-14-2006 06:19 PM
Is there a Python MVC that works just as well with just CGI, or FCGI? walterbyrd Python 1 04-10-2006 07:57 PM
allow you to move just about any music to your iPud, MP3 player , or just burn it to disk sbcmynews Computer Support 4 05-01-2005 03:53 PM
Just bought a Digital Rebel just 1 question RacerX Digital Photography 7 11-21-2003 01:51 PM



Advertisments