Improving a minimalistic OOP for microcontrollers using C, gcc, C99, and Macros with optimization

In general what you are asking for is C++. the examples you posted are most likely going to be the more efficient or equally efficient using a C++ compiler.

Often on embedded targets you have far outdated versions of gcc that generate bad code for c++ or don't support all the gory c++ details.

You can try to run ${your_arch_prefix}-g++ --nostdlib --nostdinc which will enable c++ syntax in the parser without all the things that waste space. if you want to disable other things you can add -fno-rtti -fno-exceptions with remove runtime type checking and exception support (See this question).

Since the C++ parser is part of the C front-end even though C++ isn't officially supported by your micro controller vendor, this might still be working (sometimes you can also give it a try to compile the vendor specific version yourself and add c++ to the languages in the configure script).

This is usally considered superior to trying to invent your own OOP like macro DSL (domain specific language).

This being said if you don't want to go this path and don't want to use hand-craft vtables (as in your link). The simplest thing to do is have coding conventions. If you don't want polymorphism the code below is sufficient. you can define your struct and functions in a .c file and put the declarations in headers. The function below can be called directly so it's not in a vtable, and the first member is the this pointer in c++. struct impl is the actual data that the object holds not a vtable or similar.

struct impl;
struct impl *make_impl();
// don't use this as it is a reserved keyword in c++
void do_bar(struct impl *myThis, int bar);

If you want polymorphism look at what the kernel does. they explicitly embedd the vtable in the object and use macros to extract them and initialze them.

look at the definition of char device for instance.

and look at how people instanciate this in code and headers. Look at the container_of macro and understand how media_entity_to_video_device casting works. (If this is too little context for you, look at this Book: Linux Device Drivers (LDD3)).

I know your code works and you should be proud to understand what you are doing. But if you show your code to other people, they expect you to either write C or C++. If you are in C and are missing OOP I would try to write the code in a way, that others can grasp easily what you are doing. Using macros to extract function pointers or get a polymorphic member is usually fine, hiding function calls and generate structs in macros is often unreadable and people have to debug your code while running gcc -E to see your creations expanded from the preprocessor to understand what they are actually calling.

Edit

I've had a very quick shot at generating C code from clang++. according to this so question and this one the commands should be:

$ clang++ -std=c++11 -S -emit-llvm -o out main.cc # Worked
$ llc -march=c out 
llc: error: invalid target 'c'.

 $ clang++ --version
 clang version 3.7.0 (trunk 232670)
Target: x86_64-unknown-linux-gnu
Thread model: posix

It seems the clang C backend has been removed (see also these sources resurrecting the C-backend code). That being said you could also have a look at generating a backend for your target plattform, but I think thats definitely over-engineered.

For the side question, you can use -std=gnu99 to get C99 with gnu extensions (like anonymous struct and union members within structs and unions).

The question mentions -std=c11, so I guess that use of _Generic is OK in this situation.

Since what you appear to be asking for is a way to statically resolve methods from a shared name based on argument type, it makes some sense to look at overloading(/static polymorphism/ad-hoc polymorphism/etc.) as the basis for your system's operation, rather than trying to optimize a pattern generally intended for runtime resolution. _Generic is a static type->value selection operator that is intended specifically for helping with situations like this. It allows you to macro-expand the type-selection code directly into the calling expression and guarantees it will be removed at compile-time, which is exactly what you need.

Since it's an expression operator, _Generic has to list all of the types it's going to operate on in the expression. This means something has to be clustered, which isn't a perfect fit for your OOP strategy. Conventional overloading strategies cluster the function definitions, which would mess up trying to organize methods into classes; however, if you're willing to make an explicit list of all classes in use in your program (i.e. cluster the types instead) it should still be possible to achieve static resolution in a similar way.

e.g. (rough example):

#include <stdio.h>

// shared method table structure for all classes
typedef struct {
    void (* init)( void* );
    char* (* tryme)( void*, char* echo );
} poly_method_table;

// define class1
typedef struct {
    char* name;
    int   one;
} class1;
void class1_init( class1* self ) {
    self->name = "test";
    self->one=5;  
}
const poly_method_table class1_mt = {
    .init = class1_init
};

// define class2
typedef struct {
    int x;
} class2;
char* class2_tryme( class2* self, char* echo ) {
    return echo;
}
const poly_method_table class2_mt = {
    .tryme = class2_tryme
};

