tags:

views:

297

answers:

4

according to http://www.cplusplus.com/reference/clibrary/cstring/memcpy/ c++'s memcpy takes three parameters: destination, source and size/bytes. it also returns a pointer. why is that so? aren't the parameters enough to input and copy data.

or am i misunderstanding something? the examples don't use the return value

+1  A: 

By returning a value, an invocation of the memcpy function can be used as an r-value.

Brandon E Taylor
then why not simply make it return the resulting array instead of passing it as parameter?
knittl
"instead of passing it as a parameter" -- think about that for a few seconds.
kurige
Because you are responsible for creating the space space for the destination. memcpy doesn't create any new space.
nos
Because memcpy() does not allocate new memory for the destination (i.e. it needs a pointer to allocated memory to be passed to it). btw...I have rarely found the need to avail myself of memcpy()'s return value.
Brandon E Taylor
+6  A: 

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.

Steve Jessop
+9  A: 

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 input dst value as its result. Basically, when designing such a function, you are supposed 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);
}

Most of the time people find the fact that memcpy returns the same pointer as the one passed to it confusing, because there is a popular belief that returning a pointer form a function should normally (or always) indicate that the function might reallocate the 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.

AndreyT
A: 

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);

mike jones