Question

Having considerable trouble with some pointer arithmatic. I think I get the concepts (pointer variables point to a memory address, normal variables point to data) but I believe my problem is with the syntax (*, &, (*), *(), etc.)

What I want to do is build dynamic arrays of a custom struct (i.e. arrays of pointers to heap structs), and my interface provides two methods, “ad_to_obj_array” (which takes the object to add and the array which can be null for empty) and “obj_array_dustbin” (which just takes the array to dispose, also disposing of the contents, the heap objs). The former is rendered below.

The details of the objects are not important (and the struct has been renamed anyway) but my solution to the general problem is below, and I’d be grateful if you can spot the error. The compiler is complaining about an invalid lvalue, where I try and assign the address in the pointer on the RHS to the pointer value in an array of pointers to heap structs:

#define NUM_ELEM(x) (sizeof (x) / sizeof (*(x)))

obj* add_to_obj_array(obj* new_obj, obj* array)
{
  int number_of_elements = 0;
  if (array != NULL)
  {
    number_of_elements = NUM_ELEM(array);
  }

  obj* new_array = NULL;

  /* note: I am expecting sizeof(new_obj) to return the size of an obj* 
     to go into the array of pointers. */
  if ( NULL ==
       (new_array = (obj*)malloc((number_of_elements + 1)* sizeof(new_obj))) )
  {
    /* memory request refused :( */
    return NULL;
  }

  /* copy the old array pointers into the new array's pointer slots: */
  int i;
  for (i = 0; i < number_of_elements; i++)
  {
    &(new_array[i]) = &(array[i]);
  }

  /* add the new item to the end (assign pointer value directly): */
  new_array[number_of_elements] = new_obj;

  if (number_of_elements > 0)
  {
    free(&array);
  }

  return new_array;
}

Now, I have tried the following permutations of the offending line:

  &(new_array[i]) = &(array[i]);
  *(new_array[i]) = &(array[i]);
  new_array[i] = &(array[i]);

and all give a compiler error of one sort or another. I am fairly sure that the right hand side is the address of the ith element of the old array, but how to I assign to the ith element of the new, when the elements of the array are pointers to structs?

EDIT – please note, the macro NUM_ELEM above DOES NOT WORK; it will always return 1. See @Merlyn Morgan-Graham’s answer below for why.

Answer 1

Based on your description, you’re starting off wrong, so by the time you get to copying things, nothing you can do is likely to work.

Right now, you’ve defined new_array (and, presumably, array) as a pointer to obj. The result looks like this:

In this case, you have a pointer to a dynamically allocated array of objects. When/if you expand the allocation, you’ll need to copy all the objects themselves.

According to your description: “(i.e. arrays of pointers to heap structs)”, what you want is an array of pointers. If you want to allocate that array of pointers automatically, your definition would look like:

obj *array[NUMBER];

My guess is that’s not what you want though. Presumably, you want to allocate that array dynamically as well. That would look like this:

In this case, new_array and array will each need to be defined as a pointer to pointer to obj. You’d then allocate an array of pointers (i.e., pointers to as many objs as you want) and have each point point at an obj:

obj **new_array;

// allocate an array of pointers with space to point at more items:    
new_array = malloc(sizeof(obj *) * new_elements);

// copy the pointers to the current items to the new array:
for (i=0; i<current_elements; i++)
    new_array[i] = array[i];

The advantage of this is that when you do the copying, you only copy pointers, not the objects themselves. Especially with large objects, this can save a substantial amount of effort. The tradeoff is that using an element goes through two levels of indirection intead of one, so the reference may be slower (though rarely much slower, especially on a relatively high-performance processor).

As @rerun already pointed out, in either case you probably want to use realloc. In particular, this might be able to expand an allocation “in place”, and avoid copying data as often. Of course, that’s not guaranteed, but at least you’re giving it a chance; if you malloc and copy every time, you eliminate even the possibility of that optimization.