How would you define an interface in C?

S

s0suk3

Some time ago I came across this:

http://developer.apple.com/document...rence/CFAllocatorRef/Reference/reference.html

It's an object that's created by specifying a generic pointer to user-
defined data, as well as a set of pointers to functions that perform
various memory management tasks (allocate, deallocate, etc.).

The object can then be used by clients to allocate memory
independently of what kind of user-defined data and function pointers
are associated with a particular instance of the type.

I thought it was a good idea so I implemented my own version of it and
have been using it in a program. A couple of days ago I realized that
the type uses a design pattern that's really analogous to what other
languages offer in the form of an "interface": a type that's used only
as a base type for other types, and that can't be instanciated, but
variables of the type can hold instances of types that are derived
from the interface. In Java, for example, the Allocator type shown in
the above page would ideally be defined something like this (for
simplicity, I'll only deal with three of the functions shown in the
page):

public interface Allocator {
public void* allocate(int size);
public void* reallocate(void* ptr, int newSize);
public void deallocate(void* ptr);
}

(I know that Java doesn't have void*, but I couldn't think of an
alternative :)

In C++ there are no interfaces, but the equivalent is an "abstract
class" (a class with pure virtual functions):

class Allocator {
public:
virtual ~Allocator() {}
virtual void* allocate(size_t size) = 0;
virtual void* reallocate(void* ptr, size_t newSize) = 0;
virtual void deallocate(void* ptr) = 0;
};

So the question is what the Subject says: how would you define such an
interface in C? The method shown in the Apple page works but is IMO
inflexible, because the Allocator is a concrete type, and so it
prevents several design techniques that are inherent to subtyping,
like for example deriving a type that implements only part of the
functionality.

Sebastian
 
C

cr88192

Malcolm McLean said:
By using structures that contain function pointers you can emulate any
type of object-orientation in C. However beyond the simple "interface"
design that allows no extension, but different functions for different
objects, it rapidly becomes cluntsy. All the table management has to be
done by yourself, and the code ceases to read as C. You are better off
moving to another language if you want inheritance hierarchies and the
like.

that, or to open a whole new set of issues:
the object system can be implemented as an abstract API, where one first
"defines" the classes and interfaces via function calls, and then proceeds
to create instances, call methods, ... with, in turn, more function calls...

I have an API which does this, which FWIW can be loosely compared with
JNI...


but, alas, using structs filled with function pointers to manipulate types
works fairly well in practice. this is typically how I implement "plug in"
capabilities in APIs, where one retrieves the struct for the type/... in
question, and fills in the relevant functions.

in general, it works a lot better than hard-coding everything, but alas, it
is often more effort initially than hard-coding things...
 
L

luserXtrog

On Jun 7, 12:55 am, (e-mail address removed) wrote:
So the question is what the Subject says: how would you define such an
interface in C? The method shown in the Apple page works but is IMO
inflexible, because the Allocator is a concrete type, and so it
prevents several design techniques that are inherent to subtyping,
like for example deriving a type that implements only part of the
functionality.

As others have noted, you /can/ pack a struct with function pointers.
But (depending on the complexity (YMMV)), this can often be overkill.
It can be much cleaner to implement method as simple functions with
a sensible naming convention. Since the struct has to be passed to
the function anyway --and unless you need real polymorphism-- it's
silly to call the function through the object.
Compare
obj->meth(obj);
with
obj_meth(obj);
Wait, dammit! That doesn't illustrate my point at all.
Um. I'm sorry. I was typing this during a dull part of I Spy.
But just then Bill Cosby said something really profound.

Back in the oven...
 
C

Chris M. Thomasson

C

Chris M. Thomasson

Chris M. Thomasson said:
Some time ago I came across this:

http://developer.apple.com/document...rence/CFAllocatorRef/Reference/reference.html

It's an object that's created by specifying a generic pointer to user-
defined data, as well as a set of pointers to functions that perform
various memory management tasks (allocate, deallocate, etc.).
[...]

Here is how I would implement abstract interfaces in C:

http://groups.google.com/group/comp.lang.c/msg/26fa846e943d8dc5


http://clc.pastebin.com/f52a443b1


IMVHO, the very simplistic technique can be fairly useful.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,905
Latest member
Kristy_Poole

Latest Threads

Top