By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,720 Members | 2,237 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,720 IT Pros & Developers. It's quick & easy.

Why does this fail?

P: n/a
I have been working on my maze program and this line is failing:
class space{
char gchar;
graphic *gr;
graphic *grDefault;
player * play;
bool seen;

public:
space();
~space();
void graphicIn(char g);
graphic& graphicOut();
....
};
graphic& space::graphicOut(){
if(play){return play->gOut();} <--This line fails
if(seen){return *gr;}
else {return *grDefault;}
}

class player{

string name;
graphic * gr;

void create();

public:
player();
graphic& gOut(){return *gr;} <--Function that leads to the
failure.
};

The two stantemts below the player get graphic work fine. Why does the
program fail when I use a function to return a pointer than just
returning the pointer?

Apr 11 '06 #1
Share this Question
Share on Google+
6 Replies


P: n/a
JoeC wrote:
I have been working on my maze program and this line is failing:
class space{
char gchar;
graphic *gr;
graphic *grDefault;
player * play;
bool seen;

public:
space();
~space();
void graphicIn(char g);
graphic& graphicOut();
...
};
graphic& space::graphicOut(){
if(play){return play->gOut();} <--This line fails
if(seen){return *gr;}
else {return *grDefault;}
}

class player{

string name;
graphic * gr;

void create();

public:
player();
graphic& gOut(){return *gr;} <--Function that leads to the
failure.
};

The two stantemts below the player get graphic work fine. Why does
the program fail when I use a function to return a pointer than just
returning the pointer?


In the code you cared to share there is no apparent reason for any
failure (whatever failure you mean by "line fails"). You're using
some pointers in those functions. Are you sure the pointers are
actually pointing somewhere valid?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Apr 11 '06 #2

P: n/a
In the code you cared to share there is no apparent reason for any
failure (whatever failure you mean by "line fails"). You're using
some pointers in those functions. Are you sure the pointers are
actually pointing somewhere valid?

My program is pretty long and if more and if I need to post more I
will. I do believe that the poiter is pointing to somthing. Here is
the object that holds the graphic object:

class player{

string name;
graphic * gr;

void create();

public:
player();
graphic& gOut(){return *gr;}
};

player::player(){
name = "";
BYTE pgr[] = {0x03,0xc0, 0x03,0x0c,0xff,0xff,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,00,0,0,0,0,0,0};
gr = new graphic(pgr);

}
I am not sure what else to post, the graphic get created in the player
and I don't delete the objects until the program ends.

Apr 12 '06 #3

P: n/a
JoeC wrote:
In the code you cared to share there is no apparent reason for any
failure (whatever failure you mean by "line fails"). You're using
some pointers in those functions. Are you sure the pointers are
actually pointing somewhere valid?
When you quote, it's customary to indicate what exactly you quote and
from whom (not that I need any credit here).
My program is pretty long and if more and if I need to post more I
will.
You did not post enough to conclude anything of substance. Now, does
this mean you _need_ to post more? I don't know. Do you?
I do believe that the poiter is pointing to somthing.
What you believe is really irrelevant. You believed you wrote a valid
program. But it didn't work.
Here
is the object that holds the graphic object:

class player{

string name;
graphic * gr;

void create();

public:
player();
graphic& gOut(){return *gr;}
};

player::player(){
name = "";
BYTE pgr[] = {0x03,0xc0, 0x03,0x0c,0xff,0xff,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,00,0,0,0,0,0,0};
gr = new graphic(pgr);

}
I am not sure what else to post, the graphic get created in the player
and I don't delete the objects until the program ends.


Well, your 'player' class is not implemented according to the "Rule of
Three" (look it up). Do you really need 'gr' as a pointer? Why don't
you simply keep it an an instance. It seems to belong to 'player'
anyway...

If you think that having 'gr' a pointer is the only way, you are wrong.
You _can_ have it as an object. All you need to do is to have 'pgr' as
a _static_ array, and then initialise your 'gr' from that array in the
constructor initialiser list.

Read the FAQ: http://www.parashift.com/c++-faq-lite/, especially the
section on posting and on handling dynamic memory. If you don't feel
like digging through the mud that is pointers, don't. Just use normal
instances of the class. If you have trouble initialising those, ask
more questions.

V
--
Please remove capital As from my address when replying by mail
Apr 12 '06 #4

P: n/a
Thanks for the help. It is one thing to read up on this stuff in books
and it is another to actualy create a program. As you can probibly
tell, I have no formal education in programming or C++. I am pretty
confused, my graphics object works fine here:

if(seen){return *gr;}
else {return *grDefault;}
but not here:
if(play){return play->gOut();} <--This line fails

You say that it has somthing to do with the array in graphic.

I awaire of the rule of three constructor, destructor and copy
constructor I do believe. Do I need to add a assignment operator top
my graphic class? I tried doing that but I ran into some problems.

