Prev: read the last n lines of a file or reverse
Next: Template function in template class
From: Ben Bacarisse on 26 May 2008 11:57
Barry Schwarz <schwarzb(a)dqel.com> writes:

> On Wed, 21 May 2008 04:44:12 +0200 (CEST), Anand Hariharan
> <znvygb.nanaq.unevunena(a)tznvy.pbz> wrote:
>
>>On Wed, 14 May 2008 18:32:05 +0000, Richard Heathfield wrote:
>>
>>> Aggro said:
>>>
>>>> Ben Bacarisse wrote:
>>>>
>>>>> The second case is the "normal" one so I assume you know why that one
>>>>> is fine! (The name of the array -- an array-valued expression -- is
>>>>> converted to a pointer to its first element and then that is converted
>>>>> to a void * for memset.)
>>>>
>>>> So both usr_data and &usr_data are converted into &usr_data[0] by the
>>>> compiler?
>>>
>>> No. usr_data is converted to &usr_data[0]
>>
>>Is that true? I thought usr_data[0] implies a dereference, hence
>>&usr_data[0] is better expressed as &(*(usr_data)) rather than usr_data.
>
> If the value of the array elements were indeterminate, your "better
> expression" would lead to undefined behavior since *(usr_data)
> requires evaluation of usr_data[0].

I don't think either one does. Section 6.5.3.2 (Address and
indirection operators) says about &:

"If the operand is the result of a unary * operator, neither that
operator nor the & operator is evaluated and the result is as if
both were omitted..."

&usr_data[0] is &*(usr_data+0) is &*usr_data is usr_data.

--
Ben.
From: Francis Glassborow on 26 May 2008 14:39
Ben Bacarisse wrote:
> Barry Schwarz <schwarzb(a)dqel.com> writes:
>
>> On Wed, 21 May 2008 04:44:12 +0200 (CEST), Anand Hariharan
>> <znvygb.nanaq.unevunena(a)tznvy.pbz> wrote:
>>
>>> On Wed, 14 May 2008 18:32:05 +0000, Richard Heathfield wrote:
>>>
>>>> Aggro said:
>>>>
>>>>> Ben Bacarisse wrote:
>>>>>
>>>>>> The second case is the "normal" one so I assume you know why that one
>>>>>> is fine! (The name of the array -- an array-valued expression -- is
>>>>>> converted to a pointer to its first element and then that is converted
>>>>>> to a void * for memset.)
>>>>> So both usr_data and &usr_data are converted into &usr_data[0] by the
>>>>> compiler?
>>>> No. usr_data is converted to &usr_data[0]
>>> Is that true? I thought usr_data[0] implies a dereference, hence
>>> &usr_data[0] is better expressed as &(*(usr_data)) rather than usr_data.
>> If the value of the array elements were indeterminate, your "better
>> expression" would lead to undefined behavior since *(usr_data)
>> requires evaluation of usr_data[0].
>
> I don't think either one does. Section 6.5.3.2 (Address and
> indirection operators) says about &:
>
> "If the operand is the result of a unary * operator, neither that
> operator nor the & operator is evaluated and the result is as if
> both were omitted..."
>
> &usr_data[0] is &*(usr_data+0) is &*usr_data is usr_data.
>

Exactly and we cannot do that in C++ because operator & may have been
overloaded for a class type.
From: Keith Thompson on 26 May 2008 17:14
Francis Glassborow <francis.glassborow(a)btinternet.com> writes:
> Ben Bacarisse wrote:
>> Barry Schwarz <schwarzb(a)dqel.com> writes:
>>
>>> On Wed, 21 May 2008 04:44:12 +0200 (CEST), Anand Hariharan
>>> <znvygb.nanaq.unevunena(a)tznvy.pbz> wrote:
>>>
>>>> On Wed, 14 May 2008 18:32:05 +0000, Richard Heathfield wrote:
>>>>
>>>>> Aggro said:
>>>>>
>>>>>> Ben Bacarisse wrote:
>>>>>>
>>>>>>> The second case is the "normal" one so I assume you know why that one
>>>>>>> is fine! (The name of the array -- an array-valued expression -- is
>>>>>>> converted to a pointer to its first element and then that is converted
>>>>>>> to a void * for memset.)
>>>>>> So both usr_data and &usr_data are converted into &usr_data[0] by the
>>>>>> compiler?
>>>>> No. usr_data is converted to &usr_data[0]
>>>> Is that true? I thought usr_data[0] implies a dereference, hence
>>>> &usr_data[0] is better expressed as &(*(usr_data)) rather than usr_data.
>>> If the value of the array elements were indeterminate, your "better
>>> expression" would lead to undefined behavior since *(usr_data)
>>> requires evaluation of usr_data[0].
>> I don't think either one does. Section 6.5.3.2 (Address and
>> indirection operators) says about &:
>> "If the operand is the result of a unary * operator, neither that
>> operator nor the & operator is evaluated and the result is as if
>> both were omitted..."
>> &usr_data[0] is &*(usr_data+0) is &*usr_data is usr_data.
>
> Exactly and we cannot do that in C++ because operator & may have been
> overloaded for a class type.

But the compiler certainly knows whether it's been overloaded or not.
The C++ standard could easily have the same rule, and have it apply
only to the built-in "&" and "*" operators. Does it not do so?

--
Keith Thompson (The_Other_Keith) kst-u(a)mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
From: Ben Bacarisse on 26 May 2008 23:01
Francis Glassborow <francis.glassborow(a)btinternet.com> writes:

> Ben Bacarisse wrote:
<snip>
>> I don't think either one does. Section 6.5.3.2 (Address and
>> indirection operators) says...
<snip>
> Exactly and we cannot do that in C++ because operator & may have been
> overloaded for a class type.

I forgot the -c++ in the group name. I should have made it clear my
answer was a C-only answer.

--
Ben.
From: Ben Bacarisse on 26 May 2008 23:23
Keith Thompson <kst-u(a)mib.org> writes:

> Francis Glassborow <francis.glassborow(a)btinternet.com> writes:
>> Ben Bacarisse wrote:
<talking initially only about C>
>>> I don't think either one does. Section 6.5.3.2 (Address and
>>> indirection operators) says about &:
>>> "If the operand is the result of a unary * operator, neither that
>>> operator nor the & operator is evaluated and the result is as if
>>> both were omitted..."
>>> &usr_data[0] is &*(usr_data+0) is &*usr_data is usr_data.
>>
>> Exactly and we cannot do that in C++ because operator & may have been
>> overloaded for a class type.
>
> But the compiler certainly knows whether it's been overloaded or not.
> The C++ standard could easily have the same rule, and have it apply
> only to the built-in "&" and "*" operators. Does it not do so?

Not in the '03 standard nor in my 1990 Annotated Reference manual (so
I imagine not in any version in between).

--
Ben.
 | 
Pages: 1
Prev: read the last n lines of a file or reverse
Next: Template function in template class