Check out realloc().

#include <stdlib.h>;#include <stdio.h>int main(){   /* Get a pointer to some memory of an adequate size for 16x16 copies      of a struct MapFormat. Note that no cast is needed as malloc returns      void*. */    if(!struct MapFormat *Map = malloc(16 * 16 * sizeof(struct MapFormat)))    {        printf("Insufficient memory for allocation. Terminating.");        exit(1); // Return 1 as an error value    }        // Do whatever with Map    if(!Map = realloc(Map, 128 * 128 * sizeof(struct MapFormat)))    {        printf("Insufficient memory for reallocation. Terminating.");        exit(1);    }    free(Map);}

EDIT: Tidied code up: checking for NULL, freeing Map.

You can't resize an array in C, their size is set at compile time.

You can have a dynamically-sized array-like memory region, but you have to use memory allocation. Master it and move on. Don't let the technology master you. You will be all the happier for it.

It is true, you absolutely cannot resize a "vanilla" array. However, you could use a linked list or a vector, both of which can be resized and neither of which is all that difficult to use.

You cannot resize an array that is statically declared like your code sample.

You CAN resize a heap-allocated block of memory. However, you cannot use two-dimensional syntax, so you have to calculate the address yourself.

Contrary to what Gullanian said, there is no speed difference between statically declared arrays, and arrays-in-vectors.

Something like this:

struct Array {  MapFormat * element;  size_t width;  size_t height;};void init_array(Array * a, size_t width, size_t height) {  a->element = (MapFormat *)calloc(sizeof(MapFormat), width*height);  a->width = width;  a->height = height;}MapFormat * get_element(Array const * a, size_t x, size_t y) {  if (x >= a->width) return NULL;  if (y >= a->height) return NULL;  return a->element + x + y * a->width;}void resize_array(Array * a, size_t nuWidth, size_t nuHeight) {  MapFormat * nuElem = (MapFormat *)calloc(sizeof(MapFormat), width*height);  for (size_t y = 0; y < min(a->height, nuHeight); ++y) {    for (size_t x = 0; x < min(a->width, nuWidth); ++x) {      nuElem[x + y * nuWidth] = a->element[x + y * a->width];    }  }  free(a->element);  a->element = nuElem;  a->width = nuWidth;  w->height = nuHeight;}

It looks like you want to load a map during runtime. Why not include a file header that declares the size of the map, and then allocate however much you need?

Quote:Original post by hplus0603
You cannot resize an array that is statically declared like your code sample.

You CAN resize a heap-allocated block of memory. However, you cannot use two-dimensional syntax, so you have to calculate the address yourself.

[emphesis added]

While multi-dimensional allocations are not supported directly, it is possible, though not straight forward, to simulate them.

To allocate a HxW array of ints -- outined briefly:

int** array = malloc(sizeof(int *) * H);int* rows = malloc(sizeof(int) * W * H);for(i = 0; i < H; i++)  array = rows + (i * W);

I don't have a compiler to test this in front of me, however this should be the gist of how it works. To the compiler, a statically-defined multi-dimensional array acts just an array of arrays anyhow, so allocating one manually provides the same results, though it does take a few extra steps and a little more memory.

That said, taking into account that you admit to your shortcomings with memory allocation, its much easier to allocate a single contigious block of memory and to calculate the given row-column position yourself; you can even write a generic function to do so. In this way, you will have 1 allocation, 1 de-allocation, and only 1 chance for a dangling pointer (this simulated multi-dimensional array above is 2, 2, and H+1 respectively.) Calculating the address yourself is also likely faster as it requires one less look-up, yielding one less chance for a cache-miss and keeping your memory accesses localized (good for your cache.) This is the approach I recommend.

The "Easy Way Out", if you know the maximum size of the array and the memory requirements aren't too high, is to simply statically allocate an array large enough for the biggest possible map, but only fill what you need. Stylistically this is bad, but it will work from a practical standpoint. A 256x256 array of integers, for example, is only 256KB (a quarter of a megabyte), and memory is not a limiting factor today like it used to be in the past.

Back in my DOS programming days I had to write a paging system for my RPG engine because I wanted a 4-layer map that could be up to 256x256 tiles. Each layer was a full 64k (using 8bit indices) for a total of 256k for a single map. This was back in the 16bit days, and your application (after DOS, drivers and other services loaded) had about 384-512 K to play in... A Traditional, static approach would have left me 128-256 K for all my code, graphics, scripts, sounds and other data. Clearly this was too limiting so the paging system was born. Today there's little reason to worry too much about a measly 256K - unless you're on the GBA, DS, or some other older, limited platform.