I carelessly confused memmove and memcpy in my previous post.
When Jeremy asked about adding restrict to the prototype of
memmove, I took that to mean replacing it with memcpy, which
does have restrict in its prototype in C, but I continued to refer
to memmove. There is no problem with __copy_trivial using memmove,
but there would be a problem with it using memcpy. See below.
On Sun, 2 Apr 2000, Bill Homer wrote:
> On Thu, 30 Mar 2000 jsiek@lsc.nd.edu wrote:
>
[snip]
> > 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?
>
> It doesn't cause a problem. One of the design goals for the
> restrict qualifier was that it could be added to the prototype
> for memmove without raising any type compatibility issues in
> existing uses of that function. And it achieves that goal
> because type qualifiers (at the "top level") on arguments and
> parameters are ignored for the purpose of checking type
> compatibility in C, or for overload resolution in C++.
Here I should have said that adding restrict to memmove would
require replacing it with memcpy, which has the restrictions
needed for the qualifier.
Also, in the last sentence, I was thinking of section 14.8.2.1,
Deducing template arguments from a function call, which implies
that it doesn't matter whether the call of copy has arguments with
top-level qualifiers, because they are ignored for the type
deduction. I am assuming that restrict would be specified to
satisfy the same rules as "cv-qualifiers". (I guess it might be
possible specify that restrict is not ignored for type deduction,
but I'd want to think through the implications of that pretty
carefully before proposing it.)
[snip]
> (I realize this is somewhat tangential, but notice that
> specializing copy to __copy_trivial as above for a type such
> as (char *) is not portable. Doing so assumes that memmove
> copies from lowest address up, but there is no such
> requirement on memmove in the C standard. On some types of
> machines, it might be faster to divide the source into
> multiple blocks, and move them in parallel to the
> destination. So a library writer cannot use the above
> specialization without knowing how memmove is implemented.)
In the above paragraph, I intended to say memcpy in place of memmove.
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