Today I came across the situation where I had to copy – using delphi – some chunck of memory from one place to another. I nevery did that before (using OOP techniques gets you around that most of the time – at least in Delphi), so I had no idea how to do it. What I knew is that in C, I’d do that with memcpy. As a convinced fan of Pascals intuitive API notation, I looked in the help for MemCopy or CopyMem. Nothing (which is strange, considering things like AllocMem actually exist).
Some googling around turned out the name of the function: it’s
procedure Move(const Source; var Dest; Count: Integer);
Move? That can’t be. Can it? I want to copy, not to move. A quick glance at the help file revealed that it’s the truth: Move actually copies…
Move copies Count bytes from Source to Dest. No range checking is performed. Move compensates for overlaps between the source and destination blocks.
Descriptive procedure names? Usually, yes. But this can only be described as way beyond the optimum ;-)
Oh… on another note: What do you think, Copy does? Copying memory? No way:
function Copy(S; Index, Count: Integer): string; function Copy(S; Index, Count: Integer): array;
S is an expression of a string or dynamic-array type. Index and Count are integer-type expressions. Copy returns a substring or subarray containing Count characters or elements starting at S[Index]. The substring or subarray is a unique copy (that is, it does not share memory with S, although if the elements of the array are pointers or objects, these are not copied as well.)
If Index is larger than the length of S, Copy returns an empty string or array.
If Count specifies more characters or array elements than are available, only the characters or elements from S[Index] to the end of S are returned.
Yeah!. Right.
Oh and on second thought: The move-thing may have its roots in the assembler language, where MOV actually copies the data too – at least I think so. But anyway: If even C got it right, why has my beloved Pascal to fail in such an easy case?
gnegg 