Ok, that seems like an improvement, but how does it handle the
following situation?
In STL, often times a few special cases of a generic algorithm are
specialized, for instance take copy(). In one specialization it calls
memmove() to do the work. Now, suppose memmove() has restrict in its
parameter list. What happens when someone calls the generic copy()
with non-restrict pointers?
template <class _Tp>
inline _Tp*
__copy_trivial(const _Tp* __first, const _Tp* __last, _Tp* __result) {
memmove(__result, __first, sizeof(_Tp) * (__last - __first));
return __result + (__last - __first);
}
The problem I'm trying to get at is that if the generic function
depends on how it is used (instantiated) as to whether the input is
unaliased, then the library writer can't make optimizations like the
call to memmove above. To enable such optimizations the library writer
needs to be able to declare the generic copy() function to take only
unaliased iterators, no matter how it is instantiated.
Bill Homer writes:
> 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?
--------------------- 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 : Mon Apr 10 2000 - 12:47:56 EST