In section 26.6.2.7 valarray computed assignment, paragraph 3 states

"If the array and the argument array do not have the same length, the
behavior is undefined."

Is there a good reason why equal length should not be a requirement?

The same applies to binary operators (26.6.3.1) and logical operators
(26.6.3.2).

--
Ian Collins


[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 2011-04-13 21:06, Ian Collins wrote:
>
>  In section 26.6.2.7 valarray computed assignment, paragraph 3 states
>
>  "If the array and the argument array do not have the same length, the
>  behavior is undefined."
>
>  Is there a good reason why equal length should not be a requirement?
>
>  The same applies to binary operators (26.6.3.1) and logical operators
>  (26.6.3.2).

For me the current state has good reasons. Compound assignments or
binary operations are semantically elementwise operations, e.g.
operator+= is supposed to add to the i-th element of the destination the
i-th element of the source. If the array length are different it is
unclear what the semantic of the operation would be. It is possible to
invent some semantics (e.g. consider the value of the missing element as
T(0)), but I consider this decision as arguable and not necessarily
natural or intuitive (you also need to answer the question, whether the
initial or whether the final elements are considered as null values).

This situation is very different from an unconditional assignment e.g.
for the move/copy-assignment: Here the semantics is a full replacement
of the destination by the source, there is no possible interpretation
problem in regard to not matching elements, because the elements are
fully replaced.

HTH&  Greetings from Bremen,

Daniel Kr   gler


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 04/15/11 07:12 AM, Daniel Kr=FCgler wrote:

>
> On 2011-04-13 21:06, Ian Collins wrote:
>
>>
>>  In section 26.6.2.7 valarray computed assignment, paragraph 3 states
>>
>>  "If the array and the argument array do not have the same length, the
>>  behavior is undefined."
>>
>>  Is there a good reason why equal length should not be a requirement?
>>
>>  The same applies to binary operators (26.6.3.1) and logical operators
>>  (26.6.3.2).
>>
>
> For me the current state has good reasons. Compound assignments or
> binary operations are semantically elementwise operations, e.g.
> operator+= is supposed to add to the i-th element of the destination th=
e
> i-th element of the source. If the array length are different it is
> unclear what the semantic of the operation would be. It is possible to
> invent some semantics (e.g. consider the value of the missing element as
> T(0)), but I consider this decision as arguable and not necessarily
> natural or intuitive (you also need to answer the question, whether the
> initial or whether the final elements are considered as null values).
>

Exactly, so why keep yet another instance of UB in the standard?  The
programmer can't assume one implementation's design decisions are portable.

Let me rephrase: What harm would be done if equal length were a requirement=
?

This situation is very different from an unconditional assignment e.g.
> for the move/copy-assignment: Here the semantics is a full replacement
> of the destination by the source, there is no possible interpretation
> problem in regard to not matching elements, because the elements are
> fully replaced.
>

It is different, but I ask again, why leave the ambiguity in the standard?

--
Ian Collins


[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Am 15.04.2011 01:18, schrieb Ian Collins:
>
> On 04/15/11 07:12 AM, Daniel Kr=FCgler wrote:
>
>>
>> On 2011-04-13 21:06, Ian Collins wrote:
>>
>>>
>>> In section 26.6.2.7 valarray computed assignment, paragraph 3 states
>>>
>>> "If the array and the argument array do not have the same length, the
>>> behavior is undefined."
>>>
>>> Is there a good reason why equal length should not be a requirement?
>>>
>>> The same applies to binary operators (26.6.3.1) and logical operators
>>> (26.6.3.2).
>>>
>>
>> For me the current state has good reasons. Compound assignments or
>> binary operations are semantically elementwise operations, e.g.
>> operator+= is supposed to add to the i-th element of the destination th=
> e
>> i-th element of the source. If the array length are different it is
>> unclear what the semantic of the operation would be. It is possible to
>> invent some semantics (e.g. consider the value of the missing element as
>> T(0)), but I consider this decision as arguable and not necessarily
>> natural or intuitive (you also need to answer the question, whether the
>> initial or whether the final elements are considered as null values).
>>
>
> Exactly, so why keep yet another instance of UB in the standard? The
> programmer can't assume one implementation's design decisions are portable.
>
> Let me rephrase: What harm would be done if equal length were a
> requirement=
> ?

So, is your complain that there is no explicit *requirement* that the
length of both operands shall be the same? Why do you consider this as
different compared to the current state? Violating a requirement also
leads to undefined behavior.

I agree that an explicit requirement would make the wording situation
clearer, but the essence looks the same to me. The wording style in
these clauses is different as in other clauses of the library, but at
least consistently different ;-) E.g. instead of the requirement, we
have a description of undefined behaviour for the operator[] overloads
as well, as of [valarray.access] p. 6:

"If the subscript operator is invoked with a size_t argument whose value
is not less than the length of the array, the behavior is undefined."

> This situation is very different from an unconditional assignment e.g.
>> for the move/copy-assignment: Here the semantics is a full replacement
>> of the destination by the source, there is no possible interpretation
>> problem in regard to not matching elements, because the elements are
>> fully replaced.
>>
>
> It is different, but I ask again, why leave the ambiguity in the standard?

What precisely is the ambiguity you are referring to?

Thanks & Greetings from Bremen,

Daniel Kr   gler



--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 04/16/11 07:17 AM, Daniel Kr   gler wrote:
>
>  Am 15.04.2011 01:18, schrieb Ian Collins:
>>
>>  On 04/15/11 07:12 AM, Daniel Kr=FCgler wrote:
>>
>>>
>>>  On 2011-04-13 21:06, Ian Collins wrote:
>>>
>>>>
>>>>  In section 26.6.2.7 valarray computed assignment, paragraph 3 states
>>>>
>>>>  "If the array and the argument array do not have the same length, the
>>>>  behavior is undefined."
>>>>
>>>>  Is there a good reason why equal length should not be a requirement?
>>>>
>>>>  The same applies to binary operators (26.6.3.1) and logical operators
>>>>  (26.6.3.2).
>>>>
>>>
>>>  For me the current state has good reasons. Compound assignments or
>>>  binary operations are semantically elementwise operations, e.g.
>>>  operator+= is supposed to add to the i-th element of the destination th=
>>  e
>>>  i-th element of the source. If the array length are different it is
>>>  unclear what the semantic of the operation would be. It is possible to
>>>  invent some semantics (e.g. consider the value of the missing element as
>>>  T(0)), but I consider this decision as arguable and not necessarily
>>>  natural or intuitive (you also need to answer the question, whether the
>>>  initial or whether the final elements are considered as null values).
>>>
>>
>>  Exactly, so why keep yet another instance of UB in the standard? The
>>  programmer can't assume one implementation's design decisions are portable.
>>
>>  Let me rephrase: What harm would be done if equal length were a
>>  requirement=
>>  ?
>
>  So, is your complain that there is no explicit *requirement* that the
>  length of both operands shall be the same? Why do you consider this as
>  different compared to the current state? Violating a requirement also
>  leads to undefined behavior.

If the requirement existed, a run time error condition could be detected
in a consistent way (throwing an exception for example).

>  I agree that an explicit requirement would make the wording situation
>  clearer, but the essence looks the same to me. The wording style in
>  these clauses is different as in other clauses of the library, but at
>  least consistently different ;-) E.g. instead of the requirement, we
>  have a description of undefined behaviour for the operator[] overloads
>  as well, as of [valarray.access] p. 6:

