Re: [ublas] Transition to default handling of possible lvalue aliases

From: David Abrahams (dave_at_[hidden])
Date: 2005-06-26 20:02:55

Ian McCulloch <ianmcc_at_[hidden]> writes:

> David Abrahams wrote:
>
>> Gunter Winkler <guwi17_at_[hidden]> writes:
>> 
>>> On Monday 20 June 2005 11:44, Ian McCulloch wrote:
>>>> So, how about
>>>>
>>>> Vector<double> x;          // default: forces 'safe' handling of aliases
>>>> Vector<double, noalias> y; // fast: user takes responsibility for
>>>> aliases
>>>
>>> This looks really good. Here both strategies are possible, the user has
>>> the choice and it has a clear and short syntax. I vote for this version.
>> 
>> It puts the information in the wrong place.  Whether or not there will
>> be aliasing in an expression depends on that expression, not on the
>> types of the objects used in it.  I'd rather have the notation that 
>> there is no aliasing as part of the expression so they don't get out
>> of synch.  Objects can come from anywhere -- imagine passing a
>> vector<double,noalias> to a generic function.
>
> As an author of a generic function, how do you know whether to use noalias()
> or not?  The interesting case is where there are one or more parameters
> that may, or may not, be aliases.  The function author cannot know how the
> user is going to call their function!  They would overwise have to write
> two versions, one that uses noalias() and one that does not, and document
> which to call.

Yep, that calls for a noalias view that you can build around any
vector or matrix before passing it into a generic function.

> Also, if the 'generic function' does not use noalias(), but has no aliasing
> problems, you might want to avoid pessimistic code by using a vector type
> that assumes no aliasing.

It belongs in the type system, labelling the reference to the vector
ormatrix object, just not as an integral part of the vector or matrix.
You might do

       noalias(v1) = v2 + v3;

and later

       v1 = v1 + v2;

> This issue seems very close to the question of whether overloading on
> restricted pointers is allowed or not (for those C++ compilers that have
> restrict as an extension).  

Yes.

> IIRC, there are compilers that implement both semantics.  Do you
> know what the experience there has been?

I'm afraid not, sorry.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com