I have a library in C where the API uses "objects" to interact with the application. These "objects" are opaque pointers that are created, destroyed, and modified via API calls.
These "objects" do not exist in a hierarchy and their lifetimes are loosely managed. As a result, the library has to keep pools of these objects and track of which ones are being used and which ones aren't. This requires that the library has some sort of state for managing these pools.
My current solution use a global state to manage them, like so:
initializeLibrary(); Object *obj = createObject(); //Do something with obj destroyObject(obj); terminateLibrary();
However, it's entirely possible to make the library not rely on global state:
Instance *instance = initializeLibrary(); Object *obj = createObject(instance); //Do something with obj destroyObject(obj); terminateLibrary(instance);
My reason for using a global state is that it's easier to read the code when I'm not passing around an instance variable everywhere. Generally the reason given for why global states are bad is that it results in unpredictable behavior, but I don't think that applies here.
My question is whether or not my use of global state is a bad design choice.