7 replies to this topic

[tate]

So I have been coding in C for a while now but function pointers are something I don't use a lot. I am wondering how bad of an idea it would be to make a class type structure using function pointers for example:

typedef struct tempPoint Point;

struct tempPoint{
    int x;
    int y;
    int (*getX) (Point *p);
    int (*getY) (Point *p);
    void (*setX) (Point *p, int x);
    void (*setY) (Point *p, int y);
};

int getX(Point *p){
    return p->x;
}

int getY(Point *p){
    return p->y;
}

void setX(Point *p, int x){
    p->x=x;
}

void setY(Point *p, int y){
    p->y=y;
}

//Constructor
Point newPoint(int x, int y){
    Point p;
    p.getX=getX;
    p.getY=getY;
    p.setX=setX;
    p.setY=setY;
    p.x=x;
    p.y=y;
    return p;
}

I would put the typedef and newPoint in the header file to use in other files. I know by doing this I might as well just use c++ classes but is this a bad thing to do if I want to?

[dargueta]

You can't. Function pointers with classes can only go across classes of the same type, or classes that inherit from a common parent class. The reason is that member methods take an extra hidden argument, the this pointer; if you pass an incompatible class, who knows what the methods'll do to it?

Or am I misinterpreting something here?

[tate]

I think you are misinterpreting something or I am misinterpreting what you are saying lol. I'm not using classes. I am just using a c struct and I didn't think there was a "this" argument in c, there is in c++. I initialize all my Point structs with "newPoint()" so there are no null pointers anywhere. Everything compiles and works just fine so far in everything I have done. To make it more clear, here is my .c file and .h file.
Point.c

//Point.c methods and constructor for a 
//point in a [x,y] coordinate system.
#include "Point.h"

static int getX(Point *p){
    return p->x;
}

static int getY(Point *p){
    return p->y;
}

static void setX(Point *p, int x){
    p->x=x;
}

static void setY(Point *p, int y){
    p->y=y;
}

Point newPoint(int x, int y){
    Point p;
    p.getX=getX;
    p.getY=getY;
    p.setX=setX;
    p.setY=setY;
    p.x=x;
    p.y=y;
    return p;
}

Point.h

#ifndef POINT_H_
#define POINT_H_

#include <stdlib.h>
#include <stdio.h>

typedef struct tempPoint Point;
struct tempPoint{
    int x;
    int y;
    int (* getX) (Point *p);
    int (* getY) (Point *p);
    void (* setX) (Point *p,int x);
    void (* setY) (Point *p,int y);
};
Point newPoint(int x, int y);


#endif /* POINT_H_ */

[dargueta]

Ooohhh, okay. I get it now. So you're basically imitating a C++ class in C with snap-in functions.

[tate]

Ya that is what I am doing. I just don't know if it is a good idea to do it. My employer requires our code to be in c not c++ for reasons I haven't read all the way through so I was just looking for some way to make it feel more like c++ objects. If there are no real drawbacks to doing it this way then I will go for it since my employer does not seem to care but i have a feeling there is some drawback somewhere i have just missed.

[dargueta]

Eh...I don't really see one, except you could easily segfault if you forget a pointer.

[abzero]

you'll only need function pointers if you want to implement some sort of virtual dispatch. So if you're adding callbacks or want polymorphic behaviour.

You would still need to manually provide the this pointer to the functions if they are ment to act on the struct's data.
so:

struct anCObject {
    void (*foo)(anCObject*this);
}

....
anCObject c;
c->foo(&c); //Foo can act like a member of the object here
c->foo(); //Cannot do this, no automatic this pointer.

[dargueta]

In this case, I really don't see the need for function pointers, unless--like abzero said--you need callbacks or customizable functionality on a per-object basis.