according to http://en.cppreference.com/w/cpp/string/byte/memcpy c++\'s memcpy
takes three parameters: destination, source and size/bytes. it also returns a pointer
If a function has nothing specific to return, it is often customary to return one of the input parameters (the one that is seen as the primary one). Doing this allows you to use "chained" function calls in expressions. For example, you can do
char buffer[1024];
strcat(strcpy(buffer, "Hello"), " World");
specifically because strcpy
returns the original dst
value as its result. Basically, when designing such a function, you might want to choose the most appropriate parameter for "chaining" and return it as the result (again, if you have noting else to return, i.e. if otherwise your function would return void
).
Some people like it, some people don't. It is a matter of personal preference. C standard library often supports this technique, memcpy
being another example. A possible use case might be something along the lines of
char *clone_buffer(const char *buffer, size_t size)
{
return memcpy(new char[size], buffer, size);
}
If memcpy
did not return the destination buffer pointer, we'd probably have to implement the above as
char *clone_buffer(const char *buffer, size_t size)
{
char *clone = new char[size];
memcpy(clone, buffer, size);
return clone;
}
which looks "longer". There's no reason for any difference in efficiency between these two implementations. And it is arguable which version is more readable. Still many people might appreciate the "free" opportunity to write such concise one-liners as the first version above.
Quite often people find it confusing that memcpy
returns the destination buffer pointer, because there is a popular belief that returning a pointer form a function should normally (or always) indicate that the function might allocate/reallocate memory. While this might indeed indicate the latter, there's no such hard rule and there has never been, so the often expressed opinion that returning a pointer (like memcpy
does) is somehow "wrong" or "bad practice" is totally unfounded.
void *memcpy(void* dest, const void* src, std::size_t count);
//returns void * which can be assigned to another void array that can be used as int or char data type.
void *ret = new int[6];
ret = memcpy(newarr, arr, sizeof(int)* 5);
You can cast the return into a void if you want to indicate that you aren't using it - eg:
(void) memcpy(mydest, mysrc, mybytes);
IIRC, in early versions of C there was no void
return. So library functions which have been around long enough return something for legacy reasons, and this was the best they could come up with.
There are a bunch of functions in string.h
which return the destination parameter: memcpy
, strcpy
, strcat
. It's not very useful, but it does no harm (probably in many calling conventions doesn't even require an instruction to implement).
You might conceivably come up with a use: char *nextbuf = memcpy(get_next_buf(), previous_buf+offset, previous_size-offset);
instead of char *nextbuf = get_next_buf(); memcpy(nextbuf, etc);
Or something.
For comparison, qsort
returns void. It could have been defined to return base
on the principle of "return something, it might come in handy", but wasn't. std::copy
rather more usefully returns an iterator to the end of the output range. For non-random-access iterators that might not be trivial, or even possible, for the caller to compute.
By returning a value, an invocation of the memcpy function can be used as an r-value.