On Mon, Sep 14, 2009 at 07:15:07PM +0100, Anselm R Garbe wrote:
[snip]
> > 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.
>
> I don't like this approach. What's wrong with struct composition and
> some type field at the struct's beginning? Using that approach you can
> write quite generic functions that deal with different types. Eg
>
> typedef struct _GenericType GenericType;
> struct _GenericType {
> int kind;
> union {
> SpecialType1 type1;
> SpecialType2 type2;
> } type;
> };
>
> then you can use GenericType as argument or return type, but
> specialise the handling for each of such values based on type->kind
> and cast accordingly. In fact it's pretty much smilar to what your
> colleage does with his macros, but more honest and clear imho.
>
That is definitely clearer. Great tip!
> Kind regards,
> Anselm
>
Thanks.
