class NPC
{
int targetx,targety,x,y;

void movenpc()//doline is in this function
void drawb()//the function that is used by doline

void npcset()
};

I keep getting an error that says:

ISO C++ forbids taking the address of an unqualified or parenthesized non-static member function to form a pointer to member function. Say `&NPC::drawb'

the error leads to a line with this code:
do_line(all,x,y,targetx,targety,0,&drawb);

can somone plz help

http://www.google.com/search?q=c%2B%2B+member+function+callback&btnI=whee

Try this coding style

Because coding style affects the ability to pass member functions through C function pointers

Inphernic has it, of course. Also check out this link, which is just results on this forum (people using timers have this problem a lot).

thanks all
i got it working now all i did was change:

void bdraw();
to
void static bdraw();

do_line(all,x,y,targetx,targety,0,&drawb);
to
do_line(all,x,y,targetx,targety,0,*drawb);

seems to work pretty well

[EDIT]
never mind now it gives me this error:

invalid use of member `NPC::laserx' in static member function

why do c++ callbacks have to be so hard:(

[EDIT]
I give up ,I'm just going to use a diffrent line algorithm

You used a non-static field in a static function.

Static functions belong to the classes themselves, not the objects, and do not know about specific objects.

Try passing a pointer to the object as the int d parameter of do_line().

static void NPC::bdraw(BITMAP *_bitmap, int _x, int _y, int _d)
{
    CObject* obj = (CObject*)_d; //the object pointer we snuck in
    //do other stuff
}

void NPC::movenpc()
{
    do_line(buffer, x, y, targetx, targety, (int)this, bdraw);
    //do other stuff
}

Thanks everyone for help i used BresenhamLine algorithm instead of do_line and everything works now with no errors

No it affects the ability to read the code

besides I gave an answer aswell if you lookend at my code

If you're referring to the lack of an ampersand on the reference to draw, it's invalid, and it doesn't fix the error.

Ah! ew! My eyes!

I'm not even going to comment on the name 'CObject' or the underscores perpended to those parameters...

Microsoft strikes again! I'm always reminded of this quote:

This is an argument I have with students I tutor all the time, it made sense to use it back when compilers didn't do much in the way of checking data-types, now its at the opposite end of the scale (with c++ anyway) wanting you to cast everything.

I can't really complain though I use all upper case for my class/struct names

class BULLET : public OBJECT
{
...
};

Hahaha, I change styles at will. Recently I've been reading Game Coding Complete and ZoidCom's manual. The former uses C before all classes that aren't interfaces (those get an I, singletons get no prefix) and the latter uses _ for parameters.

I don't see what's wrong with either of those, though. I always found it pretty nifty to be able to distinguish parameters from locals, so I try to use that style when I think of it, but maybe that's just me. And what's wrong with CObject? If it's just Object, how do you know it's not an interface? Also makes code completion a bit better, in case you want to use an interface but don't recall the specific name you can narrow it down in an instant.

***

Oh, I thought you just re-posted my code, which I thought was quite strange. But I see you added some lines. ...I don't really understand why you would do it that way, did I miss something?

Part of the reason I dislike Java so much is the idea that all class' should for some reason inherit from some Object class.

You're assuming the size of a pointer == the size of an int. Which is an invalid and dangerous assumption.

As a random side note, Allegro's internals also make this assumption.

Who brought up Java? I use "object" as a generic term for a class. What would you have me use instead, so I don't offend you in the future?

Oh, understood. Then why would you need a vector to store them in? Why not just have a single static CObject*?

General inter-ability. Maybe one day (aka this happens a lot) you'll want to use the callback for uses whose state last longer then the function call. It also is a good step towards thread safety (for some operations, even though in this one you could just mutex the do_line call).

Really its just good callback habit (when you can't pass an actual pointer*).
_{* edited in afterwards}

My OBJECT isn't just deriving for the sake of deriving (aka java)

Its a world object

class OBJECT
{
public:
OBJECT();
virtual ~OBJECT()
virtual void logic() = 0;
virtual void render(BITMAP *buffer) = 0;
virtual void kill() = 0;
POINT location;
bool dead;
int mode;
int colour;
};

However, this whole thread brings up a good point, and maybe we should add a do_line_ex that accepts a void* d instead of an int d...

Yeah, I just looked up install_param_int_ex and thought the same thing... How come that one is void* and this is int?

Edit: I still wanna know about those coding practices, though. Is there a reason why they're bad?

This is an int because you can pass putpixel to it:
do_line(screen, 0, 0, SCREEN_W - 1, SCREEN_H - 1, makecol(255, 0, 0), putpixel);

Or you can write a special putpixel that does something slightly different, but shares the same prototype. Enter object oriented programming and just screw everything up

Yes...

Edit: Also, since we have do_line(), shouldn't we also have dont_do_line()?