Copying 2D array contents into another 2D array

[rill17]

Hi, i need to copy the contents of a 2D array into another 2D array of the same size on a microcontroller. i tried an iterative approach using for loops as shown in the code below but it doesn't work. Any ideas?
int a = 0;
for( a=0; a<7; a++);
{
          int b = 0;
          for (b=0; b<256; b++);
          {
                    pulse_b[a] = pulse[a];
           }
}

[Farley]

for( a=0; a<7; a++);
.
.
.
for (b=0; b<256; b++);

Remove the semicolons at the ends of the quoted lines.
Also, check the logic of what you're attempting. Research 2d arrays.

[RoGeorge]

For max speed I would use sizeoff and memcpy.
Carefull with memcpy, it is fast, but tricky.

[sokoloff]

Once you remove the semicolons as Farley notes, you will find that your code is copying each of the 7 elements (0 through 6) from the first array into the second array, 256 times.

(Inside the inner loop, you do the same assignment 256 times.)

For two-D arrays, you'll need the inner statement to look something like:

Code: [Select]

pulse_alternate[a][b] = pulse [a][b];
or

Code: [Select]

pulse_alternate[a*DIM + b] = pulse[a*DIM + b];
where DIM is the size of the array along the "b" dimension (in this case, 256).

Edit: Added code blocks to make clear what I was writing.

[ynfo]

There are no 2D arrays in your code!

2D arrays have 2 indices e.g. a[1][2]

[timothyaag]

He's not using a code block, but if you quote him you can see he's actually doing this:

Code: [Select]

pulse_b[a][b] = pulse[a][b];

[wraper]

Remove the semicolons at the ends of the quoted lines.

This

Also, check the logic of what you're attempting. Research 2d arrays.

What he posted was crippled by the forum:

He's not using a code block, but if you quote him you can see he's actually doing this:

Code: [Select]

pulse_b[a][b] = pulse[a][b];

+1

[brucehoult]

Hi, i need to copy the contents of a 2D array into another 2D array of the same size on a microcontroller. i tried an iterative approach using for loops as shown in the code below but it doesn't work. Any ideas?

Code: [Select]

int a = 0;
for( a=0; a<7; a++);
{
          int b = 0;
          for (b=0; b<256; b++);
          {
                    pulse_b[a][b] = pulse[a][b];
           }
}


Don't do this:

Code: [Select]

int a = 0;
for( a=0; a<7; a++);

Do this:

Code: [Select]

for(int a=0; a<7; a++);

I suspect you started with that, and the compiler told you there was a problem that a (and b) were not defined in the

Code: [Select]

pulse_b[a][b] = pulse[a][b]; line.

But you didn't understand what the compiler told you and "fixed" it in entirely the wrong way.

[rill17]

yeah the code i am using is without the for loop semicolons and was modified due to the post shortcuts, the actual code is as follows

Code: [Select]

int a = 0;
                                for( a=0; a<7; a++)
                                {
                                    int b = 0;
                                    for (b=0; b<256; b++)
                                    {
                                        pulse_b[a][b] = pulse[a][b];
                                    }
                                }ill try the memcpy and your other suggestions and report back, thanks

[wraper]

Do this:

Code: [Select]

for(int a=0; a<7; a++);


First of all
for(int a=0; a<7; a++); will not work with many compilers.
Secondly, don't do this:
int a;
for(a=0; a<7; a++);
{
...
}
Do this:
int a;
for(a=0; a<7; a++)
{
...
}

[rill17]

for anyone following, the simplest and most efficient way i found which works is by ditching the for loops and using memcpy. the following code works:

Code: [Select]

int i;
  for(i = 0; i<7; i++)
memcpy(&pulse_b[i], &pulse[i], sizeof(pulse[0]));
}still cant figure out why the for loops didn't work though, thanks for the help

[sokoloff]

Don't stop here. (IMO)

Now that you have a way that works, power through and figure out why the "other" way that should have worked didn't.

Post your new (but broken) code here in a code block and we'll help you figure it out.

[MK14]

still cant figure out why the for loops didn't work though, thanks for the help

(as others are trying to explain)
The for loop, continually repeats the NEXT statement block.

So if you go for (..............) ;

The statement block is empty, so it does NOTHING. i.e. the semi-colon ends the statement block.

for (i = 0; i < 1000000; i++) ;
x = x + 1;

would just increase x by ONE not a million.

for (i = 0; i < 1000000; i++)
x = x + 1;

or better still

for (i = 0; i < 1000000; i++)
{
  x++;
}

would increase x by a million.

[Nusa]

For two identically sized arrays, it's as simple as:

Code: [Select]

memcpy(pulse_b, pulse, sizeof(pulse));


[sokoloff]

Also, find the compiler setting that will emit a warning for "empty if body" and "empty loop body".

