   C++ float**
  I am not sure if this is legal or safe to do...//float** Foo();float** f = Foo();for(int i = 0; i < 1000; ++i)std::cout << f << std::endl;Do I need to use f[][] notation or can I use the single bracket notation to access all elements in the pointer array?Thanks   
  Whether or not it is safe depends on what exactly f is pointing to. However, what will get printed will just be pointer addresses, which probably isn't what you want.   ;  Yeah, it really depends on what Foo is returning, and if you're trying to print out numbers or addresses.float** Foo(){  static float data[1000];  return &data;}float** f = Foo();for(int i = 0; i < 1000; ++i)  std::cout << (*f) << std::endl; float** Foo(){  static float* data[1000];  return data;}float** f = Foo();for(int i = 0; i < 1000; ++i)  std::cout << *(f) << std::endl;;  An array decays to a pointer under most circumstances-- that is, despite having type int[3], it will convert itself to int*, without even being explicitly asked. Semantically, this is almost entirely unnoticeable. It doesn't matter whether in the expression arr[idx], arr decays to a pointer and then is dereferenced with the pointer indexing operator, or whether arr remains an array and is dereferenced with an array indexing operator. The two behaviors would produce equivalent results.It's not always so transparent, though. In order for an int** ptr to pretend it's a real 2D array, ptr needs to point to an array of pointers, each of which points to its own array of ints (the rows in the 2D array). A real 2D array doesn't need that extra first-lookup-array; in the expression arr[j], the subexpression arr becomes a pointer to a row despite not actually performing a lookup anywhere (it's just a matter of simple arithmetic). Thus, &ptr[0] will work because there is actually the array-of-rows somewhere in memory, whereas &arr[0] will not, because there isn't (because there doesn't need to be).The upshot of all that: 2D "arrays", in their several forms, are confusing and yucky. Ignore their existence. Use 1D arrays and [y*w+x]-style addressing. Or make a class to do it for you. Or use someone else's class to do it for you.;  I agree with you Sneftel... Problem is this is someone else Lib I am using and they have alot of struct** types as return types from functions. I myself use one large 1D array and like you said index with pointer math, but makes no difference as this isn't my choice. ;)Anyway I think its working but will have to ask the devs why they did it this way and how they intended it to be used.THanks and you info was very informative.   ;Quote:Original post by SneftelIn order for an int** ptr to pretend it's a real 2D array, ptr needs to point to an array of pointers, each of which points to its own array of ints (the rows in the 2D array).You do not need an array of pointers if you know the size of the second dimension at compile time.int real_2d[25][40];int (*pointer)[40] = real_2d;This seems to come up every few weeks. Maybe we need a FAQ for multidimensional arrays? :)   ;Quote:Original post by DevFredQuote:Original post by SneftelIn order for an int** ptr to pretend it's a real 2D array, ptr needs to point to an array of pointers, each of which points to its own array of ints (the rows in the 2D array).You do not need an array of pointers if you know the size of the second dimension at compile time.int real_2d[25][40];int (*pointer)[40] = real_2d;This seems to come up every few weeks. Maybe we need a FAQ for multidimensional arrays? :)Agreed, but I was told one reason they used this format was this"subsequent allocations (read: need for deep copy)";Quote:Original post by MARS_999I was told one reason they used this format was this"subsequent allocations (read: need for deep copy)"A more probable reason is that most people are not familiar with pointers to arrays. Again, if you know the sizes of all dimensions except the first, you can use pointers to arrays. This has nothing to do with deep copies.   