Why does this fail?

Discussion in 'C++' started by JoeC, Apr 11, 2006.

  1. JoeC

    JoeC Guest

    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?
     
    JoeC, Apr 11, 2006
    #1
    1. Advertising

  2. 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
     
    Victor Bazarov, Apr 11, 2006
    #2
    1. Advertising

  3. JoeC

    JoeC Guest

    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.
     
    JoeC, Apr 12, 2006
    #3
  4. 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
     
    Victor Bazarov, Apr 12, 2006
    #4
  5. JoeC

    JoeC Guest

    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::eek:perator = (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.
     
    JoeC, Apr 12, 2006
    #5
  6. 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
     
    Victor Bazarov, Apr 12, 2006
    #6
  7. JoeC

    ajk Guest

    On 11 Apr 2006 13:19:26 -0700, "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?



    where do you allocate what 'play' points to?
     
    ajk, Apr 22, 2006
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Fred
    Replies:
    0
    Views:
    620
  2. Jim West
    Replies:
    5
    Views:
    615
    Jim West
    Oct 14, 2003
  3. Wenjie

    if (f() != FAIL) or if (FAIL != f())?

    Wenjie, Jul 28, 2003, in forum: C Programming
    Replies:
    3
    Views:
    482
    E. Robert Tisdale
    Jul 31, 2003
  4. Mr. SweatyFinger

    why why why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    989
    Mark Rae
    Dec 21, 2006
  5. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,249
    Smokey Grindel
    Dec 2, 2006
Loading...

Share This Page