Anyone know about class assignments?

[tkups]

I have a class monster with attributes name and power, and have two objects, lion and dragon. I assign dragon power of 1 and no name. If I give lion the name "lion" then say lion = dragon, will the lion now have a no name? Or will it only overwrite the properties that have a value?

[ThatOneDude02]

Lion would have no name.

[tkups]

Lion would have no name.

Damn it.
Do you know much about pointers? My images are having pointer issues I think.

[ThatOneDude02]

Damn it.
Do you know much about pointers? My images are having pointer issues I think.Pointers are what I understand the least about C++. And I've never made a GUI in C++.

[zethon]

Damn it.
Do you know much about pointers? My images are having pointer issues I think.

What do you need to know?

[tkups]

What do you need to know?

I'm not sure how to explain it, because I lack knowledge of pointers, so I'll just show you the parts that are causing error:
BITMAP *budgieSprite; // I declare a bitmap. It is a pointer, I think.
budgieSprite = load_bitmap( "Budgie.bmp", NULL);//I assign a bitmap to the variable
class monster {//Monster class
int health;
BITMAP *image;// This was a guess that seemed to work. To a point
}ark_Zombie;
ark_Zombie.image = budgieSprite; // This is the part that causes windows errors. I'm guessing its a pointer error. Do you know how I would assign this properly?

[zethon]

I'm not sure how to explain it, because I lack knowledge of pointers, so I'll just show you the parts that are causing error:
BITMAP *budgieSprite; // I declare a bitmap. It is a pointer, I think.
budgieSprite = load_bitmap( "Budgie.bmp", NULL);//I assign a bitmap to the variable
class monster {//Monster class
int health;
BITMAP *image;// This was a guess that seemed to work. To a point
}ark_Zombie;
ark_Zombie.image = budgieSprite; // This is the part that causes windows errors. I'm guessing its a pointer error. Do you know how I would assign this properly?



Are you getting a runtime error or a compile error? It doesn't look like that code should compile. "image" is a private member of class monster.

Class members default to private, struct members default to public.

[tkups]

Are you getting a runtime error or a compile error? It doesn't look like that code should compile. "image" is a private member of class monster.

Class members default to private, struct members default to public.

There should be a "public:" in the monster class, I must have accidently deleted it when I was deleting the unneeded other values. It compiles, but after it runs for about 3 seconds, it gives me a windows error.

[zethon]

There should be a "public:" in the monster class, I must have accidently deleted it when I was deleting the unneeded other values. It compiles, but after it runs for about 3 seconds, it gives me a windows error.

I can't see anything obvious that would throw an error.

What's the error? Have you stepped through to verify that it's that line crashing the app? Check the value of 'budgieSprite' right before it's assigned.

[tkups]

I can't see anything obvious that would throw an error.

What's the error? Have you stepped through to verify that it's that line crashing the app? Check the value of 'budgieSprite' right before it's assigned.

Yeah, I have. The program works wonderfully right now, because I bypassed that line with a bunch of if statements. And the error is "Windows has encountered an unexpected error"

[Ledifni.Sseldog]

Yeah, I have. The program works wonderfully right now, because I bypassed that line with a bunch of if statements. And the error is "Windows has encountered an unexpected error"

Sounds like you might be using a bad pointer value. What does load_bitmap return?

[zethon]

Sounds like you might be using a bad pointer value. What does load_bitmap return?

Even if load_bitmap returns NULL it should still assign it just fine. I'd be curious to look at the entire code. The error isn't in the code posted.

[Ledifni.Sseldog]

Even if load_bitmap returns NULL it should still assign it just fine. I'd be curious to look at the entire code. The error isn't in the code posted.

I didn't say he was getting a NULL pointer value. Depending on the machine, if he gets an illegal pointer value (which is very different from NULL), he could get an error on that line.

[zethon]

I didn't say he was getting a NULL pointer value. Depending on the machine, if he gets an illegal pointer value (which is very different from NULL), he could get an error on that line.

An illegal pointer being what? Just a random address in memory that contains garbage. Even so, the assignment would still work just fine. It would only crash if you tried to access that pointer, but assignment, even to an illegal pointer, will still work.

[tkups]

Well it crashes when the prgram runs, I am not entirely sure why, but directly assigning images works and assigning images based on other images does not work.

[zethon]

Well it crashes when the prgram runs, I am not entirely sure why, but directly assigning images works and assigning images based on other images does not work.

