If you are using C++ you might look into using the boost multiarray class. It will take care of many of these issues, and you can use it the same way ie. with multiple bracket operators [][][][][][][][]... Brian On 5/15/06, andre maute <andre.maute@xxxxxx> wrote:
On Monday 15 May 2006 13:32, John Love-Jensen wrote: > Hi Andre, > > I have not run into the number-of-dimension limit of the compiler. > > But I've never tried 8 (or more) dimensions! I investigated it further and i can limit it to 9 dimensions > > I don't think the ISO 9899:1999 (C99) or ISO 9899:1989 (C89) have limits on > the number of dimensions. I presume the only constraint is available > memory for your architecture. that would be nice > > Calculate out how many bytes of storage your technique will utilize: > sizeof(double) * n1 * n2 * n3 * n4 * n5 * n6 * n7 * n8; > Is that within the constraint of your platform? For instance, PC-DOS that > limit would be 65536 bytes. My system is a i686-pc-linux-gnu with enough memory. I thought that perhaps the compiler needed a maximum dimension constraint. > > Also note: putting arrays (or any sort of data) in header files is > strongly discouraged. If two different source files include that same > header file, each translation unit will get its own copy of that data. > Header files are for declarations of things (no storage reserved), not > definitions of things (bytes of code or data allocated). I know. Perhaps the best way for such a big array is to create a file e.g called bigarray.cc and one bigarray.h where the array is declared extern. > > Also, as mentioned already, putting large arrays on the stack is > discouraged, because the stack is usually significantly smaller than the > heap (or in C++ lingo, the global store). I don't put them on the stack, so ... > > Sincerely, > --Eljay Thank you for your kind response, regards Andre
