Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » doline error help plz

This thread is locked; no one can reply to it. rss feed Print
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

Ariesnl
Member #2,902
November 2002
avatar

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

- Wisdom is the art of using knowledge
- String theory: There's music in everything

CGamesPlay
Member #2,559
July 2002
avatar

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
avatar

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
}

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
avatar

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

- Wisdom is the art of using knowledge
- String theory: There's music in everything

CGamesPlay
Member #2,559
July 2002
avatar

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

Dustin Dettmer
Member #3,935
October 2003
avatar

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

Rampage
Member #3,035
December 2002
avatar

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
avatar

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?

Dustin Dettmer
Member #3,935
October 2003
avatar

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.

Kibiz0r
Member #6,203
September 2005
avatar

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*?

Dustin Dettmer
Member #3,935
October 2003
avatar

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

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

:P :D

____________________________________________________________________________________________
"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

CGamesPlay
Member #2,559
July 2002
avatar

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
avatar

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?

CGamesPlay
Member #2,559
July 2002
avatar

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
avatar

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

Go to: