From: Ian Collins Newsgroups: comp.std.c++ Subject: Re: valarray computed assignment - arrays of different sizes Date: Mon, 18 Apr 2011 13:07:22 CST Organization: unknown Lines: 86 Sender: std-cpp-request@vandevoorde.com Approved: stephen.clamage@oracle.com Message-ID: <9111enFpdmU6@mid.individual.net> References: <90jvqmFhg6U15@mid.individual.net> <90p22kFeeiU17@mid.individual.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed To: undisclosed-recipients:; Return-Path: X-Original-Date: Mon, 18 Apr 2011 08:38:47 +1200 X-Submission-Address: std-c++-submit@vandevoorde.com Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.stben.net!border3.nntp.ams.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!usenetcore.com!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!news.alt.net Xref: x330-a1.tempe.blueboxinc.net comp.std.c++:110 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 ]