Boost logo

Ublas :

From: christopher diggins (cdiggins_at_[hidden])
Date: 2005-06-14 16:30:11


----- Original Message -----
From: "Michael Stevens" <mail_at_[hidden]>
To: "ublas mailing list" <ublas_at_[hidden]>
Sent: Tuesday, June 14, 2005 4:10 PM
Subject: Re: [ublas] Aliasing for += and -=

> On Monday 13 June 2005 17:21, Gunter Winkler wrote:
>> @all: Do you think, that it is possible to autodetect aliasing at
>> compile time via the container_reference class?
>>
>> Should we add new overloads of += and co. to vector and matrix types:
>>
>> self_type & operator += (const self_type& rhs) {
>> plus_assign(rhs);
>> return (*this);
>> }
>
> This would also be my suggestion. For some container classes in can be
> made a
> little more general then self_type. We just need to ensure the the rhs is
> a
> similar container. For example vector has the following:
> template<class A2> // Generic vector assignment without
> temporary
> BOOST_UBLAS_INLINE
> vector &operator = (const vector<T, A2> &v) {
> resize (v.size (), false);
> assign (v);
> return *this;
> }
>
> The key thing is this needs to be propgated to all container types. I was
> hoping Christopher would submit a patch :-)

If I wrote a patch it would involve creating a new namespace:

boost::numeric::ublas::unaliased

and writing unaliased versions of all the library. I would then move the
existing library into a boost::numeric::ublas::aliased namespace and
petition for the unaliased namespace to become the default version of the
library when aliased/unaliased is not specified.

I wonder if the community would actually support such a bold action? This
way people can stop telling new users "in order to get acceptable
performance out of basic operations you must somehow assure aliasing isn't
occuring and then write noalias(x)". What offends me most off about people
recommending noalias(x), is the misguided idea that knowing when it is safe
to use noalias is a trivial task for a casual user of the library.

--
Christopher Diggins