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

From: Ian McCulloch (ianmcc_at_[hidden])
Date: 2005-06-27 11:50:28

David Abrahams wrote:

> 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.

Ok, so that brings us back to something like is_noalias<T> metafunction. 
Once you give vectors and matrices an 'alias' attribute, whether or not
there exists a concrete container type (as opposed to a view) that is
'noalias', becomes a minor detail?  A user should be able to trivially
write such a container, even if the lib does not provide one.

Cheers,
Ian