Sorry Anselm, I forgot to thank you for your quick answer.
1. I designed a software to automate testing of the boxes that we
build. The main language used is Python (I guess it's hard to avoid OO
when using python). Basically the design is such that I have a test
case class that is used when instantiating different test cases
(attributes include: name, status, tester, etc.). How would you
approach this in a non-OO way?
Can't speak for python, I have very limited experience with python.
Though what's wrong with function pointers to unit test functions?
(Instead of class/interfaces that just have a test function?). Or even
less coupled, what about a test case per executable, that way you can
test using very different approaches from a shell script and/or
Makefile.
I think the problem one eventually hits in plain C is its lack of closures.
It can be walked around in more or less ugly ways, thought.
Objects versus closures is a good way to start flamewars in more-or-less
academic circles.
It is usually said that objects are poor men's closures, and closures are
poor men's objects.
I'm currently trying to design a little language which is, contrary to the
vast majority of
the languages created these days, is not OO (it's really really hard to
find an OO less language
these days).
One of the things I tried before going this way is to test the design on
OO's favorite playground,
design patterns. I didn't conduct any real serious study so what I say
must be taken with
a handful of salt (don't throw it in my eyes, please). What I noticed in
the few things I tried
is that closures are much more fine grained that objects. For instance,
the "observer" design pattern
done with closure becomes a trivial callback scheme; with OO it is much
more bulky but also less flexible.
OTOH, there are situations where closures are much more bulky than
objects. In the case of an
abstract type, the OO approach offers relatively clean abstract (virtual
in C++ terminology)
class. With closures, one ends up with structures full of closure/function
pointers.
as a corollary, one musts manage by hand closure pointers to achieve
inheritence when C++ does
it for you. But in one case (decorator pattern) it made me realise that
the OO approach can easily
waste memory if one does take care of what's happening. With closures,
what is going on in terms of
structure size and field duplications is more obvious.
To summarize, closures are to me more fine-grained than objects; one gets
some of the nice features
of dynamic languages in a static one (my case), like being able to change
the behavior of one instance
of a data type in a straight manner when it requires a heavy, ad hoc
mechanism with OO. The flip side
is that it is sort of "lower level" because one has to manage the details
by yourself. But maybe it can
be improved with a good macro system.
2. A colleague of mine needed to design a packet generation engines for
our box. He used OO concepts in CC by using techniques such as VTABLE,
defines for methods, classes, etc:
/**
* Macros for declaring classes
*/
#define CLASS(CX, SX)\
typedef struct CX *CX;\
struct CX {struct SX super;
#define IMPLEMENTS(IX) struct IX *IX
#define VTABLE(CX, SX) };\
extern struct CX##Class __##CX;\
typedef struct CX##Class *CX##Class;\
struct CX##Class {struct SX##Class super;
#define METHODS };
#define END_CLASS
So then, he can instantiate multiple different engines depending on
processor load, etc.
It looks like a job for "super macros", aka X-macros
(http://en.wikipedia.org/wiki/C_preprocessor#X-Macros)
