question about contructors / is this wrong ???
Author
high, this is the third time im typing out this post because i keep forgetting to put a subject or i keep hitting a button or something and losing all the info, so im making it quick
im making a pong clone and have a class called Objects, which hold the x,y width and height of all the images in my game. the contructor looks like this
Objects::Objects(int xPos,int yPos,int w,int h)
{
this->xPos = xPos;
this->yPos = yPos;
this->w = w;
this->h = h;
this->Top_Right_Corner = this->xPos + this->w;
this->Bottom_Left_Corner = this->yPos + this->h;
}
now, when i create a ball object like
Objects ball(400,300,50,50):
this will start my ball in the middle of the screen, and since the w/h is 50, the Top_Right_Corner is 450. but what about when the ball moves? will the T_R_C change with the balls x? or will it stay at 450? ive been using ball.T_R_C instead of writing out ball.x + ball.w because it would make things more clear, but ive been testing it out and getting mixed results. thanks if you can help me.....
[edited by - graveyard filla on February 22, 2004 4:51:24 PM]
varibles only change and you make an assignment to them, so T_R_C will stay the same as it was when you assigned it xPos+w until you reassign it with a new number
Author
hmmmmm, ok that sort of makes me happy that now i know why my collsions is ALL FUKED up. i figured that it woulnt change dynamically (would need pointers for that, right?)
who cares, it would be easier to just write out the ball.x + ball.w then screwing with pointers anyway
[edited by - graveyard filla on February 22, 2004 4:58:43 PM]
who cares, it would be easier to just write out the ball.x + ball.w then screwing with pointers anyway
[edited by - graveyard filla on February 22, 2004 4:58:43 PM]
quote:Original post by graveyard filla
but what about when the ball moves? will the T_R_C change with the balls x? or will it stay at 450?
From what I can tell, it will stay at 450. Everytime your ball.xPos changes, you need to re-calculate the ball.Top_Right_Corner. Same thing applies to the bottom y coordinate.
kingnosis
The constructor function is only called once. If there is anything that must be done frequently, the constructor is not the place to put it.
This situation is exactly the sort of thing that accessor functions are good for. If you make all your member variables private, and create public functions to modify and read those values, then any automatic updating can be performed inside those functions.
Example:
This way, you can only change things like xPos by going through accessor functions like set_xPos(), and therefore Top_Right_Corner will always hold the correct value.
This situation is exactly the sort of thing that accessor functions are good for. If you make all your member variables private, and create public functions to modify and read those values, then any automatic updating can be performed inside those functions.
Example:
class Objects{private: int xPos, yPos, w, h; int Top_Right_Corner, Bottom_Left_Corner;public: void set_xPos(int x) {xPos=x; Top_Right_Corner=xPos+w;}; int get_xPos() {return xPos;}; // similar functions for all variables...};This way, you can only change things like xPos by going through accessor functions like set_xPos(), and therefore Top_Right_Corner will always hold the correct value.
get_xPos in your example really should be constant, and you don''t need to end your functions with semicolons.
quote:Original post by smart_idiot
get_xPos in your example really should be constant, and you don''t need to end your functions with semicolons.
Yes it should be constant, but I didn''t want to confuse the issue, and besides, I can never remember where to put the const. If I got that wrong, it would really confuse things. It works as it is, and it demonstrates the concept.
I didn''t know the semicolons were optional. I guess it makes sense though.
This is just a suggestion, but I like to group coordinates in a separate class, for ease of use and understanding.
Operator overloading (what I''m doing with operator+ above) may be a bit advanced for you, but the thing to get out of this is it''s a good idea to use a 2d vector(or coordinate) object when you have a 2D concept. Also, rather than store the other vertex in a variable, I made the calculation dynamic (ie, made it a function) so that it''s recreated every time you need it. This might be slower than storing it in a variable (or it could be faster) but for now it''s less error-prone.
Now, if you changed the size, position, whatever, GetBottomRight will always return the correct value.
PS: some of my ranting might have stepped into the realm of personal preference, so do what you will.
class VI2D //2d integer vector{public: int x, y; VI2D( int x_, int y_ ) { x = x_; y = y_; } VI2D operator+( VI2d& v ) const { return VI2D( v.x + x, v.y + y ); }};class Objects{private: VI2D pos; VI2D size;public: VI2D GetPos(); VI2D GetBottomRight() { return pos + size; //adding 2 vectors }};Operator overloading (what I''m doing with operator+ above) may be a bit advanced for you, but the thing to get out of this is it''s a good idea to use a 2d vector(or coordinate) object when you have a 2D concept. Also, rather than store the other vertex in a variable, I made the calculation dynamic (ie, made it a function) so that it''s recreated every time you need it. This might be slower than storing it in a variable (or it could be faster) but for now it''s less error-prone.
Now, if you changed the size, position, whatever, GetBottomRight will always return the correct value.
PS: some of my ranting might have stepped into the realm of personal preference, so do what you will.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
