You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Martin Sebor <se...@roguewave.com> on 2007/08/08 23:20:36 UTC

Re: [PATCH] 26.valarray.cassign.cpp

The problem here is actually in valarray, not in the new test.
The reason why it compiles in my tests is because I've made local
changes to valarray (the rewrite I've been promising to check in
for months). Among the changes I've made are improvements to the
implementation of the computed assignment operators that make
them use the same operators defined for value_type. E.g., the
new implementation of operator*=() looks like this:

     valarray<T>::operator*= (const valarray<T> &rhs) {
         for (size_t i = 0; i != size (); ++i)
             (*this)[i] *= rhs [i];
     }

instead of like this:

     valarray<T>::operator*= (const valarray<>& rhs) {
         transform (&(*this)[0], &(*this)[0] + size (),
                    &rhs [0], &(*this)[0],
                    multiplies<_TypeT>());
     }

I'm still not ready to check in my changes so I've opened a new
issue to track this problem. It'll give us the opportunity to
check in a fix just for this issue without having to wait until
the whole rewrite is ready.

     https://issues.apache.org/jira/browse/STDCXX-512

Martin

Martin Sebor wrote:
> Farid Zaripov wrote:
>>> -----Original Message-----
>>> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
>>> Sent: Friday, July 27, 2007 7:06 PM
>>> To: stdcxx-dev@incubator.apache.org
>>> Subject: Re: [PATCH] 26.valarray.cassign.cpp
>>>
>>> Farid Zaripov wrote:
>>>>   The 26.valarray.cassign.cpp test expect that UserClass 
>>> type provides
>>>> +, -, *, / operations. But these operations are not defined in 
>>>> rw_value.h.
>>> HP aCC and Intel C++ compile the code but I did notice some errors 
>>> from gcc yesterday, and I see Sun C++ has trouble with the code as 
>>> well. I tend to trust Intel C++ over the other compilers, so I wonder 
>>> if the reasons for the error are actually compiler bugs. Otherwise 
>>> there's a bug in Intel
>>> C++ (and HP aCC), or we're relying on some extension. What's
>>> your take on it?
>>
>>   As I see from night build results, that Intel C++ 10.0 and acc 6.13
>> also failed to compile:
> 
> You're right, I only looked at the output from generating dependencies
> abd didn't go as far as the actual compilation. Doh! It's still odd,
> because I compiled the test manually using Intel C++ 10.0 on Linux
> before I committed it. I'll need to look into why it had passed then
> or what I did wrong. Let me do that first and apply your patch when
> I know about what went wrong.
> 
> Martin
> 
>> http://people.apache.org/~sebor/stdcxx/results/linux_suse-9.1-amd64-icc-
>> 32b-10.0-15s-559650-log.gz.txt
>> http://people.apache.org/~sebor/stdcxx/results/linux_suse-9.1-amd64-icc-
>> 64b-10.0-8S-559650-log.gz.txt
>> http://people.apache.org/~sebor/stdcxx/results/hpux-11.23-ia64-acc-64b-6
>> .13-8S-559650-log.gz.txt
>>
>>
>>   The test instantiating valarray<UserClass>::operator{+-/*}= (...)
>> operators, but they can't be instantiated
>> because of  UserClass has not provided +,-,/,* operations.
>>
>>> From standard:
>>
>>   26.5.2.6 valarray computed assignment [valarray.cassign]
>> valarray<T>& operator*= (const valarray<T>&);
>> valarray<T>& operator/= (const valarray<T>&);
>> valarray<T>& operator%= (const valarray<T>&);
>> valarray<T>& operator+= (const valarray<T>&);
>> valarray<T>& operator-= (const valarray<T>&);
>> valarray<T>& operator^= (const valarray<T>&);
>> valarray<T>& operator&= (const valarray<T>&);
>> valarray<T>& operator|= (const valarray<T>&);
>> valarray<T>& operator<<=(const valarray<T>&);
>> valarray<T>& operator>>=(const valarray<T>&);
>> 1 Each of these operators may only be instantiated for a type T to which
>> the indicated operator can be applied. Each
>> of these operators performs the indicated operation on each of its
>> elements and the corresponding element of the
>> argument array.
>>
>>
>> Farid.
>>
>