You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Farid Zaripov <Fa...@epam.com> on 2007/07/27 16:39:01 UTC
[PATCH] 26.valarray.cassign.cpp
The 26.valarray.cassign.cpp test expect that UserClass type
provides +, -, *, / operations. But these operations are not
defined in rw_value.h.
The patch below defines them and also deletes res_array.
Index: 26.valarray.cassign.cpp
===================================================================
--- 26.valarray.cassign.cpp (revision 560134)
+++ 26.valarray.cassign.cpp (working copy)
@@ -240,6 +240,19 @@
int value (const UserClass &val) { return val.data_.val_; }
+#define USERCLASS_OPERATOR(op)
\
+inline UserClass operator##op (const UserClass& __x, const UserClass&
__y) \
+{
\
+ UserClass __tmp (__x);
\
+ __tmp op##= __y;
\
+ return __tmp;
\
+} typedef void rw_unused_typedef
+
+USERCLASS_OPERATOR (+);
+USERCLASS_OPERATOR (-);
+USERCLASS_OPERATOR (*);
+USERCLASS_OPERATOR (/);
+
/***********************************************************************
***/
template <class T>
@@ -332,6 +345,7 @@
delete_array (lhs_array, nelems);
delete_array (rhs_array, nelems);
+ delete_array (res_array, nelems);
std::free (fname);
}
Farid.
Re: [PATCH] 26.valarray.cassign.cpp
Posted by Martin Sebor <se...@roguewave.com>.
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.
>>
>
Re: [PATCH] 26.valarray.cassign.cpp
Posted by Martin Sebor <se...@roguewave.com>.
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.
>
RE: [PATCH] 26.valarray.cassign.cpp
Posted by Farid Zaripov <Fa...@epam.com>.
> -----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:
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.
Re: [PATCH] 26.valarray.cassign.cpp
Posted by Martin Sebor <se...@roguewave.com>.
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?
Martin
>
> The patch below defines them and also deletes res_array.
>
> Index: 26.valarray.cassign.cpp
> ===================================================================
> --- 26.valarray.cassign.cpp (revision 560134)
> +++ 26.valarray.cassign.cpp (working copy)
> @@ -240,6 +240,19 @@
>
> int value (const UserClass &val) { return val.data_.val_; }
>
> +#define USERCLASS_OPERATOR(op)
> \
> +inline UserClass operator##op (const UserClass& __x, const UserClass&
> __y) \
> +{
> \
> + UserClass __tmp (__x);
> \
> + __tmp op##= __y;
> \
> + return __tmp;
> \
> +} typedef void rw_unused_typedef
> +
> +USERCLASS_OPERATOR (+);
> +USERCLASS_OPERATOR (-);
> +USERCLASS_OPERATOR (*);
> +USERCLASS_OPERATOR (/);
> +
>
> /***********************************************************************
> ***/
>
> template <class T>
> @@ -332,6 +345,7 @@
>
> delete_array (lhs_array, nelems);
> delete_array (rhs_array, nelems);
> + delete_array (res_array, nelems);
>
> std::free (fname);
> }
>
> Farid.
>