Jeremy Siek wrote:
> [...], 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?
The compiler must not use the specialization that uses such a memmove.
> [...] 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.
It would help if it /did/ matter how it is instantiated.
Just as it is possible to overload and specialize with respect to the
constness of argument types, the same should be possible
with respect to the restrict qualification (restrictedness?)
of argument types.
template <class T> copy(T const * restrict, ...) { memmove(...); ...; }
should be different from
template <class T> copy(T const * /*aliased*/, ...) { ...; }
Bill Homer suggested that the `restrict' qualifier should behave (i.e.
propagate) similarly to the way `const' does. Also analogous to `const',
this might make necessary analoga for `mutable' and `const_cast', e.g.
`aliased' and `restrict_cast'.
Or am I on the wrong track entirely?
Rainer
--------------------- 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