Take the 2-minute tour ×

Suppose I have two int arrays x and y, and both of them have length 3. x={0,1,2}.

Is there any one step way to assign the values of x to y. When I do y=x, and try to print the values of y,

the code does not compile.

I dont want to go through the pain of writing a for loop, and write y[i]=x[i]

share|improve this question
Retagging, because regex-negation makes no sense here. –  Carl Norum Sep 20 '10 at 21:00
Go through the pain. The compiler may optimize it to something more efficient. For small arrays, individual assignment by cell is faster than a loop; and usually faster than a call to memcpy. The overhead involved in a function call or for loop is the determining factor. –  Thomas Matthews Sep 20 '10 at 23:20
add comment

7 Answers

You can use memcpy or memmove:

memcpy(y, x, sizeof x);
share|improve this answer
You are correct that the loop inside memcpy will do the same job. This is not to suggest that the code you offer will run faster, much less that it will be safer. –  Steven Sudit Sep 20 '10 at 21:03
On a lot of machines, memcpy is hugely optimized. Now, in this case, it's only a 3 element array, so that probably doesn't matter. Why would it not be safer? Somebody already debugged memcpy - if I write my own loop, I might make a mistake... –  Carl Norum Sep 20 '10 at 21:09
I've edited my answer with a full reply. –  Steven Sudit Sep 20 '10 at 21:25
add comment

Although you can't do this:

int x[ 3 ] = { 0, 1, 2 };  // an array of three items
int y[ 3 ];                // another array of three items

y = x;                     // compile error - y isn't a pointer that can be reassigned.

You can do this:

int *y = x;   // a pointer to an array

You're creating y as a pointer to the array x, rather than a copy of x. If you change the values of x, those changes will also appear when referencing y.

share|improve this answer
Nice explanation. –  Steven Sudit Sep 20 '10 at 21:06
add comment

You need to loop.

These are essentially fixed pointers, so you can't just assign one to another. You have to copy each value.


Here's why I don't recommend memcpy:

  1. It's not faster for any small number of elements; it will likely be slower.

  2. The version of memcpy he's using does not include any safeguards to prevent buffer overrun. It's very easy, even for non-novices, to confuse the number of elements with the total size of the elements, leading to a serious bug. It's less easy to mess up a for loop.

  3. Since this is just C, you can (usually) safely memcpy an element. If this were C++, you would want to ensure that the copy constructor was invoked. This makes the use of memcpy a bad habit.

In direct response to Carl:

  1. Yes, memcpy can be very fast for large arrays of simple data. This is not what we're dealing with here, though.

  2. I'm not concerned about bugs in memcpy, but the ease of having a bug in using it. It requires the count of bytes, but the natural thing would be the count of elements. A for loop would use the element count. On many platforms, there are safer versions that infer the buffer size and prevent overwrites; I'd recommend one of those, if possible, when memcpy is a good idea.

  3. If this were an array of C++ objects, such as std::string, then using memcpy instead of invoking the copy constructor would be a bug in itself. Yes, I do realize that the example is C, not C++, but that doesn't make it a good idea.

share|improve this answer
Mind explaining why you don't recommend memcpy when it will do the job for him? –  alternative Sep 20 '10 at 21:08
Why would memcpy be slower? Not explained. Point 2 is irrelevent since the size of the arrays are known to be 3 ahead of time. Point 3 is irrelevent because its C, not C++, but you pointed that out so its okay. –  alternative Sep 20 '10 at 21:25
Regarding point #2, most people would just use sizeof on the array, which just does the Right Thing in this case. As for using memcpy to copy arrays, it's a fairly commonplace C idiom. C++ is a different language with different rules; just because something is frowned upon there doesn't mean it is equally applicable in C. –  Pavel Minaev Sep 20 '10 at 21:28
If you're using C code thats compiling under C++, you are doing it wrong. –  alternative Sep 20 '10 at 21:39
@Steven Sudit If you require C++, its not C code. –  alternative Sep 20 '10 at 21:54
show 17 more comments

If two or more variables are declared as the same type of struct, and the definition of the struct contains arrays, the variables can be assigned to each other and the arrays will be copied in their entirety. Sometimes it may be handy to create a struct containing a single array, for precisely that purpose.

share|improve this answer
That's true, but it's going to involve a reinterpret_cast and only works for specific sizes. –  Steven Sudit Sep 21 '10 at 1:17
One can't assign between the array and the struct, but if one is always using a certain size of array for a certain purpose, using a "typedef" to define a struct type containing the array may be handy. On some embedded systems this may also improve code size; e.g. on PICC-18, a struct-to-struct copy will take seven words of code space; a "memcpy" will take twelve. –  supercat Sep 21 '10 at 14:34
Your mileage may vary, but I haven't found struct-to-struct copying to be highly optimized. If anything, it's something you generally try to avoid, in favor of const ref. –  Steven Sudit Feb 8 '11 at 3:35
@Steven Sudit: Generally from what I've seen, struct-to-struct copying is implemented using a memory-copy routine unless the structure is the same size as a primitive type. Usually the routine accepts parameters in registers rather than the stack, though; on 8-bit embedded compilers, the size is often a byte, even though memcpy() would require a word. As for const-ref, that's good for architectures with base-displacement addressing, and poor for architecutres which require manual multi-precision math for pointer offset computation but offer efficient direct accessing. –  supercat Feb 8 '11 at 16:22
@Steven Sudit: On one architecture I use, for example, incrementing an unsigned char foo would take 1-2 instructions, but incrementing ptr->foo (non-zero offset) would take 6-7 instructions. One need not use a structure very much before copying it becomes more efficient than passing and using a pointer to it. –  supercat Feb 8 '11 at 16:26
show 5 more comments

Roll them up in a struct (or union, in this case).

struct int3 {
    int A[3];

int3 x = {{ 0, 1, 2 }};
int3 y = x;

This will not generally result in better code from the compiler than doing individual copies of each element or using memcpy, and may result in worse code.

share|improve this answer
add comment

You need to loop or to call a library function that does that for you, e.g. memcpy/memmove.

share|improve this answer
add comment

There is no way built into the language. You can probably find a library call to do it, though. If it's something you're doing frequently, you could easily write the function yourself.

share|improve this answer
add comment

Your Answer


