I'm developing a thing in C, and currently I have followed a style where I provide a struct declaration containing data, and separate functions for acting upon said data. Something like this:

MyData.h

struct MyData
{
   int a;
   float b;
};

void initialise( struct MyData* instance );
int get_a( struct MyData* instance );
float get_b( struct MyData* instance );

MyData.c

#include <MyData.h>

void initialise( struct MyData* instance )
{
    instance->a = 2;
    instance->b = 7.3f;
}

int get_a( struct MyData* instance )
{
    return instance->a;
}

float get_b( struct MyData* instance )
{
    return instance->b;
}

main.c

#include <MyData.h>

int main( void )

{

    MyData test;
    initialise( &test );
    int x = get_a( &test );
    float y = get_b( &test );

    return 0;

}

I'm wondering whether or not to do some pointer trickery to make it look more OO, like the following:

MyData.h

struct MyData
{
    int a;
    float b;

    int (*get_a) (struct MyData*);
    float (*get_b) (struct MyData*);
};

void initialise( struct MyData* instance );

MyData.c

#include <MyData.h>

static int get_a( struct MyData* instance )
{
    return instance->a;
}

static float get_b( struct MyData* instance )
{
    return instance->b;
}

void initialise( struct MyData* instance )
{
    instance->get_a = get_a;
    instance->get_b = get_b;

    instance->a = 2;
    instance->b = 7.3f;
}

main.c

#include <MyData.h>

int main( void )

{

    MyData test;
    initialise( &test );
    int x = test.get_a( &test );
    float y = test.get_b( &test );

    return 0;

}

The benefit I see is being make get_a and get_b static, so they can't be called directly without having instantiated a type from MyData.

What other pro's and con's are there from doing this, and am I doing the initialisation correctly for assigning the function pointers?

I've done this in C to get a poor-man's polymorphism. The syntax is awkward but its a reasonable way to implement an interface you can pass around to methods that don't know which actual concrete functions will be used. Just makes me wish I was using C++ though - any reason you aren't?

If the methods are always going to be the same, its pointlessly over-complex compared to free functions taking the a pointer to the struct as a member, as Brother Bob points out, and wastes unnecessary space. I don't really buy your argument about protecting you from calling the methods accidentally. If you need that kind of encapsulation protection, you're using the wrong language. There are a million other ways you can make similar mistakes in C so this doesn't buy you a great deal, certainly not enough to warrant the overhead in terms of memory and syntax.

But as a way to implement runtime polymorphic interfaces in C it is okay. You could just simulate a v-table pointer to a static table for each "derived type" as well though to avoid having to store all the function pointers in every instance, although the syntax gets even worse then of course.

But making things "look OO" is rarely a good motivation in itself.

@all - Thanks a lot, the information provided was very insightful to me, and I see that applying the "OO" style to my program is going to be overkill, adding unnecessary complexity.

Just makes me wish I was using C++ though - any reason you aren't?

Three reasons: Mainly because the program in question is simple, needs to be very close to the underlying hardware, and there actually isn't a compiler (that I know of) that is capable of compiling C++ code to the target architecture.

Even if there were a possibility to use C++, I'd neglect to do so. I feel more comfortable programming micro controllers in C because it keeps things clean and simple. Especially when others work with your code.

So, I assume you're providing accessor functions (get_a(), get_b()) to ensure the data is only accessed by those functions, but the way you've implemented it, anyone can just access it via myData->a, etc.

If you want to hide the data, you can externally define the structure as an empty array in a header file you publish:

// myDataPublic.h
typedef struct
{
  unsigned char Data[8];
} MyData;
 
int MyDataGetA(MyData* data);
float MyDataGetB(MyData *data);

So whoever is using it doesn't know the contents of the struct.

Considering you're working on a small micro, processing/memory may be an issue, and trying to get fancy with accessors is a waste IMO. Just allow them to access the members directly.