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


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

Re: valarray computed assignment - arrays of different sizes

Message-ID <90p22kFeeiU17@mid.individual.net> (permalink)
Newsgroups comp.std.c++
From Ian Collins <ian-news@hotmail.com>
Subject Re: valarray computed assignment - arrays of different sizes
Organization unknown
References <90jvqmFhg6U15@mid.individual.net> <io6g0q$roh$1@dont-email.me>
Date 2011-04-14 17:18 -0600

Show all headers | View raw


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                      ]

Back to comp.std.c++ | Previous | NextPrevious 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