array for realview compiler

#28: expression must have a constant value

#28: expression must have a constant value

Which is, as Tamir said, a basic factor of the way that arrays work in the 'C' programming language!

Dynamic memory allocation requires that the processor do have the required amount of memory.

That also means that you could instead define a maximum allowed size, and create a statically allocated array of this maximum size.

If you can't afford to waste the memory for a static allocation of maximum allowed size, then it is very questionable if you can afford to allocate such an amount using dynamic memory, unless your program have two types of memory requirements, and when one of them needs to be large, the other will instead always manage with a small size, and reverse.

Another thing. Sometimes it is good to use a two-dimensional array. Sometimes it may even be better to have a one-dimensional array, and have the application select this single index based on the the two original indices. Note that the code generated by the compiler will somehow have to compute (I*stride + J)*element_size internally, when mapping into a specific element. But the one-dimensional array allows you to change the stride size during runtime. You could have a 100*10 array or a 10*100.

"when one of them needs to be large, the other will instead always manage with a small size, and reverse."

In which case you may be able to use a statically-allocated union...

Note that my comment was about dynamic memory allocation - that the only situation where two static variables of maximum size doesn't fit, but two dynamic allocations fit, is if one of the dynamic calls is large when the other is small, i.e. the two variables following some form of A*N and (M-B*N).

For situations where both dynamic allocations are large, then neither dynamic nor static allocation can solve the problem. For situations where both allocations are small, it will be trivial to use static allocations instead.

For the case when one variable needs to be large when the other is small, I wouldn't try to use a union and definitely not traditional dynamic memory. I would instead use a fixed-size memory block and set a pointer x bytes/elements into the block for the second variable, thereby allowing me to configure the subdivision position depending on runtime information. Since the block has a fixed size, I would be able to compute beforehand if the two variables will fit after each other, instead of having to test a dynamic allocation and check for a NULL pointer. And I wouldn't need the overhead of the dynamic memory allocation/release code. And the code can't suffer from fragmentation.

A union would be a bit boring, since it would be something like:

union {
    struct { small_A, large_B; } alt_1;
    struct { medium_A, medium_B; } alt_2;
    struct { large_A, small_B; } alt_3;
    ...
};

where the code may need a large number of in-between subdivisions, and would then need code to - at run time - gets access to alt_1.small_A, or alt2.medium_A, or alt3.large_A, or ...