C++ memcpy function, why use *s++ instead of s[i]

Question

I am writing memcpy from scratch and I have been looking up other peoples implementations...My implementation is:

void* memcpy (void *destination, const void *source, size_t num)
{
    char *D = (char*)destination;
    char *S = (char*)source;
    for(int i = 0; i < num; i++)
            D[i] = S[i];
    return D;
}

various other sources and references that I have researched have

void* memcpy (void *destination, const void *source, size_t num)
{
    char *D = (char*)destination;
    char *S = (char*)source;
    for(int i = 0; i < num; i++) 
    {
            *D = *S;
            D++;
            S++;
    }
    return D;
}

I am having trouble understanding the difference and whether they would produce different outputs. The portion that confuses me specifically is the D++; and S++;

Answer 1

Modern compilers will optimize these to the same code. It is called strength reduction. (Except for the different return values.)

Answer 2

D++ and S++ is incrementing a pointer.

Keep in mind that D[i] is equivalent to *(D + i).

Thus one is incrementing the pointer, other is keeping base and adding offset.

Modern compilers will probably compile to the same code.

NB: I assume return D; in second example is a copy-paste error, as it should be return destination; because D is increment and point to the memory "after" destination bytes.

Answer 3

At the time this code was written, it was probably faster to avoid the addition of the index to the pointers.

In my own testing on the x86 architecture, which has an indexing mode built into the low-level instructions, the indexed method is slightly faster.

Answer 4

The algorithms are equivalent. The second version uses pointer arithmetic to advance the pointers to the next position instead of indexing the arrays using the a[i] syntax.

This works because the a[i] is actually a shorthand for *(a+i) (read: advance i positions past a and read the value at that location). Instead of performing the total offset (+i) at each iteration, it performs a partial offset (++a) at each iteration and accumulates the result.

Answer 5

While both semantically mean the same thing, the *s++ version will avoid having to offset the initial pointer value as your increment through the bytes of the array you're copying. In other words the "underlying" representation of s[i] is actually *(s + i*sizeof(type)), and multiplications, especially of large values of i, are much slower than simple increments by small values, at least depending on the machine architecture.

In the end though, the libc implementation of memcpy will be much faster than anything you could hand-write in C due to the use of machine-dependent optimized memory-copying assembly instructions that you can't deliberately access through normal C-code.

Answer 6

What seems to be confusing you is the pointer arithmetic: D++, S++. The pointers are being incremented to refer to the next char (as they are char*)

Answer 7

Here are the inner loops, as compiled by GCC. I just added restrict keywords and removed the return value and compiled 32 bit for Core 2:

First one, array version:

.L3:
  movzbl  (%edi,%edx), %ecx
  addl    $1, %eax  
  cmpl    %ebx, %eax
  movb    %cl, (%esi,%edx)
  movl    %eax, %edx
  jne .L3

Second one, increment version:

.L9:
  movzbl  (%edx), %ebx
  addl    $1, %ecx   
  addl    $1, %edx   
  movb    %bl, (%eax)
  addl    $1, %eax  
  cmpl    %ecx, %esi
  ja  .L9

The compiler, as you can see, saw right through both constructs.

Answer 8

Though it makes little difference either way, I'd be a bit surprised to see either of those. I'd expect something closer to:

void* memcpy (void *destination, const void *source, size_t num) {
    char *S = (char *)source;
    char *D = (char *)destination;
    while (--num)
        *D++ = *S++;
    return destination;
}

Most decent compilers will produce about the same code regardless. I haven't checked recently, but at one time most compilers targeting x86 would turn most of the loop into a single rep movsd instruction. They might not any more though -- that's no longer optimal.