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

From: Ian McCulloch (ianmcc_at_[hidden])
Date: 2005-06-24 14:15:50

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.

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.

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).  IIRC, there are compilers that implement both
semantics.  Do you know what the experience there has been?  

Cheers,
Ian