// global lookup table
const poly_method_table * table_select[] = {
    &class1_mt,
    &class2_mt,
};
#define M(MSG, THIS, ...) table_select[_Generic((THIS), \
    class1 *: 0, \
    class2 *: 1, \
    default: "error")]->MSG((THIS), ## __VA_ARGS__)


int main( void ) {
    class1 a;
    class2 b;

    M( init, &a );
    printf("a=%s %s\n",a.name, M( tryme, &b, "echo is this" ) );
}

The method operator M produces a constant lookup value into the global table-of-vtables (instead of trying to retrieve the vtable from the object itself). With enough const declarations I would expect a decent optimizer to be able to remove this and go straight to the selected function, since there's no runtime variance in which vtable gets selected.

Since you're already using GNU extensions (i.e. ,## for method calls), you could improve this by using typeof to cast the vtable lookup to a specialized type for each class (instead of having a single vtable class that supports all polymorphic method names), potentially reducing size somewhat and making room for further overloading at the method level.

You could remove the annoying repetition in the definitions of table_select and M with a FOR_EACH macro (it would automatically fill out the table, the middle of the _Generic block, and an enum to build indexes), e.g.:

#define CLASSES class1, class2 //etc.

#define BUILD_ENUM(class) class ## _enum,
#define BUILD_SELECTOR(class) &class ## _mt,
#define SELECT_CLASS(class) class *: class ## _enum,

#define M(MSG, THIS, ...) table_select[_Generic((THIS), \
  FOR_EACH(SELECT_CLASS, CLASSES) \
  default: "error")]->MSG((THIS), ## __VA_ARGS__)

enum { FOR_EACH(BUILD_ENUM, CLASSES) };
const poly_method_table * table_select[] = {
    FOR_EACH(BUILD_SELECTOR, CLASSES)
};

(you can find suitable definitions of FOR_EACH elsewhere on SO)

If you're willing to forgo any runtime polymorphism, you can completely get rid of your method table objects by replacing them with a _Generic structure simulating a compile-time dispatch table. You can first dispatch on the declared type of an object to choose its static method table, and then dispatch on a dummy type declared to match the method name, to resolve the actual method to call. Basic structure:

#define M(MSG, THIS, ...) _Generic((THIS), \
  class1 *: class1_selector((struct class1_ ## MSG ## _dmy*)0), \
  class2 *: class2_selector((struct class2_ ## MSG ## _dmy*)0), \
  default: "error")(THIS, ## __VA_ARGS__)

_{(note: there is a reason why I reversed the THIS/MSG operands, explained below)}

The method call operator M is built around a centralized list of all the classes in the program. It dispatches on the THIS pointer to select a classX_selector macro to call. It passes the selector a dummy pointer of a type named around the method (cast from zero is fine, we're not going to use it anyway).

#define class1_selector(MSG) _Generic((MSG), \
  struct class1_init_dmy *: class1_init, \
  struct class1_show_dmy *: class1_show, \
  struct class1_getOne_dmy *: class1_getOne, \
  default: "error")

The classX_selector macro expands to a static dispatch table for all of the methods supported by that class. In this case, class1 is defined to support three methods init, show and getOne. The type of the dummy pointer is used to select a method using another type dispatch table. The method is returned, becomes the return value of M's _Generic structure, and is called with object and arguments.

_Generic isn't the only compile-time operator (e.g. the ternary operator should be compile-time as well when given constants), but it has three advantages: firstly, it guarantees the operation will not happen at runtime; secondly, it doesn't double-evaluate your THIS pointer (since the expression used for dispatch is not compiled); and thirdly, since the dummy type expressions are name-based, we don't need to waste effort computing enum IDs for methods, making sure they're consistent across class definitions... just paste the name and the selector works. (Note that you don't even have to declare the dummy types - it's implicit in the use, although doing so doesn't hurt.)

Fundamentally this is really just overloading, but it's oriented towards grouping the method definitions by class instead of by selector name, so there's still some element of OOP to it.

Working example:

#include <stdio.h>

// centralized list of classes
#define CLASSES  class1, class2

// static class dispatch
#define M(MSG, THIS, ...) _Generic((THIS), \
  class1 *: class1_selector((struct class1_ ## MSG ## _dmy*)0), \
  class2 *: class2_selector((struct class2_ ## MSG ## _dmy*)0), \
  default: "error: unknown class")(THIS, ## __VA_ARGS__)


// define class1
typedef struct {
    char* name;
    int   one;
} class1;
void class1_init( class1* self ) {
    self->name = "test";
    self->one=5;  
}
void class1_show(class1 * self) { printf("class1: (%s, %d)\n", self->name, self->one); }
int class1_getOne(class1 * self) { return self->one; }

// class1 static method dispatch table
#define class1_selector(MSG) _Generic((MSG), \
  struct class1_init_dmy *: class1_init, \
  struct class1_show_dmy *: class1_show, \
  struct class1_getOne_dmy *: class1_getOne, \
  default: "error: unknown method")


// define class2
typedef struct {
    int x;
} class2;
void class2_show(class2 * self) { printf("class2: (%d)\n", self->x); }
char* class2_tryme( class2* self, char* echo ) { return echo; }

// class2 static method dispatch table
#define class2_selector(MSG) _Generic((MSG), \
  struct class2_tryme_dmy *: class2_tryme, \
  struct class2_show_dmy *: class2_show, \
  default: "error: unknown method")


int main(void) {
    class1 a;
    class2 b;

    M( init, &a );
    b.x = 13;
    M( show, &a );
    M( show, &b );
}

Because I hate repetition and like excessive metaprogramming, here's a version that uses looping macros to eliminate most of the character overhead involved in defining classes (the block at the top should be hidden away in a different file; cmacros.h is implemented here):

#include <stdio.h>

// !!METAPROGRAMMING BOILERPLATE
#include "cmacros.h"
// static class dispatch
#define M(MSG, ...) _Generic(M_FIRST(__VA_ARGS__), \
  M_REST(M_REST(M_FOR_EACH(M_RE_EXP, \
    (D1, D2, D3) \
    M_ZIP_WITH(MSG_SEL, (CLASSES), M_ENLIST(MSG, M_NARGS(CLASSES))) ) )) \
  ,default: "error: unknown class") \
  (__VA_ARGS__)

#define M_RE_EXP(E) ,M_FIRST E*: _Generic(DUMMY_SEL(M_FIRST E, M_FIRST(M_REST E)), \
  M_CONC2(M, M_REST(M_REST E)) \
  default: "error: unknown method")

#define M_CONC2(L, R) M_CONC2_(L, R)
#define M_CONC2_(L, R) L##R

#define MSG_SEL(CLASS, MSG) ,MSG_SEL_(CLASS, MSG)
#define MSG_SEL_(CLASS, MSG) (CLASS, MSG, LIST_METHODS(CLASS, CLASS ## _methods))

#define DUMMY_SEL(CLASS, MSG) DUMMY_SEL_(CLASS, MSG)
#define DUMMY_SEL_(CLASS, MSG) (struct CLASS##_##MSG##_dmy*)0

#define LIST_METHODS(CLASS, ...) \
  _ZIP_WITH(METHOD_SEL, M_ENLIST(CLASS, M_NARGS(__VA_ARGS__)), (__VA_ARGS__))
#define METHOD_SEL(CLASS, METH) METHOD_SEL_(CLASS, METH)
#define METHOD_SEL_(CLASS, METH) struct CLASS##_##METH##_dmy*: CLASS##_##METH,
// !!END OF BOILERPLATE


// centralized list of classes
#define CLASSES  class1, class2


// define class1
typedef struct {
    char* name;
    int   one;
} class1;
void class1_init( class1* self ) {
    self->name = "test";
    self->one=5;  
}
void class1_show(class1 * self) { printf("class1: (%s, %d)\n", self->name, self->one); }
int class1_getOne(class1 * self) { return self->one; }

#define class1_methods init, show, getOne


// define class2
typedef struct {
    int x;
} class2;
void class2_show(class2 * self) { printf("class2: (%d)\n", self->x); }
char* class2_tryme( class2* self, char* echo ) { return echo; }

#define class2_methods show, tryme


int main(void) {
    class1 a;
    class2 b;

    M( init, &a );
    b.x = 13;
    M( show, &a );
    M( show, &b );
}

Finally, this last version shows the reason for swapping MSG and THIS in the definition of M - it makes it possible to eliminate warnings about unused variadic arguments without relying on a GCC extension. (Besides, who says you need to be controlled by C++'s obj.method convention?)

N.B. there is a possible downside to this strategy (who would have thought) - the macro step pastes the full method table selection for every class in at each method call site. There's no runtime code bloat because _Generic removes it all again, but it will probably slow compilation down, or most likely run out of compiler memory, if you have hundreds of classes and methods! Overloading would be much more efficient in this respect.