I can take a look at the code if you'd like. I've been programming since the early 80s, I've gotten pretty good at it since then. ;)

From the code you pasted, there's no reason it shouldn't work. Also, "Windows has enountered an unexpected error" suggests that there's something else going on.

[Ledifni.Sseldog]

An illegal pointer being what? Just a random address in memory that contains garbage. Even so, the assignment would still work just fine. It would only crash if you tried to access that pointer, but assignment, even to an illegal pointer, will still work.

No, an illegal pointer value is one that points to either a memory location that doesn't exist, or a memory location that is reserved for the operating system. And assigning a pointer value of that sort can give you an error depending on the C compiler you're using.

[Ledifni.Sseldog]

I can take a look at the code if you'd like. I've been programming since the early 80s, I've gotten pretty good at it since then. ;)

From the code you pasted, there's no reason it shouldn't work. Also, "Windows has enountered an unexpected error" suggests that there's something else going on.

It suggests to me that his C compiler is not designed to prevent him from assigning pointer values that the OS uses, and that he's trying to put an image file in an OS memory block.

[zethon]

It suggests to me that his C compiler is not designed to prevent him from assigning pointer values that the OS uses, and that he's trying to put an image file in an OS memory block.

That doesn't make any sense.

BITMAP *pBMP = load_bitmap(....);
BITMAP *pOther = pBMP;

If load_bitmap returns a pointer to a BITMAP object, then the only thing that is happening on that second line is copying the contents of pBMP into pOther. The contents being nothing more than a number which represents a memory address.

[Ledifni.Sseldog]

That doesn't make any sense.

BITMAP *pBMP = load_bitmap(....);
BITMAP *pOther = pBMP;

If load_bitmap returns a pointer to a BITMAP object, then the only thing that is happening on that second line is copying the contents of pBMP into pOther. The contents being nothing more than a number which represents a memory address.

But how do you know that load_bitmap returns a pointer to a BITMAP object? All you know from the above is that is returns a pointer variable that C treats as a pointer-to-BITMAP. It doesn't necessarily point to a BITMAP, or anything for that matter.

EDIT: Hmm... actually, I think you're right (though that doesn't help to find a solution). C shouldn't allow load_bitmap to return a bad pointer value without throwing an exception.

[zethon]

But how do you know that load_bitmap returns a pointer to a BITMAP object? All you know from the above is that is returns a pointer variable that C treats as a pointer-to-BITMAP. It doesn't necessarily point to a BITMAP, or anything for that matter.

EDIT: Hmm... actually, I think you're right (though that doesn't help to find a solution). C shouldn't allow load_bitmap to return a bad pointer value without throwing an exception.

It doesn't matter what load_bitmap returns. When you say a "bad pointer" I'm guessing you mean "an integer representing a memory address that doesn't contain a bitmap object". Even so, assigning that integer to another variable will work. The only time that would crash the program is if you tried to access the BitMap object.

Remember, a pointer is nothing more than a memory address.

[Ledifni.Sseldog]

It doesn't matter what load_bitmap returns. When you say a "bad pointer" I'm guessing you mean "an integer representing a memory address that doesn't contain a bitmap object".

No, you already asked that and I already said that's not what I meant. A bad pointer, as I said, is one that points to a memory location that does not exist.

That is, say you have 512MB of memory. Each of those bytes is represented by a memory address. Since there are a finite number of bytes, those memory addresses fall within a range: [lowest address]-[highest address]. If a pointer contains a value that is smaller than [lowest address] or larger than [highest address], then it is a bad pointer. The problems with assigning a non-BITMAP memory block to a BITMAP * variable do not apply here. You are not assigning a non-BITMAP memory block, you are assigning a pointer that does not refer to any memory location.

[Ledifni.Sseldog]

Even so, assigning that integer to another variable will work. The only time that would crash the program is if you tried to access the BitMap object.

Not if it's a bad pointer value. Many C compilers detect bad pointer assignments (that is, assignments that fall outside the valid memory range) and automatically fail. The fact that really proves me wrong (which I've already realized) is when and where the error occurred. If it was a bad pointer value (probably caused by incorrectly overloading the load_bitmap function), it would either fail on compile or at the load_bitmap line.

TJP, try assigning a NULL pointer to ark_Zombie.image, tell us what happens. That is, if you're even still working on this.