True, but I guess undefined behaviour for the operator[] overloads is
considered a performance optimisation.  If the operation is trivial, a
check may be considered expensive, but if the operation relatively
expensive, a check is noise.

>  "If the subscript operator is invoked with a size_t argument whose value
>  is not less than the length of the array, the behavior is undefined."
>
>>  This situation is very different from an unconditional assignment e.g.
>>>  for the move/copy-assignment: Here the semantics is a full replacement
>>>  of the destination by the source, there is no possible interpretation
>>>  problem in regard to not matching elements, because the elements are
>>>  fully replaced.
>>>
>>
>>  It is different, but I ask again, why leave the ambiguity in the standard?
>
>  What precisely is the ambiguity you are referring to?

The undefined behaviour.

--
Ian Collins


[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

[Second submission attempt after 24 hours]

Am 18.04.2011 21:07, schrieb Ian Collins:
>
>  On 04/16/11 07:17 AM, Daniel Kr   gler wrote:
>>
>>  Am 15.04.2011 01:18, schrieb Ian Collins:
>>>
>>>  On 04/15/11 07:12 AM, Daniel Kr=FCgler wrote:
>>>
>>>>
>>>>  On 2011-04-13 21:06, Ian Collins wrote:
>>>>
>>>>>
>>>>>  In section 26.6.2.7 valarray computed assignment, paragraph 3 states
>>>>>
>>>>>  "If the array and the argument array do not have the same length, the
>>>>>  behavior is undefined."
>>>>>
>>>>>  Is there a good reason why equal length should not be a requirement?
>>>>>
>>>>>  The same applies to binary operators (26.6.3.1) and logical operators
>>>>>  (26.6.3.2).
>>>>>
>>>>
>>>>  For me the current state has good reasons. Compound assignments or
>>>>  binary operations are semantically elementwise operations, e.g.
>>>>  operator+= is supposed to add to the i-th element of the destination
>>>>  th=
>>>  e
>>>>  i-th element of the source. If the array length are different it is
>>>>  unclear what the semantic of the operation would be. It is possible to
>>>>  invent some semantics (e.g. consider the value of the missing
>>>>  element as
>>>>  T(0)), but I consider this decision as arguable and not necessarily
>>>>  natural or intuitive (you also need to answer the question,
whether the
>>>>  initial or whether the final elements are considered as null values).
>>>>
>>>
>>>  Exactly, so why keep yet another instance of UB in the standard? The
>>>  programmer can't assume one implementation's design decisions are
>>>  portable.
>>>
>>>  Let me rephrase: What harm would be done if equal length were a
>>>  requirement=
>>>  ?
>>
>>  So, is your complain that there is no explicit *requirement* that the
>>  length of both operands shall be the same? Why do you consider this as
>>  different compared to the current state? Violating a requirement also
>>  leads to undefined behavior.
>
>  If the requirement existed, a run time error condition could be detected
>  in a consistent way (throwing an exception for example).

This is incorrect. The pure existence of the requirement alone wouldn't
change anything. Whether any of these operations throws an exception in
case of a violation would not result out of these differences. If you
want a guaranteed exception in case of equal-length constraint
violations you have to add explicit wording that requires an exception
as a result of such a violation.

Note that adding an explicit exception guarantee is violating the design
of valarrays. valarrays are supposed to satisfy the numeric types
requirements as of [numeric.requirements], the note 272 in the FDIS
makes this clear. Among the requirements for these types we have p. 2:

"If any operation on T throws an exception the effects are undefined."

There exists only a small leeway for exceptions (which is not
recommended) for out-of-resource limits described in [valarray.syn] p. 6:

"These library functions are permitted to throw a bad_alloc (18.6.2.1)
exception if there are not sufficient resources available to carry out
the operation. Note that the exception is not mandated."

>>  What precisely is the ambiguity you are referring to?
>
>  The undefined behaviour.

Just to be sure: What is your *precise* suggestion to change? As noted
above, changing the undefined behaviour wording into a requirement is
not a significant change at all.

HTH&  Greetings from Bremen,

Daniel Kr   gler


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]