Dynamically-expanding array in C

Ron Klein covered it pretty well, but here's a few more things:

Consider the struct an implementation detail, not part of the API

The consumer of your vector shouldn't need to be concerned with what the struct looks like. Nothing in the struct should ever be directly accessed by the user. In fact, I woudln't even expose the struct to the user. I would just forward declare it in the header, and not fully declare it except for in the implementation file.

.h:

struct DynArray;

typedef struct DynArray DynArray;

.c:

struct DynArray {
    ...
};

A consumer of the API should never need to know what is in the struct.

Stop trying to emulate objects

someDynArray->insert(someDynArray, i); is silly. Just use DynArray_insert (and others) directly:

DynArray_insert(someDynArray, i);

Note that storing function pointers in the struct is fine, but the user should never be calling them directly.

Your print function shouldn't exist

There's nothing wrong with a print function, but it shouldn't be part of the library. Imagine if you were to bundle this code up and distribute it. Do you think everyone who used it would want exactly the same format? There's no point in having a bundled print function.

DynArray_extend is wrong

You never have dynArr->arr = newArr;.

Multi-Variable Declaration

int newCapacity = dynArr->capacity * 2,
    *newArr = malloc(sizeof(int)*newCapacity),
    i;

There's nothing technically wrong with this, but it's fairly standard to only have one variable per declaration. Multi-variable declarations can get quite nasty and confusing when values/pointers/const/non-const all come into play in the same statement.

Consistent Naming

Why is createDynArray named how it is, yet everything else is named DynArray_*? I would go with DynArray_create.

There's no reason to dynamically allocate the DynArray

There will of course be situations where it's necessary, but there's no reason to force dynamic allocation.

Consider instead a usage like this:

DynArray da;
if (DynArray_Init(&da)) {
    //Success (or you could alternatively return 0 on success and then use non-zero for error codes)
}

Raw memory functions should only be paired with each other

This is completely opinion, but I believe that the low(ish) level memory functions should only be used together.

What I mean by this is that you shouldn't have a function for creating your struct and no function for freeing it. You actually need a function to free it for correctness, but even if you did not, it would be a good idea.

Abstracting away the freeing allows you to change the free-ing method at a later time seamlessly.

Consider Extending it to be Generic

You could easily extend this to be generic. It would make the API a bit more awkward to use, but it would be worth the reuse.

If you don't know where to start on that, this video should help. About 37 or 38 minutes in is when it becomes relevant (though the professor is doing a stack, not a vector). (I actually quite love that entire lecture series... :D)

In addition to what others have mentioned (good points raised by others), I'd like to talk about function pointers and vtables for a moment.

The first suggestion would be to not use them in this case. I would avoid using function pointers in the struct unless you really want the behavior to change at runtime from one buffer to another (i.e. the allocation strategy of buffer subclass A is different from B -- seems unlikely that you'd want this). Otherwise using the function pointers will cost you in CPU time, memory overhead, and source code readability.

If you did want to go the "function pointer in the struct" route, you can save memory by using more of a "vtable" approach. This pattern is used extensively by the Linux kernel, by COM, and by many C++ compilers when they implement virtual methods.

Instead of:

typedef struct DynArray
{
   // ...

   void (*extend)(struct DynArray *dynArr);
   void (*insert)(struct DynArray *dynArr, int val);
   void (*print) (struct DynArray *dynArr);
} DynArray;

You can do:

typedef struct
{
   void (*extend)(struct DynArray *dynArr);
   void (*insert)(struct DynArray *dynArr, int val);
   void (*print) (struct DynArray *dynArr);
} DynArrayOps;

typedef struct DynArray
{
   // ...

   DynArrayOps *ops;
} DynArray;

This means that there can be only one instance of DynArrayOps (maybe make it a static object in your .c file), and the memory overhead per DynArray is 1 pointer. (3 times less than your code).