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

Groups > comp.std.c++ > #110

Re: valarray computed assignment - arrays of different sizes

Show all headers | View raw

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                      ]

Back to comp.std.c++ | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

valarray computed assignment - arrays of different sizes  Ian Collins <ian-news@hotmail.com> - 2011-04-13 13:06 -0600
  Re: valarray computed assignment - arrays of different sizes Daniel Krügler<daniel.kruegler@googlemail.com> - 2011-04-14 13:12 -0600
    Re: valarray computed assignment - arrays of different sizes  Ian Collins <ian-news@hotmail.com> - 2011-04-14 17:18 -0600
      Re: valarray computed assignment - arrays of different sizes  Daniel Krügler <daniel.kruegler@googlemail.com> - 2011-04-15 13:17 -0600
        Re: valarray computed assignment - arrays of different sizes Ian Collins<ian-news@hotmail.com> - 2011-04-18 13:07 -0600
          Re: valarray computed assignment - arrays of different sizes Daniel Krügler<daniel.kruegler@googlemail.com> - 2011-04-20 14:06 -0600

csiph-web