doline error help plz

doline error help plz

meinaW

Member #7,943

November 2006

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

Inphernic

Member #1,111

March 2001

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

--
ĸoтёнoк

Ariesnl

Member #2,902

November 2002

1class NPC
2{
3int m_nTargetX,m_nTargetY,m_nX,m_nY;
4 
5//doline is in this function
6void moveNPC();
7 
8//the function that is used by doline
9void draw();
10 
11void setNPC();
12};
13 
14 
15void NPC::moveNPC()
16{
17    do_line(pBitmap, nX, nY, nX2, nY2, nD, draw);
18 
19}
20 
21 
22void NPC::draw(BITMAP *a_pBitmap, int a_nX, int a_nY, int a_nD)
23{
24 
25}
26 
27void NPC::setNPC()
28{
29 
30}

Try this coding style

Perhaps one day we will find that the human factor is more complicated than space and time (Jean luc Picard)
Current project: [Star Trek Project ] Join if you want ;-)

CGamesPlay

Member #2,559

July 2002

Quote:

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).

--
Tomasu: Every time you read this: hugging!

Ryan Patterson - <http://cgamesplay.com/>

meinaW

Member #7,943

November 2006

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

Kibiz0r

Member #6,203

September 2005

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
}

---
https://www.allegro.cc/account/agreement <-- Read it, newbies.

meinaW

Member #7,943

November 2006

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

Ariesnl

Member #2,902

November 2002

Quote:

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

No it affects the ability to read the code

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

Perhaps one day we will find that the human factor is more complicated than space and time (Jean luc Picard)
Current project: [Star Trek Project ] Join if you want ;-)

CGamesPlay

Member #2,559

July 2002

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.

--
Tomasu: Every time you read this: hugging!

Ryan Patterson - <http://cgamesplay.com/>

ImLeftFooted

Member #3,935

October 2003

Quote:

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

Ah! ew! My eyes!

1// In a .cpp file
2#include <vector>
3 
4static std::vector<CObject*> bdraw_refs;
5 
6static void NPC::bdraw(BITMAP *_bitmap, int _x, int _y, int _d)
7{
8    CObject* obj = (CObject*)bdraw_refs[_d]; //the object pointer we snuck in
9    //do other stuff
10}
11 
12void NPC::movenpc()
13{
14    bdraw_refs.push_back(this);
15    do_line(buffer, x, y, targetx, targety, (int)bdraw_refs.size() - 1, bdraw);
16    //do other stuff
17}

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

How is my posting?

Rampage

Member #3,035

December 2002

Quote:

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:

The Linux kernel coding style guide said:

Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged - the compiler knows the types anyway and can check those, and it only confuses the programmer. No wonder Microsoft makes buggy programs.

-R

Timorg

Member #2,028

March 2002

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
{
...
};

____________________________________________________________________________________________
"c is much better than c++ if you don't need OOP simply because it's smaller and requires less load time." - alethiophile
OMG my sides are hurting from laughing so hard ... :D

Kibiz0r

Member #6,203

September 2005

Quote:

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

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?

---
https://www.allegro.cc/account/agreement <-- Read it, newbies.

ImLeftFooted

Member #3,935

October 2003

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

Quote:

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?

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.

How is my posting?

Kibiz0r

Member #6,203

September 2005

Quote:

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

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?

Quote:

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

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

---
https://www.allegro.cc/account/agreement <-- Read it, newbies.

ImLeftFooted

Member #3,935

October 2003

Quote:

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}

How is my posting?

Timorg

Member #2,028

March 2002

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;
};

CGamesPlay

Member #2,559

July 2002

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...

--
Tomasu: Every time you read this: hugging!

Ryan Patterson - <http://cgamesplay.com/>

Kibiz0r

Member #6,203

September 2005

Quote:

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?

---
https://www.allegro.cc/account/agreement <-- Read it, newbies.

CGamesPlay

Member #2,559

July 2002

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

--
Tomasu: Every time you read this: hugging!

Ryan Patterson - <http://cgamesplay.com/>

Kibiz0r

Member #6,203

September 2005

Quote:

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()?

---
https://www.allegro.cc/account/agreement <-- Read it, newbies.