For bonus points, turn on both that and "treat warnings as errors" (assuming you can find the pragmas to disable specific warnings that you cautiously verify as safe.

[helius]

for anyone following, the simplest and most efficient way i found which works is by ditching the for loops and using memcpy. the following code works:

Code: [Select]

int i;
  for(i = 0; i<7; i++)
memcpy(&pulse_b[i], &pulse[i], sizeof(pulse[0]));
}still cant figure out why the for loops didn't work though, thanks for the help

If the arrays were declared in the normal way, like

Code: [Select]

int pulse[48][48];then the elements will all be contiguous. You don't need to call memcpy() once per row, but can just call it once for the array.

Code: [Select]

memcpy(pulse_b, pulse, sizeof(pulse));This won't work if the array was really declared as an array of pointers:

Code: [Select]

int *pulse[48]; because the memory need not be contiguous.

[TNorthover]

First of all
for(int a=0; a<7; a++); will not work with many compilers.

Really, really shitty compilers, to the extent that I'd not touch the chip with a barge pole if that was all that was available. The standard revision that added support is 18 years old already (more if you count C++), and if that's not supported yet I wouldn't trust them to get anything else right either.

[helius]

Really, really shitty compilers, to the extent that I'd not touch the chip with a barge pole if that was all that was available. The standard revision that added support is 18 years old already (more if you count C++), and if that's not supported yet I wouldn't trust them to get anything else right either.

Code: [Select]

> gcc test.c
test.c: In function ‘main’:
test.c:11:3: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
   for (int i=0; i<12; ++i)
   ^
> cc -v
gcc version 4.9.2 (Debian 4.9.2-10)

[TNorthover]

Code: [Select]

> cc -v
gcc version 4.9.2 (Debian 4.9.2-10)

On modern systems the tool names dating from early UNIX (cc, cc1, ...) are often wrappers that tell the real compiler to use ancient standards so that old code still compiles. The underlying compiler is quite capable of supporting C99.

Newly written code shouldn't be using that (at least not without a -std=something_sane argument).

[helius]

On modern systems the tool names dating from early UNIX (cc, cc1, ...) are often wrappers that tell the real compiler to use ancient standards so that old code still compiles. The underlying compiler is quite capable of supporting C99.

On this system cc is not a wrapper. It is a symbolic link, as gcc is also.

Code: [Select]

lrwxrwxrwx 1 root root 20 May  1 16:32 /usr/bin/cc -> /etc/alternatives/cc
lrwxrwxrwx 1 root root     12 May  1 16:32 /etc/alternatives/cc -> /usr/bin/gcc
lrwxrwxrwx 1 root root  7 Feb 25  2015 /usr/bin/gcc -> gcc-4.9
It makes no difference which you type, because all these links act exactly the same.

Newly written code shouldn't be using that (at least not without a -std=something_sane argument).

-std=gnu90 is the default, which is C89. It stayed that way for a very long time, until GCC 5.1.0 changed it recently.

[TNorthover]

On this system cc is not a wrapper. It is a symbolic link, as gcc is also.

Same thing, or at least I decided not worth noting the difference unless you're trying to implement this kind of thing. You can either have a real wrapper of some code to look at argv[0] to decide how to behave.

(I do believe you that this particular behaviour doesn't change for you, especially as it doesn't for me on Linux. macOS isn't so lucky: cpp is a wrapper that implements a pre-ANSI preprocessor!)

It stayed that way for a very long time, until GCC 5.1.0 changed it recently.

Thank goodness. It should have happened a long time ago.

[brucehoult]

On modern systems the tool names dating from early UNIX (cc, cc1, ...) are often wrappers that tell the real compiler to use ancient standards so that old code still compiles. The underlying compiler is quite capable of supporting C99.

On this system cc is not a wrapper. It is a symbolic link, as gcc is also.

Code: [Select]

lrwxrwxrwx 1 root root 20 May  1 16:32 /usr/bin/cc -> /etc/alternatives/cc
lrwxrwxrwx 1 root root     12 May  1 16:32 /etc/alternatives/cc -> /usr/bin/gcc
lrwxrwxrwx 1 root root  7 Feb 25  2015 /usr/bin/gcc -> gcc-4.9
It makes no difference which you type, because all these links act exactly the same.

Boy are you going to get a surprise when you learn how ccache works. Or busybox.

Or, to be more historical, ex and vi, which both link to the same executable, and always have, but behave differently.

[helius]

Boy are you going to get a surprise when you learn how ccache works. Or busybox.
Or, to be more historical, ex and vi, which both link to the same executable, and always have, but behave differently.

Not at all. The sources for gcc aren't exactly a government secret: you can see for yourself that it does not care what argv[0] is when selecting a language standard (within the C family; it does behave differently for ADA et cetera).