Jeremy Siek writes:
> > 2. The restrict qualifier is compatible with the iterator style
> > of programming. In particular:
> >
> > typedef double * restrict T;
> >
> > void f(T a, T a_end, T b) {
> > while(a != a_end) {
> > *a++ = *b++;
> > }
> > }
>
> Ok, lets look at a generic version of this example:
>
> template <class Iter1, class Iter2>
> void f(Iter1 a, Iter1 a_end, Iter2 b) {
> while (a != a_end)
> *a++ = *b++;
> }
>
> We want to be able to make the same kind of aliasing assertion as in
> the non-generic version. That is, that "a" doesn't alias with "b".
> First off, you can't make the same kind of assertion if you use the
> technique suggested in part 4 below. In the above example we aren't
> dealing with a container, and don't have a choice between using the
> const_iterator, restrict_iterator, or const_restrict_iterator
> typedefs. Instead, we need to express something more like this:
>
> template <class Iter1, class Iter2>
> void f(restrict Iter1 a, Iter1 a_end, Iter2 b) {
> while (a != a_end)
> *a++ = *b++;
> }
Here we come to a real fork in the road.
One way leads to the attempt to define a meaning for restrict
qualifying an iterator that is not a simple pointer. For the reasons
you list and others, I agree that this is problematic, at best. Even
in C, it would have been possible to extend the "focus" of a single
qualifier beyond a single level of indirection. But it seemed better
to keep the focus narrow, and ensure that the semantics for multiple
qualifiers at multiple levels "combine" properly to make sufficiently
strong assertions.
The other way is to confine the use of restrict to pointer and
reference types, and explore how usable it is in various styles of OO
programming. That is what I am proposing to explore. In your
particular example, I am interested in the first version, when it is
instantiated with Iter1 containing a restricted pointer. However, see
below.
[snip]
>
> > 4. For generic programming, the restrict qualifier can be
> > packaged in much the same way as the const qualifier.
> > In particular, we could add a typedef for, say,
> > restrict_iterator to those for iterator and const_iterator
> > in an STL-style container. So, for example, if an
> > implementation uses (void *) members for the links in the
> > iterator class for list, then it would use (void * restrict)
> > members for the links in the restrict_iterator class.
> > (Those members will have to be cast to other types, but the
> > semantics of the restrict qualifier is not affected by that.)
> >
> > Note that only a new typedef name is added, not new
> > semantics for the restrict qualifier.
> >
> > Note that restrict_const_iterator might also be interesting,
> > because traversing a list with such an iterator asserts that
> > its nodes (both values and links) will not be modified,
> > either in that loop or anywhere else during the execution of
> > the block in which the iterator is declared.
>
>
> Actually, the fact that we are required to have typedefs for both
> iterators and const_iterators is already annoying. And don't forget
> reverse iterators: so we'd have restrict_const_reverse_iterator's.
At first I was inclined to protest this criticism as unfair, because
it seemed aimed more at the existing STL framework than at my attempt
to fit restrict into it. But it did make me reconsider the
differences between const and restrict, and I believe that something
better is possible.
Consider an iterator of the form
class Iter {
T *current;
// declarations of member functions and operators follow ...
};
In the current C specification, restrict is allowed on the pointer
member, current, but not on the structure as a whole. Nevertheless,
there is a reasonable extension to allow the latter. The standard
already states that, given a declaration of the form
restrict struct Iter i;
the lvalue i.current has type (T * restrict).
So, by simply relaxing the constraint against restrict-qualifying a
non-pointer type (replacing it with the statement that the semantics
only apply to lvalues with pointer types), we can indeed avoid the
need to declare another variant of Iter, with a qualified version of
current. In particular there would be no need for restrict_iterator,
etc.
At the same time, we avoid needing to formulate new semantics for a
restrict-qualified iterator, because it reduces to the existing
semantics for pointers.
This seems like a nice return for a small change. Does it seem like
progress to you?
-- Bill Homer (651) 683-5606 Silicon Graphics, Inc. homer@cray.com 655F Lone Oak Drive, Eagan, MN 55121--------------------- Object Oriented Numerics List -------------------------- * To subscribe/unsubscribe: use the handy web form at http://oonumerics.org/oon/ * If this doesn't work, please send a note to owner-oon-list@oonumerics.org
This archive was generated by hypermail 2b29 : Wed Feb 20 2002 - 03:20:12 EST