0

I have so many 2D arrays with different name like

const int a[][2]
{
    {1,2},
    {3,4},
};
const int b[][2]
{
    {5,6},
    {7,8},
};

and so many .... I took the array name in other variable like

int t_huff,f_huff;

t_huff =a;
f_huff =b;

now I want to write a function in which recived the argument(array name) and then use the argument in the switch case

function_name(string name)
{
switch(name)
{
case a:

break;

case b:

break;
}
}

but when I am doing this I got some warning like warning C4047: '=' : 'int' differs in levels of indirection from 'const int (*)[2]'

please help me to remove this warning from my project

Yu Hao
  • 119,891
  • 44
  • 235
  • 294
  • 5
    You are trying to do reflection, which C does not support. You cannot start with a string and get a C variable. Also, your code does not do what you seem to think it does. The reason for your warning is that you are trying to assign an `int*` to an `int`. Your comments suggest that you think `t_huff =a` is setting `t_huff` to the name of the array `a`. That is not even remotely what it does. – Gort the Robot Aug 14 '14 at 04:19

2 Answers2

0

You probably need to use a pointer-to-array, but it would be easier to use a pointer-to-int. As noted in a comment, you can't simply map string names to variables; you really don't want to write the code out multiple times, anyway.

Option 1: Pointer to int

void function_name(int *base)
{
   int i = 0;
   int j = 1;
   int v = base[i * 2 + j];
   …
}

Call it using:

function_name(&a[0][0]);
function_name(&b[0][0]);

Option 2: Pointer to array

void function_name(int (*arr)[][2])
{
    int i = 0;
    int j = 1;
    int v = (*arr)[i][j];
    …
}

Call it using:

function_name(&a);
function_name(&b);

The advantage of the pointer-to-array is that you can use the subscripts as normal (more or less; you need to use the (*arr) notation, though).

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
  • Isn't option 1 *technically* undefined behavior? – Drew McGowen Aug 14 '14 at 05:42
  • @DrewMcGowen: What do you think constitutes the undefined behaviour? It all looks 100% kosher to me, but I'm not at all sure what you might be thinking is undefined behaviour. – Jonathan Leffler Aug 14 '14 at 05:44
  • I'm referring to [this](http://stackoverflow.com/a/2834306/2478565) answer, which suggests that a pointer to `a[0][0]` can only be used to iterate through the first row, not the entire array. – Drew McGowen Aug 14 '14 at 05:47
  • @DrewMcGowen: AFAIAC, the accepted answer in [Does C99 guarantee that arrays are contiguous?](http://stackoverflow.com/questions/2832970/does-c99-guarantee-that-arrays-are-contiguous) is bullshit. It isn't clear from the question quite what they're casting to an `int *`. I'm not casting anything to an `int *`; I'm simply taking the address of an integer, and then using that as the start of an array. The calculation my code does is what the compiler does behind the scenes. I simply don't believe that it is undefined behaviour. (I don't have the energy to debunk it over there tonight, though.) – Jonathan Leffler Aug 14 '14 at 05:55
  • And honestly, I would be surprised if it *was* considered undefined behavior, based on the requirement of array contiguity. However, as I have discussed with others earlier, I'm not 100% certain whether it's possible for two pointers to "compare" the same (i.e. `p == q`), but one has different bounds than the other. – Drew McGowen Aug 14 '14 at 06:01
-1

You can't do like that. You need to take array variable t_huff[]. And you can name a by t_huff as &t_huff=a;