[clug] Object-Oriented C?

[Michael Cohen]

Hi Paul,
  I have been using object oriented programming in ANSI C for a while now. Its really quite simple to 
use and you do get the full gammit of things you expect with normal object oriented languages, for 
example inheritance and even introspection (yeah you can ask an object what type it is and list its 
methods as strings etc).

For more information look at:

http://pyflag.sourceforge.net/pyflag/src/lib/class.c

http://pyflag.sourceforge.net/pyflag/src/include/class.h

It also uses talloc to attach destructors for automatic memroy management (but that is another story).
The idea is to hide all the unpleasant stuff in macros and to add information about the objects 
automatically. You might spot the great resemblence to python in this scheme.

For example you can always find out the current object name (a string) by doing object->__name__. The 
current class where the object was instantiated from by doing object-->__class__ and the super class of 
the object (where it was derived from) object-->__super__ . There is even an obj-->__doc__ !!! this is 
great in gdb when you need to figure out what kind of object you are actually looking at in memory.

Once you get used to developing with this scheme its really as simple as developing in python, but with 
native C speed.

A great example of using this is in StringIO classes:

http://pyflag.sourceforge.net/pyflag/src/include/stringio.h

which makes a memory buffer look like a file. This really simplified lots of string like operations like 
fifo, stack etc.

Michael.

On Wed, Feb 22, 2006 at 01:17:06PM +1100, Paul Wayper wrote:
> Hi all!
> 
> I wanted a set of C functions that could display and control a simple
> 'progress bar' on the (text) screen.  Because I couldn't see one already
> written, and because I've already implemented one in Perl, I wrote it
> again in C.  It's pretty simple but works nicely, and I'm still adding
> features to it.  Interested people can find it at
> http://biojanus.anu.edu.au/~paulway/progress.c and
> http://biojanus.anu.edu.au/~paulway/progress.h, or by doing svn checkout
> svn://tangram.dnsalias.net/pwlib-c/trunk (with a bunch of my other
> 'handy' routines).
> 
> Anyway, I've heard several people talk about writing C in an
> object-oriented way.  I've done the simplest thing here, which is that
> each function takes a PInfo pointer as its first argument, which is the
> 'object' that it operates on.  This isn't ver object-oriented at all, in
> that you have to constantly tell the 'method' which object to orient
> itself toward.  The more complex way would be to have a structure a bit
> like this:
> 
> typedef struct object_struct {
>     int public_property;
>     int (*method)(int value);
> } Object;
> 
> Thus if you had "Object *foo" you could call foo->method(42).  When you
> get a new object the 'constructor' would put the pointers to the actual
> methods into the Object struct so that the call was correct.  The
> problem is, of course, that the actual method function enters and sees -
> what?  No context, no object, no nothing.  Implicit in the 'constructor'
> of object-oriented actions is the idea that the method call gets told
> _which_ object it's operating on - Perl does it semi-explicitly by
> assuming that the first parameter is a reference to the object.
> 
> So how do I do this in C?  Is it even possible?  The only method I can
> think of involves some sort of trickery with knowing the address of the
> method function pointer and subtracting a known offset for each method
> that takes you back to the start of the actual object structure - in the
> same way that talloc puts its own information before the start of any
> pointer allocated by talloc.  But this still seems like opening the box
> with the crowbar inside.  Do I have to stick to the
> 'pseudo-object-oriented' approach?
> 
> Have fun,
> 
> Paul
> 
> P.S.  I'd also be interested in GPLing this code, and sharing it in the
> grand tradition of Open Source Software.  There must be dozens of little
> implementations like this sitting around in people's source folders
> because they've never really thought it was worth sharing components
> like these.  Maybe I need to pore through the entire results of Googling
> "C text progress bar", but it took me shorter than that to write the
> damn thing... :-)  And besides, as Tridge says, who needs an excuse to
> reimplement something?  IMNSHO how to share our code and (perhaps more
> importantly) how (and where) to find others' shared code is a good topic
> for an upcoming Programmers SIG...
> 
> -- 
> -- Paul Wayper at ANU - +61 2 6125 0643
> -- Research Programmer and System Administrator
> 
> -- 
> linux mailing list
> linux at lists.samba.org
> https://lists.samba.org/mailman/listinfo/linux