This is my graphic class.

class graphic{
int btmap;
int lr,ud; //Diminsion (size) of the graphic
HBITMAP hbitmap;
BITMAP bitmap;
HDC hdc, hdcmem;

public:
graphic();
graphic(BYTE c[]);
graphic& operator = (const graphic&);
void SetGr(BYTE c[]);
void display(HWND, int, int);

};

graphic::graphic(){
lr = ud =16;
BYTE c[32] = {0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff

};
BITMAP bitmap = {0,ud,lr,2,1,1};
bitmap.bmBits = c;
hbitmap = CreateBitmapIndirect(&bitmap);
}

void graphic::SetGr(BYTE c[]){
//Changing the graphic
BITMAP bitmap = {0,ud,lr,2,1,1};
bitmap.bmBits = c;
hbitmap = CreateBitmapIndirect(&bitmap);
}

graphic::graphic(BYTE c[]){
//constructor need an array 32 int or hex elements to create graphic

ud = lr = 16; // size in bits
BITMAP bitmap = {0,ud,lr,2,1,1};
bitmap.bmBits = c;
hbitmap = CreateBitmapIndirect(&bitmap);
//MessageBox(NULL, "Graphic Created" , "Error!", MB_OK);
}

graphic& graphic::operator = (const graphic& gr){
if(&gr != this){
lr = ud = 16;
BITMAP bitmap = {0,ud,lr,2,1,1};
hbitmap = gr.hbitmap;
hbitmap = CreateBitmapIndirect(&bitmap);
}
return *this;
}
void graphic::display(HWND hwnd, int x, int y){
//prints the graphic on the screen
hdc = GetDC(hwnd);
hdcmem = CreateCompatibleDC(hdc);
SelectObject(hdcmem, hbitmap);
BitBlt(hdc, x, y, ud, lr, hdcmem, 0, 0, SRCCOPY);
DeleteDC(hdcmem);
ReleaseDC(hwnd, hdc);

}
I wanted to use pointers because I didn't want to do alot of copying of
objects and also that is how I saw it in a book. The program actually
runs fiine if I do:

//if(play){return play->gOut();}

It just dosn't print out the character graphic.

Apr 12 '06 #5

P: n/a
JoeC wrote:
Thanks for the help. It is one thing to read up on this stuff in
books and it is another to actualy create a program. As you can
probibly tell, I have no formal education in programming or C++.
Neither do I. Can you tell?

BTW, no, I can't tell whether someone has formal education in some
field or has none. I've known many folks who had formal education in
something, and still did much worse than others who didn't have any
formal education in the same field. It's not the formal education,
it's the studying and paying attention that make a difference.
I
am pretty confused, my graphics object works fine here:

if(seen){return *gr;}
else {return *grDefault;}
but not here:
if(play){return play->gOut();} <--This line fails

You say that it has somthing to do with the array in graphic.
No, that's not what I say at all. I think your problem is that you keep
a pointer to 'graphic' instead of just keeping an object inside your
'player' instance.
I awaire of the rule of three constructor, destructor and copy
constructor I do believe. Do I need to add a assignment operator top
my graphic class? I tried doing that but I ran into some problems.
[..]
Take one step (class) at a time. Make your class do what you need it
to do and make it do it right. Don't try to write the whole program at
once and expect it to work right off the bat.

Write test cases for every class you create. Also follow the KISS
principle. Don't use pointers _unless_ there is a complelling enough
reason to do so. "I don't want to do alot of copying" is not good
enough a reason. It's not you who does the copying, it's the computer,
so *let it*. Do not optimise _prematurely_.
I wanted to use pointers because I didn't want to do alot of copying
of objects and also that is how I saw it in a book.
There are many books out there. Don't just do it because "a book" said
so.
The program
actually runs fiine if I do:

//if(play){return play->gOut();}

It just dosn't print out the character graphic.


Wait... So, the program works fine, it just doesn't do what you expect
of it? I guess I don't understand...

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Apr 12 '06 #6

P: n/a
ajk
On 11 Apr 2006 13:19:26 -0700, "JoeC" <en*****@yahoo.com> wrote:
I have been working on my maze program and this line is failing:
class space{
char gchar;
graphic *gr;
graphic *grDefault;
player * play;
bool seen;

public:
space();
~space();
void graphicIn(char g);
graphic& graphicOut();
...
};
graphic& space::graphicOut(){
if(play){return play->gOut();} <--This line fails
if(seen){return *gr;}
else {return *grDefault;}
}

class player{

string name;
graphic * gr;

void create();

public:
player();
graphic& gOut(){return *gr;} <--Function that leads to the
failure.
};

The two stantemts below the player get graphic work fine. Why does the
program fail when I use a function to return a pointer than just
returning the pointer?

where do you allocate what 'play' points to?

Apr 22 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.