Alternative to reference virtual table in C without using function pointers.

Question

I am taking advantage of polymorphism in C by using virtual tables as described in Polymorphism (in C) and it works great.

Unfortunately, the limitation of my current project does not allow me to use function pointer or reference to structs in some part of my code. As a consequence, I cannot use the original approach directly.

In the mentioned approach, the base "class/struct" has a member that points to the virtual table. In order to get ride of this pointer, I decided to replace it with an enumerate that acts as key to access the virtual table.

It works but I wonder if if is the best solution. Do you come up with any alternative that fits better than my proposal?

/**
 * This example shows a common approach to achive polymorphism in C and an 
 * alternative that does NOT include a reference to function pointer in the 
 * base 
 * class.
 **/
#include<stdio.h>

//  some functions to make use of polymorphism
void funBase1()
{
    printf("base 1 \n");
}
void funBase2()
{
    printf("base 2 \n");
}
void funDerived1()
{
    printf("derived 1 \n");
}
void funDerived2()
{
    printf("derived 2 \n");
}


// struct to host virtual tables
typedef struct vtable {
    void (*method1)(void);
    void (*method2)(void);
}sVtable;

// enumerate to access the virtual table
typedef enum {BASE, DERIVED} eTypes;

// global virtual table used for the alternative solution
const sVtable g_vtableBaseAlternative[] = { 
    {funBase1, funBase2}, 
    {funDerived1, funDerived2},  };


// original approach that i cannot use
typedef struct base {
    const sVtable* vtable;
    int baseAttribute;
}sBase;

// alternative approach
typedef struct baseAlternative {
    const eTypes vtable_key;
    int baseAttribute;
}sBaseAlternative;


typedef struct derived {
    sBase base;
    int derivedAttribute;
}sDerived;

// original way to use 
static inline void method1(sBase* base)
{
    base->vtable->method1();
}

const sVtable* getVtable(const int key, const sVtable* vTableDic)
{
    return &vTableDic[key];
}

// Alternative to get a reference to the virtual table
static inline void method1Aternative(sBaseAlternative* baseAlternative)
{
    const sVtable* vtable;
    vtable = getVtable(baseAlternative->vtable_key, g_vtableBaseAlternative);
    printf("alternative version: ");
    vtable->method1();
}

int main() {

const sVtable vtableBase[] = { {funBase1, funBase2} };
const sVtable vtableDerived[] = { {funDerived1, funDerived2} };


sBase base = {vtableBase, 0 };
sBase derived = {vtableDerived, 1 };
sBaseAlternative baseAlternative = {DERIVED, 1 };

method1(&base);
method1(&derived);
method1Aternative(&baseAlternative);

}

Answer 1

I am taking advantage of polymorphism in C

you do not of course. You only create a prothesis of it. IMO the simulation of objects in C is the worst possible solution. If you prefer the OOP paradigm - use the OO language. In this case C++.

Answering your question - you can't do it (sane way) without the function pointers.

I discourage people from attempts of OOP like programming in the procedural languages. It usually leads to the less readable, error prone and very difficult to maintain programs.

Choose the correct tool (the language is the tool) for the task and the method.

It is like using the knife instead of screwdriver. You can, but the screwdriver will definitely be much better.

Answer 2

my current project does not allow me to use function pointer or reference to structs

You could use an array of T (any type you like) to represent a data type. For example, I tend to use arrays of unsigned char to serialise and deserialise my data structures for web transfer... Let's for example assume you're using sprintf and sscanf for serialisation and deserialisation (which you shouldn't really do, but they're okay for demos)... Instead of struct arguments, you use char * arguments, and you use sscanf to read that data to local variables, sprintf to modify it... that covers the no reference to structs allowed problem.

With regards to the function pointer problem, you could combine all of your functions into one which switches on... a tagged structure in string form... Here's a simple (yet incomplete) example involving two candidates for classes: a length-prefixed string which uses two bytes to encode the length and kind of derives from C-string behaviour, and a C string.

enum { fubar_is_string, fubar_is_length_prefixed_string };
typedef unsigned char non_struct_str_class;

size_t non_struct_strlen(non_struct_str_class *fubar) {
    size_t length = 0;
    switch (fubar++[0]) {
        case fubar_is_length_prefixed_string:
                              length = fubar++[0];
                              length <<= 8;
                              length += fubar++[0];
                              // carry through into the next case
                              // to support strings longer than 64KB
        case fubar_is_string: if (!length)
                                  length = strlen(fubar);
                              /* handle fubar as string */
    }
    return length;
}

C is a turing complete programming language, so of course it can be used to mimic object oriented polymorphism... but it's far better at mimicking procedural polymorphism, or in some cases even functional polymorphism... As an example, you could say qsort and bsearch use a primitive form of parametric polymorphism similar to that of map (even more similar to a filter idiom).

You could also use _Generic with limited success, for example as the C11 standard does by providing a generic cbrt macro for all of the standard floating point types:

#define cbrt(X) _Generic((X),                                      \
                        long double: cbrtl,                        \
                        default: cbrt,                             \
                        float: cbrtf                               \
                        )(X)

The preprocessor is particularly useful if you're going to go the route of mimicry... You might be interested in the C11 book by Klemens.