The Motif, X11 junk is one way to do OO C. Its hideous.

As for padding resumes - ObjC is a lot more impressive than "I can make objects in C" as this claim is so nebulous as to be worthless (and more importatantly - it often implies the guys is clueless as to what objects are). But that is another topic.

Anyhow, one way to do it is to stick function pointers into your structs. This is useful for relatively limited sorts of "objects". Like maybe IO descriptors that need to look the same regardless of whether you are writing to a file, socket, memory, etc... You only have a few "methods" so you can afford the redundancy of function pointers in the struct.

If you care about space at all, your struct layout basically needs to have a common header that you can always count on (so at one level all structs look alike), then you put the differing stuff below that. The simplest thing done is to stick an isA pointer first that points to a "class" record of some sort. The isA points to the method dictionary and object layout info - often stored in a linked list of some sort.

If you want to see how Objective C works - go to the Apple developers site and download the runtime. There are struct definitions for what a class is, what a method descriptor looks like, info on keeping name offsets in a lookup table, etc.

There's also a book on "design and implementation of C++" something like that - this is a good read if you want to see how to do it wrong. FWIW, C++'s biggest design error (IMNAAHO) is the vtable and name mangling. Tossing out the method descriptor info and relying on positional info is just plain the stupidest thing ever in code that is going to live longer than one dev cycle (basically all code).

I could write a book on this but the best thing is to look at lots of implementations and decide what you need. X11 stuff, C++ implementation, ObjectiveC runtime, and (I think - I forget if this is right) unix IO descriptors store function pointers for some ops to implement the "everything looks like a file" illusion.

slower? OK sure.

We have GIGAHertz machines these days and smalltalk was originally working with decent performance on 8MHz boxes.

Now to be fair, ST has some tricks. One is that the very most common message sends to the most common objects are actually treated specially and implemented as byte code ops - its sort of the 80/20 rule. So for instance the #ifTrue: message

finished ifTrue: [ dosomething ]

is pedagogically implemented as a polymorphic message to Boolean with specializations in subclasses True and False - but this isn't how it *really* works. Instead the compiler generates special instructions for a small number of key messages (which you can change BTW). Loops are also treated specially.

Otherwise - yeah - there's a lookup. Its a pretty cheap lookup though.

Plus, having the methods in a method dictionary lets you do crazy things like create new kinds of scope, wacky fallback strategies, etc....

Smalltalk is an environment that will let you create pretty much any kind of programming model you like.

It totally depends on the implementation and there are a lot of really clever tricks. It might not seem like it - but ST actually (sometimes) gets you closer to the metal in a lot of nifty ways than something like C. Its very freaky.

For instance, the opencroquet guys are moving a huge amount of rendering into graphics hardware despite the fact that you're calling it from Smalltalk with ST data structures.