   Interfaces in C
  I was playing around with C, and I got to wondering: A lot of C interfaces are accessed via integer id's, like so:intType objectId = CreateObject();ObjectSetVal(objectId, 5);// ...DeleteObject(objectId);Is there a standard way of implementing this kind of interface?  Is there a specific name for it?For instance, how are id numbers generated and how does the underlying implementation find the desired object based on an id number?My first guess would be that this kind of interface uses an array of objects and assigns id numbers based on how many objects have been created and what objects have been removed, but I really don't know.I suppose any kind of associative data structure would work, but I also imagine that the underlying implementation uses something simpler than, for example, a map, considering how basic most of these libraries are.I've tried searching teh googles, but I haven't found anything useful, other than a not-so-free book or two.Thanks in advance for any information.-Chris   
  I'm not certain this has a name, but this is a typical procedural handle-based system. These systems generally have an array (dynamic or static) which either contains the manipulated objects (if they have the same size) or pointers to these objects (which may reside on the system heap or in a self-managed big-old-buffer). This is generally combined with a 'free handle' list or array, which contains indices that have been freed. If this list is empty, allocation uses the current largest index plus one.   ;  Easiest way is to return the pointer, disguised as something, or just as a void*. Saves you from having to associate IDs with objects.   ;Quote:Original post by outRiderEasiest way is to return the pointer, disguised as something, or just as a void*. Saves you from having to associate IDs with objects.Easy, but hard to debug. Returning an index into an array of pointers means that the library can check the bounds of the index to ensure that a bad handle wasn't passed.   ;Quote:Original post by Nathan BaumEasy, but hard to debug. Returning an index into an array of pointers means that the library can check the bounds of the index to ensure that a bad handle wasn't passed.And it can also do internal realloc or defragmentation voodoo, which isn't possible with raw pointers.;  Every type of data structure can do the job. What data structure to use depends of the needs of your application. If you create few objects and rarely a simple dynamic array is enough. If your needs are more complex a map can be better.Returning an handle isn’t the only way to write an OOP library in C. You can also return the object like in the following example:Object *object = new_object();object_set_val(object, 5);/* ... */delete_object(object);;  I am unsure whether there is a more specific name, but this is a variation on the common handle-body idiom.  Basically you pass around light weight handles (in this case integer IDs) that in some way point to a 'body' implementation (hidden behind the interface) that does the real work.The wonderous thing about having an interface is that the implementation can change without needing to change how the user/client interacts with the system.So there is no standard way to implemenent the system, for example I use this idiom in my renderer, I have an implementation for OpenGL, for D3D9 and D3D10 and they all return integer handles:OpenGL implemetation - OpenGL returns integers handles itself anyway so this handle is passed straight through: myIntHandle = OGLIntHandle;D3D9 implementation - Like you described I have an array of items and the integer handle is just the index into the array, the more things in the array the higher the value of the integer, I can reuse slots in the array using a method like ToohrVyk explained.D3D10 implementation - In D3D10 I have the option of casting the pointers into integers, I'm still working on this implementation but that's a probable route I'll take.In all cases the interface is the same and the way the integer values are generated is different, more complex data structures could be used if they make sense, as I said at the start there is no 'standard' method.Hope that helped clarify things for you [smile]   ;  Thank you all for the replies!Quote:Original post by ToohrVykI'm not certain this has a name, but this is a typical procedural handle-based system. These systems generally have an array (dynamic or static) which either contains the manipulated objects (if they have the same size) or pointers to these objects (which may reside on the system heap or in a self-managed big-old-buffer).This is generally combined with a 'free handle' list or array, which contains indices that have been freed. If this list is empty, allocation uses the current largest index plus one.For some reason the term "handle" never came to my mind when I was thinking about this.  That may help me search for related information a little more effectively.I've used that type of handle system before in some of my own projects, and indeed, it does look like a good fit for this kind of interface.Quote:Original post by outRiderEasiest way is to return the pointer, disguised as something, or just as a void*. Saves you from having to associate IDs with objects.Bah, I didn't even think about that!  Obviously it isn't ideal for every application, and, as Nathan pointed out, it's kind of dangerous, but it is a very simple and elegant solution.Thanks again for the input, everyone.  ;Quote:Original post by extralongpantsQuote:Original post by outRiderEasiest way is to return the pointer, disguised as something, or just as a void*. Saves you from having to associate IDs with objects.Bah, I didn't even think about that!  Obviously it isn't ideal for every application, and, as Nathan pointed out, it's kind of dangerous, but it is a very simple and elegant solution.When using pointers rather than a special handle value, one handy technique is to use forward-referenced typedefs to hide the implementations. For example:// myobject.htypedef struct MyObject_s MyObject;MyObject *MyObject_New();void MyObject_Delete(MyObject *obj);// myobject.cstruct MyObject_s{   int x;};MyObject *MyObject_New() {...}void MyObject_Delete(MyObject *obj) {...}Of course, nothing is ever truly hidden when dealing with pointers, but this allows simple data hiding. This also helps you to keep from crowding the global namespace and, in larger projects, helps reduce compile times by cutting down on the number of includes. For example, a log object that has a FILE* member would require stdio.h to be included by every module that uses it. You can cut out a lot of includes by keeping things internal to a single source module this way.   ;Quote:Original post by AldacronQuote:Original post by extralongpantsQuote:Original post by outRiderEasiest way is to return the pointer, disguised as something, or just as a void*. Saves you from having to associate IDs with objects.Bah, I didn't even think about that!  Obviously it isn't ideal for every application, and, as Nathan pointed out, it's kind of dangerous, but it is a very simple and elegant solution.When using pointers rather than a special handle value, one handy technique is to use forward-referenced typedefs to hide the implementations. For example:*** Source Snippet Removed ***Of course, nothing is ever truly hidden when dealing with pointers, but this allows simple data hiding. This also helps you to keep from crowding the global namespace and, in larger projects, helps reduce compile times by cutting down on the number of includes. For example, a log object that has a FILE* member would require stdio.h to be included by every module that uses it. You can cut out a lot of includes by keeping things internal to a single source module this way.Good point.  I hadn't really thought about that advantage being inherent to the interface.