Boost logo

Ublas :

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.