The reason to hide the types behind void
pointers could be a (misguided) attempt to hide (in the sense of modular programming) the internal details. This is dangerous, as it throws any type checking the compiler might do right out the window.
Better would be something along the lines:
for-user.h
:
struct internalstuff;
void somefunc(struct internalstuff *p);
for-internal-use.h
:
#include "for-user.h"
struct internalstuff { ...};
implementation.c
:
#include "for-internal-use.h";
void somefunc(struct internalstuff *p)
{
...
}
This way nobody will mix up internalstuff
with a random string or the raw result from malloc(3)
without getting at least a warning. As long as you only mention pointers to struct internalstuff
in C it is fine not to have the definition of the struct
at hand.
Something along the same lines can be done in C++ with class
, and I'd be suprised if Objective C doesn't allow the same. But the object oriented programming languages have their own, much more flexible, tools for this. There you can define a bare-bones base class to export, while internally extensions are used. Take a look at a good C++ book for details (there are extensive lists here).